Серебряной пули, как мы все знаем, нет… А так да, у всех цели разные, и интервью все проводят по-разному, и какие-то вопросы имеют смысл для одних сегментов, какие-то — для других. Что весьма очевидно, если вдуматься, но действительно явно не звучало.
А разве кто-то представляет? Но эти крупные компании — они весьма значимый кусок индустрии, не менее значимый, чем маленькие фирмы или проекты, где реально нужны скиллы. Иными словами, на одном полюсе у нас абстрактные инженеры, умеющие программировать "на всем", на другом — специалисты с конкретными скиллами. Большая часть мира — она где-то между, как обычно.
Я вашу логику понимаю, но в больших компаниях это немного не так работает… Все приходящие новички — они на одно лицо, им надо учиться внутренним технологиям и практически всему. Именно поэтому такой акцент на элементарные задачи и "основы" — все, что выше — оно почти и не нужно. Ну то есть, для примера, питон, алгоритмы, навыки тестирования, проектирования, вот это все надо всем и всегда, а все остальное учить на месте.
Другими словами, в крупных компаниях настолько замкнутая своя техническая экосистема, что практически любой конкретный опыт кандидата нерелевантен. Нам не важно, какие вы знаете фреймворки — наших вы все равно не знаете.
Конечно, для уникальных вакансий или людей очень высокого уровня это не так — но их единицы. А рядовых инженеров набирают тысячами в месяц.
А если кто-то хочет себе в команду конкретные скиллы, то внешние кандидаты вообще не рассматриваются. Тогда надо внутри искать.
Я такой же профессиональный собеседующий, как любой другой инженер :) Это общественная нагрузка такая — собеседования. Каждый сколько-то проводит. Просто так нагрузка масштабируется, каждый по чуть-чуть делает, в итоге процесс предсказуем. У меня вот в команде вакансий нет сейчас, я помогаю другим таким образом. А команды уже выбирают себе из тех, кто прошел через общий процесс.
Вы во-многом правы, плюс добавьте к этому, что для крупных компаний на средние и высокие должности испытательный срок должен занимать годы (только освоение внутренних технологий на достаточном уровне может занять 6-12 месяцев), что лишает его всякого смысла. Поэтому испытательный срок и применяется не так уж часто.
Да, это игра в угадайку — попытка предсказать будущую производительность человека по очень слабым исходным данным. Но другого способа-то и нет.
А в примере со связным список — проверяется знание теории и практики работы со специфичным типом данных.
Да нет же! Проверяется умение решать поставленные задачи на простейших примерах. Не надо знать, как обращать связные списки, но надо понимать, как он устроен, и суметь решить задачу его обращения (придумать решение). Это не требует никакого заучивания. Это требует умения воплощать в коде элементарные алгоритмы. Работать с переменными, ссылками, памятью, понимать, что это вообще такое.
Наверное, дело в том, что многие — и я в том числе — считают, что человек, не знающий, что такое список и как он устроен, программистом называться не может. Ну или массив, и в чем между ними разница.
Цель — проверить умение программировать вообще — решать программистские задачи. Какие поставят — такие и решать. И работа со списками — это только индикатор такого умения, как пишут выше.
Вклинюсь и повторю другими словами то, что говорили выше — такие задачи проверяют навыки ПИСАТЬ КОД. Не поговорить о написании кода, не рассказать, как он работает, не показать свой старый код (который то ли свой, то ли не свой, пес разберет), а просто сесть и написать код. Не надо помнить названия классов и методов — интервьюер подскажет. Не надо писать без ошибок. Но надо суметь написать код, ну а уже потом объяснить, что написали, как, и почему.
Конечно, задача искусственная — в основном, для простоты постановки — что такое массив или список, по идее, знает каждый.
И присоединюсь к комментирующим — огромное количество "программистов", приходящих на интервью, не может написать код. Зато может красиво порассуждать.
"Первое" лично я спрашиваю на собеседованиях в Гугле (ну не именно это, но в таком духе) — базовые навыки работы со списками/массивами, "напишите пару тестов", "оцените сложность вот этой вот функции из 5 строк кода" (никаких подводных камней), и т.д., и т.п. Даже на простой задаче можно очень содержательную дискуссию развернуть именно на понимание, а не на знание каких-то тонкостей.
90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…
Человека сперва оценивают вообще, брать или не брать на должность инженера или ещё кого-то, а уже потом он общается с командой. То есть до команды доходят только те люди, которые фильтр уже прошли.
Прокомментирую как человек, проводящий по 1-2 интервью в неделю в Google. Передо мной, как интервьюером, стоит ровно одна задача — понять, хочу я нанять этого человека, или нет. Не хорошо ли он знает <ЯЗЫК> или ещё что-то, не умнее ли он меня, не (даже) решил ли он задачу — а нанимать или нет. По комплексу факторов. И такая же задача стоит у всех собеседующих, думаю, во всех компаниях — нанимать или нет.
Соответственно, я буду вести интервью так, чтобы ответить на этот вопрос как для себя, так и для других людей, принимающих в итоге решение о найме. Других целей у меня на интервью нет. В частности, нет цели объяснить кандидату, что с ним не так (если не так). Рекрутер, конечно, потом что-то скажет (не знаю уж, что), но мне никто не ставит задачу объяснить причины отказа (тем более, что и решение принимаю не я).
Более того, у меня десятки других дел, требующих моего внимания, и мне уж точно не интересно заниматься доминированием или еще какими-то психологическими играми с людьми, которых я, скорее всего, вижу в первый и последний раз в жизни. Я почти всегда даю одну и ту же задачу, я хорошо знаю возможные решения, типичные проблемы, куда можно глубже копнуть, — процесс весьма оптимизирован. Это все равно по-своему интересно, и иногда получаются очень интересные разговоры, люди продолжают удивлять в хорошем и плохом смыслах, но вот чтобы как-то самоутверждаться за счет людей, которые и так в диком стрессе, а для меня это рутина, — увольте.
Хмм, я про такие даже не знал — но как-то не рассматривал 2.5 диски для хранения даже, только 3.5. Может быть, зря. В итоге у меня 5x3.5 + 1x1.5 SSD для системы.
Я пятый так добавил плюс SSD (впихнул оба в отсек 5.25, даже скобочки продаются), но больше уже нет без каких-то странных решений… Правда, мне больше и не надо особо, заменил винты с 2TB на 4TB в какой-то момент просто.
Учитывая, какой там треш с транспортом сейчас, им бы хоть тушкой, хоть чучелом...
Серебряной пули, как мы все знаем, нет… А так да, у всех цели разные, и интервью все проводят по-разному, и какие-то вопросы имеют смысл для одних сегментов, какие-то — для других. Что весьма очевидно, если вдуматься, но действительно явно не звучало.
А разве кто-то представляет? Но эти крупные компании — они весьма значимый кусок индустрии, не менее значимый, чем маленькие фирмы или проекты, где реально нужны скиллы. Иными словами, на одном полюсе у нас абстрактные инженеры, умеющие программировать "на всем", на другом — специалисты с конкретными скиллами. Большая часть мира — она где-то между, как обычно.
Я вашу логику понимаю, но в больших компаниях это немного не так работает… Все приходящие новички — они на одно лицо, им надо учиться внутренним технологиям и практически всему. Именно поэтому такой акцент на элементарные задачи и "основы" — все, что выше — оно почти и не нужно. Ну то есть, для примера, питон, алгоритмы, навыки тестирования, проектирования, вот это все надо всем и всегда, а все остальное учить на месте.
Другими словами, в крупных компаниях настолько замкнутая своя техническая экосистема, что практически любой конкретный опыт кандидата нерелевантен. Нам не важно, какие вы знаете фреймворки — наших вы все равно не знаете.
Конечно, для уникальных вакансий или людей очень высокого уровня это не так — но их единицы. А рядовых инженеров набирают тысячами в месяц.
А если кто-то хочет себе в команду конкретные скиллы, то внешние кандидаты вообще не рассматриваются. Тогда надо внутри искать.
Ну, в общем, это свой мир.
Я такой же профессиональный собеседующий, как любой другой инженер :) Это общественная нагрузка такая — собеседования. Каждый сколько-то проводит. Просто так нагрузка масштабируется, каждый по чуть-чуть делает, в итоге процесс предсказуем. У меня вот в команде вакансий нет сейчас, я помогаю другим таким образом. А команды уже выбирают себе из тех, кто прошел через общий процесс.
Вы во-многом правы, плюс добавьте к этому, что для крупных компаний на средние и высокие должности испытательный срок должен занимать годы (только освоение внутренних технологий на достаточном уровне может занять 6-12 месяцев), что лишает его всякого смысла. Поэтому испытательный срок и применяется не так уж часто.
Да, это игра в угадайку — попытка предсказать будущую производительность человека по очень слабым исходным данным. Но другого способа-то и нет.
Вы же не знаете, кем он там работал...
Ну, наверное, стоит честно говорить, чем предстоит заниматься, чтобы те, кому не интересно, не нанимались?
Да нет же! Проверяется умение решать поставленные задачи на простейших примерах. Не надо знать, как обращать связные списки, но надо понимать, как он устроен, и суметь решить задачу его обращения (придумать решение). Это не требует никакого заучивания. Это требует умения воплощать в коде элементарные алгоритмы. Работать с переменными, ссылками, памятью, понимать, что это вообще такое.
По-моему логично — нанимать максимально хороших людей, вписывающихся в ваш бюджет. Разве нет?..
Это-то разумеется, но это очень сложно предсказать. Так что реальная стратегия — лучшие в пределах бюджета — это, по крайней мере, можно измерить.
Наверное, дело в том, что многие — и я в том числе — считают, что человек, не знающий, что такое список и как он устроен, программистом называться не может. Ну или массив, и в чем между ними разница.
Цель — проверить умение программировать вообще — решать программистские задачи. Какие поставят — такие и решать. И работа со списками — это только индикатор такого умения, как пишут выше.
Ну по мне так в этом цель любой компании, нет? Нанимать лучших из имеющихся…
Вклинюсь и повторю другими словами то, что говорили выше — такие задачи проверяют навыки ПИСАТЬ КОД. Не поговорить о написании кода, не рассказать, как он работает, не показать свой старый код (который то ли свой, то ли не свой, пес разберет), а просто сесть и написать код. Не надо помнить названия классов и методов — интервьюер подскажет. Не надо писать без ошибок. Но надо суметь написать код, ну а уже потом объяснить, что написали, как, и почему.
Конечно, задача искусственная — в основном, для простоты постановки — что такое массив или список, по идее, знает каждый.
И присоединюсь к комментирующим — огромное количество "программистов", приходящих на интервью, не может написать код. Зато может красиво порассуждать.
"Первое" лично я спрашиваю на собеседованиях в Гугле (ну не именно это, но в таком духе) — базовые навыки работы со списками/массивами, "напишите пару тестов", "оцените сложность вот этой вот функции из 5 строк кода" (никаких подводных камней), и т.д., и т.п. Даже на простой задаче можно очень содержательную дискуссию развернуть именно на понимание, а не на знание каких-то тонкостей.
90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…
Ну и читаем классиков.
Человека сперва оценивают вообще, брать или не брать на должность инженера или ещё кого-то, а уже потом он общается с командой. То есть до команды доходят только те люди, которые фильтр уже прошли.
Уже после собеседования бывает team fit, когда говоришь с конкретными командами. Интервью — это конвейер…
Прокомментирую как человек, проводящий по 1-2 интервью в неделю в Google. Передо мной, как интервьюером, стоит ровно одна задача — понять, хочу я нанять этого человека, или нет. Не хорошо ли он знает <ЯЗЫК> или ещё что-то, не умнее ли он меня, не (даже) решил ли он задачу — а нанимать или нет. По комплексу факторов. И такая же задача стоит у всех собеседующих, думаю, во всех компаниях — нанимать или нет.
Соответственно, я буду вести интервью так, чтобы ответить на этот вопрос как для себя, так и для других людей, принимающих в итоге решение о найме. Других целей у меня на интервью нет. В частности, нет цели объяснить кандидату, что с ним не так (если не так). Рекрутер, конечно, потом что-то скажет (не знаю уж, что), но мне никто не ставит задачу объяснить причины отказа (тем более, что и решение принимаю не я).
Более того, у меня десятки других дел, требующих моего внимания, и мне уж точно не интересно заниматься доминированием или еще какими-то психологическими играми с людьми, которых я, скорее всего, вижу в первый и последний раз в жизни. Я почти всегда даю одну и ту же задачу, я хорошо знаю возможные решения, типичные проблемы, куда можно глубже копнуть, — процесс весьма оптимизирован. Это все равно по-своему интересно, и иногда получаются очень интересные разговоры, люди продолжают удивлять в хорошем и плохом смыслах, но вот чтобы как-то самоутверждаться за счет людей, которые и так в диком стрессе, а для меня это рутина, — увольте.
Хмм, я про такие даже не знал — но как-то не рассматривал 2.5 диски для хранения даже, только 3.5. Может быть, зря. В итоге у меня 5x3.5 + 1x1.5 SSD для системы.
Я пятый так добавил плюс SSD (впихнул оба в отсек 5.25, даже скобочки продаются), но больше уже нет без каких-то странных решений… Правда, мне больше и не надо особо, заменил винты с 2TB на 4TB в какой-то момент просто.