💡Про технические собеседования нетехническими сотрудниками
Для экспериментов и поддержания себя в форме, приходится часто проходить технические собеседования. Пусть даже и нет явной цели в получении новой работы. Это действительно помогает держаться в тренде актуальных технологий и не поддаваться окоренению сидя на одном месте.
Но что же не так? Дело в том, что ИТ-компании в край уже обленились. Дошло до того, что техническое собеседование с вами проводит сотрудник, который не имеет соответствующих навыков и более того, техническим сотрудником не является. Это нелепая попытка выполнить первичную фильтрацию на этапе общения с HR или рекрутером. Ранее, в этом не видел ничего плохого, просто ссылаясь на выбор компании в том как искать кандидатов. Другое дело, что похоже эта нелепость уже превращается в тренд.
За последние несколько лет, мне пришлось неоднократно встретить такой подход. И вот буквально две недели назад произошло то же самое в большой известной компании, имя которой не буду раскрывать по соображениям рабочей этики.
Парнишка из HR задавал мне вопросы, ответы на которые искал из списка лежащего перед ним. Но когда он задал вопрос: "Расскажите среднюю скорость выполнения операции HashMap", я разумеется ему ответил O(log n) ссылаясь на коллизию в виде дерева. На что последовал ответ: "Неверно, средняя O(n)". На мой вопрос: "Почему так, когда HashMap имеет O(n) худшей сложностью? (Разумеется с приведением всех обоснований)", последовал очень краткий ответ: "Это зависит от реализации."
Реализации какой, Карл? LinkedHashMap и немногочисленных кастомизаций HashMap которые в широком смысле не применяются или все-таки реализованного класса HashMap? :)
Всё это заставляет скрипеть зубами. Надеюсь, что такое не укоренится и все-таки людям начнут платить деньги за их непосредственную работу, а разработчики начнут воспринимать собеседование как часть их повседневной работы, за которую им между прочим тоже платят и не заставляют перерабатывать.
🌟 Какие у тебя ощущения после такого псевдо-технического интервью?
⬇️ Пиши в комментариях
Макс Добрынин
Для экспериментов и поддержания себя в форме, приходится часто проходить технические собеседования. Пусть даже и нет явной цели в получении новой работы. Это действительно помогает держаться в тренде актуальных технологий и не поддаваться окоренению сидя на одном месте.
Но что же не так? Дело в том, что ИТ-компании в край уже обленились. Дошло до того, что техническое собеседование с вами проводит сотрудник, который не имеет соответствующих навыков и более того, техническим сотрудником не является. Это нелепая попытка выполнить первичную фильтрацию на этапе общения с HR или рекрутером. Ранее, в этом не видел ничего плохого, просто ссылаясь на выбор компании в том как искать кандидатов. Другое дело, что похоже эта нелепость уже превращается в тренд.
За последние несколько лет, мне пришлось неоднократно встретить такой подход. И вот буквально две недели назад произошло то же самое в большой известной компании, имя которой не буду раскрывать по соображениям рабочей этики.
Парнишка из HR задавал мне вопросы, ответы на которые искал из списка лежащего перед ним. Но когда он задал вопрос: "Расскажите среднюю скорость выполнения операции HashMap", я разумеется ему ответил O(log n) ссылаясь на коллизию в виде дерева. На что последовал ответ: "Неверно, средняя O(n)". На мой вопрос: "Почему так, когда HashMap имеет O(n) худшей сложностью? (Разумеется с приведением всех обоснований)", последовал очень краткий ответ: "Это зависит от реализации."
Реализации какой, Карл? LinkedHashMap и немногочисленных кастомизаций HashMap которые в широком смысле не применяются или все-таки реализованного класса HashMap? :)
Всё это заставляет скрипеть зубами. Надеюсь, что такое не укоренится и все-таки людям начнут платить деньги за их непосредственную работу, а разработчики начнут воспринимать собеседование как часть их повседневной работы, за которую им между прочим тоже платят и не заставляют перерабатывать.
🌟 Какие у тебя ощущения после такого псевдо-технического интервью?
⬇️ Пиши в комментариях
Макс Добрынин