Комментарии 143
Спасибо за статью, от себя добавлю - пару раз интервьюировался с роботом, обленились до того, что даже уже не девочки из кадров читают тебе вопросы, а железяка. (На самом деле уже сильно настораживает такое отношение работодателя к соискателям).
От стиля написания статьи осталось ощущение, что проблема все же в авторе.
Так-то можно 20 лет вариться в "собственном соку" в IT и оказаться действительно невостребованным в современной разработке.
По своему опыту скажу, что тоже, бывает, не прохожу какие-то собеседования, но это скорее на уровне погрешности - в основном проблем с этим нет. (разработчик, 15+ лет стажа)
Есть такое ощущение.
Но требования растут и причиной отказа становятся вещи, которые раньше были просто в разделе "Желательно" или "Будет здорово, если вы умеете еще:"
Ну и действительно есть туповатые вопросы в стиле что будет i + ++i - i++
Ну и действительно есть туповатые вопросы в стиле что будет i + ++i - i++
Как-то этот вопрос обсуждался в одном паблике вконтакте. Так вот ответов, которые можно было зачесть за правильные, почти не было. Так что не бывает туповатых вопросов, но есть туповатые ответы.
Решение одно)
Просто какой вопрос, такие и ответы)))
В вашем вопросе даже не указано, какой это язык программирования, так что ответ неоднозначен уже поэтому. Ну и самый "убедительный" аргумент в пользу того, что вопрос глупый -- это слиться не дав на него ответа.
Какой бы язык нибыл один и тот же код даст только один ответ для конкретного языка (ессно, не беря многопоточку и гонку).
Но если вы задаете такой вопрос своим кандидатам, то мягко говоря это не разумно.
"С вами свяжется наш HR" (c)
На позицию C++ разработчика вы не прошли.
Повезло что пишу на java и не ищу работу)))
Никогда за 25 лет опыта на Java не писал такие выражения. Из интереса проверил. Предсказуемо, если подумать. Теперь буду джунов подбадривать и этим вопросом )
Не стоит. Этот вопрос имеет практическую пользу для найма, в основном, только в контексте C/C++, и он намного более глубок чем банальный приоритет операций. Если нарветесь на кандидата, знающего язык лучше вас, то может случиться конфуз.
Кстати, когда-то в большой небезызвестной компании любили просить кандидатов реализовать аналог shared_ptr. Так вот интересно, ни один из спрашивающих не смог правильно объяснить настоящее его устройство.
Джунов подбадривают не для найма, а чтобы мозги шевелились. В контексте Java надо помнить спецификацию, UB здесь нет. Но кто ж её помнит в деталях, которые в быту не нужны. А джунам полезно для расширения кругозора. Оно и мне интересно было.
Это и в С не имеет смысла. Правильный ответ один - так писать нельзя.
Ну я как бы и написал "C/C++". Но ответ "так писать нельзя" скушен для собеседования, гораздо лучше звучит "так писать нельзя потому что...", и вот тут объяснение причин будет различным даже с точки зрения разных версий стандарта. Вопрос позволяет дать развернутый ответ и продемонстрировать знания выше среднего, и именно этого я бы хотел от кандидата.
На мой взгляд, это прекрасный вопрос, и ответ у него тоже однозначный:
Это пример неуточненного поведения и грубой ошибки в коде. Здесь нет смысла обсуждать результат, так как он может различаться в зависимости от платформы, компилятора, и даже разных запусков программы на одной и тоже же машине.
Любой программист на C++, например, обязан это знать.
У этого вопроса один минус: он очень заезженный, но если закрыть на это глаза, то он отлично подойдёт для собеседования джуна: посмотреть, знаком ли человек с концепцией такого поведения и как он рассуждает. Да и для мидла, в целом, вопрос может подойти как один из первичных примитивных фильтров -- на случай, если на собеседование на мидлла пришел человек с недостаточными компетенциями.
Вот и я о том же. Хотя даже приведенный вами ответ не полный, т.к. там все-таки подразумевается, что какой-то результат будет, в то время как компилятор волен выкинуть этот кусок кода ко всем чертям. То есть данный вопрос позволяет кандидату рассказать о том, что такое "назальные демоны" во всех красках и с примерами из собственного опыта, что может дать дополнительные очки.
Мой любимый вопрос, на который кандидаты расплевываются даже не представляя насколько они далеки от правильного решения, это про дождь в Сиэтле (я такого вопроса на собесах не задаю, просто люблю почитать его обсуждения в форумах). Напомню, вопрос в том, чтобы оценить вероятность дождя в Сиэтле, куда высобираетесь лететь. Вы позвонили трем незнакомым друг с другом друзьям, которые там живут, и все они ответили, что да, дождь идет. Одна беда, как вы знаете по прошлому опыту, каждый из этих друзей неисправимый шутник, и с вероятностью 1/3 он вас разыгрывает.
Ну вот автор про таких собеседующих и пишет)))
дык не 8/27 разве?
Даю подсказку. Что будет если "вероятность дождя в Сиэтле" заменить на "вероятность встретить динозавра в Сиэтле"? Все трое подтвердили, что видели. Тоже 8/27?
Для динозавров, естественно, 1/2
А в целом — мы про вероятности или про что? Если "про что", то разве в жизни бывают придурки, врущие ровно один раз из трёх? Если же про вероятности, то что не так с дождём в Сиэтле?
UPD понял прикол. Ну, скажем, я не знаю размеры Сиэтла, но в моём Новосибирске примерно в километре от меня зачарованное место на дороге, где довольно часто с одной стороны может идти дожь, а с другой — сухо. Поэтому, поскольку люди незнакомы друг с другом, можно предположить, что живут они в разных местах, где-то идёт, где-то не идёт. Да, задачка немножко сложнее. Считать лень )) Но внутренняя убеждённость в 8/27 пока жива
Придурков, врущих ровно один раз из трех, легко эмулировать технически. За определенную оплату я могу побыть вашим "другом", смотреть за окно, подбрасывать кость и врать про дождь если выпадет 1 или 2. В более реалистичном сценарии можно представить себе датчик, который посылает верную информацию, но из-за помех бит информации может быть инвертирован.
В контексте задачи можно считать, что дождь либо идет во всем Сиэтле, либо во всем Сиэтле сухо.
Ответ 8/27 не принимается как верный.
В контексте задачи ничего не говорится ни про одновременность дождя во всём Сиэтле, ни про вероятность дождя в Сиэтле вообще, ни про то, что в момент моего звонка придурки вообще находятся в этом самом Сиэтле и не отвечают про какой-нибудь Пхукет или Хургаду, где проводят отпуск. Стало быть, я могу значения выбирать|оценивать по усмотрению или уточнять при желании. Был у нас такой класс задач на вступительных, вида "оцените натяжение бельевой верёвки".
Впрочем, я не собеседуюсь, поэтому дальше углубляться не хочу.
Есть программист, за плечами которого более 20 реализованных проектов
различной сложности и нагрузки. ... Программист ищет работу. И проходит собеседования. И...и не может их пройти!
Вы не забывайте, что иногда 10 лет опыта это 1 год, повторенный 10 раз.
По моему опыту проведения собесов каждый третий такой кандидат с регалиями это уставший человек без всякого желания учиться и выходить из зоны комфорта. Вот именно это "а мне и так норм, а я и так все знаю, да я в 96 году драйвер на линукс уже писал" и становится причиной отказа.
Очень странная статья. Не знаю на какой уровень вы претендуете, но вопросы вполне адекватные.
> чему будет равно (true + true * 5) - 2?
Вопрос, чтобы вас расслабить, посмотреть понимаете ли вы, как происходит конвертация типов в вашем языке.
> Как бы вы реализовали архитектуру
Нормальный вопрос для уровня сеньора или техлида. Что в нем не так? Такой вопрос задается, знает ли соискатель, как можно управлять нагрузкой на сервисы, проводить масштабирование. Какие технологии для этого соискатель знает и может использовать.
> Какие вы знаете типы данных\что такое ООП?
Скорее всего этот вопрос вам задали, чтобы прощупать нижнюю границу, если на предыдущий вопрос вы ответить вразумительно не смогли. Я так же на собеседовании калибрирую уровень соискателя. Начинаю со средней степени вопросов, потом в зависимости от ответов либо усложняю, либо упрощаю следующие. Тут цель не доказать, что "соискатель с его-то опытом работы точно знает меньше". А выяснить реальный уровень знаний. Часто бывает, что соискатель претендует на условного мидла, а по хард скиллам может быть и сеньором, так и джуном. "Линейки" грейдов в разных компаниях - разные.
> http - это набор аргументов вовьюхе и возврат значений.
Неплохо. А процессор - это ящик с проводами под столом. Для успешной коммуникации в команде, нужен одинаковый понятийный словарь. А если для вас http или api - это набор аргументов и возврат значений, то вас переучить будет сложно, если вообще возможно. В итоге будет в тасках постоянная путаница. Будет постоянное недопонимание. А зачем это будущему лиду?
Ну и в целом, если вы отвечали с раздражением на собеседовании, то понятно почему вам отказ. И точно не по тем причинам, которые вы сделали в выводе. Сейчас рынок работодателя. И мне, как нанимающему менеджеру, проще найти точно такого же по скилам сотрудника, как у вас, но которые не раздражается от любого вопроса.
> Но если так получилось, что вы ответили на20 вопросов из 20, то результат собеседования будет отрицательным. КАКТАК?
Собеседование - это не тест, где ответил 20 из 20 и принят на работу. Кроме хард скиллов очень важны и софт скиллы. Поверьте, работать с хамоватым и вечно недовольным сотрудником - очень тяжело.
чему будет равно (true + true * 5) - 2?
Вопрос, чтобы вас расслабить, посмотреть понимаете ли вы, как происходит конвертация типов в вашем >языке.
Не нужно выдумывать. Этот вопрос был найден в статье 100 вопросов python программисту. Эти 100 вопросов собеседующее лицо скачало и просто озвучивало
Какие вы знаете типы данных\что такое ООП?
Скорее всего этот вопрос вам задали, чтобы прощупать нижнюю границу, если на предыдущий вопрос
Да-да, нижнюю границу. При этом было 20 уточняющих вопросов по проектам, которые указаны в CV. А потом резко нужно прощупать нижнюю границу соискателя
http - это набор аргументов вовьюхе и возврат значений.
Неплохо. А процессор - это ящик с проводами под столом. Для успешной коммуникации в команде, >нужен одинаковый понятийный словарь. А если для вас http или api - это набор аргументов и возврат >значений, то вас переучить будет сложно, если вообще возможно. В итоге будет в тасках постоянная >путаница. Будет постоянное недопонимание. А зачем это будущему лиду?
Да-да, ежедневно весь пул задач забит именно этим
Собственно, что и требовалось доказать. Всего хорошего.
У вас весь текст пронизан обидой и какими-то внутренними страхами и предубеждениями. Вы сами кого-то собеседовали? Какой у вас там Вариант 1 или Вариант 2? Описанные варианты присутствуют при собеседовании менеджеров, а не программистов. Это менеджер боится что кандидат заберет его работу и станет его начальником, а программист только рад отдать часть своей работы, потому что у него всегда найдется еще.
Человек, который разрабатывает web-сервис и не понимает что такое http, то это либо Джун либо Джун...
В чём проблема не попасть в компанию с тараканами и сложным трудоустройством? Это же подарок судьбы.
Да. Подарок судьбы. Но в большинстве случаев начальство не знает о сложном трудоустройстве. Дают вполне адекватному в работе сеньору Васе задание "найти себе коллегу" и Вася выполняет это задание. Но выполняет он его так, как ему хочется, а не как лучше для фирмы
По моему опыту, в современном бизнесе вообще все выполняется так, как хочется "Васе", а не так, как нужно бизнесу. Менеджеры свои обязанности "делегировали" и оставили за собой только обязанность получать зарплату / премии. Потом они увольняют последнего человека, знающего X и через несколько месяцев, внезапно, обнаруживают, что как делать X никто не знает. Или, например, обнаруживают, что сервис компании работают на личном аккаунте уволенного разработчика. Оба случая реальны и из моей практики.
В ходе собеседования постепенно возникает сначала нечто неуловимое, а затем все более определенное — интересно/легко ли нам будет работать с этим человеком или нет. Естественно, хочется получить определенность по возможности быстрее, поэтому могут задаваться вопросы про true плюс два или про архитектуру приложения, чтобы увидеть хотя бы, как вы размышляете в прямом эфире, насколько у вас живая мысль, не включается ли у вас конфликтность («А как мне это поможет в работе?»).
По вашему тексту можно сделать косвенный вывод, что вам приходилось преодолевать некие проблемы социализации. Возможно, вы перешли в такую фазу, когда они еще не преодолены, но вам достаточно комфортно и нет желания что-то менять. Заметно, что вы делаете особенный упор на формальное соответствие критериям, однако в отборе кандидатов это не единственный фактор. Мне кажется, что проблема где-то в этой зоне. Если вы когда-нибудь окажетесь в положении нанимающей стороны, то сможете это увидеть наиболее очевидным образом.
чтобы увидеть хотя бы, как вы размышляете в прямом эфире, насколько у вас живая мысль, не >включается ли у вас конфликтность
Это всё очень интересные и красивые слова. Я на собеседованиях никогда не конфликтую. Вопрос «А как мне это поможет в работе?» - это не конфликт, а вполне здравый и адекватный вопрос. Тут не угадаешь. Один хочет посмотреть живую мысль, а другому нравится, когда говорят "не знаю" и не гадают на кофейной гуще(были такие реальные фразы от собеседующего лица) при отсутствии знаний в предметной области
Про социализацию - промахнулся. Я вполне общительный человек. В этом проблемы нет
Я собеседовал людей. Оказывались вполне адекватными
Хорошо. Мое мнение — для большинства собеседующих встречный вопрос насчет «как поможет в работе» будет тревожным звоночком. Ответ про HTTP тоже. Здесь не нужен ни один из перечисленных вариантов, а нужен просто нормальный ответ на человеческом языке.
По вашему тексту — капслок в тексте — не очень хороший маркер.
На собеседовании я полностью провалил интервью с тимлидом. Я, практически, ни одной задачи не решил. И очень удивился, когда меня позвали на следующий этап.
Скоро два года, как здесь работаю. И это офигенно. Ну а когда тимлида спросил про его странные задачи, он ответил, что я не должен был их решить, ему интересно было, как я буду пытаться их решать.
В ходе собеседования постепенно возникает сначала нечто неуловимое, а затем все более определенное — интересно/легко ли нам будет работать с этим человеком или нет.
Я описал в статье твой случай
С точки зрения собеседующего:
Тривиальные вопросы типа "на джуна" очень часто нужны, чтобы понять общий уровень. Я не одного сеньора отправил с собеседования, потому что люди не знали, чем в C# отличаются разные способы объявить переменные. (Предполагаю что в крупные компании люди прут на собеседования, авось проскачу)
Вопросы без практической пользы, типа "(true + true * 5) - 2" нужны не для того, чтобы вы на них посмотрели и дали ответ. Скорее всего от вас хотят увидеть умение думать и рассуждать, покажите, что вы это умеете.
Я часто даю на собеседование задание на "написать код", только даю что-то нетривиальное, что по памяти очень сложно написать. При этом сразу говорю, что можно гуглить, главное решить задачу. При этом на самом деле мне важен не результат, а важно увидеть как человек думает, насколько переусложняет решение, может ли он сформулировать вопрос и найти ответ в интернете.
Есть технические вопросы на которые многие кандидаты прям на собеседовании реагируют типа "что за херню вы меня спрашиваете, это не имеет практической пользы". Это признак того, что в реальных задачах человек также будет реагировать на задачи типа "что за фигню вы меня заставляете делать, я хочу задачи поинтереснее". Естественно, что такие кандидаты получают отказ, т.к. они потенциально конфликтны.
С точки зрения собеседуемого:
Подходите к собеседованию не как к тесту, а как к дружеской беседе. На позитиве. Компания смотрит на вас, но и вы смотрите на компанию. Всё должно быть взаимно.
Если понимаете, что на собеседовании вас спрашивают дичь - прямо об этом скажите и попытайтесь объяснить спокойно свою позицию. Предложите тем, кто вас собеседует техническую тему которая на ваш взгляд лучше показывает ваши технические навыки. Это действительно работает иногда. Если это не помогает, просто отнеситесь к этому как дополнительному опыту. Но таких компаний единицы.
Если что-то не знаете - прямо об этом скажите. Попытайтесь порассуждать, сделать предположение об ответе, пусть даже он будет неправильный. Главное не молчите. Это не экзамен.
С другой стороны, многие не зная ответ пытаются заговаривать зубы и без остановки несут какой-то бессвязный бред без конкретики. Так тоже не надо делать.
В случае удалённых собеседований всегда общайтесь с камерой по умолчанию. Если ваш собеседник без камеры, попросите её включить (а лучше заранее договориться об этом). Никто не захочет брать на работу аватарку, да и вам не очень захочется потом работать с людьми, которых вы в глаза не видели.
Подходите к собеседованию не как к тесту, а как к дружеской беседе. На позитиве.
Ага, щас. Человек пришел к вам по сути просить денег и выполнять задания, и будь он хоть трижды позитивный и общительный это его уже подсознательно ставит в подчиненную позицию.
Если понимаете, что на собеседовании вас спрашивают дичь - прямо об этом скажите и попытайтесь объяснить спокойно свою позицию.
А потом
Естественно, что такие кандидаты получают отказ, т.к. они потенциально конфликтны.
Интересно, почему кандидаты не хотят объяснять свою позицию? Загадка...
Если что-то не знаете - прямо об этом скажите. Попытайтесь порассуждать, сделать предположение об ответе, пусть даже он будет неправильный. Главное не молчите. Это не экзамен.
Конечно не экзамен. На экзамене вопросы известны заранее. А тут даже рассуждать опасно, вдруг окажется, что нужно давать только точный ответ?
Да и вообще поразительная ситуация. Человек делится обратной связью, указывает на недостатки, говорит как можно проводить собеседования, что бы было лучше всем, но обязательно набежит куча рекрутеров и начнет объяснять, что вот только именно так и надо собеседовать и никак иначе. Не, ну серьезно, вы на самом деле хотите выглядеть непонятно чего хотящими людьми задающими идиотские вопросы?
Человек (автор), к сожалению, указывает совсем не на недостатки собеседований, а на какие-то свои проблемы, вероятно с софт скиллами, из-за которых получает отказ за отказом. И другой человек, которому отвечаете вы, мягко пытается это объяснить.
Ага, щас. Человек пришел к вам по сути просить денег и выполнять задания, и будь он хоть трижды позитивный и общительный это его уже подсознательно ставит в подчиненную позицию.
Если человек придёт, как вы говорите "просить денег", то значит он через месяц может уйти, потому что ему в другом месте предложат больше. Не удивительно, что такие люди не получают офферы.
В моём понимании разработчик приходя на собеседование с одной стороны должен уметь продать свои знания и опыт (и да, это навык, который ничего общего с реальной разработкой не имеет), но с другой стороны работодатель также должен продать этому разработчику свой проект, заинтересовать, показать, что человек при должной инициативе может расти в компании.
Поэтому я не согласен, что соискатель тут в какой-то подчинённой позиции, только если он себя сам не ставит в такое положение.
А потом
Есть большая разница
Когда на "неудобный" вопрос соискатель отвечает односложно и ждёт следующего вопроса, это может восприниматься как "от**итесь от меня" и это воспринимается как токсичность.
Или если человек спокойно и аргументировано объяснит свою позицию это будет восприниматься совершенно иначе.
Допустим пример: вам дают листочек и говорят: "напиши сортировку пузырьком по памяти".
Можно ответить: "Вы сами то часто код на листочке пишите? Какое практическое значение сортировка пузырьком вообще имеет? Вы что, часто её используете?"
Или можно сказать: "Я не думаю что писать код на листочке у меня получится, редко приходится таким заниматься. Могу на листочке схематично нарисовать и объяснить как это сортировка работает. Если дадите ноут, могу в IDE попробовать накидать алгоритм. Устроит такой вариант?"
Скорее всего первый ответ будет воспринят негативно, а второй более позитивно.
но обязательно набежит куча рекрутеров и начнет объяснять, что вот только именно так и надо собеседовать и никак иначе.
И я вовсе не рекрутёр, а разработчик, который частенько находится как с одной, так и с другой стороны стола на собеседованиях.
Это сугубо ваше восприятие, что кандидат в слабой позиции. Де факто это просто разговор продавца и покупателя.
Это признак того, что в реальных задачах человек также будет реагировать на задачи типа "что за фигню вы меня заставляете делать, я хочу задачи поинтереснее".
Это далеко не признак.
Есть технические вопросы на которые многие кандидаты прям на собеседовании реагируют типа "что за херню вы меня спрашиваете, это не имеет практической пользы". Это признак того, что в реальных задачах человек также будет реагировать на задачи типа "что за фигню вы меня заставляете делать, я хочу задачи поинтереснее". Естественно, что такие кандидаты получают отказ, т.к. они потенциально конфликтны.
Если кандидат подчеркнул что это не имеет практической пользы, это не всегда означает что он конфликтный, возможно это означает что вы действительно фигню спрашиваете. По поводу неинтересных задач ситуация похожая и тут важно на этапе собеса согласовать ожидания по задачам, но опять же о конфликтности человека это ничего не говорит.
Я не одного сеньора отправил с собеседования, потому что люди не знали, чем в C# отличаются >разные способы объявить переменные
Если человек работает в отрасли более 3-х лет и не может ответить на какой-то вопрос, скорей всего это редко применяется в работе. И только. Т.е вопрос оторванный от реальности
Вопросы без практической пользы, типа "(true + true * 5) - 2" нужны не для того, чтобы вы на них >посмотрели и дали ответ. Скорее всего от вас хотят увидеть умение думать и рассуждать, покажите, что >вы это умеете.
Человек с опытом работы решает все задачи, которые перед ним ставятся. Зачем это перепроверять? Все вопросы всегда проходят через технологический цикл. Думать и рассуждать человек умеет, раз он более 3-х лет работает. Логика-с.
Во-первых, из того, что человек где-то работал 3 года не следуют ни его квалификация, ни умение рассуждать. Приходили ко мне на собес товарищи с 5+ годами опыта на Java и рассказывали, что в Java строки мутабельные. Будете утверждать, что за 5 лет им как-то не пришлось со строками столкнуться?
Ну а во-вторых, не всегда всё что у кандидата написано в резюме является правдой.
Я вам так скажу, если человек работает в отрасли более 3-х лет, но не может объяснить, чем в C# отличаются:
int x1 = 42;
int? x2 = 42;
var x3 = 42;
object x4 = 42;То скорее всего он просто на***дел в резюме. Вписал туда проекты и задачи которые возможно решали его коллеги. Именно за этим и даются задания на собеседовании.
Мне в linkedin несколько раз пытался добавиться чувак, с которым я когда-то работал. Он был на позиции middle, но с трудом до неё дотягивал и был скорее средним между junior и middle. Но в linkedin он, о чудо, senior!
А что делать? Тех, кто проводит собеседования не изменишь, тут только приспосабливаться, по-возможности спокойно воспринимая отказы. Где отказали потому что реально не хватает технических знаний - доучивать, принимать к сведению. Четыре года назад проходил собесы (тоже больше 10 лет опыта). Где-то 3-4 собеса были реально странными. На паре собесов могу признать, что опыта не хватило (может быть, узкоспециализированного, но всё же). На 7-ом собесе получил оффер (но сам отказался по ряду причин). В итоге пошёл в компанию, где собес был просто в форме беседы, вообще без технических вопросов и успешно там отработал 3 с лишним года :) Так что с автором всё же во многом согласен. Но опять же - вряд ли можно с этим что-то сделать.
Я бы рекомендовал не относится к отказам как личному поражению или результату недооценки прошлых заслуг. У интервьюера вообще нет такой задачи как оценка ваших прошлых достижений. Ему нужно найти подходящего работника. Понятно, что требования у всех разные. Но он имеет точно такое же право считать вас неподходящим как и вы их предложение.
Хороший вы специалист или нет это оценочное суждение, справедливость которого зависит от контекста. Мы довольно сильно привязываемся к среде, где достаточно долго живём - как команда Летучего Голландца вростая в борта компаний, стран, коллег и т.п. Будучи незаменимым и почитаемым персонажем в одном месте, нужно быть готовым к тому, что на вас будут смотреть как на чудовище в другом. Это вовсе не потому, что процессы найма плохие или кто-то не прав - просто вы разные.
Меня больше беспокоит не отсутствие офера, а отсутствие обратной связи.
Первый вопрос важен для языков с динамической типизацией. Я бы сначала акцентировал внимание на том, что ни в коем случае нельзя допускать ситуации когда идёт счёт между разными типами. Такие кейсы требуется закрывать линтерами и тестами.
Далее бы ответил почему и какой был бы результат.По второму вопросу стало самому интересно какие могут быть варианты system design. Сам в основном сталкиваюсь с обратной ситуацией.
Кому не лень, можете расписать как бы вы решили проблему аплодинга больших файлов (актуально на примере видео хостинга)? Заранее спасибо)Третий вопрос чудесный. В Go вероятно был бы правильный ответ: типы с указателями и без. Это очень важно знать, иначе чревато серьёзными проблемами на проекте.
cкажите пожалуйста, чему будет равно (true + true * 5) - 2?
А у вас такое реально проходит кодревью и попадает на прод? До свидания!
Я с вами от части соглашусь, так как давно привык к тому, что навык прохождения собеседований это отдельный навык который прокачивается тоже отдельно. Но, безусловно это очень плохо. Тебя тестируют как компьютер который либо проходит, либо не проходит определенный тест, попутно совершенно забывая, что собеседующие работают с людьми, а не с машинами. Часто на собеседование моделируется ситуация, что нет интернета, заблокированы яндекс и гугл...и все что у тебя есть, это твоя память...Попутно забывая, что если такие случится, то их компания будет не нужна вообще и таких странностей очень много..
Совет тем кто проводит собеседования: собеседования это не экзамен, а свидание. Лучше взять на работу приятного человека, у которого есть пробелы (обращаю внимание ПРОБЕЛЫ, а не нулевые знания), чем взять мудака с энциклопедическими знаниями, с которым вам потом будет крайне сложно работать.
P.S IT требует постоянного развития. Если вы работаете только с 9 до 18 и потом не занимаетесь самообразованием, в этой сфере делать нечего . Еще несколько лет назад в вакансиях для бекендеров очень редко можно быть встретить docker, kubernates и разного рода инструменты для devOps-ов, cloud и т.д....Сейчас это must-have
Если вы работаете только с 9 до 18 и потом не занимаетесь самообразованием, в этой сфере делать нечего.
Только заниматься самообразованием надо в рабочее время. После него мозгу надо отдыхать. Иначе прощай кукуха.
Кукуха едет если ты занимаешься нелюбимым делом. А если любимым -- то мозг отдыхает уже от смены рабочего на пет проект. Отдыхать, конечно, нужно, но у увлеченных людей все-таки большая фора.
мозг отдыхает уже от смены рабочего на пет проект.
Я тоже так думал. А потом...
Ну в целом-то да, лучше заниматься самообразованием в рабочее время. Но есть два "но": не каждый работодатель этому рад, и не любую технологию так позволят изучить. Поскольку самообразование нужно в первую очередь самому работнику, то дальше выбор невелик: либо выгореть на работе, либо рискнуть кукухой и самообразовываться, либо бросить этот IT к черту.
"Если вы работаете только с 9 до 18 и потом не занимаетесь самообразованием, в этой сфере делать нечего" - актуально для людей без семьи, детей и домашних дел работать и еще после работы штудировать мануалы.
Еще несколько лет назад в вакансиях для бекендеров очень редко можно быть встретить docker, kubernates и разного рода инструменты для devOps-ов, cloud и т.д… Сейчас это must-have
Ещё с десяток технологий и людям с семьёй или у которых есть ещё какое-то хобби, кроме IT, вообще нечего будет делать в этом IT :/
Еще несколько лет назад в вакансиях для бекендеров очень редко можно быть встретить docker, kubernates и разного рода инструменты для devOps-ов, cloud и т.д....Сейчас это must-have
Вы серьезно так думаете? Вы не подумали, что в программистов пытаются впихнуть обязанности девопса? Когда меня на собеседованиях такое спрашивают - я отвечаю, что могу таким заниматься, но лучше взять настоящего devops, а я хороший программист.
Уважайте себя и знайте себе цену
К собеседованию в IT надо готовится как к спортивному мероприятию, а результата ожидать как в азартной игре.
Если вы воспринимаете это близко к сердцу, постарайтесь абстрагироваться. При решении об оффере факторов десятки, начиная от степени необходимости закрыть позицию, заканчивая цветом носков соискателя. Не будучи "внутри" не угадать.
Я знаю реальный случай отказа кандидату из-за того, что он пришел на собеседование в шляпе...
Главное после всех узких вопросов потом сунуть на проект с другим стеком :)
Да не в возрасте дело.
Автор вроде как пишет про много лет разностороннего опыта, а значит, наверное, претендует на сеньерную позицию, и тут же в том же тексте выдает за проблемный самый обычный large scale system design вопрос.
Есть медиасервис, который даёт пользователю закачивать файлы больше 30гб на сервер. Как бы вы реализовали архитектуру? Какой бы вы использовали стек? Как бы вы реализовали API?
Если автора, наверное претендующего на сеньерную позицию, такие вопросы удивляют, раздражают, вызывают ступор, а тем более если автор открыто выражает свою неготовность решать подобные задачи на интервью в реальном времени (а это ведь даже не задача, это просто приглашение к как правило довольно интересному диалогу, который позволяет интервьирующему и интервьюируемому лучше друг друга понять), то это автоматический отказ в 95% случаев.
Ну и там еще несколько тревожных сигналов в тексте.
неготовность решать подобные задачи на интервью в реальном времени
Есть люди, которые не могут выдавать ответы на такие задача в реальном времени. Тем более в условиях стресса. Таким людям нужно несколько часов походить, повертеть в руках любимый предмет, а потом они выдадут решение, которое сформировалось у них в голове. Означает-ли это автоматически, что это плохие специалисты?
Есть люди, которые не могут выдавать ответы на такие задача в реальном времени
Если человек не может даже начать обсуждение таких вопросов без многочасового верчения любимого предмета, то да, он так себе специалист. Тут как бы никто не требует вживую за 15 минут составить дизайндокумент и план работ, тут требуется чтобы человек хотябы начал выдавать какие-то мысли.
Ловите эффективного менеджера. Очень безаппеляционное утверждение.
Очень безаппеляционное утверждение
Это называется мнение. Вы спросили - вам ответили.
Ваше мнение является ошибочным и легко опровергается. Имеется реальный человек, который никакое решение не может выдать в реальном времени. Этот человек разработал и поддерживает систему, приносящую компании доход. Вы действительно продолжите утверждать, что этот человек не является хорошим специалистом, на том основании, что он не может немедленно выдать какое-то решение, без предварительного обдумывания?
Суждение о том хороший специалист или плохой - оценочное. В таком суждение не достижима полная объективаность. И для таких суждений даже придумали специальный термин - мнение.
И да, я считаю, что если человек не готов в условиях собеседования (т.е. в условиях события о котором кандидат заранее знал) начинать обсуждать такую простую задачу, то это плохая для специалиста черта. Я бы такому кандидату отказал.
PS Никто кроме вас тут не требует немедленно выдать решение задачи. Требуют начать её решать. А вы упорно игнорируете эту разницу.
А вы упорно игнорируете эту разницу.
Вы тоже упорно игнорирует, что для таких людей начать решать задачу - означает, походить и повертеть в руках любимый предмет, прежде, чем в голове оформит я хоть что-то, что можно выразить словами.
Суждение о том хороший специалист или плохой - оценочное.
Что же тут оценочного? Если результат работы такого специалиста приносит компании прибыль, то это вполне объективный показатель.
Вы тоже упорно игнорирует, что для таких людей начать решать задачу - означает, походить и повертеть в руках любимый предмет.
Где я это игнорирую? Я же прямо пишу
И да, я считаю, что если человек не готов в условиях собеседования (т.е. в условиях события о котором кандидат заранее знал) начинать обсуждать такую простую задачу, то это плохая для специалиста черта.
Ну вы хотябы читайте сообщение на которое отвечаете... А то это уде обидно как-то.
Что же тут оценочного? Если результат работы такого специалиста приносит компании прибыль, то это вполне объективный показатель.
В реальности, продукт - это результат работы десятков/сотен/тысяч человек. И его успешность определяется не только вкладом всех этих людей, но и банальной удачей. Можно быть хорошим специальностом, но ни разу не выпустить комерчиски успешный продукт. А можно быть хреновым специалистом, которому просто повезло вписаться в выстреливший продукт.
Например, мы вот с вами несогласны следует ли отказывать кандидатам, которые на собеседовании не могут начать отвечать на (конкретный) вопрос. Если есть комерчески успешная компания которая придерживается моей позиции, будет ли это доказательством моей точки зрения?
В реальности, продукт - это результат работы десятков/сотен/тысяч человек.
Не всегда. Иногда - это результат работы одного / двух человек. И в этом случае финансовые показатели - это в том числе и показатели работы этих двух землекопов. Да, на короткой дистанции - это может быть просто везение или результат работы сейлзов. Но на протяжении десятка лет - это точно не везение. Потому, что если система не потянет нагрузку - никакие сейлзы не помогут.
не могут начать отвечать на (конкретный) вопрос
Извините, не могу согласиться. Вопрос типа "опишите, как бы вы построили высоконагруженную систему загрузки террабайтных данных" - это совсем не конкретный вопрос.
Не всегда. Иногда - это результат работы одного / двух человек. И в этом случае финансовые показатели - это в том числе и показатели работы этих двух землекопов. Да, на короткой дистанции - это может быть просто везение или результат работы сейлзов. Но на протяжении десятка лет - это точно не везение. Потому, что если система не потянет нагрузку - никакие сейлзы не помогут.
Ну ок, признаюсь, я рассматривал исключительно найм человека в команду. Там важны навыки командной работы. Чловек может быть замечательным соло игроком, но отвратительным командным. Если нужен именно соло игрок, то заморочка с крученим предмета ни на что не влияет. Но в реальности же, большинство собесов именно в команду.
Извините, не могу согласиться. Вопрос типа "опишите, как бы вы построили высоконагруженную систему загрузки террабайтных данных" - это совсем не конкретный вопрос.
Слово "конктерный" в данном случае не характеристика вопроса, а указание на то, что речь идёт об уже обсуждаемом вопросе. Ну чтобы не повторять его в 100500 раз. Хотя судя по всему нужно было таки повторить вопрос, ибо вы как-то умудрились вопрос "есть медиасервис, который даёт пользователю закачивать файлы больше 30гб на сервер. Как бы вы реализовали архитектуру? Какой бы вы использовали стек? Как бы вы реализовали API?" превратить в "опишите, как бы вы построили высоконагруженную систему загрузки террабайтных данных". Заметьте в изанчальном вопросе более четко очерченные вопросы и условия, никаких террабайтных данных, никаких "высоконагруженных".
И да, я считаю, что если человек не готов в условиях собеседования (т.е. в >условиях события о котором кандидат заранее знал) начинать обсуждать >такую простую задачу, то это плохая для специалиста черта.
Пункт 1 и 2 длится обычно минут 30-40. После 25 минут активной работы у человека плывёт кепка. Ресурс мозга исчерпан. В таком состоянии человек готов извлекать только то, что у него уже есть в голове, но не решать новые задачи. После пункта 1 и 2 никто перерыв не делает. Собеседующее лицо радостно сообщает: "ясно, а теперь давайте проведем техническое собеседование!!!" И еще минут 20 спрашивает теорию, а потом в самом конце переходит к самому вкусному, - решение алгоритмов. В итоге 60 минут активной работы мозга. Человеку уже плевать, как он выглядит перед собеседующим лицом и может сказать "я не готов ответить на этот вопрос" или, если у него сильная мотивация устроиться на работу, - героически пытаться решать эту задачу. При этом решения выглядят настолько смешно, что может показаться, что перед тобой джуниор после 3-х месячного курса программирования(в лучшем случае). Исчерпывающе?
Подтверждаю. На собеседовании волнуются все. К тому же на пункте 1 и 2 человек оч. сильно напрягает мозги. И после пункта2, когда он рассказывает о себе - мозг перегружается и на пункте 3 человек уже ничего в реалтайме решить не сможет. После собеседования, я немного передохнув, вполне нормально все эти задачи решал на 1 2 3. Но уже да, постфактум
Чтобы такого не было собес можно разбивать на несколько этапов. Ну и хороший интервьюер увидев, что кандидат волнуется постарается что-то с этим сделать. Может задать вопрос на который кандидат точно ответит, затем похвалит кандидата. Может предложить сделать паузу или перенести собеседование. Да и в целом, скидка не нервы делается всегда. Ну и если сами понимаете, что черезмерно нервничаете, то так и скажите. Перенести собеседование для интервьюера обычно не проблема.
Вообще, по-логике за подобные вещи так-то должен отвечать HR-рекрутёр. Работать с такими одно удовольствие и кандидату и интервьюеру. Но хороший HR - это зверь достаточно редкий :(
думаю что автор пишет вполне искренно, система приема на работу в IT поломана, и не только в россии, поэтому давным-давно только через networking, что всем и советую
Мне тоже кажется, что ситуация какая-то странная. Притом за границами постсоветского пространства точно также, судя по опыту. Все ноют, какой страшный дефицит айтишников, а я, к примеру , с опытом работы за 20 лет, уже больше года не могу найти удалённую работу. Ах вы не использовали фреймворк X - досвидания. Ах вы не использовали фреймворк Y - вы нам не подходите. Ах вы не использовали фреймворк X вместе с библиотекой Z - извините, мы отдали предпочтение другому кандидату. Плюс куча менеджерских заморочек, когда неявно ищут не разработчика, а мастера на все руки. Пусть он и код пишет, и админит, и ещё проектом заведует и с заказчиками все согласовывает, а менеджер будет зарплату получать, на экране рожей маячить и презентации рисовать, какой ОН молодец и как под его управлением все тут прекрасно работает. Так что да, сидит где-нибудь тимлид и горюет, вот уже год не можем никого в команду найти, вот же дефицит какой. И невдомёк ему, что нет никакого дефицита, просто никто до него прорваться не может, через их рекрутёров, HR-ов и прочие защитные бастионы.
Нет, не HR виноваты. Перечитай то, что я написал
Все ноют, какой страшный дефицит айтишников
На самом деле дефицит подходящих айтишников. Здесь это вопрос денег и больших чисел. Обучать людей на месте методом их проб и ошибок это очень дорого. Условная задача, которая решается специалистом в теме за считанные часы, у падавана может растянуться на месяцы (на практике был не один такой кейс). Конкуренция среди инженеров на международном рынке конкретно сейчас очень высока - после всех этих релокаций рабсилы из стран некогда развитого социализма, готовых теперь работать тут чуть ли не за еду, а так же массовых увольнений из айти гигантов. Конечно, каждый считает себя самым-самым, но лучше взять того у которого X, Y и Z на самом деле сходятся, или продолжать поиски, чем взять не того и мучаться с ним все следующие годы.
Обучать людей на месте методом их проб и ошибок это очень дорого.
Да какое обучать... Мы же говорим о кандидате с опытом работы в десятки лет, который этих фреймворков и языков успел сменить не один пяток. Ну какое обучать? Документацию прочитать, это что-ли обучение?
Условная задача, которая решается специалистом в теме за считанные часы, у падавана может растянуться на месяцы
Ммм... у меня бы не поднялась рука назвать падаваном кандидата с опым работы в 20 лет. Ну смешно даже. На месяцы растянуться...
чем взять не того и мучаться с ним все следующие годы.
Да с чего мучаться-то? Вот, к примеру, на одном из последних мест я работал 15 лет. Это значит, раз я там столько работал, значит успешно выполнял свои задачи. Значит там со мной не мучались. А тут вдруг начнут мучаться.
Документацию прочитать, это что-ли обучение?
Все зависит от требований. Если компания готова вкладываться, почему нет. Но в целом документации у тех же w3c уже давно понаписано на второе высшее образование (вы когда последний раз пересматривали?). Пройти какую-то базовую сертификацию в популярных клаудах (AWS, GCP, Azure) займет пару месяцев на каждый. Научиться эффективно использовать, обходя разные специфичные грабли - ещё больше. ITIL - у этих вообще планы расписаны на годы с обязательной наработкой профильного опыта в промежутке между экзаменами. ISO/IEC, если до этого не сталкивались с отраслевыми стандартами (безопасной разработки, например), можно читать хоть всю жизнь.
с опым работы в 20 лет. Ну смешно даже
У меня айтишный стаж немного больше, но это не мешает относиться к этим цифрам, так скажем, с юмором. Причем чем больше, тем веселее. То что перед глазами - разработка двадцать лет тому назад и сейчас это довольно разные вещи. Если вы этого не заметили, значит вероятно работаете в какой-то специфичной нише.
а я, к примеру , с опытом работы за 20 лет, уже больше года не могу найти удалённую работу
В автоспорте есть поговорка, что ты хорош настолько, насколько хороша твоя последняя гонка. А в волатильной индустрии важны в лучшем случае последние 3 года.
Удалёнка как мне кажется это более специализированная работа. Тут нужен набор конкретных навыков здесь и сейчас. Никто не хочет ждать пока вы выучите фреймворк или библиотеку, когда срочно нужно закрыть багу. Удалёнка это не про рост и не про корп культуру, а про работу.
пока вы выучите фреймворк или библиотеку, когда срочно нужно закрыть багу.
Это какой-то миф. Во первых, мне приходилось исправлять ошибки в проектах, написанных на незнакомом мне языке.
Во вторых, если только что принятый человек в первый же день полезет что-то исправлять, я бы такого по рукам бил, ибо не фиг костылить, пока не изучил архитектуру проекта. А результатом такого изменения 100% будут костыли. И хорошо, если хотя бы следствие бага будет исправленное, а не добавлено ещё 2 новых.
А в конце третьих, кого бы не приняли, минимум месяц этот человек будет вникать в новый проект, прежде, чем сможет что-то осмысленно в нем делать.
Никто не хочет ждать пока вы выучите фреймворк или библиотеку, когда срочно нужно закрыть багу.
Если человека сразу после найма кидают исправалть срочную багу, то что-то в консерватории не так. В реальности процесс он-боардинга на существующий проект занимает несколько месяцев. И разбирательства в фреймворках и библиотеах там занимает достаточно мало времени (если не учитывать самописные библиотеки). Так что первые месяцы будут в фиксах далеко не самых значительных багов и реализации не самых важных фич.
Удалёнка это не про рост и не про корп культуру, а про работу
Любая работа - это про работу и зарплату. Работодатель нанимает работника, чтобы тот делал работу, а работник нанимается, чтобы получать зарплату. Культура и рост - это лишь сопутствующие сущности.
Ну и много где нет жесткого деления на удалёнку и не удалёнку. Хочешь - ходишь в офис, не хочешь - работаешь из дома. Лишь бы результат выдавал, а кушаешь ли ты корпоративные печеньки и просиживаешь ли корпоративный стул - это дело десятое.
важны в лучшем случае последние 3 года
Т.е. Вы считаете, что специалист с опытом работы 20 лет, которому не пришлось использовать, ну допустим, mongodb, хуже новичка с опытом работы 5 лет, который утверждает (замечу в скобках, всего лишь утверждает, что он работал с mongodb)?
Это я вспоминаю, что начать использовать mongodb у меня не заняло нисколько времени. Ну в самом деле, люди (это я уже не Вам пишу сейчас) . Вы что, считаете, что все эти фреймворки - это какой-то рокет сайнс, которые ну никак нельзя начать использовать, просто прочитав документацию и имея опыт работы с другими фреймворками?
Т.е. Вы считаете, что специалист с опытом работы 20 лет, которому не пришлось использовать, ну допустим, mongodb, хуже новичка с опытом работы 5 лет, который утверждает (замечу в скобках, всего лишь утверждает, что он работал с mongodb)?
Я считаю, что 20 лет и 5 лет это просто числа. Кто-то 20 лет сидит на саппорте легасей. Кто-то за 5 лет гаражный проект до IPO доводит. Вы размахиваете своими 20ю годами, как будто это 20 млн баксов - якобы такая самоценность. А это так не работает.
А легаси - это что-то очень плохое? А если это легаси приносит миллионы долларов? Человек, который 20 лет сидит на саппорте легасей, скорее всего знает и умеет гораздо больше, чем тот, который за 5 лет проект до IPO довёл. Первый опытный специалист, решивший за эти годы множество проблем, походивший по множеству граблей и поддерживающий в рабочем состоянии систему, приносящую компании миллионы долларов. А второй - обыкновенный болтун, навешавший лапши на уши инвесторам, решивший ковать, пока горячо и продать свой проект пока он не успел развалиться.
Зачем вы мне-то это пишете? Я вам просто логику рынка озвучиваю, которую вы, судя по всему, и так своими глазами видите. Идите на собесе доказывать, что команда должна нанять и обучить до требуемого уровня именно вас за миллион денег, а не мидла вчетверо дешевле.
Логика рынка - это фиктивные тимлиды и сеньоры, которые заворачивают людей с опытом на собеседованиях
Фиктивные сеньоры завернули 1 раз - бывает.
Фиктивные сеньоры завернули N раз подряд - ну я не знаю, кто тут фиктивный. Видимо, один вы истинный lore keeper, а остальные все фиктивные. Непонятно, как ИТ у нас вообще живет.
На логике "я дАртаньян" далеко не уедешь.
Если завернули по делу -- правильно сделали, а если не по делу -- то избавили от риска очутиться в токсичной команде. win-win.
Пройди 20-30 собеседований с отрицательным результатом. Я посмотрю, как ты радостно будешь говорить фразу "win-win" :)
Два года назад я как раз много собеседовался и имел много отказов, но, что интересно, не из-за технической части, а из-за несоответствия духу компании. Софт скилы. И даже зная "правильные" кастрированные ответы на многие подобные вопросы я предпочитал отвечать с разумной долей частности, заранее зная, что собеседующему ответ может не понравится. При этом интервью -- это процесс двусторонний, не забывайте. Я оценивал и компанию, и ее представителей, и делал вывод о том, насколько хочу у них работать. В любом случае очень мало было собеседований, на которых я был бы недоволен техническими вопросами. Хотя иногда был недоволен плохим техническим уровнем человека, их задающего.
Говорю с сарказмом: конечно-конечно, 20 лет коммерческого опыта ничто, по сравнению с 26-летним фиктивным сеньором, который только 2 года назад из универа откинулся. Человек 20 лет в командной разработке работал. Скорей всего он точно знает, как работать
Я думаю, что вы сознательно пытаетесь в уничижительном контексте говорить о большом опыте работы. Обычно, за 20 лет человек меняет несколько мест работы. Т.е работал уже в нескольких командах. И на каждой работе ему платили деньги. И не за красивые глаза. Поэтому этот человек умеет работать и его опыт - большая ценность
Подписываюсь под каждым словом. Фиктивный сеньор 26 лет будет изучать месяц то, что специалист с опытом 5+ лет за два дня изучит и будет писать так, как фиктивный сеньор напишет только лет через 10. Такие сеньоры никогда человека с опытом не пропустят на собеседовании. Это и есть причина отрицательных результатов
команда должна нанять и обучить до требуемого уровня именно вас за миллион денег
Да почему обучить и почему за миллион? Откуда это взялось? Человека с 10-ками лет опыта не нужно обучать. Он сам и вас обучить может и сам обучится, притом бесплатно. Вот мы как раз и пришли к тому, что описано в статье. Видит эдакий "сеньёр" с 5 годами опыта, на собеседовании, человека 20 годами опыта и понимает, что ему самому ещё учиться и учиться. А признаваться в этом не хочется и другим показать страшно.
Видит эдакий "сеньёр" с 5 годами опыта, на собеседовании, человека 20 годами опыта и понимает, >что ему самому ещё учиться и учиться. А признаваться в этом не хочется и другим показать страшно.
Да, это настоящая причина отрицательных результатов на собеседованиях, а не то, что ты не знаешь ответ на какой-то вопрос
Статья отражает текущую реальность.
Но это потому, что соискателей на самом деле хватает... Поэтому можно отсеивать пачками.
Недавно на хабре писал человек, про то что все хотят высокие зп, но не имеют интереса, не хотят делать тестовые, на вопросы могут ответить "точно не помню". И он не может поэтому хорошего бэка найти...
не хотят делать тестовые
Конечно не хотят. Если у тебя 20 собеседований, то надо сделать 20 тестовых. Я, обычно, предлагаю уже сделанное тестовое с других собеседований. При этом готов полностью объяснить как это работает. Если это не устраивает работодателя и он требует сделать его тестовое, то предлагаю по рейту оплатить его(если оно объемное), если вариант не подходит, предлагаю проверить мои знания другим способом. Потому как есть много хитровыделанных товарищей, которые реальные мини-проекты выдают за тестовое задание и хотят, чтобы их сделали бесплатно
Недавно на хабре писал человек, про то что все хотят высокие зп, но не имеют интереса, на вопросы >могут ответить "точно не помню"
Такие люди, понятно, что должны отсеиваться. Но опять же, никто не видел этих вопросов и то, что спрашивает человек. Может он из интернета скачал "100 вопросов language_name программисту" и озвучивает их соискателю
"Если у тебя 20 собеседований, то надо сделать 20 тестовых." А почему у тебя 20 собеседований? Все совсем плохо или неразборчивость?
Для меня собеседование -- это возможность поднять свой технический уровень (а заодно потешить ЧСВ и оценить адекватность нынешней зарплаты). К сожалению, оставаясь на одном месте, ты скорее теряешь квалификацию, становять не то что "узким специалистом", а "узким специалистом в определенном участке некого легаси кода". Собеседования позволяют взглянуть на себя со стороны. И, кстати, даже в самые тяжелые времена у меня не было "20 тестовых".
Статья написана в духе сопливого тинэйджера, типа "я такой хороший, а она со мной гулять не хочет". Запомните, объективность -- это не главное при приеме на работу, так же как при выборе супруга, друга или же помидоров на рынке. Она важна в суде. Она важна при сдаче экзамена. Она желательна при оценке результатов работы уже нанятых сотрудников, но не при собеседовании еще не нанятых кандидатов.
"Эта статья будет полезна прежде всего работодателям..." -- она ни хрена им не полезна, ровно так же, как неинтересны (или же просто смешны) стенания отвергнутого ухажера. В конце концов в вашей модели мира должно получаться так, что и кандидаты страдают, и работодатели. А в реальном мире последние не страдают, а если и страдают, то точно не от того, что отсеяли тех, кого посчитали нужным.
Чтобы просто устроиться на работу и выполнять свои функциональные обязанности. Чтобы получать зарплату, расти профессионально и приносить пользу предприятию, в котором ты работаешь.
"Чтобы получать зарплату" надо, чтобы кто-то ее платил. А у него есть свое представление о том, на кого он согласен тратиться, и кандидаты, знающие ответы на вопросы, не в приоритете. Вопросы в стиле "(true + true * 5) - 2" проверяют не знания, а понимание. Безусловно, за такой код в продакшене нужно бить по рукам, но за отсутствие любопытства о том, как работает движок твоего любимого языка, надо бить не менее жестко.
Посмешило сравнение программиста с механиком СТО. Ну так и идите в механики СТО. Или вам у программистов зарплата кажется более привлекательной? Поверьте, неспроста. Это у механика все обязанности и знания строго регламентированы, программистам же (настоящим, а не формошлепам) приходится постоянно плавать в зыбком болоте неизвестности. Хорошим программистам при этом удается находить островки определенности и уменьшать сложность задачи/системы/окружающего мира, в чем и состоит ключ к их эффективности. Формошлепство -- это низкооплачиваемое и легко заменяемое AI занятие, так что таких вакансий существенно меньше желающих.
Вы можете аппелировать к тому, что вокруг вас сплошные "специалисты", которые разделяют вашу точку зрения. Пусть так, но вокруг меня много коллег, которых я бы хотел поганой метлой гнать с их высокооплачиваемых позиций. И да, у них может возникнуть та же самая проблема с трудоустройством: им будут жестко отказывать к компаниях-конкурентах. Нужно очень быстро бежать, чтобы оставаться на одном месте.
Напоследок рекомендую прочитать повесть Айзека Азимова "Профессия". Как раз о том, о чем вы тут пишете.
Самуил Маршак - Мельник, мальчик и осел. При всех возможных ситуациях кому-то смешно или кто-то недоволен. Имитаторам никогда не нравятся инициаторы
А в реальном мире последние не страдают, а если и страдают, то точно не от того, что отсеяли тех, кого >посчитали нужным.
Всё завязано на кадрах. И только на кадрах. Промах с кадрами зачастую выливается в банкротство. Иногда руководители выходят из окна квартиры на 9-ом этаже
"Чтобы получать зарплату" надо, чтобы кто-то ее платил. А у него есть свое представление о том, на кого он согласен тратиться, и кандидаты, знающие ответы на вопросы, не в приоритете. Вопросы в стиле "(true + true * 5) - 2" проверяют не знания, а понимание.
Всё проще. Такие вопросы копипастятся из статьи 100 вопросов программисту и зачитываются. В твоем мире собеседующее лицо - это Макиавелли, который подготавливается по три недели к собеседованиям, чтобы определить лучшего кандидата по знаниям. В реальном мире программиста вырвали из контекста, дали задание обработать 50 кандидатов. Он хочет по-быстрей их отсобеседовать и забыть как страшный сон. При этом, конечно же, не навредить себе и не взять какого-то товарища, который или его подсидит или начальству доложит, что этот самый программист - не сеньор, а мидл минус. И завтра уже зарплата этого сеньора будет в три раза меньше, если не попросят уйти. Кому от этого хорошо, кроме этого самого сеньора-помидора?
Посмешило сравнение программиста с механиком СТО. Ну так и идите в механики СТО
Когда говоришь механик СТО, некоторые товарищи видят в этом тольтко механика СТО. Забавный реципиент.
Пусть так, но вокруг меня много коллег, которых я бы хотел поганой метлой гнать с их >высокооплачиваемых позиций
Как это "неожиданно". А кто ж их отсобеседовал и принял на работу, а ?
Напоследок рекомендую прочитать повесть Айзека Азимова "Профессия". Как раз о том, о чем вы тут >пишете.
Спасибо, поставлю в пул задач
Всё завязано на кадрах. И только на кадрах. Промах с кадрами зачастую выливается в банкротство.
Не это ли является ответом на ваш вопрос? И с чего вы взяли, что именно вы -- правильный выбор для минимизации вероятности банкротства?
Всё проще. Такие вопросы копипастятся из статьи 100 вопросов программисту и зачитываются.
Ни разу такого не видел, чтобы на интервью зачитывали бы примитивные вопросы. Иногда былало, что на телефонном скрининге -- но это скорее исключение. Но самое важное: не бывает глупых вопросов, бывают лишь глупые ответы. Если собеседующий сам технически сведущ, то любой вопрос он может превратить в конфетку при помощи дополнительных вопросов. По тому, как кандидат ответил на "примитивный" вопрос, можно понять, куда имеет смысл копать.
Что интересно, для меня, как собеседующего, нет цели найти области незнания кандидата и макать его в помои. У меня обратная цель: найти те области, в которых кандидат особенно хорош, и дать ему раскрыться. Даже если тот заучил ответы, впечатлить меня не удастся, но вот если у него есть особый интерес в каких-то областях, то всегда можно "рассказать о блошках".
Как это "неожиданно". А кто ж их отсобеседовал и принял на работу, а ?
Не я. Но, поучаствовав в процессе найма со стороны интервьюеров, я все-таки скажу, что моих коллег не за просто так взяли. Но все равно хотелось бы большего.
Недавно прочитал шутку (вернее, это правда в шутливой форме): в 40-х годах был один компьютер и один программист, и им был Алан Тьюринг. В 50-х были десятки компьютеров, а программистами были лучшие умы человечества. В 60-х компьютеров были тысячи, а программистами были доктора наук. Количество компьютеров постоянно росло, а уровень образования программистов постоянно опускался. В 80-е средний программист имел PhD. В 90-е -- высшее образование. В 2000-х за высшее образование считалась степень бакалавра. В последнее время все больше идет разговоров о том, "что важнее, образование или опыт"...
Знание фреймворков -- это нечто сродни умению поменять колесо на шиномонтаже. И неспроста в статье приведено сравнение с механиком СТО: формошлепство и ремонт авто -- все это работы одного порядка, для узких специалистов, от которых требуется лишь знание. А кругозор, эрудиция, любопытство, самообучаемость, самокритичность, аналитический ум, умение видеть картину в целом, умение вникать в детали -- это и многое другое являются необходимыми качествами для инженера. Отними все это и оставь знания -- и останется текник.
В современном мире развелось до хрена техников, т.е. людей, которые в прошлом веке были бы, может, хорошими сантехниками или строителями. Но спрос на IT и реклама хорошей жизни айтишников наводнили профессию людьми без инженерной жилки. Иногда (сайты ваять на фреймворках) это бывает приемлемо, но даже там все-таки еще приветствуется инженерный подход.
Знание фреймворков -- это нечто сродни умению поменять колесо на шиномонтаже. И неспроста в >статье приведено сравнение с механиком СТО: формошлепство и ремонт авто -- все это работы одного >порядка, для узких специалистов, от которых требуется лишь знание. А кругозор, эрудиция, >любопытство, самообучаемость, самокритичность, аналитический ум, умение видеть картину в целом, >умение вникать в детали -- это и многое другое являются необходимыми качествами для инженера. >Отними все это и оставь знания -- и останется текник.
Эхъ! Какой романтИк!
Это не просто диван. Место, чтобы переночевать ночь. Обычный набор досок, покрытый материей и простёганный ниткой. Диван - это нечто особенное! Это...это обитель сна, колыбель души. Он должен быть и мягким и обволакивающим, но в то же время упругим. Но не навязчиво упругим. Он должен быть и строгим одновременно и располагающим. Вызывающим умиротворение и страсть. Нежность и трепет. Убери всё это и он превратится просто в...
Пойди к психологу. Это просто работа. Пришел узнал что-то новое, порешал интересные задачи, коммуникация с коллегами опять же. Принес пользу предприятию
Знание фреймворков -- это нечто сродни умению поменять колесо на шиномонтаже
формошлепство
Не рассказывай нам тут сказки. На одном и том же фреймворке можно делать апи, а можно микросервисы со сложной логикой делать. Формошлёпа можно легко определить парой вопросов, но, зачастую, соискатель всё это в своём CV пишет
Человек за 5 лет коммерческого опыта столько уже задач порешал - не счесть. Если бы он не был интеллектуалом и не имел аналитического ума - его бы увольняли на второй неделе работы. На каждой работе. И не было бы 5-ти лет коммерческого опыта. Человек с опытом 10лет+ - это сияние чистого разума. Это мегамозг, летящий на крыльях ночи. Он отличается от фиктивного сеньора примерно так, как двортерьер отличается от породистой среднеазиатской овчарки. Хотя внешне они могут быть очень похожи
Пойди к психологу. Это просто работа. Пришел узнал что-то новое, порешал интересные задачи, коммуникация с коллегами опять же. Принес пользу предприятию
Вы (судя по вашим же комментам) сходили на 20 собеседований, и на каждом получили отказ. 20 работодателей недвусмысленно дали вам понять, что такой работник им не нужен. Но вы не унимаетесь и рветесь приносить пользу их предприятиям... И кому из нас к психологу?
На одном и том же фреймворке можно делать апи, а можно микросервисы со сложной логикой делать.
Ну вот уже более умные слова появились: апи и микросервисы. Знание фреймворка не гарантирует умения писать микросервисы, зато умение хорошо дизайнить микросервисы должно означать возможность быстро изучить любой фреймворк. По моим наблюдениям те, кто выставляет вперед знание фреймворков, валятся именно на более высокоуровневых понятиях, т.е. "таскают кирпичи там, где нужно церковь строить". Но я могу ошибаться, на то собеседования и даны, чтобы проверить соответствие ожидаемого и действительного.
Человек за 5 лет коммерческого опыта столько уже задач порешал - не счесть. Если бы он не был интеллектуалом и не имел аналитического ума - его бы увольняли на второй неделе работы. На каждой работе. И не было бы 5-ти лет коммерческого опыта. Человек с опытом 10лет+ - это сияние чистого разума. Это мегамозг, летящий на крыльях ночи.
Ооооо! Тут мы с вами не сходимся от слова совсем. Начнем с того, что человек, просидевший на одном месте работы 10 лет -- это далеко не всегда сияние чистого разума. Зачастую это как раз свидетельство того, о чем вы писали: нигде больше не нужен. Безусловно, везде есть свои исключения, но факт в том, что от сидения на одном и том же месте появляются трупные пролежни. Эта проблема, с которой хорошему сотруднику приходится бороться, а у плохого в итоге получится как кто-то писал выше: 10 раз по одному году сурка. Как пример, один из моих коллег (позиция C++ разработчика), который в 2019 году не слышал про C++11, не желал с Python 2 переходить на Python 3, понятия не имел о функциональном программировании и очень жестко реагировал на любые советы хоть немножко пополнить свой арсенал. И его не увольняли, а знаете почему? Потому что никому не хотелось лезть в поддержку того легаси, который он наваял за все это время. Но легаси становился все хуже, он все более не справлялся, и у менеджмента появилась мысль нанять нового толкового сотрудника, чтобы полностью это гуано переписать... под руководством того самого "сияния чистого ума".
Коллеги изложили в комментариях много моментов, но всё же считаю важным подсветить сочетание нескольких:
1) В нашей отрасли, в т.ч. в профессии программиста, пока не видно четкого стандарта подтверждения квалификации (аналогично советскому "слесарь 18 разряда"), и при этом у работодателя на всю беседу с Вами - буквально 1 час, за который нужно убедиться и в тех. навыках и в личностных качествах. Тем не менее, если в вашем резюме есть маркеры объективного признания ваших технических заслуг третьими лицами - поверьте, вас будут приглашать на собеседование в первую очередь:
а) контрибьютили(-те) FOSS? замечательно, всегда можно посмотреть ваш труд
б) участвовали в соревнованиях/конкурсах один/в команде и заняли призовое место? великолепно
в) участвовали в тех. конференциях как спикер? с Вами сразу начнут задушевную беседу вместо "экзамена"
можно продолжать перечисление, но, думаю, Вы мысль поняли. Однако, в таком случае, от вас будут инстинктивно ожидать более профессионального общения на тех. собеседовании. И, поверьте, разочарование будет сильнее, если кандидат не соответствует такому красивому резюме.
2) Работодателю может и не понадобиться весь ваш опыт X лет, если окажется, что его специфика настолько отличается, что пересечение ваших навыков, релевантных их поискам, просто будет уровня джуна. Но это означает:
а) Вам, возможно, и не стоит к данному работодателю, если Вы, конечно, не желаете кардинально сменить направление. Скорее всего данный вариант подошел бы для небольшой доли отказывающих работодателей, но Вами описан другой исход.
б) У Вас будут стараться вызнать Ваши способности, желания и систематическую практику изучать что-то новое, постоянно стараться идти "в ногу с прогрессом", в т.ч. в нерабочее время. Если соискатель сразу отрезает "я учусь только в рабочее время" - это красный маркер, т.к. мы живем в капитализме, вам хотят оплачивать рабочее время за применение ваших знаний и опыта, а не изучение банальных вещей за счет работодателя, уж извините. Работодатель готов потратить время на изучение его специфики, само собой.
3) Почему-то не заметил в других комментариях: в компанию может требоваться всего 1 специалист, а откликнувшихся соискателей банально больше, в т.ч. хорошо показавших себя на тех. собеседовании. И вот тут часть работодателей (не надо винить конкретно рекрутеров или собеседующего техлида) просто выбирает наилучшего, и тут лаг во времени. К сожалению, в таких случаях большая часть работодателей не удосуживается дать обратную связь тем, кого не выбрали. При этом, если я как соискатель, сразу на собеседовании прямо попросил потом дать обратную связь - почти всегда её получаю (причём вполне честную, только обычно в таких фразировках, чтобы я не обиделся)
4) Самое неадекватное - считать, что собеседующие с Вами пытаются самореализоваться. Я видел попытки спора собеседующего со мной как соискателем, когда я смог ответить по теме лучше, чем он знал или ожидал (да, он тоже человек с эмоциями и слабостями), но(!) - таких случаев малый процент (чаще даже слышу благодарность, что мой вариант лучше, чем задумали вопрошающие), и, поверьте, если вас как лида/руководителя, просят провести уже NN-ное собеседование - вам в последнюю очередь хочется заваливать очередного кандидата.
Во время собеседования проверяют не только формальные знания, но и на со ответствие корпоративной культуре. Человек, с отличающимися ценностями начинает разрушать созданную до него среду уже через месяц активного общения с коллегами.
А это как потери со стороны уже вложенных в работу HR денег, так и будущие издержки начиная от повышенных потребностей в адоптации, до затрат на увольнение (и тут речь не только о выплатах, но человекочасах загрузки других сотрудников, с этим процессом связанных).
Следите за руками: соответствовать ожиданиям по психологическом портрету = понимать диапазон ваших реакций = быть управляемым сотрудником.
проверяют не только формальные знания, но и на со ответствие корпоративной культуре. Человек, с >отличающимися ценностями начинает разрушать созданную до него среду уже через месяц активного >общения с коллегами.
Боже ш ты мой. "корпоративная культура", "ценности", "адаптация", "психологический портрет"
А приходишь в такой офис, а там 15 человек на 23 квадратных метрах сидят, без вытяжки и во второй комнате нет даже шкафа, а просто труба подвешена, на которой тремпели с одеждой висят. И зарплату готовы платить не выше $1200
Я вообще в первый раз слышу, что программисту сложно найти работу)
Я фронтендер, опыта 5+ лет, есть друзья и знакомые с опытом от 1+ до 15+ лет, тоже веб разработчики в основном и вот ни у кого проблем с поиском работы не возникает. Да, бывают не прикладные вопросы, задаются они с разными целями адекватными, или нет, но ни кому не приходило в голову по этому поводу целую статью написать. И да, отвечая на ваш вопрос, бывает, что человек отработал 20 лет в области и некомпитентен. В отличие от вашего примера с СТО в программировании за эти 20 лет куча принципиальных вещей изменилось, а за следующие 10 поменяется ещё.
А компании обычно не ищут людей, которые по аналогии вашей же аналогии "умеют чинить уазики", нужны люди, которые в случае необходимости научатся "чинить любые машины". А не говорить "зачем вы задаёте вопрос про хундай, как мне это пригодится в ремонте уазика?"))
Может быть действительно не нанимателям нужно что-то менять в процессе найма?)
А компании обычно не ищут людей, которые по аналогии вашей же аналогии "умеют чинить уазики", >нужны люди, которые в случае необходимости научатся "чинить любые машины". А не говорить "зачем >вы задаёте вопрос про хундай, как мне это пригодится в ремонте уазика?"))
Не нужно "ля-ля". Человек за 5+ лет умеет чинить любые машины
Человек, который "умеет чинить любые машины", при желании в состоянии пройти любые собеседования.
Предлагаю подумать в таком направлении: ремонт машин -- не самая хорошая метафора для описания работы программиста, поскольку машины ремонтируют механики. Гораздо более правильной метафорой является проектирование автомобилей, и вот здесь нужны инженеры. А для инженера недостаточно ограниченного списка знаний и умений (типа "умею чинить уазики"), а требуется гораздо больший спектр познаний, который невозможно проверить по чек-листу.
Автор сей статьи явно тяготеет к механической работе (к тому, что я уничижительно называю формошлепством), где однажды изученной на средненьком уровне технологии должно хватать на хлеб с маслом (но без икры). Иногда и без масла: ну в самом деле, если хочешь хлеба с маслом, то нужно уметь показать собственную квалификацию на уровне выше среднего. А все, что выше среднего -- это конкуренция с такими же как ты кандидатами, которые тоже масло любят, а потому и книжки иногда почитывают, и к собеседованиям готовятся.
Если же позариться на икру, то о позициях сродни механику СТО придется забыть. Тут уже правильнее сравнить со спортсменом или актером. Первому постоянно приходится поддерживать себя в форме, чтобы быть лучше остальных таких же амбициозных (иначе его удел -- работа физрука). Актеру же приходится проходить прослушивания: тоже своеобразные собеседования; и почему-то никто не ропщет, что его не взяли "просто потому что он умеет лицедействовать"...
Сейчас действительно стало искать сложно. Без опыта решений на леткоде я не могу пройти собесы. За час нужно решить 2 задачи, я успеваю одну. Итог - отказ. А причина в одном - нет опыта быстрого решения оторванных от жизни алгоритмических задач. Рука не набита.
Мне кажется, суть статьи во фразе "И все они, как и я, испытывают очень серьезные затруднения при поиске новой работы."
Т.е. статья написана человеком, который имеет сложности с поиском работы и вращается в круге таких же. Это в целом достаточно :)
По собеседования ... по опыту, если ищешь человека на не очень большую ставку, отсев очень большой. Реально, можно играть в игру "я закончу собеседование за 10 минут ... а я за 9 ... ок, собеседуй". Многие кандидаты просто не знают элемкнтарных вещей, вообще. И так было и раньше. Помню в 2000е искали кандидатов, где главный технический критерий был знание SQL. Было 4 запроса, от простого к сложному. Сложный был что-то вроде выбрать сначала с чем-то самым большим, а потом с ними еще что-то сделать. Ничего заумного, реально. До 4го не доходил почти никто, да и до третьего тоже
По своему негативному опыту. Было собеседование (архитектор), когда спрашивали кучу терминов, которых я не знал. Я их и сейчас наверное не знаю, но им было очень важно.
Было неуспешное, когда искали спеца на нишевые задачи в базах и реально спрашивали нюансы, на фоне которых щнание сайд эффекта от ключа, не подпертого индексом кажутся цветочками. Наверное и хорошо
Хорошие србеседования, когда с той стороны сидит умный человек и вы просто беседуете. Есть о чем, можно обменяться мыслями и в конце прийти к соглашению о потенутале возможного сотрудничества. Жаль, трудно понять, насколько ты являешьс таким человнком, когда собеседуешь :)
Я не бог весть какой работодатель, однако работодатель с 15-летним опытом проведения собеседований. Если бы я проводил собеседование и потом увидел, что автор написал такую статью, я был бы рад, что отказал. Потому что "некомфортно работать вместе"
В последний раз о собеседованиях