Представьте себе, что вы директор маленькой средней школы, который ищет нового учителя. Поскольку у вас в штате менее 20 учителей, вы должны убедиться, что каждый человек, которого вы нанимаете, может преподавать во всех классах. Кроме того, вы недавно потеряли одного из своих лучших учителей, человека с 15-летним опытом и наставника для более молодых коллег. Как вы замените его? Вот тут-то и начинается занятное.

После неких размышлений вы придумываете то, что считаете творческим подходом к собеседованию. Когда кандидаты появятся, вы попросите их провести урок из учебной программы средней школы [от 5-6 до 14 лет]. Вы хотите убедиться, что кандидат хорошо подготовлен, так что не станете рассказывать ему о том, какой урок хотите увидеть, до начала собеседования. Если кандидаты поймут тему, вы сделаете вывод, что они смогут легко научить чему-либо, поскольку они явно хорошо проявили себя под давлением по случайно выбранной теме.
Итак, вы размещаете объявление о найме, и некоторые действительно замечательные кандидаты откликаются. Однако для первого испытания нового подхода вы планируете опробовать его на человеке, который пришёл по рекомендации: учительнице, с которой один из ваших сотрудников работал в прошлом и утверждает, что она была звездой школы. Вы удивляетесь своей удаче и думаете, что она идеально подходит для проверки вашего нового метода собеседования. Вы связываетесь с ней, чтобы договориться о дате собеседования, и рассказываете ей о применяемом подходе, чтобы дать ей возможность подготовиться.
Затем наступает день собеседования, и ваш кандидат появляется в школе. Вы можете почувствовать, что она немного нервничает, а это странно, потому что она опытный учитель с безупречным резюме. Вы решаете не зацикливаться на этом и вместо этого приглашаете учительницу в один из ваших классов, чтобы начать собеседование. «Я бы хотел, чтобы вы провели урок по теории чисел». В этот момент её лицо опускается: вы не знали, что она не преподавала в 8 классе более 10 лет. Но как профессионал она идёт к доске и начинает урок. Рассказывает о множителях чисел и о том, как определить, делится ли данное число на 2, 5 и 10, но делает это с трудом. Когда вы спрашиваете о НОД и НОК, ей нужно разъяснение аббревиатур, а вы расцениваете это как плохой знак. Вы объясняете, что имеете в виду «наибольший общий делитель» и «наименьшее общее кратное», но теперь вы можете сказать, что её уверенность подорвана, а кроме того, улавливаете раздражение в её голосе.
В конце часа она допустила ошибку в основных моментах теории чисел, и это совсем не наполняет вас чувством уверенности в том, что она сможет провести этот же урок перед группой непослушных восьмиклассников. Учительница прекрасно справляется с другими вопросами о поведении, но вы не можете избавиться от чувства, что, возможно, она не лучший учитель в этом кабинете. После некоторого раздумья вы решаете нанять гораздо менее опытного преподавателя, который отличился на «тестовом уроке».
Хотя это может показаться совершенно надуманным примером и странным способом собеседования с кандидатом на преподавание, именно такой метод применяется при собеседованиях инженеров-программистов. Хотя я здесь не для того, чтобы лихорадочно доказывать, что собеседования с программированием не работают вовсе (хотя другие делали это), я твёрдо уверен, что им нет места при собеседовании сеньоров.
Почему? Если говорить просто, сеньоры отличаются друг от друга, и типичное собеседование с программированием ставит их в невыгодное положение по ряду причин. Итак, такие собеседования:
Суммируя все эти факторы, не стоит удивляться, что сеньоры ненавидят собеседования с программированием. Если вы хотите привлечь лучших и уменьшить трения при собеседовании на этом очень узком рынке труда, я бы посоветовал вам перестать применять собеседование с программированием.
Но, возможно, вы думаете о том, как сможете узнать, могут ли кандидаты программировать? Если вы с подозрением относитесь к найму разработчика такого уровня, не ощутив его способностей к программированию, я бы предложил вам дать очень короткое задание (которое занимает не более часа или двух и выполняется им дома). Большинство должны быть в состоянии найти небольшое количество времени для выполнения такого задания, особенно по той причине, что оно исключает работу по подготовке, необходимую для собеседования с программированием, и может быть разбито на временные отрезки, которые лучше вписываются в их напряженный график. Задание также позволяет им работать в своей родной среде IDE (если они этого захотят) и потратить любое количество времени для повторного знакомства со стандартными библиотеками.
Дополнительное преимущество — тот факт, что соискатель может посвятить этому упражнению как можно меньше или как можно больше времени, позволяет вам понять, что ими движет. Внимательны ли они к комментариям? Подумали ли они о тестировании? Структурировали свой код разумно и понятно? Насколько они сосредоточены на качестве работы? Другими словами, вы будете знать, могут ли кандидаты программировать и могут ли они программировать хорошо и в более реалистичных обстоятельствах.
Сеньоры — источник жизненной силы любой IT-компании. Они самые желанные, самые дорогие и их труднее всего привлечь. И особенно на исторически сложном рынке труда ваш процесс найма должен быть адаптирован к их конкретным потребностям, поскольку вы нуждаетесь в них гораздо больше, чем они нуждаются в вас. Они ненавидят собеседования с программированием, и вы тоже должны их возненавидеть, если вы хотите привлечь лучших.
А вам приходилось участвовать в таких проблемных собеседованиях?

Как обычно, промокод HABR — добавит 10% к скидке на обучение, отраженной на баннере.

После неких размышлений вы придумываете то, что считаете творческим подходом к собеседованию. Когда кандидаты появятся, вы попросите их провести урок из учебной программы средней школы [от 5-6 до 14 лет]. Вы хотите убедиться, что кандидат хорошо подготовлен, так что не станете рассказывать ему о том, какой урок хотите увидеть, до начала собеседования. Если кандидаты поймут тему, вы сделаете вывод, что они смогут легко научить чему-либо, поскольку они явно хорошо проявили себя под давлением по случайно выбранной теме.
Итак, вы размещаете объявление о найме, и некоторые действительно замечательные кандидаты откликаются. Однако для первого испытания нового подхода вы планируете опробовать его на человеке, который пришёл по рекомендации: учительнице, с которой один из ваших сотрудников работал в прошлом и утверждает, что она была звездой школы. Вы удивляетесь своей удаче и думаете, что она идеально подходит для проверки вашего нового метода собеседования. Вы связываетесь с ней, чтобы договориться о дате собеседования, и рассказываете ей о применяемом подходе, чтобы дать ей возможность подготовиться.
Затем наступает день собеседования, и ваш кандидат появляется в школе. Вы можете почувствовать, что она немного нервничает, а это странно, потому что она опытный учитель с безупречным резюме. Вы решаете не зацикливаться на этом и вместо этого приглашаете учительницу в один из ваших классов, чтобы начать собеседование. «Я бы хотел, чтобы вы провели урок по теории чисел». В этот момент её лицо опускается: вы не знали, что она не преподавала в 8 классе более 10 лет. Но как профессионал она идёт к доске и начинает урок. Рассказывает о множителях чисел и о том, как определить, делится ли данное число на 2, 5 и 10, но делает это с трудом. Когда вы спрашиваете о НОД и НОК, ей нужно разъяснение аббревиатур, а вы расцениваете это как плохой знак. Вы объясняете, что имеете в виду «наибольший общий делитель» и «наименьшее общее кратное», но теперь вы можете сказать, что её уверенность подорвана, а кроме того, улавливаете раздражение в её голосе.
В конце часа она допустила ошибку в основных моментах теории чисел, и это совсем не наполняет вас чувством уверенности в том, что она сможет провести этот же урок перед группой непослушных восьмиклассников. Учительница прекрасно справляется с другими вопросами о поведении, но вы не можете избавиться от чувства, что, возможно, она не лучший учитель в этом кабинете. После некоторого раздумья вы решаете нанять гораздо менее опытного преподавателя, который отличился на «тестовом уроке».
Хотя это может показаться совершенно надуманным примером и странным способом собеседования с кандидатом на преподавание, именно такой метод применяется при собеседованиях инженеров-программистов. Хотя я здесь не для того, чтобы лихорадочно доказывать, что собеседования с программированием не работают вовсе (хотя другие делали это), я твёрдо уверен, что им нет места при собеседовании сеньоров.
Почему? Если говорить просто, сеньоры отличаются друг от друга, и типичное собеседование с программированием ставит их в невыгодное положение по ряду причин. Итак, такие собеседования:
- Отнимают массу времени на подготовку — поскольку собеседования с программированием черпают вопросы из всей области разработки программного обеспечения, к ним очень трудно подготовиться полностью. Эта проблема усиливается для сеньоров несколькими способами. Прежде всего, по определению, они далеко отошли от первоначального обучения, при котором, возможно, в последний раз сталкивались с некоторыми эзотерическими аспектами разработки программного обеспечения, такими как динамическое программирование, красно-чёрные деревья или даже рекурсия. Обновление в памяти широкого спектра алгоритмов и структур данных может занять значительное количество времени на подготовку. Добавьте к этому тот факт, что сеньоры стеснены во времени (у них есть неотложные задачи и часто значительные личные обязанности), и всё это идеальный шторм. Я знаю несколько случаев, когда сеньоры интересовались процессом собеседования у работодателя и, услышав, что было собеседование с программированием, отказались от него.
- Заставляют работать по-другому — сеньоры далеки от голых сред разработки, которые используются на собеседованиях с программированием. Как правило, их среда разработки хорошо настроена и совершенствовалась в течение многих лет для того, чтобы освободить их от ненужного труда. Отнять среду в тот момент, когда есть не менее значимые искусственные ограничения по времени, — значит, поставить их в весьма невыгодное положение. Кроме того, они, возможно, провели последние несколько лет, работая с собственными библиотеками (управления памятью, проверки ошибок, трассировки) у своего нынешнего работодателя. Собеседование с программированием резко выводит их из зоны комфорта, возвращая в мир стандартных библиотек и простых текстовых редакторов.
- Не проверяют то, что вы хотите от разработчиков после найма — возможно, самая вопиющая сторона применения собеседования с программированием к сеньорам заключается вот в чём: такое собеседование проверяет только небольшую часть того, для чего вы их нанимаете. Сеньоры обычно делают в 3-5 раз больше (или даже ещё больше), чем свежеиспеченный выпускник. Ожидать, что сеньор напишет в 3–5 раз больше кода, чем выпускник, очевидно, неразумно: просто не хватит времени. На самом деле вы ищете их, чтобы они помогли команде джунов и мидлов, наставляли такие команды, выявляли системные проблемы, отлаживали самые сложные проблемы, понимали сложные системы и выполняли запутанную работу, необходимую при программировании внутри этих систем. Ни один из этих аспектов не проверяется на собеседовании с программированием, и это одна из главных причин, почему сеньоры ненавидят их.
- Они сами по себе плохой сигнал — вы понимаете, что не нанимаете сеньоров для программирования, и они тоже это понимают. Но когда вы подчёркиваете важность собеседования с программированием в процессе найма, вы заставляете сеньоров сомневаться в роли, для которой нанимаете их. «Они что, просто хотят, чтобы я был кодирующей обезьянкой? Неужели я буду растрачивать здесь свои таланты? Это шаг вперед или шаг назад?» Меньше всего вы хотите, чтобы талантливый разработчик сомневался в своей роли или в вашей компании в процессе собеседования. Когда вопросом становится кодирование на собеседовании, происходит именно это.
Суммируя все эти факторы, не стоит удивляться, что сеньоры ненавидят собеседования с программированием. Если вы хотите привлечь лучших и уменьшить трения при собеседовании на этом очень узком рынке труда, я бы посоветовал вам перестать применять собеседование с программированием.
Но, возможно, вы думаете о том, как сможете узнать, могут ли кандидаты программировать? Если вы с подозрением относитесь к найму разработчика такого уровня, не ощутив его способностей к программированию, я бы предложил вам дать очень короткое задание (которое занимает не более часа или двух и выполняется им дома). Большинство должны быть в состоянии найти небольшое количество времени для выполнения такого задания, особенно по той причине, что оно исключает работу по подготовке, необходимую для собеседования с программированием, и может быть разбито на временные отрезки, которые лучше вписываются в их напряженный график. Задание также позволяет им работать в своей родной среде IDE (если они этого захотят) и потратить любое количество времени для повторного знакомства со стандартными библиотеками.
Дополнительное преимущество — тот факт, что соискатель может посвятить этому упражнению как можно меньше или как можно больше времени, позволяет вам понять, что ими движет. Внимательны ли они к комментариям? Подумали ли они о тестировании? Структурировали свой код разумно и понятно? Насколько они сосредоточены на качестве работы? Другими словами, вы будете знать, могут ли кандидаты программировать и могут ли они программировать хорошо и в более реалистичных обстоятельствах.
Сеньоры — источник жизненной силы любой IT-компании. Они самые желанные, самые дорогие и их труднее всего привлечь. И особенно на исторически сложном рынке труда ваш процесс найма должен быть адаптирован к их конкретным потребностям, поскольку вы нуждаетесь в них гораздо больше, чем они нуждаются в вас. Они ненавидят собеседования с программированием, и вы тоже должны их возненавидеть, если вы хотите привлечь лучших.
А вам приходилось участвовать в таких проблемных собеседованиях?

Как обычно, промокод HABR — добавит 10% к скидке на обучение, отраженной на баннере.
Eще курсы
- Профессия Этичный хакер
- Frontend-разработчик
- Профессия Веб-разработчик
- Курс «Python для веб-разработки»
- Продвинутый курс «Machine Learning Pro + Deep Learning»
- Курс по Machine Learning
- Курс «Математика и Machine Learning для Data Science»
- Разработчик игр на Unity
- Курс по JavaScript
- Профессия Java-разработчик
- C++ разработчик
- Курс по аналитике данных
- Курс по DevOps
- Профессия iOS-разработчик с нуля
- Профессия Android-разработчик с нуля
welovelain
А еще дайте гуглить. Если у вас кто-то из сеньоров говорит, что работает без вечного гуглинга — увольняйте, он врет =)
Zifix
Весь вопрос что именно гуглить. Если «сеньор» лезет искать пример по поиску максимального числа в массиве… А это реальные случаи, между прочим.
welovelain
Такое вполне лучше гуглить, чтобы а) не растерять картину общего решения задачи, которое сейчас в разрабоперативной памяти б) гуглить быстрее чем самому писать, типовая задача находится за 10-20 секунд и в) не посадить в элементарном какую-нибудь тупую ошибку из-за того что голова занята пунктом а) и потом не дебажить весь алгоритм целый час
Aecktann
Такое не лучше гуглить. Задача поиска максимального числа в массиве решается в голове быстрее, чем открывается новая вкладка в браузере. Если кандидат действительно гуглит это, я боюсь, это red flag.
dmtrka
Хотелось бы глянуть на самый быстрый алгоритм поиска максимума (x86, g++ >= 9, linux, ядер >= 64). который получается
«быстрее, чем открывается новая вкладка в браузере».
Код очень желателен, т.к есть сомнения что он оптимален.
Aecktann
Не доводите до абсурда.
"Абстрактный алгоритм поиска максимума в неупорядоченном списке на абстрактном вычислителе с абстрактным компаратором" и "поиск максимума в компактном массиве в конкретной архитектуре и конкретных типах" — две разные задачи. На интервью на разогреве, когда вас просят написать поиск максимума в массиве, ожидают обычно первое, а не второе.
arrakisfremen
Ну, допустим, что в C# с LINQ это будет что-то типа array.Sum()
Это я помню. А почему я не могу глянуть в документацию, если мне нужно что-то чуть сложнее, например, Aggregate оттуда же? Я обязан помнить порядок всех аргументов?
И это реальный кейс, который со мной случился вот прям сегодня. Я работаю как фулстэк и я помню, как в JavaScript сделать reduce, а что в шарпе у Aggregate начальное значение задаётся первым аргументом, а не последний, я забыл.
Это всё, да, red flag?
Aecktann
Вы придумали другую задачу, другой вопрос, другие требования и утверждаете что они абсурдные. Прекрасно. Что это доказывает?
Перед интервью я всегда говорю кандидатам, что если они не помнят что-то в стандартной библиотеке, то они могут смело написать как придётся, на полупсевдокоде. Мы не на спецолимпиаде по запоминанию параметров у всей стандартной библиотеки. На интервью, если меня спрашивают, я поступаю так же. Никогда не возникало проблем.
arrakisfremen
Простите, я ошибся, нужно было использовать array.Max(), а не array.Sum(). Это уж точно red flag.
Нет проблемы это расписать. Но есть проблемы в реализации.
Aecktann
Вот у людей есть проблемы с тем, чтобы это написать. Над такой задачей можно просидеть все 45 минут интервью и закончить решением за O(n^2). К сожалению, я не шучу.
kraidiky
Если вы считаете, что алгоритм поиска максимального числа в массиве очевиден — возможно вы просто недостаточно квалифицированны чтобы задавать такие задачки на собеседовании? А?
Допустим C# синьер к вам на собеседование пришёл и первое что бы он подумал, если бы мне на собеседовании задали такой дебильный вопрос — значит есть какая-то подколка. А точно элементы в массиве не упорядочены хотя бы частично? А может есть какая-то эвристика и логично проверять массив как-то по другому, например известно максимально возможное значение?
Если уж вы тут заговорили о вычислительной сложности алгоритма сразу уточняющий вопрос — а какова длинна массива? А какой тип данных? А какой компилятор? На чё спорим, что при достаточной длине массива в C# будет эффективнее будет фикснуть массив и пройти по нему указателем в ансейфе? А если вы компилитесь через IL2CPP то лучше просто поставить директиву компилятора отключающую проверку границ массива, и которую я без гугла или подглядывания в своей проект ни в жизни не вспомню. А точно ли компилятор догадается, что два упоминания array[i] в теле цикла это одно и то же число и сунет его в регистр, или нужно ему на это указать.
А как должна обрабатываться исключительная ситуация когда элементов в массиве 0? Вы даже не обратили на это внимание, а между прочим такой код может подкинуть вам проблем.
А компилятор точно справится с оптимизацией прохода по массиву не с начала? А то вы рискуете нарваться на проверку Array bounds и доставание array.Length каждый раз из памяти.
И наконец самый главный вопрос, если вы рассчитываете составить о синьёре суждение на основании ответа на ТАКОЙ вопрос, может быть синьёру не стоит с вами работать?
imanushin
В такой задаче часто пишут "неупорядоченный массив", но вообще да, лучше спросить о таком.
Если мы говорим про C#, то
input.Length
, гдеinput
— это название переменной/параметра.Чаще всего в таких задачах пишут "целых чисел, вот пример — [3, 2, 5]". В любом случае, можно спросить, или же решить задачу для более общего случая, там где на вход передается IComparer.
Мы про C#? Вроде, эта задача решается более-менее одинаковым кодом, начиная с .Net 2.0.
Если кандидат простые задачи начнет решать через unsafe, то вопрос, выявивший подобное, уже сразу становится хорошим классификатором. А если еще и кандидат говорит с намеком на хамство "а на чё спорим", то вообще классно, что эта задачка встретилась.
В любом случае — алгоритм-то будет тем же самым, просто реализация немного иная.
Если мы говорим про "синьора", то кандидат и так знает, что foreach оптимизирован так, чтобы не было проверки массива. Да и стандартные циклы до
.Length
тоже иногда оптимизируются.А так — комментарий хороший, хоть и не влияет на сам алгоритм.
Если это важно, сохраните в переменную. Если нет — то зачем задавать вопрос? Разве хоть кого-то отсеяли за отсутствие микрооптимизаций?
Спросите "можно ли предположить, что в массиве есть хотя бы один элемент?". И действуйте согласно ответу.
Если интервьювера заботит этот вопрос, то он может спросить. Или же кандидат может ответить, если это действительно важно.
Это просто первая задача, чтобы проверить, человек занимается программированием, или нет. Просто самая база. Мы ведь не просто "сеньора" собеседуем, а "программиста-сеньора". Так что это буквально мелкий вопрос, чтобы проверить, что человек может решить хотя бы простую задачу, когда не надо долго и упорно понимать бизнес-область. По сути, проверяем, что "если человек понял, что надо на самом деле делать, то сможет ли он сделать хотя бы первые шаги".
Сеньорные вопросы будут потом.
Igor_90
Зачем тогда в видеокартах делают много ядер, которые решают 'простые' задачи, ведь засунуть данные в неё зачастую отдельный кодинг, муторнее чем тот же unsafe?
imanushin
Скорее всего, я плохо раскрыл мысль в своем комментарии. На первых этапах часто просят написать хоть какой-то простой код для того, чтобы понять, может ли человек написать ну хотя бы что-то тривиальное. Буквально чтобы отсеять людей, которые и программировать-то не хотят особо. Все сеньорные задачи про видеокарты и дизайн систем будут потом. Причина — немало приходящих людей даже эту простую задачу не могут решить ну хоть каким-то образом, к сожалению.
kraidiky
Вы бы не наняли меня, а я бы не стал нанимать вас, только и всего. Причём это, на самом деле даже хорошо потому что если:
Значит у вас, скорее всего нет задач, ради которых следовало бы привлекать меня. А задачи которые встают передо мной вы, скорее всего, просто на сможете сделать.И даже не факт, что это плохо. Как говорится «Чем круче внедорожник, тем дальше бежать за трактором».
ФАтальная ошибка — думать, что хороший код нужен только гуглу с фейсбуком. Я работаю на C# для Unity и там оптимизация необходима примерно всегда если ваш проект хоть чуть-чуть поднялся над уровнем Indi (но не во всех частях проекта безусловно), потому что FPS сам себя не алё.
То есть вы как бы правы, остаётся только загадкой, а вообще вам вообще приглашать на собеседование синьеров и переплачивать им то полтинника и выше если ваш «managed код, без дополнительных усложнений» вам прекрасно напишет любой мидл.
imanushin
Да, я так и написал выше. Запросто может быть, что кандидат не подходит на должность или компания не подходит для кандидата.
Я же написал совсем другое — подобная задача является необходимым, но не достаточным условием синьорности. Далее у кандидата все равно будут сложные задачи — на архитектуру и пр. Просто если не написал простой код, то смысла гонять по архитектуре?
kraidiky
В прошлой моей конторе это было оптимизировано ещё лучше. Прежде чем приглашать кандидата на собеседование ему задавали 10 простых вопросов в скайп, меньше чем по минуте на вопрос, причём делал это даже не технарь, а менеджер. После этого технари смотрели на бумажку с ответами и там было очевидно, кого приглашать даже и не надо начинать. Работало неплохо.
Вообще, по опыту найма с hh.ru я по виду резюме обычно мог определить тех людей, которых стоит приглашать. Но надо сказать, что шанс ошибиться тут больше, а времени и техлида на такую сортировку тоже уходило больше.
Srgun
Достаточно спорный момент.
Умение/неумение делать одно не всегда коррелирует с наличием и качеством других умений.
Потенциально я готов представить реально неплохого архитектора приложений, который не сможет сходу написать алгоритм оптимальной сортировки или поиска максимума. Просто потому, что в ежедневной работе ему это не требуется. При этом понимание оптимальности алгоритма у него есть, т.к. в институте соответствующую лабораторку сдал и нейроны в мозгу это зафиксировали, но на уровне понимания, а не досконального запоминания.
Если привести аналогию — директор по производству может не знать, как лучше вручную снять фаску с какой-то детали. Но должен понимать, что это за операция, и чего она стоит. При этом знание «как» хорошо скажется на его общение и авторитет у «простых работяг», но неизвестным образом влияет на результат его работы именно как директора. Потенциально, теоретик с MBA и без опыта работы с напильником может дать лучшие результаты на этой должности.
imanushin
Вы затронули очень важную тему — стоит ли управленцу быть хотя бы средним специалистом. А в противовес Вашему примеру я приведу свой — мне коллега рассказывала, что с ней работал Software Architect. Он был крайне хорош, закончил Оксфорд, по бумагам и речам вопросов не было. Опыт тоже присутствовал. Вот только он не знал, что такое Json.
Однако, вернемся к вопросу. В MBA практиках (если так можно сказать, так как литература там определена не совсем четко) есть разделение управленческих позиций на две группы — "исполнительный директор" и "управляющий директор". Первая группа — это не только управленцы, но и довольно неплохие спецы. То есть, условно, скрипт на питоне написать человек сможет, а потому человек способен разобраться в деталях того, что происходит. Вторая группа вообще не обязана быть специалистом в управляемой области. Но "управляющий директор" не выбирает способа, он обязан всегда полагаться на советы экспертов. По карьере получается так, что из специалиста сначала вырастает "исполнительный директор", который потом, после курсов MBA, может работать управляющим. Эти люди стоят очень дорого (насколько я смотрел в интернете — около ?200.000 будет минимальная общая компенсация в год), а потому, если кто-то с зп менее 1млн рублей пытается выдавать себя за птицу высокого полета, то будет разумный вопрос — "а почему бы данной персоне не пойти на более высокий оклад в крупную компанию?"
Другой важный вопрос, который Вы неявно подняли, это соответствие должностей в разных компаниях. Архитектор в небольшой компании на 50 человек запросто будет middle developer'ом в крупной компании, что по зарплате, что по уровню знаний (кстати, тут я привел реальный пример из жизни).
В любом случае, мы говорим не о высоких должностях, а о довольно базовых — Software Developer. И для этой группы людей возможность написать код является базовой способностью. Из этого пункта растет все остальное — и возможность предложить более удобное решение для пользователя, и способность понять, почему архитектура Х не подойдет проекту.
donPedro
Удалено, ибо я очень невнимателен этим утром
doctorw
По-моему, надо так
arrakisfremen
Метод .Max() в таком случае бросит исключение. И правильно сделает. Потому что по условию задачи совсем непонятно, что нужно делать, когда элементов в массиве вообще нет. И возвращать ноль или int.MinValue в данном случае — одинаково бессмысленно.
0xd34df00d
Нет, не одинаково.
int.MinValue
является единицей, иmin
иint.MinValue
образуют моноид (точно так же, как ноль является единицей для сложения, и они вместе тоже образуют моноид). Возвращатьint.MinValue
осмысленно настолько же, насколько осмысленно возвращать 0 из гипотетическогоSum()
или 1 изProduct()
. Что, кстати, делает имеющаяся у меня под рукой реализация:Вот кидать исключение (а лучше — возвращать
Nothing
или аналог) для функции расчёта какого-нибудь среднего арифметического для пустого массива уже логичнее, да.doctorw
Возвращать 0 в качестве максимального элемента, когда в массиве все элементы < 0, тоже неправильно.
Milein
Так в любом случае во многих практических применениях какое бы случайное число не возвращалось при отсутствии элементов, придётся проверять а содержит ли массив это число.
Хоть int.min хоть 0, хоть int.max верни, всё равно информации недостаточно.
Есть случаи когда int.min подойдёт, но я чаще встречаю что не хватает.
Paskin
Ваша задача требует некоторых уточнений — к примеру, оценки размера массива. Потому что поиск максимума в массиве гигабайт так на 50 — это несколько другой алгоритм. Будете потом удивляться что «кандидаты не знают классику».
wiha
Ага, на 50 гиг уже можно юзать распаралеливание на шейдерах например, а ну кто там за 15 мин на псевдокоде набрасает) И как это потом оценивать? В том то наверно и разница джуна и сеньера. Первый без вопросов напишет этот стандартный код, второй вначале всесторонне обдумает, примет решения по всем возможным вариантам. И как вариант вообще обойдется без этого поиска ))))
0xd34df00d
А смысл в параллелизме, если для такой задачи все равно все упрется в шину памяти?
wiha
Я ж и говорю, что для более опытного разраба такая задача встает в другом свете. В свете его опыта работы над другими проектами. Может упрется, а может и нет уже. Зависит от железа. А может этот функционал можно реализовать гдето в другом месте, например в АПИ доступа к данным и не «упирать» лишний раз. Это стандартное мышление опытного разработчика. Потому как если вопрос дошел до него, значит там есть реальная сложность. Боюсь что в реальной жизни сеньер на такую задачу потратит больше времени чем все интервью) Вначале все перегуглит в поисках ответа почему этот примитив еще не реализован, потом всю ночь в его мозгу будет вариться архитектура решения. И возможно в будущем это будет работать хорошо, но это не точно ) Студент же выдаст «правильный» ответ в пару минут.
Paskin
Скорее, синьор даст ответ в той архитектуре, в которой ему приходится работать сейчас. Точно так же, как стандартные библиотеки для разных архитектур имеют довольно сильно отличающиеся реализации — при абсолютно одинаковых API.
Paskin
Бог с ними, с шейдерами — давайте начнем с того, имеет ли смысл держать в памяти весь массив или лучше читать блоками, вспомним по дороге про отображение файлов в память и так далее.
0xd34df00d
А в шарпе типы разве не помогут?
amphasis
В шарпе типы конечно сразу все расставляют по местам, но тут то явно речь о написании кода «на бумажке», а не в IDE.
dmtrka
Ну а кстати а где спрашивают «первое»?
Ну прямо контору можно узнать? Я был пару раз на гугл лайк интерьвьюс в гугле, амазоне, фейсбуке (всегда неудачно к слову) так вот там скорее спрашивали как построить какойнить граф родственных связей по данным из БД или как построить цепочку установок пакетов с зависимостями ну и тд, а не как найти максимальный елемент в массиве.
В конторах которые по нормальней вообще ничего такого не спрашивали.
Aecktann
Первое может вполне попасться подзадачей в каком-нибудь гугле или фейсбуке.
Топологическую сортировку в разных формулировках вполне задают в FANNG и FAANG-like конторах, да. Её при этом необязательно знать, чтобы суметь написать работающий алгоритм.
dmtrka
Т.е например «объявить переменную» тоже спрашивают на собеседованиях, т.к это подзадача в реализации A*, это так нужно понимать?
Aecktann
Сказать слово (или даже фонему) — тоже. Продолжаете доводить до абсурда, да?
dmtrka
Говорить не обязательно, если немой придет на собеседование можно просто писать текстом или еще как.
dj1m
проблема в том, что это не показатель. И, как пример, там в соседней статье как раз бывший гуглопрограммист жалуется на жизнь, что они собрали систему и за день просрали 72килобакса. Ну зато все списки и мапы разложены как надо вместе со всеми деревьями.
PleaseKING
"Первое" лично я спрашиваю на собеседованиях в Гугле (ну не именно это, но в таком духе) — базовые навыки работы со списками/массивами, "напишите пару тестов", "оцените сложность вот этой вот функции из 5 строк кода" (никаких подводных камней), и т.д., и т.п. Даже на простой задаче можно очень содержательную дискуссию развернуть именно на понимание, а не на знание каких-то тонкостей.
90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…
Ну и читаем классиков.
Srgun
наверное потому, что 90% людей за 20 лет работы ни разу не приходилось работать со связными списками
Если для вакансии умение работать со связными списками критично — выставляйте в требованиях.
Если нет — то зачем это проверять.
ApeCoder
возможно, чтобы проверить умение разбираться со структурой данных? Понимать что такое ссылки и так далее.
Проверяют не умение работать с X а наличие каких-то знаний и умений позволяющих работать с X.
Условно если мне хочется знать силу кандидата я могу попросить его отжаться при этом мне важна сила, а не умение отжиматься.
Или я измерю температуру человека чтобы узнать, здоров ли он, хотя сама по себе температура интересует как признак. Просто градусником проверить быстрее, чем ездить в лабораторию.
Srgun
Хотите проверить понимание абстракций — спрашивайте про абстракции. А не про специфичную структуру данных, которую первый и последний раз использовал в лабораторке те же 20 лет назад.
Когда спрашивают про связный список — проверить можно только опыт работы именно со связным списком. А не то, сможет ли человек понять, как он работает.
Ибо ответ — «я не помню, что такое связный список» сразу засчитывается как отрицательный.
И если получите результат в 20 отжиманий, запросто решите, что силы недостаточно. А то, что при этом он сможет в рывке взять 200кг — останется за кадром.
Угу, и получите классическую среднюю температуру по больнице. Которая ничего не говорит о конкретике. Например, что у человека последняя стадия рака. Но градусник сказал что здоров — значит здоров.
ApeCoder
Мне хочется проверить навыки и умения. Не только знания. Если кандидат не справляется с задачей я и буду спрашивать, чтобы понять причину и подсказывать и пытаться понять.
Вы были бы правы если бы я написал, что буду проверять только отжимания.
Я не писал, что буду проверять только температуру.
Srgun
Вы уходите от темы.
Мой комментарий был про возмущение про то, что
типа это п… ц, а не программист.
Я утверждаю, данный пример — это проверка специфичной конкретики, которая практически ничего не говорит про общие знания и умения.
Ну вы же сами привели этот пример. И не упомянули никакой другой проверки. И я лишь указал, что данная проверка недостаточно для общей оценки.
ApeCoder
Ну фиг знает. Одно дело, если он не знают, что означают эти слова "связанный список" другое дело, если не понимает даже после демонстрации структуры и не может решить задачу.
Я увидел здоровенных ребят в комбинезонах, ходивших в обнимку, чертыхавшихся и оравших немелодичные песни на плохие стихи. То и дело попадались какие-то люди, одетые только частично: скажем, в зеленой шляпе и красном пиджаке на голое тело (больше ничего); или в желтых ботинках и цветастом галстуке (ни штанов, ни рубашки, ни даже белья); или в изящных туфельках на босу ногу. Окружающие относились к ним спокойно, а я смущался до тех пор, пока не вспомнил, что некоторые авторы имеют обыкновение писать что-нибудь вроде "дверь отворилась, и на пороге появился стройный мускулистый человек в мохнатой кепке и темных очках".
Srgun
Возможно тут есть нюанс, что собеседуется сеньор, и ответить «да, конечно знаю» про вещь, которую он помнит очень приблизительно — психологически может быть непросто, с учётом того, что собеседование — это и так стресс.
Кстати, извиняюсь за излишнюю категоричность, т.к. в исходной цитате, было про «понимание» связного списка, а не про его «знание», невнимательно прочитал. Если задачи на уровне понимания — это действительно абстракция.
Daemonis
Тут был бы уместен пример общего знания :)
Srgun
Уже упоминали те же массивы и списки, без которых не обходится ни одна более-менее сложная программа.
Но вообще грамотно придумать вопрос намного сложнее, чем на него ответить. Ибо формулировка вопроса/задачи должна коррелировать с проверяемыми умениями, иметь критерии правильности ответа, отсекать возможность случайного угадывания и т.д.
В этом плане проще давать около-реальные задачи бизнеса, чем гонять по теории.
Daemonis
Что именно массивы и списки? Поиск максимального значения в массиве тут забраковали :)
Околореальные задачи бизнеса уж точно не являются общим знанием.
Srgun
Угу, потому что голая теория и никакой практики. В проде за такие велосипеды по рукам бить принято.
Зато позволяют оценить, как человек думать и работать будет.
Хз, что и в какой пропорции важнее — знание или практика. Серебряной пули точно нет.
PleaseKING
Наверное, дело в том, что многие — и я в том числе — считают, что человек, не знающий, что такое список и как он устроен, программистом называться не может. Ну или массив, и в чем между ними разница.
Цель — проверить умение программировать вообще — решать программистские задачи. Какие поставят — такие и решать. И работа со списками — это только индикатор такого умения, как пишут выше.
Srgun
Изначально речь шла про связный список. Который в индустрии используется ОЧЕНЬ редко из-за его специфичности.
Ну так и ставьте программистские задачи.
А в примере со связным список — проверяется знание теории и практики работы со специфичным типом данных. Оно может влиять на умение решать конкретно ваши задачи. А может и нет. Только это надо понять до того, как такие вопросы задавать.
PleaseKING
Да нет же! Проверяется умение решать поставленные задачи на простейших примерах. Не надо знать, как обращать связные списки, но надо понимать, как он устроен, и суметь решить задачу его обращения (придумать решение). Это не требует никакого заучивания. Это требует умения воплощать в коде элементарные алгоритмы. Работать с переменными, ссылками, памятью, понимать, что это вообще такое.
Srgun
Ещё раз — неумение работать со связным списком говорит лишь о незнании связных списков. А не о том, сможет ли человек с ним работать.
Вопросы про массивы и листы на порядок более актуальные, ибо без них действительно программы не пишутся.
red75prim
Гы. Требуется программист со знаниями: односвязных списков, поведением знаковых/беззнаковых целых при переполнении в (список языков), условий допустимости использования сортировки пузырьком.
Srgun
Несмотря на кажущийся маразм ситуации — да, это честнее. Не настолько досконально, но пунктик «знание алгоритмов работы с большими объёмами данных» вполне себе уместен в вакансии.
Тогда чел будет знать, что его и по хештейблам погоняют, и различия между типами деревьев спросят, и списки попереворачивать попросить могут. И если не считает свои знания/опыт релевантным — то не будет тратить своё и чужое время.
А иначе появляются возмущения от собеседующих, что пришёл чел с опупенным заявленным опытом работы, а «на наши простейшие» вопросы ответить не может. Если для ваших задач это минимальный базис — заявите сразу. Опыт соискателя может быть сильно нерелевантен вашим запросам, несмотря на схожесть по общим признакам.
Моей фантазии не хватает представить, зачем это знание нужно кому-то за пределами института. С таким же успехом можно о различии поэтов серебряного века порассуждать.
В 99% случае всё, что надо знать о сортировке — это что она вызывается из библиотеки Math или подобной. Всё остальное нужно либо в 1% случаев (если не меньше), либо ведёт к появлению костыльных велосипедов.
AndyPike
Сложилось устойчивое мнение, что для фронта это не надо никогда. Я про реализацию сортировки вручную, а не нативными методами .sort((el) => a — b).
На клиенте нет Big Data, и быть не должно.
Для этого есть Back End, там это может понадобиться, и нередко алгоритмы надо реализовывать руками в особых случаях с запутанными зависимостями. Это уже зависит от задачи, БД, заранее продуманной архитектуры.
Но в 1% это помогает и на фронте тоже иногда, когда он очень запутан. Не количеством данных, а сложностью алгоритма.
Srgun
Ни разу не сталкивался с такой необходимостью даже на бэке, при том, что это мое основное направление.
Не буду утверждать за конкретный случай, но делать собственную сортировку — имхо — последнее дело, когда по другому уже совсем никак.
Мне в своё время сильно понравилось такое высказывание про квалификации программистов: джюниор умеет решать простые задачи простыми методами, мидл — сложные задачи сложными методами, сеньор — сложные задачи простыми методами.
По ощущениям, к вашему примеру это высказывание очень хорошо подходит.
При наличии хоть какого-то запаса времени лучше разобраться со структурами зависимых данных, чтобы с ними проще работать было, чем в имеющуюся сложность ещё свою сортировку запихивать.
kraidiky
Столкнулся как-то раз с необходимостью на C# выбрать 20 наибольших чисел из 300-10000. В готовых библиотеках ничего подходящего не нарыл. Может плохо копал, конечно. Но в целом иногда задачи на сортировку встречаются даже в реальности.
Srgun
Это задача на последовательное применение 2 операций: array.Sort().Take(20);
Никаких самописных велосипедов тут и близко не надо.
kraidiky
В первом прототипе в конце концов я так и оставил. Потому что для маленького исходного числа я так и не смог сделать лучше чем вот это. :) Но дело в том, что уже в следующей версии мне нужно было сделать это для, например миллиона чисел, и там решение близкое к o(n*log(n)) уже будет выглядеть немного не очень.
Srgun
Для миллионов и более — могут быть ньюансы. Но для одномерных списков — скорее всего некритичные.
Но в любом случае — своей сортировки здесь не видно. Сортировать тут имеет только свой массив Топ20, чтобы последний(минимальный) его элемент сравнить с текущим значением из большого массива. Тогда сложность прохода по большому массиву будет o(n), а сложность сортировки массива 20 элементов, которая будет вызываться неопределённое кол-во раз (>=20, но по вероятности сильно < n) — скорее всего ничтожна, по сравнению с миллионами основного массива. Остаётся правда краевой момент с полностью отсортированным исходным массивом. Но кастомной сортировкой он всё равно не решится.
Но соглашусь, именно поиск максимумов тут получится самописный.
Хотя с точки зрения стоимости написания и отладки кастомного алгоритма, возможно можно пренебречь повышенной сложностью при использования стандартных методов, т.к. в рантайме даже при миллионах счёт, скорее всего, всё равно на доли секунды будет.
kraidiky
Всё так, но к сожалению пренебречь в рантайме я не мог. Основной вопрос, который интересовал — имеет ли смысл держать свой массив размером 20 в отсортированном состоянии или просто держать в отдельной переменной минимум и при каждой замене находить новый минимум и элемент который нужно заменить полным проходом. Этот вариант показал себя чуть лучше. Видимо за счёт того, что не нужно было сдвигать пол массива вниз каждый раз при добавлении нового элемента. Впрочем, это, возможно, особенности реализации.
Srgun
Охотно верю.
Но вернувшись к нашим баранам — весь этот алгоритм к кастомной сортировке пузырьком или как-либо по другому это не имеет отношения. Сортировка, в итоге, может использоваться стандартная из библиотеки.
А можно вообще без неё обойтись, что, похоже, и получилось в итоге, т.к. задача свелась к поиску максимумов/минимумов в 2 массивах.
kraidiky
Ну при поддержании отсортированного массива там кроме первых 20 элементов тоже получается не коробочной сортировкой. Выгоднее поиск места для вставки за log(n) делением пополам и вставка сдвигающая пол массива вниз, o(n) но часто меньше, потому что очень быстро возникает ситуация, что новые элементы попадают в самый низ списка. Так получается меньше сравнений, которые не предиктятся процессором (что несколько не совподает с устаревшей логикой о-маленького).
Srgun
ИМХО, экономия на спичках.
Если остались какие-то цифры (хотя бы в голове) от итоговой (всего алгоритма) разницы с коробочной сортировкой — с интересом выслушаю.
wataru
Эту задачу, кстати, я спрашивал на интервью в гугл, пока ее не забанили за извесность.
Тут не надо никаких 20 элементов много раз сортировать! Вот зачем нужно знать алгоритмы.
Тут можно, например, вместо сортировки использовать pritority_queue какой-то (храните в очереди на минимум 20 максимальных пока найденных элементов. Новый элемент или вытесняет минимум, или идет лесом).
Тогда вместо O(n log n) будет O(n log k) — при n=10^6 и k = 20, это ускорение в 4 раза. Плюс к этому оно сильно дружнее к кэшу и вообще константа у этого решения меньше. К сожаленю, в js нет встроенной структуры данных позволяющей реализовать priority queue малой кровью. Но структура весьма простая и так.
Но, если знать алгоритмы хорошо, то можно запилить чуть-чуть обобщенный QuickSelect, который в среднем работает за O(n) — это в 20 раз быстрее наивной сортировки.
Скажете: всего-то в 20 раз соптимизировали — фигня… Но тут 20 раз, там 2 раза, вот тут еще 20% скинули… Результат пользователю будет заметен.
Srgun
В целом да, грамотность специалиста со знанием оптимальных алгоритмов выше, чем без оных. Но большинство рутины делается на гораздо более примитивном уровне.
А универсальный специалист стоит дороже. И рутиной ему заниматься скучно :)
Всё, что дольше 2-3 секунд ожидания пользователем ответа — оптимизировать надо. Разница более 30% заметна без секундомера, соот-но полезна к реализации при превышении тех самых 2-3 секунд.
vedenin1980
Вообще, 2-3 секунды это уже много, если каждая кнопка ждет по 2 секунды — это может раздражать, про игры вообще — целая вечность за которой персонаж успеет погибнуть.
По-хорошему человек не замечает замедления при ответе около 0.3-0.4 секунд, все что выше будет уже заметно.
0xd34df00d
Тут, кстати, ещё интересно, что в некоторых ленивых языках можно просто сконструировать
take 20 . sort
(сортируем и потом берём 20 первых), и это выражение сортировать весь список не будет именно за счёт ленивости. Правда, посчитать асимптотическую сложность уже будет куда сложнее.Srgun
Я не в курсе за «некоторые» языки, но по логике — последовательность операций take + sort сначала возьмёт элементы, а потом их отсортирует. А надо наоборот — сначала отсортировать, потом взять из верхушки отсортированного.
А о продвинутых языках, которые бы дали оптимизацию конструкции sort + sort я не слышал. Было бы прикольно, но боюсь в более-менее универсальном виде это нерационально трудоёмко для оптимальной реализации.
Milein
Это видимо был хаскель, и это вроде читается справа налево. Без понятия почему так.
wataru
Ну, если все — функции, то Take20(Sort(array)) — как раз то, что надо.
0xd34df00d
Да, это хаскель, и это читается справа налево. В математике композиция функций записывается справа налево (g 0 f означает применение сначала f, а потом g), поэтому в хаскеле решили сделать так же.
vedenin1980
Но вы в курсе, что log n от миллиона это 6?
На практике, может оказаться, что алгоритм O(n*log(n)) будет работать быстрее O(n) и на миллионе, так как на каждую итерацию O(n) делает в 20 раз больше операций (например, постоянно держать массив из 100 000 наибольших чисел и сортировать его на каждой итерации — формально тот же O(n)).
А на миллиарде оба алгоритима могут упасть с OutOfMemory и их в любом случае нужно будет заменять.
То есть, не стоит ориентироваться только на O алгоритма в большинстве практических случаев.
wataru
А логарифм 20 — 1.3 — более чем в 4 раза меньше. Сокрашение в 4 раза — плохо что ли?
Потом, не надо забывать про константу. Логарифм вылезает из-за деления пополам и он двоичный. На самом деле, если тупо операции считать, то там будет не 6*n а 20*n. Потому что log_2(1000000)~20.
vedenin1980
Смотря от какой цифры, если алгоритм работает 0.4 ms, а ответ нужно дать пользователю в течении 500 ms, сокращение в 4 раза до 0.1 ms не имеет большого смысла, намного важнее оптимизировать другие части системы.
Да не стоит забывать про константу — не стоит забывать, что O(n) при равном n может выполняться и 1ms и один час, так как константа у O(n) при практическом применени может быть очень разной.
Например, формально ArrayList и LinkedList в java имеют одинаковый сумарный O, но на практике первый практически всегда быстрее, даже в тех случаях когда считая только O должно быть наоборот.
0xd34df00d
Ух ты, наконец-то стандартная либа плюсов в чём-то заруливает C#'ную! У нас тут есть
std::nth_element
.wataru
Но если вам нужны n максимальных элементов, то надо что-то допиливать.
Или еще один проход и разбираться с дубликатами, или писать через priority_queue/quickSelect.
0xd34df00d
Нет, он их переупорядочивает достаточно для решения искомой задачи:
Srgun
Это, на практике, тоже абсолютно бесполезно.
Всё, что надо знать о переполнениях — это то, что они бывают, и что если оно случилось — то это критическая ошибка, которую надо исправлять.
Необходимость закладывать логику программы на поведение состоянии переменной при переполнении — это совсем экзотика-экзотика. И там, где это действительно надо — простого знания о переполнениях мало, надо ещё чётко представлять, как это можно использовать в своих расчётах. В общем — это полноценное требования получается, а не та вещь, которую мимоходом обсудить можно на вакансию клепателя форм.
red75prim
Ага. И даже возникает подозрение, что этот блок требований можно описать короче. Системный программист, например.
0xd34df00d
Ага, именно поэтому не так давно мы с одним товарищем обсуждали особенности IEEE754 применительно к задаче генерации случайных чисел. При этом ни он, ни я не являемся системными программистами (я-то вообще уже полгода не писал код, который бы потом запускался), а IEEE754 ИМХО на порядки сложнее целочисленного переполнения.
0xd34df00d
«Не приходилось работать»…
У меня вот прям сейчас было интервью на синиор разработчика (правда, непонятно, на чём — то ли на хаскеле, то ли вообще формально верифицировать), где, короче, мы начали с обсуждения недостатков реализации словаря на связных списках (к слову о связных списках), потом перешли к обсуждению кешей процессора, потом перешли к обсуждению распространения волн в проводнике и физике разницы скорости света в вакууме и в, собственно, проводнике.
Мне короч понравилось. Всяко лучше, чем в фаангах у доски скобочки балансировать.
AndyPike
Как понял, они тебя проверяли на программистику, архитектуру процессоров, радиотехнику, физику, электротехнику.
На такие темы я могу пообщаться, т.к. ФРТК МФТИ в лохматые годы.
Видимо, адресно ищут. Или по интересам.
Senior должен знать всё ).
0xd34df00d
Там скорее просто разговор так зашёл, мол, почему кэша мало, но он быстрый, а оперативки много, но она медленная (а про кэши разговор зашёл как следствие обсуждения недостатков связных списков). Так-то среднему хаскелисту или доказывателю теорем это всё не нужно.
К счастью, я сам МФТИ, хоть и ФУПМ, так что что-то даже про физику распространения волн и всякие там скин-эффекты смог сказать.
A114n
С интересом прочитал статью.
Классик прямо говорит, что его цель — нанять звёзд, людей, которые для развлечения и удовольствия дома пишут на ассемблере. И строго предостерегает от найма людей, которые только похожи на звёзд или могли бы быть ими, но на самом деле не являются.
Это не совсем стандартная ситуация найма. А вот вопросы про связный список хотят сделать стандартными для любых собеседований.
PleaseKING
Ну по мне так в этом цель любой компании, нет? Нанимать лучших из имеющихся…
A114n
Вовсе нет.
Цель большинства компаний — нанимать работника, который сможет решить нужную для бизнеса задачу за установленное время и, по возможности, за минимальные деньги.
PleaseKING
Это-то разумеется, но это очень сложно предсказать. Так что реальная стратегия — лучшие в пределах бюджета — это, по крайней мере, можно измерить.
ardraeiss
… за ограниченный бюджет и чтоб не убежал от скуки. Хотеть от него "про запас" больше, чем нужно для реальной работы — это именно ценник специалиста поднимать и завышать ожидания от работы. Или, при прижатом "ровно столько и не больше" ценнике, снижать количество пришедших, вплоть до нуля.
Да, в теории это тоже вариант, свести всех могущих откликнуться к одному единственному пришедшему "прям что надо", но что-то мне сомнительно.
PleaseKING
По-моему логично — нанимать максимально хороших людей, вписывающихся в ваш бюджет. Разве нет?..
ardraeiss
Завышение требований никак не гарантирует "максимально хороших людей". И при этом добавляет шансы скоро начать искать замену, ибо завышенные требования привели к завышенным же ожиданиям от такой работы — а там чижика съели.
PleaseKING
Ну, наверное, стоит честно говорить, чем предстоит заниматься, чтобы те, кому не интересно, не нанимались?
AndyPike
Не всегда.
Over skilled тоже не любят.
Даже если у тебя тяжёлые времена прям сейчас, и ты готов на меньшую зарплату. Будут считать, что ты сбежишь в любой подходящий момент. Это большая проблема — притвориться потупее, чем ты есть, когда чуствуешь это.
Но сбежишь всё равно.
SwingoPingo
А бывает и такое, что меня спросили как работает библиотека, которую я и написал. К слову ответить не смог, она мне нужна была именно в тот момент и вылетела из памяти сразу как только. И тут с конечно если компании так прям важно что бы я помнил все объекты и методы «прямо сейчас», то я им наверное и не нужен.
dim2r
Если язык программирования предоставляет 100500 способов найти это число, то можно и загуглить. Пожалуйста, без гугла найдите наибольшее число в тензоре PyTorch, который хранится в оперативной памяти GPU.
Simplevolk
Нагуглил за 10 секунд:
Zifix
В продакшене лучше не писать велосипедов, и использовать std::max_element, например.
Но речь-то про собеседование, где ни один из ваших пунктов не актуален.
lpssp
Вы серьезно гуглите как найти наибольшее число в массиве? А что вы не гуглите, простите?
welovelain
Ну, в джаве поиск максимального числа в массиве можно сделать несколькими разными вариантами, в зависимости от парадигмы. Если я такой велосипед напишу с циклом и сравниванием, мой пулл-реквест просто не пропустят, потому что есть, ну, например, Arrays.stream(decMax).max(Double::compareTo).get();. Я этот метод и не вспомнил бы, потому что использовал его за 5 лет работы, ну, раз или два. При этом нагуглив я точно вспомню, что он делает, как, какие грабли, подходит ли к текущей парадигме, итд.
ReaderReader
Вы очень сужаете задачу, заранее принимая по умолчанию никем и нигде неоговоренные условия. На уровне сеньора человек не думает «от сих до сих». Вам это, вероятно, представляется чем-то а-ля вот таким, написанным за 20 секунд
А сеньор сразу начинает грузиться на тему многопоточности, архитектуры, особенности исходных данных (Они как-то упорядочены? Какой у них формат? Какой у них размер?), предельно возможного размера массива, тестов, и еще 1024 подобных вопроса. И вот тогда начинается гугление, чтобы не изобретать велосипед, который к тому же скорее всего окажется менее эффективным, чем уже известное и отработанное решение. Или по крайней мере будут какие-то куски известного и отработанного решения, которые можно будет применить. Собственно говоря, ваш вопрос как раз и показывает, что вы не видите разницы между сеньором и мидлом. Задача в такой формулировке (найти максимальное значение в массиве) хороша для мидла: ему дали задание, он его решил строго «от сих до сих». А у сеньора в этот момент голова взрывается от обилия возможных вариантов, про которые ему ничего не сказали.
sentyaev
Не, у сеньоров уже голова не взрывается, они задают уточняющие вопросы и конечно же не верят ответам, а оценивают вероятность и процент правды.
ReaderReader
Если я начну задавать уточняющие вопросы по заданию «найти максимальный элемент в массиве», то первую половину времени из интервью человек будет отвечать на мои вопросы, а вторую половину будет отвечать на мои аргументы. Потому что я начну вообще не с задания, а с вопросов, в каком проекте это собираются использовать, и какие именно аргументы привели к тому, что для этого надо писать свой велосипед вместо использования уже существующих решений. Далее мы плавно перейдем к обсуждению проекта, аргументов за постройку велосипеда и против него, архитектуры и т.д. В общем к концу первого часа собеседования до собственно кода мы точно не дойдем. Если же вдруг случиться нечто, будут веские аргументы для постройки велосипеда, и мы все-таки дойдем до кода, то первое, что я скажу, будет что-то вроде: «Ок, я понял ваши аргументы. Теперь давайте для начала посмотрим уже существующие решения для подобных задач»
Нет, я не спорю, возможно, именно это и было целью данного вопроса: проверить меня как сеньора в этом аспекте, т.к. для сеньора задания из серии «пойди туда, не знаю куда, принеси то, не знаю что» являются вполне себе типовыми. И для начала надо при помощи утюга, паяльника, пассатижей и прочих специальных предметов выдрать из приславших задание определение «туда», потом выдрать из них же определение «то», потом убедиться, что они имеют согласованное между собой мнение, т.к. бывает, что желающие понимают под одними и теми же словами самые разные варианты вплоть до строго противоположных и т.д. И вот после всего этого можно уже задумываться об архитектуре и дизайне. Но я лично сильно сомневаюсь, что задающие подобный вопрос, имели в виду именно это, а не написание сферического кода в вакууме. Я конечно могу написать за полминуты ни о чем не говорящий вариант (что я, собственно говоря, и сделал выше), который ни в один продакшен не пойдёт по причине его полной ненужности, но при чем тут позиция сеньора? Как и что вышеописанный код скажет обо мне как о сеньоре?
ApeCoder
Вам скажут, "напишите пожалуйста самый простой код, который сможете прямо сейчас". Тут уж вопрос понимания. Если обе стороны изо всех сил стараются друг друга понять, то вы друг друга поймете. Если у вас эмоциональное убеждение что задача какая-то глупая, то вы сможете в любом случае затянуть все что угодно до бесконечности.
Что кстати, косвенный признак того, насколько вы будете хотеть понять собеседника на работе.
Что вы обладаете базовыми навыками программирования, а это мастхев для сеньора.
А если не напишете что не обладаете и что не можете быть сеньором.
ReaderReader
У меня не убеждение, что задача глупая, у меня мнение, что для позиции сеньора задача неполная. Если это проверка на мое умение как сеньора тащить задания / проекты с нуля, с неполной информацией и т.д., тогда все нормально (о чем я писал в предыдущем комментарии). Если же это проверка, могу ли я писать код на уровне джуна, то по моему мнению она выглядит абсолютно бесполезной.
Написание алгоритма на уровне джуна в по одной-единственной теме дает понимание того, что у меня есть базовые навыки программирования? А вдруг я знаю массивы, но не знаю списки? А вдруг я знаю массивы, но вообще не знаю деревья? А вдруг я знаю массивы, но не знаю разницы между указателем и ссылкой? И еще 1024 подобных вопроса. Если уж так важна данная тема, то давайте тогда сделаем полную проверку на все базовые знания: вдруг я еще чего-то базового не знаю. Дабы быть правильно понятым: нет у меня корона с головы не свалится по причине ее (короны, а не головы) отсутствия, и мне несложно этот код написать, но данная задача абсолютно бесполезна для позиции сеньора. Более того она вызовет у меня недоумение и подозрение: если подобный код проверяется на позиции сеньора, то чем, собственно говоря, я там буду заниматься? Писать что-то подобное?
ApeCoder
Конечно неполная. Есть еще все остальное собеседование. Но я говорил не об этом, а о том, что если вы захотите друг друга понять, то вы поймете.
Ага. А ненаписание дает понимение что нет.
Конечно, собеседование не состоит из одной этой задачи.
Писать не проще чем что-то подобное. Это задание не для того, чтобы дешево отсечь менее квалифицированные кадры, а не для того, чтобы только по нему судить сеньор вы или нет.
Вы почему-то рассматриваете только ситуацию когда это задание проходят, но не рассматриваете ситуацию когда это задание не могут выполнить.
lpssp
«Вам это, вероятно, представляется чем-то а-ля вот таким, написанным за 20 секунд» — это ваше предположение :).
«И вот тогда начинается гугление, чтобы не изобретать велосипед, который к тому же скорее всего окажется менее эффективным, чем уже известное и отработанное решение» — а, что, в интернете есть решение именно под вашу задачу? :) Звучит еще менее правдоподобно, чем то, что я с первого раза напишу верное решение :).
«Собственно говоря, ваш вопрос как раз и показывает, что вы не видите разницы между сеньором и мидлом» — ну или вы ее не правильно видите. Тут одно из двух :).
«А у сеньора в этот момент голова взрывается от обилия возможных вариантов, про которые ему ничего не сказали.» — а, что задать уточняющие вопросы уже нельзя?:) Обычно в ответ говорят ограничиться простым случаем :). В реальной обстановке же часто нужно на основе известного классического алгоритма написать реализацию, которая не получается простым maxOf, например. По-моему это очевидно.
HEKOT
Вот о том и речь. Я провёл последние 13 лет в С и С++ разработке тестирующего софта для железа. Два года назад собеседовался на позицию программера (сеньёром она не называлась, но фактически являлась). Проект — создание тестирующего софта для железа (как потом оказалось, на С#). Если бы меня на собеседовании попросили вспомнить С++ алгоритм поиска максимального числа в массиве, я бы очень плохо подумал о таком интервьюере. Я до этого с задачей поиска максимального в массиве встречался лет 20 назад, к тому же на Паскале.
Ну ОК, отсеяли бы они меня по этому критерию. Я бы продолжал искать работу в условиях безработицы в нашей местности. Деньги бы кончились, и «за кооперативную квартиру не заплачено». Они нашли бы кого-то, помнящего, как искать максимальное в массиве.
В реальности же я попал на ту работу. Сделал им систему тестировния, применив свой 10-летний опыт. Система работает на заводе. Все довольны.
ЗЫ: максимальное в массиве в том проекте не искалось.
ЗЗЫ: если компании нужен справочник по плюсам, надо купить справочник по плюсам, а не сеньёра.
Static_electro
Вы это серьезно? Если у вас вызывает сложность написание поиска максимального элемента в массиве — что-то сильно не так, неважно сколько лет назад вы с этой залдачей встречались. Это элементарная операция. Вот просто элементарная — неважно, сколько у вас лет опыта и с какими языками.
Если же задача не вызывает сложности, то в чем проблема? Лень? Или корона давит?
webwork
Однажды я проходил собеседование с кодированием, к своему стыду я ничего не смог написать — я очень сильно волновался — там была задача написать алгоритм вычисления чисел фибоначчи. Я чувстсвовал себя архиглупым. С тех пор на такие собеседования не хожу, т.к. боюсь завалить. Думаю, что я и поиск максимального числа напсал бы как-то не так — или медленно, или неправильным способом.
Static_electro
ну, волнение — это известная проблема, и это все-таки другая проблема. У меня подобное тоже случалось, и вообще я не то чтоб прям магистр кода. Но если уж я пришел на собес (на сеньорскую позицию, да), и меня просят написать что-то — я беру и пишу (ну, пытаюсь). Потому что… ну потому что могу, в конце-то концов.
HEKOT
Ну на С — не вопрос, а на современных плюсах, возможно, задумался бы. Связано это не с незнанием, а с тем, что ещё с института терпеть не могу экзаменов. Забываю примитивные вещи: термины, например, или помню русский термин, а английский — нет. Или могу на листочке накосячить с каким-нибудь примитивным синтаксисом, который на клавиатуре уже в пальцах запомнен (например, написать что-то типа p* вместо *p).
При этом само по себе собеседование меня не напрягает. Проблема именно с тестированиями.
Кстати, тогда я без работы сидел полгода, а «для дома, для семьи» ничего не писал. Последний проект на старой работе был на С под голое железо.
А потом, уже на новой работе был год с лишним на C#. Тоже без практики на С и С++.
N-Cube
Давайте рассмотрим типичную задачу выполнения свертки над изображением, превышающим размер доступной оперативной памяти, с варьируемым окном и ядром при использовании OpenMP/OpenMPI. Пусть ядро будет как раз функцией максимума. Покажите ваш код вычисления — не забудьте подумать, как совместно оптимизировать вычисления для набора заданных окон и так далее, ну да вы же сами все знаете. Заметьте, за плохой результат или его отсутствие вам ничего не будет, в отличие от рассматриваемой в статье ситуации:)
red75prim
А может быть всё-таки рассмотрим типичную задачу на собеседовании, которую дают с целью проверить, что собеседуемый вообще может код писать?
По задаче: арендовать инстансы с бОльшим объемом оперативки, чтобы нужные куски в память помещались и использовать стандартные функции BLAS.
N-Cube
А это типичная задача для каждого, кто использует облачные вычисления для обработки космоснимков на Google Earth Engine, к примеру. Объем данных — порядка миллиона снимков (сцен) объемом гигабайт каждый. Да, вот такая предметная область и типичная в ней задача — автор статьи ведь не указывал свою предметную область, значит, речь может и о такой задаче идти. Вы точно хотите потребовать кластер с петабайтом оперативки на собеседовании? Не говоря уж про интернет канал, чтобы все это скачать. Адекватным решением будет яваскрипт для Google Earth Engine, который выполнится бесплатно за полчаса примерно (ну, как повезет, на самом деле, но может и за полчаса). Да, полезно представлять, как гугл это все реализует, но решить указанную задачу локально не получится все равно.
Malduan
Ну, например, в моем случае, я очень плохо что-либо на собеседованиях пишу, даже если могу это быстро и элементарно сделать на рабочем месте или дома. И даже на работе, если кто-то за спиной стоит, тоже очень напрягаюсь. И каждый раз после такого собеседования, сразу жестко себя фэйспалмлю как только выхожу из кабинета.
Для меня такие кодинг собесы — чистые стресс тесты и ничего более.
Nomad1
Есть еще важный нюанс. Сеньор сразу думает не только о решении задачи, а о всех вариантах его использования, упаковки в библиотеку, стандартизации, переводе на темплейты, использования внутри BigInteger и т.д. Вы этого не видите, но под капотом происходит просчет вариантов в 8+ потоков, а главное лихорадочный поиск ответа на вопрос «где же подвох?». Если же не происходит — значит вам попался не настоящий
шотландецсеньор.Zifix
Он должен все эти вопросы задать перед началом решения задачи. Если вообще ничего из этого не требуется, написать просто алгоритм, без выкрутасов и «смотрите как я могу».
SwingoPingo
Если «он должен» столько много да еще и за ограниченные деньги, то скорее всего новости для компании не очень…
Zifix
Ну так грейд обязывает. На то он и сеньор, а не джун, чтобы знать, где можно на грабли наступить, где скрытая сложность притаилась.
Зарплата всегда представляет собой вполне определённую сумму, вполне себе конечную и ограниченную.
SwingoPingo
Вот доводилось мне работать с людьми уникальными можно даже сказать, редкими для профессии, но блин, и они в лужи садились знатно, нюансы то в проектах возникают по ходу развития. Капитан корабля прокладывает курс исходя из общих соображений на берегу и выруливает уже на месте ориентируясь на ситуацию. Требовать от капитана проложиться перед выходом в море — это как требовать билет на Титаник, право же слово. Бесконечно полное выявление всех условий задачи обычно требует бесконечных же средств и времени на это.
Zifix
Дело в том, что это просто возможность капитану продемонстрировать свой опыт, рассказать, сколько раз его корабль терпел крушение, наталкиваясь на всяческие подводные камни, и какие меры он будет применять в плавании, если увидит признаки айсберга или мели.
Бесконечно полное не требуется.
AndyPike
Вот именно для этого скилл коммуникаций тоже нужен для Senior+.
Не чувствуй себя гуру.
Общайся с бэком (если ты на фронте).
Выноси на общие обсуждения, с первого раза, со второго.
Ты должен решить проблему в любом случае, и лучше, чтобы оптимально.
WASD1
В примере по-моему не сеньор, а перемудривший джун.
Единственный значимый вопрос — возможно ли сохранение ссылки на элемент, с гарантией последующего доступа, ну и про кофе, конечно
А вот разумный вопрос — можно ли возвращать FLT_MAX при отсутствии элементов не прозвучал.
Но даже в этом случае можно было бы просто задать вопрос.
Вас всё-таки нанимают для решения проблем бизнеса, а не сидения в башне из слоновой кости.
SwingoPingo
Тут есть два подхода — решение проблем на момент «сейчас», когда Вас наняли по конкретному ТЗ за конкретную сумму. И решение проблем с прицелом на неопределенный срок, когда Вам же придется решать и проблемы, созданные текущим решением проблем, за заранее фиксированную и прописанную в договоре премию. Имеем бесконечное множество вариаций этих двух подходов, любое из которых, очевидно, таки да «решает проблемы бизнеса». Вот что Вы подразумеваете под «решением проблем»? Входит ли в Ваше понятие оценка соискателем этих самых «проблем» для выбора оптимального варианта решения или соискатель все таки должен быть телепатом?
Mikluho
Очень поддерживаю! А собеседующий, обычно, имеет ввиду одно правильное решение, и надеется, что найдёт того, кто угадает…
yakimchuk-ry
Человек может решать задачу как ему удобно, главное качественно.
Вариантов решений море, и человек не должен знать ВСЁ, а должен уметь качественно использовать свои и ЧУЖИЕ знания (сообщество) и выдавать качественно решение.
Знание даже наоборот может сыграть – если человек знает хороший алгоритм, то это реализация, отладка, и возможные ошибки, в то время как коммьюнити может использовать давно проверенные и протестированные библиотеки. Тогда решение через "гугл" и быстрее, и надежнее, и проще.
Поэтому не вижу ничего такого в поиске решений через гугл, имхо J
Zifix
На собеседовании не требуется знать все варианты решения задачи, требуется решить её любым одним, желательно оптимальным. Задача собеседования, в том числе, выяснить, есть ли ну него свои знания, или он только чужими умеет пользоваться.
Его умение отлаживать и искать ошибки — тоже предмет проверки.
Что касается продакшена, то велосипеды, конечно, писать стоит только в крайнем случае, вместо этого стоит пользоваться библиотечными функциями.
yakimchuk-ry
Так можно давать реальные задачи, и создавать реальные условия, и смотреть как человек адаптируется под изменения требований к решению и работает со своим же кодом.
Например:
Надо сделать форму авторизации. Потом добавить в форму поддержку разных стратегий авторизации (сервисов, через которые можно войти используя логин и пароль). Потом эта форма должна стать экспортируемым независимым модулем.
Он сначала напишет простую форму. Потом будет думать как построить передачу данных с одного интерфейса в разные точки, с разными интерфейсами. Потом если прибил всё это гвоздями, ему придется брать гвоздодер и разбирать свой же интерфейс.
Так и будет видно, насколько гибкое решение пишется, как оно поддерживается, и как он адаптируется к изменениям в реальных задачах, как пишет код. Чужие знания здесь не использовать, потому что задания реальные, не совсем типовые, думать придется самому.
Zifix
Есть разные подходы, этот тоже вполне имеет право на жизнь.
vitaly_il1
Вот-вот, до сих пор помню собеседование лет десять назад, с вопросами на бумажке, типа «сколько битов в IPV6 адресе», без интернета.
Acuna
Я… я правильно понял, 2010 год? Не 15 лет назад? А-то 10 лет назад у меня 60 мбит было за 450 рублей в месяц, причем не самый крутой тариф.
vitaly_il1
Это было не физическое отсутствие интернета, работодатель верил что ответы надо знать наизусть, а не гуглить :-)
Acuna
А, ясно, но хоть это и смешно, но я сам могу нагуглить (и гуглю) практически любую проблему, но честно признаться, со стороны работодателю может казаться что он нас гуглить нанимает, поэтому я в чем-то понимаю тех из них, кто просит код писать на листочке :/
vitaly_il1
Я уже семь лет как фрилансер, и вместо задачек-вопросов идет деловой разговор «у нас есть такие проблемы, можешь помочь?». Так что лично меня эта проблема уже не затрагивает к счастью.
Но с обеих сторон барьера мне трудно понять зачем помнить сколько байтов в IP или MAC адресе, какие ключи у команды 'ls', или зачем в уме считать netmasc.
Maksclub
Обидеть сеньора может каждый
avengerweb
Во всем сервисы по подготовке к интервью виноваты и книжки типа как крякнуть интервью на изучениях которых у мид+ плюс нет ни времени ни желания, а вот у ребят которые только залетают предостаточно.
На самом деле, проводя интервью, мне не важно как хорошо кандидат знает основы, алгоритмы, структуры данных, да даже язык на котором он пишет меня не очень волнует. Мне нужно понять может ли человек решать проблемы и я был бы рад дать ему написать объемное приложение чтобы оценить его со всех сторон, но у меня только час на интервью. Это значит что мне нужно придумать минимальную задачу в плане объема, за решением которой я смог бы проследить и понять, что из себя представляет человек, таких задач много на самом деле, и данный способ даже никого не бесил и всех устраивал какое то время…
А потом настал бум взломщиков собеседований появились всякие leetcode, hackerrank и тп, которые просто дрессирую разрабов на решение таких задач. Что привило к ситуации которую мы имеем сейчас, сложные алгоритмические задачи с использованием разнообразных структур данных, задачи на разогрев и подобный треш, который конечно никому из мид+ сегмента не нравится.
Kwisatz
Вы в курсе, что вы — уникум? Вот правда, большая часть собеседований как раз выглядит как олимпиада при том, что «у нас весь софт свой, реальный хайлоад и все такое».
Иногда самое сложное не выдать тут же и решения. Я это называю ежиным тестом по аналогии со статье йМосигры.
Murmurianez
Думаю, что одна из причин по которой на собеседовании дают тупую дичь сеньёрам/прошаренным — недостаток квалификации проверить сеньёра/прошаренного другим способом. Когда разговаривают два квалифицированных человека — они о насущных проблемах говорят, а не друг-другу первые вопросы из гугла задают и всякую виртуальную дичь друг у друга не спрашивают.
Kwisatz
Мн целых два раза в жизни попались такие собеседования. Приятно провел время.
Однако, надо заметить что не все соискатели готовы к таким собеседованием, мне много раз попадались люди у которых ни проблем ни достижений и вообще рассказать нечего. Я, правда, в таком случае делаю вывод, что в резюме сплошняком ложь.
senglory
Т.е. человек, работающий 10 лет в саппорте какой-нибудь CRUDной опердени, где основная проблема — составить внятное ТЗ из разрозненных фрагментов потоков сознания разных лет и разных источников мыслей, — автоматически лжец?
Kwisatz
Я говорю о ребятах у которых пестрое резюме.
Если за 10 лет одна строчка и человеку сказать нечего, то мне просто не подходит.
morsic
Аналогия в этом случае не очень хороший аргумент, потому что тут непонятно, к чему сопоставить тестовый урок: к написанию факториала? К реализации тестового приложения целиком начиная с git init?
Я например подумал про первый вариант и сделал вывод — сеньер — это тот, который круды шлепает, не вдаваясь в логику решения проблем.
Artifeks
Меня больше всего на собесах бесит что начинают спрашивать с основ и просто тратят время, каких то прям тонких мелочей, которые ты забыл потому что в проде никто это не использует уже лет 5, а то и 10. И никто не смотрит тот же гитхаб, где вполне понятен уровень на котором я нахожусь и какие вещи могу делать. но нет давай сначала
arrakisfremen
Как-то давно я устроился AngularJS разрабом, не имея вообще представления о том, что это такое, ваш AngularJS. Мне насиловали мозг основами, а потом, видимо, самим надоело, и собеседование закончили, а меня взяли. Уже в процессе трудовых будней втянулся в ангуляр)
Artifeks
сеньором взяли?
razielvamp
Кстати, нередко вижу вакансии на сеньора, например, по питону с условием опыта работы более N лет с ± любым ооп языком.
Pavenci
ага, постоянно спрашивают «а вы работали с js? или про git еще бывает спросят», при том, что в резюме более чем подробно описан весь карьерный путь, проекты, технологии и кейсы.
zaiats_2k
Это на самом деле завуалированное "а вы сами резюме писали, а помните что там насочиняли?" ;)
Acuna
У меня пару раз спрашивали использую ли я Gradle (под андроид пишу), всегда спотыкался на этом вопросе, один раз чуть не начал им рассказывать что спрашивать такое это все-равно что спросить знаю ли я Android SDK :) Не, может они конечно таким вопросом хотели узнать что если вдруг я использую другую систему сборки, а не идущую из коробки, то почему. Но все-равно как-то странно, похоже на то, что для них это просто одна из новомодных технологий, ладно бы просто HR в текст вакансии ее вписал, но это на собесе прямо :)
Aecktann
Кандидат приходит устраиваться на работу водителем. В резюме у него пять лет за баранкой пылесоса грузовика и восемь — легковушки. Я сажаю его в малолитражку и прошу в качестве демонстрации проехать полсотни метров по прямой, повернуть направо и там остановиться возле знака «P». Почти оскорбительно простое задание, не правда ли?
Я наблюдаю, как машина глохнет, потом ещё раз глохнет, потом, после снятия с ручника, рывками начинает движение и на середине дистанции врезается в бордюр. Даёт задний ход, снова глохнет, теперь поперёк дороги. Ещё раз врезается в бордюр, поднатужившись, наезжает на него и тут же цепляет зеркалом дерево. Кандидат выходит, поправляет зеркало, догоняет скатывающуюся назад машину, ставит на ручник. Машина глохнет. После снятия с ручника трогается и врезается в дерево уже бампером. Задний ход, машина съезжает с поребрика на дорогу и каким-то чудом становится по направлению движения. Газу! Заветный знак «P» маячит вдалеке, как мираж, не становясь ближе, — но это потому, что кандидат газует на нейтрали. Новая попытка, и машина с визгом трогается с места, поднимая асфальто-резиновую пыль. Чуть было не пролетев мимо нужного поворота, машина в последний момент останавливается со скрипом тормозов. Не вписываясь в поворот, она ещё раз проезжает по поребрику и останавливается на противоположной от знака «P» стороне дороги.
Кандидат выходит из машины и объясняет свою езду так: «Вы знаете, я вообще-то готовился к собеседованию. Мне не сказали, что будет практический тест».
Источник: https://feldgendler.livejournal.com/2015/08/05/
На самом деле, для нормального сениора написание примитивного кода на интервью не должно быть проблемой без всякой подготовки. Я говорю не о собеседованиях в стиле "напишите алгоритм Кнута-Морриса-Пратта для разогрева", а о значительно более приземленных задачах, наподобие "напишите функцию разворота массива".
А вообще, из личных наблюдений, сениоры делятся на два типа. Первый в ответ на просьбу написать FizzBuzz жмёт плечами, иногда косо смотрит и пишет за 30 секунд. Второй начинает истерику о том, что он сениор, его не ценят, не уважают, унижают такими вопросами, и вообще код писать должны джуниоры, а он вообще больше по архитектуре.
AriesUa
Приведу примеры задач и вопросов из интервью, которые были у меня. Итак собеседование на позицию Architec, Tech Lead, Senior TS/JS developer. Все что связано с фронтом короче.
— напишите функцию замены строки ДНК на другой участок ДНК
— напишите функцию фибоначчи
— напишите сортировку массива
— что такое замыкание
— что такое промис
-итд
А теперь главный вопрос — это серьезно задачи для архитектора и тех лида? Таких интервью у меня были десятки только за последние 10 лет моей 20-летней карьеры.
Понимаете, никак, вот совсем никак, такие задачи не раскрывают моих умений и знаний. Мне не сложно было написать эти функции и ответить на простые вопросы. Но где вопросы об архитектуре, о походах проектирования проекта, о организации документации, подходах к тестированию?
Когда таких интервью один или два — ты просто не обращаешь внимания. Когда десятки — это начинает раздражать.
Artifeks
часто соглашаются гитхаб посмотреть? Простите, ошибся с веткой, но вопрос тот же
AriesUa
Да. Кстати, почему вас это удивляет?
Artifeks
у меня негативный опыт, посмотрели лишь раз
Aecktann
Вам сложно ответить на такие простые вопросы, как вы привели? Это занимает пять минут и явно сигнализирует о том, как вы пишете код на микроуровне (в пределах одной-двух функций). Без нормального кода на микроуровне ваши навыки на макроуровне могут пригодиться разве что на позиции проджект-менеджера, но явно не на позиции сениор-разработчика.
Вы на джуниора, который спросит, что такое промис, отреагируете в стиле "ты серьезно меня об этом спрашиваешь?". Это уже про софт-скиллы, причем неявно, а не в лоб. Сениор с избыточным ЧСВ, который отказывается писать код — оно вам надо?
Обычно вопросы про "организацию и архитектуру" имеет смысл задавать тем людям, которые минимальную планку берут. А если нет — то зачем вообще?
Artifeks
а о работодателе
с избыточным чсв, которому именно надо чтобы перед его глазами написали что можно сказать? И я сомневаюсь что у джунов прям все хорошо с гитхабом и там есть что смотретьAecktann
Работодатель просто хочет увидеть, как будет писать код человек, которому, возможно, будут платить деньги за написание кода. Удивительное ЧСВ, да?
Artifeks
и он может это увидеть на гитхабе, потому что это хоть как то приближено к реальности, в отличии от собеса, где скорее стремятся унизить чтобы цену сбить, чем человека нанять
Aecktann
Вы знаете, на каждом интервью в компании, где я работаю, мы очень, очень хотим нанять человека. Каждому человеку, который проходит интервью успешно, мы очень, очень хотим платить деньги и очень, очень хотим, чтобы он работал у нас подольше и получше. Поэтому платят человеку после интервью очень, очень хорошо.
Не очень понимаю, зачем начинать отношения с человеком с агрессии и "сбива цены", не стремясь к хайру. Хайринг-мероприятия, интервью, время рекрутеров, время инженеров, поездки на интервью, оформление виз, перевоз людей и т.п. стоят денег, причем достаточно больших. Как-то тупо их тратить, чтобы "унизить и цену сбить, но не нанять", не находите?
Artifeks
не нахожу, особенно когда вижу когда интервьюер юлит и начинает доставать вопросы с верхней полки, ибо я знаю что они с верхней полки и с тем же успехом могу в обратку завалить этого интервьюера вопросами что он не ответит. получается театр с плохими актерами или мне везет, надо просто сразу вставать и уходить
Aecktann
Из такого места и нужно вставать и уходить.
andreyverbin
Так бывает в мелких аутсор конторах, им нужно подешевле и получше, но лучше подешевле. Так НЕ бывает в продуктовых компаниях или в аутсорс компаниях с серьезными проектами.
Artifeks
у меня опыт был и с большими галерами
AriesUa
Если вы еще раз внимательно прочитаете мой пост, то увидите, что я написал — «Мне не сложно было написать эти функции и ответить на простые вопросы...» (с)
Так что, к чему ваши замечания?
Aecktann
Ну так ответьте. К чему это нытьё?
Если после этих вопросов вам не задали нормальные вопросы, то это значит что вам с этой компанией не по пути. Собеседование двустороннее так-то.
AriesUa
Боюсь вы видите то что хотите видеть.
Но все же повторю — мне не сложно было ответить и написать, что я и делал. И увы, придется делать в будущем.
И это не нытье, это разговор о полезности/бесполезности некоторых видов интервью.
edogs
Проблема работодателя в том, что 9 из 10 кандидатов претендующих на позицию сеньера не осилят эти вопросы даже если они будут заданы им в виде домашнего задания с неделей на подготовку.
Такие вопросы это первичный фильтр откровенных самозванцев, которых действительно очень много.
Гитхаб и портфолио тоже не аргумент, т.к. неизвестно сколько там кода самого кандидата, а сколько заимствованного и как быстро и после скольких ошибок это было написано.
Murmurianez
Почему бы им сразу нормальные «сеньёрские» вопросы не начать задавать? Не отсеят? А раз ваши «сеньёрские» вопросы не отсеят — значит они вам подходят.
vedenin1980
Про архитектуру, базы данных и патерны? Несколько раз встречал людей, которые отвечали на все такие вопросы, но сыпались на базовых знаниях языка — потом оказывалось они давным давно архитекторами и техлидами работали, но нам-то нужны были именно программисты.
Проблема в том, что в реальной жизни нужно не на вопросы отвечать, а программировать. А многие «сеньёрские» вопросы можно просто выучить.
edogs
А во-вторых, как ни парадоксально звучит — могут и не отсеять. На должность сеньора нередко проще пройти собеседование чем на должность миддла, т.к. ответы на вопросы более расплывчатые, неоднозначные и их проще выучить. При этом когда дело дойдет до практической реализации — тут наступает оппаньки.
Собственно не знаем как в россии, а на западе достаточно много «самозванцев» таки проходит все круги собеса прокачав скилл прохождения собеса, выучив базовую теорию и список типичных вопросов. А потом фиг их уволишь. А тестирование базовых практических навыков в реальной жизни их и срезает.
markoni
Читал вчера ваши комментарии — задумался, а когда же я за 20 лет последний раз искал наибольший элемент в массиве? Вспомнить не смог. Нет, я безусловно отвечу на подобный вопрос, и скорее всего быстро напишу код. Но ценность работы в данной конторе для меня будет где-то между работой в Макдональдс и такси.
Могу предположить, что вы говорите с точки зрения «галеры», где позиция работника (с веслом в руке, и веслом в .....) определяется количеством проектов, которые он может закрыть своей тушкой.
Katasonov
Мне кажется, вопрос нужно было себе ставить не когда я искал элемент в массиве последний раз, а когда приходилось писать «алгоритм» последний раз. Нет, алгоритм не в том смысле, что я набиваю ежедневно код состоящий чисто из вызовов какого-нибудь API и рисование скажем результата на форме, а реальный такой алгоритм. Ну скажем например «Ускорение работы системы например в x раз». Поиск элемента в массиве как раз пример алгоритмичного мышления, а не мышления «машинистки» забивающей текст в редактор код, порой копируя куски другого кода со Stackoverflow.
PS: Без обид, тут я не пытался какой-то негатив в твою сторону пустить, наверняка, ты отличный программист и пишешь хорошие алгоритмы, тут скорее просто хотел отметить постановку вопроса :)
markoni
Это при том, что «реальными такими алгоритмами» последние полгода как раз и занимаюсь. Я бы и рад со Stackoverflow — но там такого нет :( И повторюсь, нахождение наибольшего элемента массива никак не характеризует senior dev. От слова — совсем. Для начинающих — вполне себе нормальный вопрос. Нейрохирург скорее всего сможет удалить аппендицит. Но при приеме на работу у него не будут спрашивать — «Скальпель-то держать умеешь?»
Katasonov
А проблема в том, что senior dev и его резюме не характеризует и даже его рассказы о самом себе, тоже никак его не характеризуют. Задача уровня джуна (ну как про поиск элемента в массиве) как минимум характеризует кандидата в том что он умеет решать задачки уровня джуна и есть уже смысл идти дальше и разговаривать про то как бы он построил космические корабли, которые бы бороздили просторы вселенных.
Artifeks
то есть когда с вами будут обсуждать senior темы вы не отличие джуна от сеньора? этакие джуны со знанием подходов людей уже с опытом и портфолио
Katasonov
Если честно, градация на джунов, сениоров, миддлов и прочих, лично для меня немного чуждая. Я больше ориентируюсь на градацию: хороший разработчик и говнокодер. Хороший разработчик для меня, это человек который может 1) мыслить алгоритмически и 2) мыслить, если угодно, архитектурно. Так вот первое проверяется обычно вот такими задачками по типу, вот тебе бумажка накидай алгоритмик. А второе проверяется уже обсуждениями по типу а как бы ты спроектировал бы систему при условии что…
Artifeks
а зарплату вы тоже так будете ему отчислять? я был бы всеми руками за, если молодым гениям сразу бы давали хорошие деньги, а не как в вакансии написано «от 4 лет опыта»
Katasonov
Меня как тех.спеца, собеседующего, другого тех.спеца мало волнуют зарплаты. Я не знаю какие зарплаты сейчас у моих коллег. Они могут быть разными, даже при условии одинакового опыта. Так же бывает зп у чувака в 25 лет выше чем у сотрудника которому под 50, хотя естественно опыт работы сильно разный в данном случае, как и способность соображать и знание конкретных технологий к примеру. Поэтому ЗП это отдельная ортогональная тема.
fshp
А теперь представьте, что интервьювер слабее вас. Вас для этого и собеседуют, что бы вы усилили команду.
О чем он вас должен спрашивать? О том, что сам не знает?
AriesUa
Это отличный вопрос.
Если в компанию требуется специалист высокого уровня и в компании нет людей, способных провести интервью, то следуют двум путям:
— Затратный. Нанимают людей или компанию, с подходящим уровнем, со стороны для аудита кандидатов.
— Дешевый или сарафанное радио. Ищем среди друзей, людей с уровнем знаний и договариваемся за пиво/кофе/пиченьки.
Но признаюсь, я такое в своей жизни не встречал.
gorodnev
Это очень странный подход. Может, как один из этапов интервью (поведенческое), но явно не техническое. В идеале, на техническую позицию нужен собеседующий на уровень-два выше кандидата. Иначе смысл в таком интервью пропадает. Ну или если на собеседовании собеседующий чувствует, что кандидат на уровень-два выше, то такого человека нужно брать. Но тут есть другая сторона — что, если собеседующий почувствует себя неуверенно, закомплексованно и не найдет в себе сил признаться в чьем-то превосходстве?
creker
Заменить такого собеседующего другим? И в компании объективно может не быть человека выше уровнем. Ну вот неоткуда. Новое направление, новые проекты, новые задачи, а человек нужен. Сам с таким сталкивался. И ничего страшного. Для этого к интервью готовятся просто обе стороны, а дальше в разговоре обычном можно понять, адекватный человек, и сможет ли он что-то рассказать сверх того, что вы сами изучили за пару часов гугления.
creker
Для этого осуществляется элементарная подготовка к интервью.
ApeCoder
По крайней мере он может проверит что кандидат не слабее его.
fshp
Он может сделать это как раз тем способом, который раздражает сеньора-помидора.
ApeCoder
Я честно говоря, не знаю, что раздражает синьора. Простой кодинг с простым анализом алгоритмов?
fshp
Я тоже не знаю. Но об этом говорится в статье. Судя по ней сеньоров раздражают вопросы для джунов и мидлов.
saboteur_kiev
Сравнение сил квалифицированных специалистов заключается не в знании конкретных алгоритмов или порядке параметров в редкоиспользуемой функции, а в архитектурном понимании и опыта использования/настройки различных решений и инструментов. В этом случае «элементарно подготовиться к интервью» не выйдет.
Imbecile
Честно говоря, не понимаю, а что в этом такого? Особенно если собеседуют на лида?
По тому, как отвечают, можно понять, уверен человек в своих ответах или нет. Можно понять, сможет ли он объяснить это менее сильным коллегам. Самому, в конце-концов понять какой-то технический момент.
Я вот в душе не гребу, что под капотом у async-await в C#. Но это не помешает мне понять, собеседуемый в этом разбирается или нет.
И да, в идеальном мире надо брать на работу людей, которые сильнее тебя.
alexovchinnicov
По моему скромному опыту, ближе всего к этому утверждению зарубежные работодатели. Но «заумность» ни в коем случае нельзя показывать в России. Я вот точно знаю пару моментов по которым я не прошел собеседования. Первый спросил у архитектора почему бы вам просто не масштабировать текущее java приложение через домен WildFly/JBoss. Второй раз спросив на собеседовании у представителя IBM/RedHat почему они рекомендуют Kubernetes, а не OpenShift. Я ни в коем разе не считаю себя сильнее интервьюеров, во всех случаях спрашивал из чистого любопытсва.
A114n
Поэтому чаще всего в таких случаях нанимают не специалистов, а эффективных менеджеров, прошедших тренинг уверенности в себе.
Imbecile
Не уверенный в себе лид, который должен вести за собой более неопытных коллег, такое себе приобретение в команду.
sentyaev
Так это же очень хорошие вопросы, если на собеседовании у меня такое начинают спрашивать, я точно знаю, что мне в эту контору не нужно идти.
andreyverbin
Можно предположить, что такие вопросы задают дураки-дилетанты, с которыми вам работать не хочется. Но эта практика довольно распространенная, следовательно нужно допустить, что дилетантов-дураков очень много. Вы, кажется, не допускаете, что у подобной практики могут быть обоснованные причины. В чем ваша логика?
Dolios
Ну вы не пойдете и ладно, я переживу. Зато я не найму те 40% "синьоров", которые приходят на собеседование на фронтэнд позицию и не могут рассказать, что такое замыкания и не понимают, как с ними работать. Вообще, такие заявления позволяют сделать вывод о том, что вы сами никого не собеседовали на регулярной основе.
Kwisatz
нуда, поэтому, например, интернет магазины сейчас адово деградируют, люди решают самую частую задачу в веб мире по нескольку лет и выдают не юзабельное нечто.
Меня, например больше волнует понимание типов, причем не на уровне типов JS а на уровне TS. Всевозможные Nullsafe должны быть в крови опять же. Базовое представление о классах и наследовании (остальное сам доучу если нужно будет). А кроме того я лучше послушаю какие проблемы человек решал и как их побеждал (заодно и выясню кем было писано резюме).
А про замыкание пусть в гугле читает.
sentyaev
А вот у меня другие критерии. И это ни хорошо, ни плохо, а возможно — вообще одинаково. Получается я бы к вам не пошел, а вы бы меня и не наняли, вот мы и сэкономили время.
andreyverbin
А вы пособеседуйте тех, кто приходит на позиции синьоров и все поймете.
Еще как раскрывают. Во первых, все говорят, что им легко написать, но далеко не все напишут. Во вторых, умение составить элементарный алгоритм говорит о наличии алгоритмического мышления — умение анализировать и раскладывать задачу на кусочки.
Есть люди, которые умеют четко изложить свою мысль, а есть те кто не умеют. Это также как и у писателей, кто-то «Ревизора» пишет, а кто-то с трудом доводит мысль до конца в сочинении «как я провел лето». Последние в любой архитектуре пишут хрень, а первым насрать на подход, главное чтобы какой-то был. Первых отличает аналитический склад ума, большой кругозор (в частности знание как что работает) и умение разложить задачу на кусочки. Всякие FAANG это давно поняли и дрючат народ задачками. А остальные могут и дальше растекаться мыслью по древу сравнивая ООП и ФП или DDD с Clean.
Wyrd
Вот это кстати очень похоже не на задачу, а на проверку умения вытягивать из заказчика требования. И в таком контексте вопрос не плох. Я недостаточно знаком с биохимией, но там, скорее всего, есть где развернуться.
Dolios
Это, с одной стороны, очень хорошая задача, причем реальная, а не высосанная из пальца. Вы правы в том, что 1 ее этап — это вытягивание требований. Это вообще обязательный этап при решении любой задачи, если кандидат его пропускает, то в 99% случаев будет фейл.
Но вообще, конкретно эта задача на понимание концепции скользящего хеша. Причем, кандидат может прийти к этому, даже не зная, что это такое.
А с другой стороны, задача плохая. Потому что если кандидат знает алгоритм Рабина — Карпа, он решит задачу за O(n) и мы не выясним ничего, кроме того, что он знает алгоритм и может его реализовать. Хотя, даже в этом случае, человек, зная концепцию, будет вынужден вспоминать и выводить функцию формирования хеша.
N-Cube
Если уж речь именно про ДНК, то обычно допускается заданное количество ошибок при поиске подстроки. Ну вот свойство такое у биологических систем — изменчивость. Задача вам все еще кажется простой?:)
Dolios
А где я писал, что задача простая?
joyfolk
Крупные компании имеют сильноформализованный процесс интервью, в котором есть этапы который должен пройти +- любой сотрудник. Да, для позиций специалистов это выглядит как пустая трата времени, но это обеспечивает потом отсутствие для компании юридических притензий, минимизирует bias, отсеивает всяких сильно неадекватных кандидатов etc. Нужно относиться к этому как к неизбежному злу. Обычно там не то, чтобы надо сильно готовиться — критерий бинарный, а не качественный — или проходишь до нормальных интервью или отсеиваешься.
Конечно, когда так поступают небольшие компании, а не условный FAANG, это выглядит очень странно и не оправдано. Но никто же не заставляет туда идти.
RouR
Некорректные аналогии подобны котёнку с дверцей.
Вы умеете водить автомобиль? Подозреваю что нет.
Это довольно незабываемый опыт, когда после нескольких лет езды на своём авто, на автомате — тебя просят проехать разок, недалеко, но на матизе (ручная коробка и другие габариты).
P.S. Особенно эта фраза повеселила — о значительно более приземленных задачах, наподобие «напишите функцию разворота массива». Вот я «прям всю жизнь» разворачиваю массивы вручную, вместо использования встроенной либы. Прям троллинг какой-то.
Aecktann
Интересно, какие у вас данные были чтобы хоть что-то подозревать в этом вопросе? Плохо подозреваете, в общем.
Он довольно незабываемый, если вы ездили на механике только в рамках учёбы в автошколе. Если у вас в анамнезе есть опыт управления механикой (написания кода) хотя бы пару десятков тысяч километров (ну хоть чуть-чуть в карьере), то вы сядете и поедете. Ну заглохнете пару раз в первые 10 минут. Но это не ноухайр.
Функция разворота массива, хоть и не очень нужна в реальной жизни, тем не менее настолько проста и примитивна, что вывести её за несколько секунд в голове может любой программист, который вообще работает с массивами. Если программист не работает с массивами, мне не очень понятно, почему он программист. Объясните?
vp7
По поводу примера с машиной — ровно по этим граблям я недавно прошёл. 100k на механике, потом 150k на автомате.
Сел на механику, и… сначала тупо заглох. Потом тронулся только раскрутив движок под 3500. С переключением передач тоже были косяки.
Уверенно я поехал минут через 5. Если бы это было собеседование, то оно, считай, провалилось в первую минуту.
Если для вас "функция разворота массива" это нечто примитивное, то у меня для вас плохие новости. Развернуть сферический массив в вакууме чертовски сложно. Нужно учесть тип массива (обычный или разреженный, а может у него магические геттеры/сеттеры есть с линейным ростом времени доступа при переборе индексов?), разобраться с хранимыми там значениями (а если там ссылки? а надо по ссылкам значения копировать или новые ссылки сделать? а язык с гарбадж коллектором или надо руками аллоки делать?), разобраться с памятью — копируем поверх или аллочим новый блок (а если поверх и это java с final массивом, то не забываем учесть exception'ы), убедиться, что операция будет thread safe при необходимости… и это, кажется, далеко не всё.
Если же для вас задача "развернуть массив" это "массив int'ов в языках типа c/pascal, тупо for'ом пробежать с конца до начала и сделать exchange значений в оригинальном массиве или выделить столько же памяти, пробежаться с начала до конца и скопировать с конца до начала", то с ЭТИМ справится студент 1го курса любого технического ВУЗ'а.
Вот только если на собеседовании миддл начнёт писать такой алгоритм, а не задавать тонны вопросов перед началом (из озвученного мной ранее списка), то надо не радоваться, а серьезнон сомневаться в квалификации этого миддла.
Ну кроме случая, когда вы сами выдаёте граничные условия вроде "неразреженный массив int'ов, без thread safe, память экономим по максимуму, оптимизация скорости не нужна" — тогда да, тогда мидл очень косо на вас посмотрит, но напишет этот алгоритм даже на бумажке на абстрактном языке за пару минут.
Aecktann
Я часто ставлю Hire кандидатам, которые первые 5-15 минут тупили. Это очень часто случается и все это понимают. Более того, мы обычно даём одну задачу на разогрев, как раз чтобы кандидат вспомнил, что это вообще такое и снял стресс на "раскрутке движка" и "переключении передач".
Функция разворота массива in-place — это как раз про примитивный случай. Мы на интервью, мы не пишем звездолёт. Если кандидат задаёт правильные вопросы — это хороший знак, конечно. Если он спрашивает "простейший примитивный кейс?", получает ответ "да", и косо глянув пишет — это хороший знак. Проблема в том, что кандидаты не пишут. Не могут. Не знают, как в языке по их выбору считается длина массивов. Забывают про концевой элемент. Ошибаются в центре. Не понимают, что arr[len(arr)] в языке по их выбору не работает.
stas2s
я сеньор уже 5 лет. На собеседовании и строчки кода(да текста простого) не напишу. Руки дрожат всегда и эта часть мозга отключается. Но и так никогда не было проблеммы работу найти.
При этом брал на работу человек 15, всегда удачно. Никогда не было проблемы оценить скил человека, просто спросив — какие последние проблемы ему запомнились, как их решал и тп. Чем бы хотелось заниматься, в чем силен. Правда никогда не стояло задачи отсеять из кучи людей. Из 5 -10 людей уже находился один подходящий.
Dolios
Нет, вы бы его с блеском прошли. Вы показали способность за 5 минут разобраться с задачей, с которой не встречаетесь каждый день, и успешно решить её. Именно так и работает кодинг интервью.
А вот этого от вас и ждут. Если кто-то сразу бросается кодить и с блеском решает задачу, не выяснив вот этого всего, он провалит интервью. А вы опять прошли.
Просто вокруг кодинг интервью много мифов. Большинство, почему-то, уверено, что это проверка способности по памяти алгоритмы писать. Что имеет отношение к реальности чуть менее, чем никакого.
creker
Оно может к вашей реальности имеет малое отношение, но у других реальность отличается. Плохое мнение об интервью зародилось не из воздуха, а из-за повсеместного подхода как раз зубрить алгоритмы и на зубок выдавать алгоритмическую сложность красно-черных деревьев. Если бы интервью работали так, как вы описываете, никто бы и не жаловался.
ApeCoder
Но мы же достаточно интеллектуальны для того, чтобы отличить такое кодинг интервью от боле осмысленного
ApeCoder
Вообще, кодинг задача это не просто решил/не решил — это как решил, как рассуждал, какие вопросы задавал, насколько было понятно то, что он хочет сказать, что забыл упомянуть, понял ли после напоминания о чем идет речь и так далее.
kraidiky
Да ладно механика! Недавно пересаживался с Лексуса гибрида на обычную машину с автоматом. Знаете сколько времени уходит на то чтобы привыкнуть? Что времени на любой манёвр нужно оставлять в два раза больше, а когда ты нажимаешь на газ этот тарантас едет не сразу, а только через секунду и не на столько на сколько ты педаль нажал, а на треть от своей мощности номинальной. Пару раз чуть не убился нахрен при выезде на МКАД.
welovelain
Он работает с коллекциями, например. Не знаю, завезли ли их в плюсы, но в джаве их довольно давно придумали и облегчили всем жизнь. Я массивы последний раз трогал в универе и на каком-то собесе.
sshikov
Он возможно работает с еще более сложными структурами. Но все-таки массивы еще встречаются в API — и их приходится знать. Хотя да, если спросить скажем меня — то в своем коде по своей инициативе я их практически не применяю никогда. Только если чужой API их требует.
0xd34df00d
Ну вот я уже почти год не работал с массивами в смысле С, и где-то полгода как не работал даже со списками, считайте, за пределами «обработать голову списка и рекурснуться на хвосте», да и там списки не совсем списки. При этом, наверное, я все ещё программист. Просто у программистов бывают разные задачи.
eyudkin
Думал о том же, пока читал исходный комментарий.
Пример с машиной некорректен потому, что в нем просят продемонстрировать вождение, то есть то, что и будет делать водитель.
В случае же с кодом, практически никто и практически никогда не пишет сортировку массива руками. Да, это несложно, но это не тот навык, который требуется в повседневной работе, если несколько лет не писал ту же быструю сортировку, то мелочи забываются, нужно перед собеседованием их из головы достать и дома повспоминать, чтобы не тупить потом за столом.
В конечном счёте это означает, что кандидату нужно поддерживать два набора навыков, отдельно для рабрты и отдельно для прохождения собеседований. А это странно.
Aecktann
Не существует навыка написания сортировки массива. Существует навык написания кода, оперирующего данными в массиве, который будет решать задачу. Сортировка — один из примеров. Поиск максимума — другой. Разворот — третий. Бинарный поиск в отсортированном массиве — четвертый. Продолжите список.
В случае с кодом, написание кода, оперирующего базовыми конструкциями языка по выбору кандидата (массивами, хештаблицами и т.п.) — минимальный набор для работы. Я говорю о случаях, когда ты просишь написать линейный поиск в массиве, а человек не может написать простой for-цикл.
creker
Для навыка написания кода тогда нужно давать кандидату полное описание алгоритма, а не сидеть ждать, когда он в голове переизобретет какой-нибудь алгоритм сортировки, который он может даже никогда не разбирался как работает. Об этом выше и говорят. Навык написания кода это стучать по клаве и набирать то, что ты и так знаешь. Сделать сортировку это навык заучивания алгоритмов, чтобы потом показать, что ты умеешь писать код. Вот на это все и жалуются. Дурацкий это подход к интервью. И ладно сортировка, а то еще реально дадут задачу с графами и деревьями.
В аналогии с водителем это больше похоже на требование не только машину вести, но еще предварительно отремонтировать ее и рассказать принцип устройства. Да, опытный водила наверное может знать это, но не этим он будет заниматься в нормальной компании. Так же как и программист не будет выдумывать алгоритмы сортировки и обхода графов, если его нанимают очередной онлайн магазин писать. Хочется оценить навыки программирования, давай профильное задание, а не матан очередной.
Aecktann
Полное описание алгоритма.
Желательно ещё его полную реализацию на целевом языке.
Тогда сениор-разработчик сможет списать и продемонстрировать, что он умеет печатать.
Вы серьёзно?
creker
А вы может не будете до абсурда доводить? Вы сами начали про навык написания кода, а вместо этого предлагаете совсем другие вещи делать. Навык написания кода на интервью это решение профильной задачи, а не сортировка массива и поиск максимума. И то и другое может человек и решит, но толку от этого будет ноль. И если поиск максимума я еще понимаю, но это не выглядит реалистичной задачей на собеседовании. Слишком оно примитивно, поэтому на интервью любят спрашивать как раз что по-сложнее. Сортировку, обход дерева и прочую ерунду. И вот для таких задач впору человеку давать описание алгоритма. Иначе мы не только код от него требуем писать, но еще и зазубрить алгоритмы. Зачем?
sentyaev
Зубриь не нужно, нужно понимать как структуры данных работают, и в каких случаях что лучше подойдет.
ardraeiss
Как часто в Вашей практике сеньору приходится изобретать новый алгоритм обхода графа и сортировки? Именно новый, а не "взять готовый, адаптировать по месту под, скажем, особенности адресации"; а то и вовсе "вызвать библиотечный".
Я вот видел такое как-то целый один раз, за 20 лет рабочей практики. Человек изобретал оптимальную(вернее, очень отдалённо кажущуюся таковой) расстановку ограниченного набора элементом по ограниченному(столько же или больше) числу позиций, с набором дополнительных ограничений.
Что по факту имеет свои типовые методы решения с плюсами и минусами, но он явно всякую схемотехнику не изучал — и потому более изобретал.
Вот потом, спустя месяцы, пошли доп. требования добавить ограничения и тут уже работа "доработать" и "своё изобрести" сравнялась.
welovelain
Так оно все в справочнике, т.е в сети есть. Достаточно знать названия алгоритмов, алгоритмическую сложность и где что лучше применять. От руки писать его полюбому включит в себя ошибки — зачем так делать?
Aecktann
Чтобы написать
senior-разработчику нужен справочник?
welovelain
А ну как надо функционально? Реактивно? В едином стиле?
Вдруг надо так?:
Object[] invertUsingStreams(Object[] array) {
return IntStream.rangeClosed(1, array.length)
.mapToObj(i -> array[array.length — i])
.toArray();
}
Aecktann
Да не надо функционально/реактивно/с вывертом/через Марс, надо хоть как-нибудь.
Люди, претендующие на сениор-позицию могут всерьез сказать, что не помнят, как объявить пустой dict в Python. А потом уйти и написать на хабре, что на интервью, видите ли, компании с ЧСВ просят писать код.
A114n
Вы не слышите ваших собеседников.
Именно это вам и говорят.
Что «человек, претендующий на сениор-позицию» вовсе не обязан помнить, как объявить пустой dict в Python.
Это не значит, что он никогда его не объявлял.
Это не значит, что у него плохая память.
Это не значит, что он не справится с задачами, которые перед ним поставят.
Это вообще ничего не значит. Это взятый с потолка параметр, который скорее всего вообще никак не коррелирует с профессионализмом. Особенно интересно здесь то, что эту корреляцию даже никто и не проверял никогда, не существует проверок уровня «Мы отловили 1000 сеньоров и 1000 миддлов случайным образом и задали каждому задачу об объявлении пустого словаря, в результате из сеньоров с этим справилось 999, а из миддлов только 700».
Зато в интернете ходит байка о том, как команда собралась нанимать кандидата, каждый член команды написал в список вопросы, которые нужно было задать кандидату чтобы он обязательно ответил, и в результате никто из команды сам итоговый список пройти не смог.
Подавляющее большинство интервьюеров это голуби Скиннера. Те устраивали сложные пляски вокруг кормушки, потому что несколько раз такие же пляски совпали с выдачей еды. Вы устраиваете сложные пляски вокруг кандидатов, потому что несколько раз эти пляски совпали с наймом нормальных кандидатов. Но практически нигде найм не обусловлен какими-либо реальными закономерностями. И возмущение людей связано именно с тем, что всё это видят. Даже жребий был бы справедливее, потому что падающая монетка не пытается наменуть, что ты глупее своего соперника.
Конечно, такие технологии очень помогают в найме «звёзд». Если человек отвечает на любые вопросы — то он, вероятно, гений, и его надо хватать. Но речь ведь не об этом.
PleaseKING
Вклинюсь и повторю другими словами то, что говорили выше — такие задачи проверяют навыки ПИСАТЬ КОД. Не поговорить о написании кода, не рассказать, как он работает, не показать свой старый код (который то ли свой, то ли не свой, пес разберет), а просто сесть и написать код. Не надо помнить названия классов и методов — интервьюер подскажет. Не надо писать без ошибок. Но надо суметь написать код, ну а уже потом объяснить, что написали, как, и почему.
Конечно, задача искусственная — в основном, для простоты постановки — что такое массив или список, по идее, знает каждый.
И присоединюсь к комментирующим — огромное количество "программистов", приходящих на интервью, не может написать код. Зато может красиво порассуждать.
sumej
PleaseKING
А я так не могу. Мой мозг протестует писать непонятно что и зачем. Большинство задач на собеседованиях не относятся к реаольности. Мне нужно искусственно придумывать оправдания всему, что в задаче.
Соответственно у отобранных от реальности задач нет для людей, который не прокачивают интервью-мысшцы — нет отскакивающих от зубов ответов. Да и с домашними заданиями беда…
В последний раз мне предложили за 30 минут 3 вопроса и по 10 минут на каждый.
Нужно запрограммировать OS Kernel Scheduler.
Я спрашиваю а какую часть — а все. У меня был шок -> адреналин и тупняк.
ЗЫ:
Я считаю что наиважнейший навык это «не писать» код.
А то вы наймете человека, который умеет писать. А потом будете его увольнять за то, что он чушь писал (даже если и красиво, с тестами и т.д.). Я не слышал, что бы увольняли архитектов, который из г--на и скотча многомиллионные продукты лепили. Наоборот им в команду кидают тех, что это все разглаживают.
А вот пусто-писателей — отпускают частенько.
так в чем проблема смотреть в репозиторий на гитхабе?
Или как тут водится у многих ревьюверов нет времени смотреть?
ardraeiss
Судя по практике, не у всех есть время даже резюме прочесть.
0xd34df00d
Не обязан, конечно. А вот человек, претендующий на синиор-позицию питон-разработчика, таки обязан.
Это значит, что у него нет мышечной памяти на эту задачу. А не выработать мышечную память на базовую конструкцию языка за годы разработки на этом языке надо очень постараться. Скорее всего, если у человека этой памяти нет, то и опыта разработки на самом деле нет.
Хотя, впрочем, у меня как раз скоро интервью на хаскелиста, а я на нем уже полгода не писал, но писал на очень похожих языках с немного другим синтаксисом, так что это будет забавно. Хотя я при этом смогу интервьюверу показать код на гитхабе что на хаскеле, что на этих других языках.
SwingoPingo
Разные ситуации возникают, особенно когда пишите на нескольких похожих языках параллельно. С одной стороны это вроде как плюс, с другой прицел сильно сбивается.
FlyingDutchman2
Я вот претендую на позицию Senior и тоже многих таких базовых вещей не помню.
Например, я не помню, как написать заголовок цикла for в C# (или C). Помню только, что он состоит из трех частей — объявление переменной цикла, инкремент переменной и условие окончания цикла.
Логично, что объявление переменной должно идти первым, но вот остальные две части — что там первое, инкремент или условие окончания цикла — этого я никогда не помнил. Приходится постоянно в Help заглядывать.
Или вот внешнее cоединение в SQL. Если у нас left outer join, то с какой стороны у нас добавляются пустые записи, слева или справа? Хоть убей, не помню. Хотя и использую это соединение уже лет 25.
Выручает только то, что у меня есть файлик с примером запроса. И когда мне нужно написать запрос с внешним соединением, то я туда подглядываю.
Правда, пустой dict в Python могу объявить. И в C# тоже. Но вот проинициализировать несколькими элементами — уже нужно где-то посмотреть.
Так что спрашивать у меня на собеседовании такие базовые вещи просто бесполезно. Я вообще помню только то, с чем непосредственно работал последние несколько недель. Если что-то не использую, то я это быстро забываю.
Видимо, это особенности моего опыта. За последние 35 лет приходилось писать как минимум на 20 различных языках программирования. Если все это постоянно держать в голове, то можно свихнуться.
Помню собеседование несколько лет назад в одной компании в Брюсселе. Перед собеседованием дали мне пачку заданий по C# по написанию кода на бумажке. Первое задание — написать определение класса. Я с этим не справился, потому что классы я всегда создаю в Visual Studio — нажал кнопку и готово. А наизусть не помню, что там пишется. Второе задание — написать код для определения Event. С ним я тоже не справился, потому что последний раз делал это лет за пять до интервью и успел все забыть. После этого я бросил делать эти задачки.
В эту компанию меня не взяли. Наверное, потому что задания не сделал. А может, оттого, что я криво усмехнулся, когда они рассказали об архитектуре своей системы.
Да что тут говорить, я, когда в школе учился, таблицы умножения не знал. Учился я очень хорошо, и при этом часто болел. И в тот момент, когда во втором классе учили таблицу умножения, я тоже несколько недель болел и ее не выучил.
И когда мне нужно было, к примеру, узнать, сколько будет 6*9 — я умножал в уме 6 на 10 и потом отнимал 6.
Но никто никогда об этом не догадывался, потому что в математике я был очень силен — был лучшим учеником в школе за много лет. Постоянно участвовал в математических олимпиадах, в 7-м классе занял первое место на областной олимпиаде.
Но все-таки через несколько лет после окончания университета как-то таблицу умножения с грехом пополам выучил. Сейчас уже помню ее, не нужно больше числа в уме перемножать.
Но при всем при этом работу свою я делаю хорошо. А часто просто отлично.
Такие дела.
A114n
Это особенности не только вашего опыта.
Это особенности работы человеческого мозга.
Хорошим примером может служить, например, всем известная «банерная слепота».
По аналогии можно назвать это явление какой-нибудь «процедурной слепотой». Человек запоминает только сжатую суть выполняемой работы и (моторная память) набор действий.
Но поскольку никто в здравом уме не пишет стандартные вещи постоянно и осознанно — то в голове задерживается только сжатая суть и «где посмотреть если что». Не сразу. Но с возрастом — всегда.
Кроме того — чем старше, тем сильнее сжатие, и в этом смысле зумерки 20-25 лет, свободно жонглирующие в памяти стандартными приёмами, просто не понимают, как именно мыслит сениор лет сорока. У них эта радость ещё впереди, они искренне уверены, что если они сейчас могут сесть и написать код из головы, потому что «всё помнят», то и через десять лет их голова будет работать таким же образом.
ApeCoder
Следовательно, на собеседовании надо позволять гуглить и пользоваться IDE
alexdevyatov
Зачем вообще такое спрашивать? Какой процент кандидатов на должность Senior не напишет подобный код?
Aecktann
Вы удивитесь, насколько высокий. В этом и проблема. Поэтому и есть разогревочные задачи. Поэтому и настоящие задачи на самом деле простые.
Static_electro
Просто многие действительно не верят, что на сеньорские позиции приходят люди "на авось", и их таких много.
Я тоже не верил, пока не увидел своими глазами. Теперь считаю, что если человек отказывается писать fizzbuzz — это красный если не флаг, то флажок точно.
sumej
Static_electro
> Просто многие действительно не верят, что на сеньорские позиции приходят люди «на авось», и их таких много.
А разве в ходе беседы этого не понять?
Это же не 500 слов выучить. Можно же смотреть на код на гитхабе.
wataru
Языком ворочать — не код писать.
Static_electro
fizzbuzz, как писали многие умные люди, делит людей быстро и практически бинарно.
Еще раз — на интервью приходят много людей, с которыми беседовать бессмысленно, потому что они не могут писать код. Вообще не могут. Если вам не надо, чтоб человек писал код — то это, наверно, нормально. Иначе — лучше все же попросить написать что-нибудь. Именно эту проблему решают такие "тупые" задачки.
avost
Ну, как вам сказать… Если это не секция алгоритмов, а именно проверка навыка кодирования, то что вам мешает задать интервьюеру вопросы? Возможно, он именно этого от вас и ждёт? Этот навык для сеньора очень важен, поскольку задания сеньорам чаще всего поступают в виде "сделай чтобы всё работало", после чего надо ещё две недели провести во встречах со стопиццот стейкхолдерами, чтобы выяснить что такое "всё", что значит "работало" и получить от смежников их API и алгоритмы работы с ним и только потом приступать к… нет, не кодингу, а проектированию. Ну, если вы и правда сеньор, у вас есть прекрасная возможность продемонстрировать именно эти навыки! (и если вы от неё отказываетесь, то, может быть, вы и не сеньор ещё вовсе?)
Так ведь это хорошая возможность разобраться, наконец, как он работает. Не? И, это, зачем заучивать-то? Достаточно разобрать принцип. Это любой студент математико-ориентированного факультета понимает где-то во втором семестре — нет смысла зазубривать матан, теоремы не зазубриваются перед экзаменом, они на экзамене и доказываются (в вашей терминологии — переизобретаются). У нас в универе была одна девочка, которая таки пыталась зазубрить. Она сдавала матан 11 (одиннадцать!) раз. На одиннадцатом, как раз поняла этот принцип и потом успешно доучилась до диплома :). Вот это подход сеньорский (не про 11 раз, а про переизобретение). А заучивание — это для школоты. Даже не джунов.
это навык для джуна. Набирать то, что ты и так знаешь. Навык сеньора — делать то, что ни ты ни кто другой ещё не знают.
Ай, бросьте! Если вы можете за 2 минуты придумать пару способов сортировки (напр, выбором и пузырьком) вы даже не джун. Я мог это сделать в 6-ом классе.
Простите, вы утверждаете, что опытный программист не будет заниматься программированием в нормальной компании? Гмммм.
А вы не нанимайтесь очередной онлайн магазин-то писать. Ну, это же, право, крайне скучно! Да и сеньоры там — оверквалифайед. Как раз пары мидлов хватит.
Давать профильное задание написать онлайн-магазин? Нуууу, тут же вылезут яжсеньоры с криками — компания хочет на мне нажиться, я напишу им магазин, а они меня не возьмут, а магазин в продакшн и будут деньгу зашибать! Неее. Да и это не задание на пол-часа. На кодинг хороши задания длиной от 10 мин до получаса. Какое туда профильное можно впихнуть?
Я вообще люблю задания на кодинг на интервью. Может потому, что я кодить люблю? Поэтому, меня и берут на работу :). А яжсеньоров гордо отказывающихся — нет. Не, ну, в самом деле, покодить и порешать задачки — это ж куда веселее, чем в сотый раз рассказывать устройство хеш-таблиц или, прости господи, спринговых конфигураций каких-нибудь (xml-ных, ага).
N-Cube
Сначала данные нужно получить — скопировать данные (как? пакетно scp, потоково ssh или еще как… и вообще, через tcp или udp? в зависимости от количества и важности данных и сети передачи выбор не очевиден… у амазона и вовсе есть грузовики с накопителями для доставки данных) или загрузить обработчик на хост с данными (там вообще какая архитектура? Компилятор есть или кросс-компиляция потребуется?) или на набор хостов с данными (как их найти? они одинаковые или разные?) и так далее. Все данные записаны в одном формате? А порядок байт одинаковый или надо проверять (а как?). И так далее.
Странно, что об этом нужно напоминать, но говорить про код, который будет работать с произвольными данными произвольного размера и расположенными в произвольных местах — абсурдно. И это не говоря про эффективность.
sumej
Aecktann мне кажется. что не существует навыка написания кода. Есть умение решать задачи в определенной среде.
Как только выйти из среды — можно и не суметь. Кто-то может и не написать годный код на новом месте работы из-за среды (колегг, задач, сроков, семейных проблем и т.д.)
> Я говорю о случаях, когда ты просишь написать линейный поиск в массиве, а человек не может написать простой for-цикл.
О я на собеседованиях могу забыть синтаксис for у Python когда 4-5 дней до этого пишу на Go сутки на пролет. Так у меня было пару раз :(
И вообще что оркестр, что танцоры или певцы — всегда на новой сцене тренируются, настраиваются. Даже проф.волейболисты или футболисты «прочувствуют» стадион перед игрой.
Но программист выкован из Т-1000.
red75prim
По-моему, именно кажется. Если программист не может описать какой-то систематический способ найти в коробке шарик с максимальным номером, то возникает большое сомнение, что он программист.
sumej
Моя мать говорила на русском. Для всех остальных языков я всегда сомневаюсь, когда, что и какой синтаксис.
Я путаю ich bin и ich habe. Is и are.
For x in y: vs For i:=0;I<10;I++
Да у меня есть утилиты: ide, Google, GitHub, исходники библиотек.
Да программисты старой школы могли с нуля написать все. Ещё 20 лет назад я знал номера и дни рождения всех родственников и так же писал в слепую.
А сегодня я должен проверять синтаксис для следующих языков:
Python, Ruby, Java, Scala, Rust, Golang, Bash;
SQL, noSQL, Esper.
Всякие фреймворки: Spark, Flink, Kafka Streams, Kinesis.
Когда решаю ежедневно задачи.
Например, когда у вас 350 элементов и вам нужно их отфильтровать по 30 признакам и быстро в Python. Тут будешь с timeit проверять и читать нюансы. Например быстрее ли list comprehension или for? Как ваши представления вам помогут, если на prod версия 3.5; 3.7 или 3.10?
Как за секунду это выгружать из своей памяти на собеседовании, когда ты в стрессе?
ApeCoder
Он не будет водить на площадке и не будет парковаться с вешками. И вообще на любом испытании можно найти разницу с тем что будет на работе.
Чтобы абсолютно точно провести испытание, надо нанять пробно на работу на год, допустим, потом на машине времени вернуться назад и принять решение — нанимать или нет.
ToSHiC
Да не просят сложные алгоритмы придумывать, во всяком случае в нормальных конторах. Это реально что-то типа экзамена в автошколе, причём даже не в городе, а на площадке: покажи, что ты в принципе умеешь код писать (машину водить) — понимаешь, что такое алгоритм, что такое цикл, и в состоянии написать несколько строк кода на том языке, который сам же назвал своим основным языком. Типичный пример подобной задачки: написать бинарный поиск в отсортированном массиве. И довольно приличный процент синьёров-помидоров такой тест реально проваливает.
Milein
Кстати пример не очень. Потому что
Не такой он и тривиальный, этот ваш бинарный поиск.
Aecktann
Тошик просто тонкий.
AndyPike
Не очень корректный пример.
Больше похож (по стилю движения) — если он с git не работал тесно.
Типа, сделал свою ветку, без спроса смержил её с master, и задеплоил на прод.
Без ревью, по привычке.
Правда, я таких давно не видел.
Большинство задач на leetcode — немного надуманные.
Да, основы Computer Science, но когда это в последний раз было надо на практике?
Опыт другой — решать сложные задачи, в основном самостоятельно.
Или с коллективом.
Понять задачу заказчика/бизнеса, декомпозировать, продумать архитектуру, организовать мини-митинг фронта и бэка, обсудить. Продумать, тикеты написать. И, в конце концов, решить задачу. А тут задачки на низкоуровневую логику.
Это хорошо, конечно, но малопрактично.
Это моё мнение. Как и проходить тесты на IQ.
welovelain
Мне кажется, вопросы просто обсуждают энтерпрайзеры и какие-нибудь системщики. Отсюда столкновение миров. Нафига человеку, пишущему дрова, митинг с фронтендом
SwingoPingo
что бы Высокие боссы видели значимость и вопросы не задавали когда зп поднимать надо будет. Перенимайте опыт.
jetcar
За такие аналогии надо вешать, есть куча вещей в программировании которые никогда не встретяться в коде продакшена, а их зачем-то спрашивают. Давайте тогда спрашивать то что реально используется, если приводите аналогии с водителем, то что делают все и везде. Любой сеньёр это сделает без проблем. А если есть какие-то специфичные или чисто теоретический решения которые когда-то для развлечения порешал и забыл, то вы ищите не сеньёра, а того кто привык решать такие задания.
gohan
Мне эта аналогия не нравится, потому что простые механические навыки вождения машины несравнимы с работой программиста. Здесь ближе что-то типа учёбы. Я бы не смог быстро и без гуглежа и учебника решить задачки по физике с 1-го или 2-го курса уже лет через 5 после окончания универа, хотя на 1-м курсе успешно писал контрольную. Это же не значит, что я дичайше деградировал, просто время прошло, и мозг был загружен совсем другими задачами. Зато, если мне показать задачу из тех времён и 4-5 вариантов её решения, где только 1 верный, то я определю верный без гугла и учебников.
Так и с собеседованиями сеньоров — просто показывайте им несколько вариантов кода для одной и той же задачи, и они без гугла скажут какой лучше написан, ещё и аргументируют. Заодно и уточнят в каких условиях код работать должен, есть ли особый приоритет по памяти или по скорости. А самозванцы пальцем в небо ткнут.
Srgun
При этом он сможет нормально разгрузить самосвал в точно заданное место и филигранно сдать задом на автопоезде к разгрузочному месту.
И за 13 лет ни разу не ездить на легковушке, и отвыкнуть от её управляемости, жёсткости сцепления, непривычных тормозов, другого типа ручника и т.п.
А вы его отбракуете почему-то ТОЛЬКО из-за того, что он не смог справиться с малолитражкой.
Хотя работать с ней на вашей работе не придётся от слова совсем.
Л — Логика
Kwisatz
ОЧЕНЬ хороший кейс, я в восторге, если это это первое задание мы экономим огромное количество времени и можно спокойно сказать: «спасибо, вы мне не подходите, всего доброго»
khabib
Очень хороший пример, потому что водитель седельного тягача (автопоезда), который не сидел за рулем малолитражки месяц-два, будет рулить именно так. А при движении задом вообще катастрофа будет.
При этом он 10 лет ездит без аварий и может развернуть фуру на пятачке земли
wiha
Аналогия вкрай неудачная. Скорее вы просите его проехать на велосипеде по восьмерочке. Да студентом он лихо делал этот трюк. Но 10 лет он рулил грузовиком. Он может и проедит, хотя это будет не очень похоже на восьмерку, но быстро навык вернется. Но он отлично понимает, что есть шанс опозориться при этом. Вся проблемма в том что синьер в обычной работе решает задачи которые впринципе решаются не быстро. С другой стороны врятли он будет делать тестовое задание которое у него отберет неделю. Остается только обсуждение достижений.
AriesUa
Перед любым интервью оговаривают этот момент, что кодить не буду, так как это вообще не показатель для сеньора. В место этого, даю ссылку на свой github профиль, где у меня мои open source проекты. Открывайте, смотрите код, коммиты. Будут вопросы — с радостью пообщаемся, расскажу почему и как выбрал то или иное решение.
И знаете, это экономит как общее время так и мои нервы.
mynameco
А если у сеньра нет гит хаб проектов?
AriesUa
Если их еще нет, то возможно настала пора их завести :)
Кстати, мои проекты не супер популярны и половина была написана «just for fun», но сам код и подходы я старался проработать по максимуму, что бы не стыдно было.
Если у сеньера все таки нет ничего из open source, тогда возможно есть один два домашних проекта, которые не стыдно показать.
AndyPike
Иногда стыдно, на самом деле.
У меня 11 проектов, но ни один не доведён до конца.
Нет идей, просто.
Поигрался, понял, и забросил.
В результате 11 сырых pet-репозиториев.
Времени на всё не хватает, и идеи нет, на самом деле.
Не Todo'ху миллионную же писать на новом стеке.
Dolios
Мои домашние проекты — это фото и diy, а программирую я на работе. Из всех людей, что я прособеседовал (в том числе успешно) гитхаб был хорошо если у 1%
tommyangelo27
А у меня наоборот — DiV проекты это максимально тупой код, лишь бы задачу решить. И пишу я их не из любви к кодингу, а чтобы в конкретных условиях решить конкретную задачу (т.е. не гнушаюсь копипаста, хардкода и лапши).
Если условия задачи поменяются — перепишу.
Поэтому все репозитории приватные :)
Stas911
Тогда придется кодить, увы
Dolios
Расскажите мне менее затратный и более эффективный способ найма синьоров, например, в гугл, когда на вакансию подается несколько сотен человек. Кстати, помимо кодинг интервью там обязательно будет пара раундов системного дизайна, где как раз синьорность и проверяют.
Aecktann
Да что они могут понимать в этом вашем гугле, вон по гитхабу можно без интервью нанимать людей на 500к в год!
AriesUa
Приведу пример, мой хороший друг работает в одном крупном стартапе в Лондоне Product Owner. Так вот когда они начинали, они искали команды (Go девелоперов) на GitHub. И именно github был основным критерием для офера девелоперам.
Так что ваш сарказм неуместен.
Aecktann
Подобный хайр хорош, когда вы нанимаете одного из нескольких лучших разработчиков в компании, в надежде построить хорошую инженерную культуру в компании, и у вас в компании прямо сейчас мало кто может хорошо интервьюировать звёзд.
Он плох, когда у вас тонны хороших инженеров, сложившаяся культура и процессы и вы этих сениоров с гитхабами нанимаете по триста в год.
Ваш стартап не кажется гуглом. Мой комментарий был про гугл-скейл компании.
tropico
В гугл попасть хотят далеко не все из-за 5+ раундов собеседований. Забугром десятки историй как рекрутеры FAANG'ов раз за разом пингают кандидатов на предмет собеседования, а те в свою очередь спрашивают нужно ли до сих пор стоять у доски и когда получают утвердительный ответ говорят до свидания.
Или еще может так получится — Google Tried to Patent My Work After a Job Interview
daniilk
абсолютно неверное представление о таком виде собеседования.
во-первых — хороший программист должен знать алгоритмы и структуры данных, по своему опыту скажу, что практика решения задачек очень полезна.
во-вторых — цель таких интервью не экзамен на знания, а выявить ваш стиль работы и увидеть то как кандидат подходит к решению проблемы.
Но к сожалению интервьюеры сами этого не знают по-этому берут первую попавшуюся задачу, и проверяют решил не решил.
Кстати очень хорошее задание попросить кандидата настроить среду разработки и продемонстрировать как она помогает ему решать задачу.
Sano000
Последний раз устраивался
через постельпо знакомству. И следующий раз (когда придет время) будет точно так же. При этом к собеседованию готовлюсь (алгоритмы, доки, паттерны).Получается комбо-эффект. С одной стороны собеседование проходит в легком режиме, с другой стороны пред-подготовка позволяет показать себя с лучшей стороны.
ZXY000
Буквально вчера вернулся с интервью, злой, плевался, повелся на обещания в гонорарах и прочих нищчаках, все как по автору, не заметил как сам стал, судя по опусу соавтором, но это наболевшее, да простят меня админы, модераторы и сам автор, такова селяви:
Интервьюировал бос небольшой фирмы, накануне был с ним обстоятельный разговор о его ожиданиях и специфике направления. Он больше разносторонний менеджер, но не специалист, смотрел его скилы на linkedin, со своими разработчиками, вопреки моим ожиданиям меня не свел, хотя я предварительно пока его ждал у них на фирме, успел с ними пообщаться, посмотреть на аппаратную их часть в прототипах, перекинуться ключевыми моментами. Общее впечатление — у них горящий проект и педали одного велосипеда они крутят всей группой.
В разговоре с шефом, задавались общие вопросы, касающиеся моих прошлых проектов, близких к его теме. В общем бла-бла-бла, и я все же дождался, когда он начнет сам себя валить. Он просто вот так взял, и тупо попросил меня показать ему примеры моего кода и тут началась 1 часть марлезонского балета. Не имею привычки брать на интервью лептоп, чисто по причине его ненадобности, если это фрилансерские переговоры, обязан и всегда при себе держу. Говорю ему — нет у меня с собой лептопа это во первых, во вторых, я не имею права это показывать сторонние проекты, т.к. под подпиской NDA. За трудовые мои года у меня накопилась своя обширная библиотека кодов (я их обычно пакую в модули для более компактного вида, он бы все равно там ничего ни с 1-го и с 3-го взгляда не разобрал) и предпочитаю не держать в голове большую свалку, при этом знаю что и для чего и где. Проехали. Далее дискусс пошел в сторону его мудреного вербального алгоритма, я ему дал пару наводок, но сказал что есть еще множество вариантов, которые можно решать в процессе разработки с аппартной частью, кроме того есть и готовые решения, которые нужно допилить к его задаче. Такой вариант ему категорически не понравился, мол хочу свой, пусть дорогой, но авторский чисто вариант. В общем он показался мне серийным дирижером, который любит помахать руками для дудей на расческах.
Далее попросил рассказать о моем проекте, заходил анонимно на мой профиль сразу после телефонного разговора, смотрел мое портфолио и личные проекты.
Показал ему свою аппаратную часть. Долго на них таращился, то ли фокус наводил, то ли не знал с какой стороны выставить микроскопы, вертел в руках, но по виду было видно, что с таким же успехом можно было ему и банан всунуть. Вопросов не задавал, чувствовалось что не знал о чем спросить, сказал что они тоже, иногда делают для клиентов подобные решения, молчать было бы несолидно, то ли еще от какого осознания. Далее 2 я часть.
Сказал что у них надо работать как минимум 2 раза в неделю на месте. Я географически от его офиса в полутора часах езды своим транспортом. На что я ответил, что могу при необходимости и больше. Но по моему личному опыту во многих проектах, необходимость присутствия на месте в группе разработчиков составляет 5%, все остальное происходит в зумах, видеоконференциях с расшаренными рабочими местами. Так сейчас во времена короны работает большинство фирм и его фирма не исключение. При этом по мере необходимости я посещаю клиентов, где надо делать аппаратные подключения и проверки. Сделал мне козью морду и привел пример своей фирмы. У него работае 2.5 разраба с пустующей лабораторией, в довесок серкретарша и все там толкутся на небольшом пространстве. Смотри мол, они все приезжают и работают на месте, т.к. это групповые проекты. Я не стал дальше с ним разводить лясы, сказал что могу раз в неделю, при условии что даст машину. Так ни к чему и не пришли. Потом он вдруг вспомнил что у него через 5 минут встреча и на этом распрощались. На все про все 1 час. Гостеприимство нулевое, стоянку искал пол часа, плюнул стал на платную. Кофе не предложили. Мне там больше особой нужды не было терять время, да и он понял, что что-то еще не созрело в его голове.
Для таких интервью за натто хватит полу часового зума.
В целом с автором согласен, проблема сеньоров, как в их опыте, а так же с теми проблемами, которые им кажутся очевидными, опять же из собственного опыта, но общение с работодателями… при этом держать себя корректно в рамках приличия, чтоб не отсвечивать в разговоре его пробелами и не дай б-г вступать в споры, пусть даже профессиональные, штука невероятно сложная.
Как бы синьоры не готовились и не старались, их слабость в их силе, они за частую раскручивают параллельно личные проекты в рамках своего стартапа, ищут инвесторов и в промежутках подсаживаются на сторонние проекты.
Mikluho
Я, как сеньор с более чем 20-летним стажем (в рамках которого меня увольняли только по сокращению и с чувством глубокого сожаления, т.е. моей работой всегда были довольны), в принципе не против покодить на собеседовании. Но я против вот таких вариантов, которые чаще всего встречаются:
— использование тонких моментов языка/платформы, ибо: их дохрена и больше, я сам могу ими завалить собеседующего, но в работе тщательно их избегаю;
(за годы практики выработались способы обходить эти самые острые углы, потому что чаще проблем существенно больше, чем пользы)
— 100500 вопросов по «азам» языка/платформы, от синтаксиса до примитивов синхронизации потоков и работы GC, ибо многое проще найти, чем вспомнить, некоторое слишком редко используется;
(я вообще предпочитаю lock-free архитектуру и пишу без утечек памяти)
— «олимпиадные» задачки, ибо: в реальной жизни не встречаются, скилл разработки для реального бизнеса не прокачивают;
(там, где я работаю, не пригодится навык найти единственный непарный элемент в целочисленном массиве)
— «стандартные» алгоритмы/структуры, ибо: в реальной жизни мне крайне редко приходится опускаться до этих низин, вполне спасают библиотеки и поиск;
(например, мне только раз после института пришлось писать дерево, это было давно и я не помню алгоритмы обхода вглубь и в ширину, помню, что бывают разные виды деревьев, где-за углом притаились графы… т.е. я знаю, что гуглить, если потребуется, но с вероятностью 99% это всё равно не пригодится)
— тестовые задачки на «сферического коня», ибо: надо узнать, первое — что именно имеет ввиду автор, второе — что же он хочет получить на выходе, третье — какой стиль программирования он предпочитает, четвёртое — какие он подразумевает ограничения;
(тут вообще сложный момент, т.к. чаще всего собеседующие хотят увидеть конкретный код, который сами придумали, а я привык решать задачи в контексте, когда все эти параметры либо известны, либо требуют уточнения, и без этого контекста у меня сотня-другая вариантов решения может найтись, какой выдать на собеседовании?)
Иначе говоря, кодинг на собеседовании лишает меня того, чем я должен заниматься в реальной работе — много узнавать про задачу, думать про архитектуру, анализировать типовые решения, работать с командой — всё это время и ресурсы, которых нет на собеседовании.
Да и вообще, сеньоры бывают разные. Точнее говоря, под это название подписывают и ходячие энциклопедии, и тимлидов, и архитекторов, и специалистов широкого профиля, и узкоспециализированных профи, и просто мастеров, умудрённых годами опыта.
(из этого списка двум категориям уместен кодинг на собеседовании).
PS
лично я собеседовался несколько десятков раз, но интервьюировал более сотни кандидатов. И я не требую писать код на собеседовании. Мне достаточно того, что человек расскажет об этом вслух. Я и так пойму, в чём он разбирается, что помнит, что забыл.
Чуть иначе для молодых специалистов — я могу предложить написать что-нибудь совсем простое в той области, какую человек сам заявил, как изученную. Например, говорит, «знаю Linq» — ок, вот пример (заготовка кода) с парой коллекций, напиши простую выборку (одна строка кода, базовый синтаксис + один важный момент, про который стоит помнить). Знает JS — пусть напишет counter с приватным значением. И не даже не важно, получится ли написать это всё на бумажке/в блокноте/в чате, мне важно, понимает ли он задачу и знает ли, чем её решать. Остальное можно нагуглить и запомнить при частом употреблении.
dimalu85
Примерно так для меня и определяется адекватный разработчик.
Но к моему удивлению, почему-то «технари» остаются «технарями» и так мало при собеседовании обсужаются детали процесса разработки в компании. По мне так лучше поговрить к какому процессу привык разработчик, какой вид «стори на доске» считает нормальным и т.п. Ведь в большинстве случаев «уникальную» проблему можно решить выбрав подходящее типовое решение. И большая часть времени уходит как раз таки на определение проблемы и выбор, чем на программирование. Умение работать с проблемами внутри и есть сеньерити левел.
alexs0ff
Я лично сеньера от мидла отличаю тем, что при обычных обстоятельствах сеньер найдет готовое решение, чем будет писать свой велосипед. Имхо, сейчас очень много инструментов и почти любая задача может быть решена с помощью какого-нибудь популярного проекта на github. Так же и на собеседованиях в компании, спрашиваю какие задачи решают и какими инструментами пользуются и если есть «велосипеды» — то почему они, а не вот-тот популярный проект. По ответам можно судить об адекватности компании и людей в целом.
andyN
Кстати да. Сейчас у любого адекватного ЯП имеется огромный набор библиотек и готовых решений. А еще не забываем про SaaS и прочие помогаторы. Программирование сейчас в большинстве случаев сводится к процессу соединения воедино готовых блоков и к констуированию таким образом надежных систем, решающих задачи бизнеса. А не вот это вот смешное «решайте олимпиадные задачи по чистому сферическому кодингу в вакууме»
EvilMonk
Когда уже пройдёт мода на бороды
springme
Когда сеньор с 20-летним опытом работы в high-load с кафками хадупами, хазелькастами не может поделить столбиком на листке бумаги – заканчиваю собеседование и жму руку – нам в компании не нужны программисты, не усвоившие программу второго класса.
A114n
Ужас, прочел ваш коммент и понял, что реально не помню метод. Картинки из детства перед глазами есть, сотни примеров ведь перерешал, но алгоритм вылетел. Пойду погуглю.
springme
Вот то-то и оно.
А они все про деревья, сортировки… Люди столбиком не могут поделить!
Rive
А зачем им это? Этот метод вычисления был адекватен XII веку, когда кроме навощённых дощечек и абака других подручных инструментов для вычислений не было.
vassabi
вот будет у вас ребенок школьного возраста, придет делить в столбик — там и вспомните! ;)
joyfolk
Почему-то в подобных статьях всегда забывают, что собеседования могут преследовать совершенно разные цели на разных этапах и в разных компаниях. И иногда описываемый тип интервью — просто необходимость, с которой надо смириться (или не идти в такую компанию), а иногда — блажь интвервьюера (но тогда туда точно лучше не идти).
На мой вкус идеальное интервью: скрининг (с разговором про опыт) + тестовое домашнее задание (оплачиваемое, объемом на 4-8 часов, можно заменить богатым гитхабом) + блок обсуждения задания. Это и кандидату удобно и сразу видно, годится человек или нет. Но так очень мало какая компания может себе позволить сделать. По крайней мере у меня такое собеседование только одно было пока.
Shinbolat
Получается Жуниор есть сениор, без настроеной среды.
ZXY000
Жуниор бегает каждый раз к сеньору если у него соска потерялась
Rive
Это разве не трейни?
ZXY000
Им по барабану кем их считают, когда от них требуют спустя какое то время просиживания штанов, что нибудь выдать самостоятельное, они начинают извиваться ужами на сковороде и доставать всех и вся, мне конечно не в лом подсказать, и сам был таким, но если это переходит границы приличия, это всегда довесок в групповом проекте.
ZXY000
И вообще по прогнозам дона эсквайера на следующие 10 лет около 100 млн кодеров сядут на забор. CEO GitHub Chris Wanstrath — «The next 10 years and the next 100 million developers»
Artifeks
ну три года прошло, пока что не похоже что сбудится
Megadeth77
Дада low code несть им числа, воз и ныне там. Почему то общаться удобнее словами а не красивыми картинками, в том числе почему то с компьютером.
lpssp
Интересно, физики там или математики тоже могут сказать, что не помнят как числа складывать потому что последнее время только интегрировали, например. По-моему это абсурд.
Artifeks
ну если математик будет проходить 4 собеседования в неделю, несколько недель подряд и на каждом у него будут спрашивать всю таблицу умножения. Думаю его это так же выбесит
lpssp
А что если его спросят 2 + 2, а он ответит 5 и скажет, что ему это вообще не надо, как в статье написано?
Artifeks
я думаю вы поймете по дальнейшей беседе и его научным трудам, что он считать не умеет, невозможно это скрыть.
lpssp
Так почему нельзя сразу спросить?
stas2s
Пpоводят исследования на матфаке.
Студентам pазных куpсов задают один вопpос «Сколько будет 2 умножить на 2?»
Студенты 1 куpса сходу отвечают: — Четыpе!
Студенты 2 куpса сначала pоются в шпаpгалках, потом отвечают: — Четыpе!
Студенты 3 куpса достают калькулятоp и посчитав тожедают пpавильный ответ.
Студенты 4 куpса пpосят вpемя, чтобы сходить в компьютеpный класс и составить для pасчета пpогpамму.
Спpашивают студента 5 куpса.
Он возмущенно: — Я что все константы наизусть помнить должен?!!!
welovelain
Аспиранты уточняют, какая алгебра и систему счисления
ardraeiss
– Никак не могу найти себе помощника, – пожаловался однажды Эдисон Эйнштейну. – Каждый день заходят молодые люди, но ни один не подходит.
– А как вы определяете их пригодность? – поинтересовался Эйнштейн.
Эдисон показал ему листок с вопросами.
– Кто на них ответит, тот и станет моим помощником.
«Сколько миль от Нью-Йорка до Чикаго?» – прочел Эйнштейн и ответил: «Нужно заглянуть в железнодорожный справочник». «Из чего делают нержавеющую сталь?» – «Об этом можно узнать в справочнике по металловедению...».
Пробежав глазами остальные вопросы, Эйнштейн сказал:
– Не дожидаясь отказа, свою кандидатуру снимаю сам.
(ц) "Физики продолжают шутить"
0xd34df00d
Ну, в 17 лет мои навыки устного счета были на порядки лучше текущих, а задачи по школьной геометрии я гарантированно не решу. Да и производную частного двух функций не помню, надо будет выводить. Но это не мешает как-то там ковырять математику.
lpssp
Как-то там — это как? К тому же вы сами сказали, что можете вывести, значит это для вас не проблема. А если вывести проблема — то это и вызывает вопросы.
0xd34df00d
Это когда вроде получается недостаточно для того, чтобы результатами можно было быть довольным, но достаточно для того, чтобы понимать, что я туповат.
HellWalk
Ой, да пофигу.
Только недавно была эпопея с поиском новой работы — чего только не случалось — забывал, что делает GROUP BY, не мог написать простой SQL-запрос с одним JOIN и WHERE, с кодом тоже были тупняки, но спасал TDD подход — написал вначале тест, а потом методом подбора (на третье собеседование в день абстрактное мышление будто ушло в оффлайн) писал алгоритм.
Новую работу так и так нашел. А на тех, кто не делает скидку на то, что собеседование для программиста это не рядовая рабочая ситуация — да и пофиг на них.
На мой взгляд, переживать надо только в тех случаях, когда нет внутреннего желания развиваться в своей области — читать книги, изучать что-то новое, писать в личное время код, что-то выкладывать на github.
ahdenchik
Бывает обидное: попадается хорошее описание вакансии, из которого следует что она мне идеально подойдёт и она мне очень интересна. Но при отклике выплывает ХРюша, которая начинает задавать вопросы вида: «Какой у вас опыт с Луникс Кёрнел?» и «Назовите недостатки языка C/C++?». После получения ответов слышно закономерное: «Мы вам перезвоним!»
SwingoPingo
Коллега, не принимайте близко к сердцу. Возможно ХРюша всплыла здесь в предыдущей итерации на этапе размещения вакансии в БД, т.к. «такое описание привлечет максимум соискателей». На заборах тоже ж пишут.
stokker
Лучше отсылать свое резюме на все близкие по духу вакансии (пусть даже и не совсем точно подходящие) и тогда станет понятным тренд эйчаров по стандартным вопросам.
Ну а знать ответы на них, к сожалению, абсолютно необходимо.
ahdenchik
Но ведь это говорит о том что что система устроена очень неэффективно!
sentyaev
«Системы» — нет.
Katasonov
Senior разработчик это не тот кто ежедневно ковыряется в носу и архитектуры придумывает. Senior разработчик это человек который может в одного тянуть проект, например, когда все остальные разработчики уволились, то он может в одного делать практически все то, что делали остальные. А это значит, что кандидат на эту позицию должен уметь мыслить. Именно это и проверяется такими, казалось бы, банальными задачками. Если кандидат не может въехать в задачу и начать мыслить, то и гарантии, что он подхватит какую-то сложную часть проекта (возможно алгоритмически сложную) в трудный момент, нету.
andyN
Так в очень многих случаях обязанности системного архитектора лежат на синьорах, поэтому вы неправы
Katasonov
Более того, обязанности программиста, тестера и скраммастера, а так же частично тимлида тоже очень часто лежат на сениорах. Это в идеале бывает, что у нас есть крупный «завод» на котором четкое разделение сотрудников на разные цвета и человек делает только то что ему положено по уставу. У нас например, ввиду нехватки ресурсов сегодня сениор девелопер, завтра архитектуру обсуждает, после завтра автоматизацию тестирования делает. Вот так и живем — «тяжела и неказиста жизнь простого программиста».
wataru
Рекурсия?! Серьезно? Сеньер не может в рекурсию? Про реализацию всяких деревьев согласен, но про динамическое программирование — нет.
Кто в команде, если не сеньер должен уметь в алгоритмы? Оно не каждый день каждому кодеру нужно, но иногда может понадобиться и без знания ДП вы не поймете даже, что его тут можно использовать, сократив код в 5 раз и ускорив программу в 20 раз.
andyN
С рекурсиями в реальном мире последний раз я сталкивался лет 15 назад, и это были учебные книги по программированию на чем-то там. В реальном мире рекурсии обычно крайне нежелательны, думаю не нужно объяснять почему ))
ardraeiss
Думаю, вот это "и почему же?" было бы хорошей темой беседы для собеседования. С примера из практики(обезличенными) и вовсе отличной.
0xd34df00d
Нет уж, объясните, пожалуйста.
Rive
Из банального: каждый вызов функции занимает память под очередной контекст и не очищает старый, таким образом при рекурсивном вычислении можно достучаться до переполнения стэка.
0xd34df00d
Только если компилятор не умеет в TCO, и если алгоритм написан не в TCO-стиле.
SwingoPingo
честно говоря не представляю как бы я выкручивался без рекурсий в xml-е. А без xml-я в реальном мире куда?
0xd34df00d
Ну, в моей практике ДП очень редко было нужно. Чаще, чем красно-черные деревья писать самому с нуля, но достаточно редко для того, чтобы ожидание этого от других людей казалось не очень разумным.
eldog
У меня был случай:
Связываются по поводу позиции. Суть позиции не вполне понятна, хочу ли я туда — не понятно, договоримся ли по деньгам — не понятно. И говорят: Для начала нужно сделать задачу по программированию, займёт не больше 4 часов (чтоооо?!). Сделаете ветку тестового задания на гитхабе, внесёте необходимые изменения, предоставите документацию. Первое желание было послать их, но задание показалось любопытным. В итоге сделал ровно то и настолько, насколько мне было интересно. Документацию делать не стал. В изначальном проекте были юнит тесты, довёл до ума один, чтобы протестировать свои изменения. Так часа 4 и заняло.
Резюме проверяющего:
1. Задание не выполнено (неправда, но ему было так же лень вникать в мой код, как мне писать документацию).
2. Документация не предоставлена (правда)
3. Юнит тесты не предоставлены (один предоставлен, но по заданию на 4 часа и того не требовалось).
Итог: нам не подходите. Ну как бы не очень и хотелось, но подход странный.
ZXY000
И не факт, что таким образом они этим не воспользовались, допилят и пустят в свое производство.
eldog
Вряд ли, там типично тестовое, coding ката какая-то про гномиков :-)
Когда работал в одной маленькой фирме, там офшорных разработчиков так пробовали: давали им задачу реальную, но несрочную. Если справлялись, им платили и продолжали, нет так нет. Один раз заплатили, но продолжать не стали: результат был получен, но мороки было невесть сколько. Но там честно, сделано — платили.
andyN
Тут наверное надо разделять синьора как разработчика и синьора как тимлида, а еще синьора как системного архитектора. Если речь идет о голом кодинге, то спрашивать решение можно. Проблема в том, что «синьоры» нынче делают очень много поимо собственно манки кодинга — они проектируют системы, решения, структуры и взаимодействия классов в конце-концов. Это уже не говоря о code review, деплоях и так далее. Компании должны в первую очередь научиться писать нормальные резюме, с четкими запросами того что им нужно. «Знание С++» это полнейшая чепуха, нужно обязательно указать предметную область. И обязательно указать что от человека еще будет требоваться, помимо собственно написания кода. Компании часто упускают некий пласт работы синьоров, типа принятия решений по архитектуре, и об этом не пишут. Хотя это иногда занимает у синьоров намного больше времени чем собственно сам кодинг. Я не устану повторять, что плохо описанные, шаблонные вакансии — это главная проблема найма в IT
ZXY000
Далеко за примером ходить не требуется. Это объявление выставляется на lincedin регулярно в течении года, причем их HR им спамят направо и налево, при том что в моем профиле присутсвуют 2 ключевых хештега #full stack engineer, #developer:
Такая растакая фирма (при входе в профиль фирмы на фото человек 50 радых веселых, судя по лицам недавних выпускников:
a new Senior Full Stack Engineer role in Tel Aviv, Israel, and we think you may be a good fit.trigo just posted a new Senior Full Stack Engineer role in Tel Aviv, Israel, and we think you may be a good fit.
«Наша супер дупер фирма aspires to enable a seamless shopping experience. Imagine walking into a supermarket, simply picking up whatever you need and exiting without having to wait in a single line. Our solution is based on neural networks, proprietary algorithms and ceiling-mounted commodity cameras, developed by a team of leading researchers from both academy, industry and military backgrounds, who happen to be really nice! We have recently secured a significant A round and we’re already deployed in a number of global grocery retailers.
The Position:
We’re looking for a talented and creative Senior Full Stack Engineer to join us.
This is a fantastic opportunity to join our excellent team early on and grow with the company.
If you’re dedicated, friendly, appreciate challenges, and looking for something beyond the ordinary- then your place is with us!
— As a Senior Full Stack Engineer you will:
Participate in the development of an enterprise-grade, highly scalable and robust cloud-based microservices architecture.
Design, implement, test and deploy high traffic features, with an emphasis on scalability, performance and security.
Develop front-end applications on web and mobile utilizing React.JS and Flutter.
Work in a multidisciplinary environment with researchers from the fields of deep learning, computer-vision and algorithms.
Deliver features from design through implementation to production.
Work closely with relevant stakeholders including product, infosec and operations.
About you:
A full-stack engineer with at least 5 years’ experience.
Highly experienced with server-side development.
At least one year working with Node.js.
Experience with client-side web frameworks like React.
Proven experience in production cloud-based environments.
Worked with CI/CD methodologies.
BSc. in Computer Science or equivalent.
Independent engineer, able to deliver features end-to-end.
Strong team player.
Nice to have:
Knowledge of UI design principles, patterns and best practices.
Experience in mobile development (Flutter/iOS/Android).
Gordon01
Ага, потом приходишь работать в %уважаемая_контора%, а там разработчики бинарный поиск реализовать не могут.
И проблема даже не в том, что они не могут написать код, они вообще не подозревают о том, что теоретически возможны алгоритмы, работающие быстрее линейного поиска.
А по резюме — серьезные ребята с 10+ летним опытом работе, куча реализованных проектов и опыт руководства.
Любая задача среднего уровня сложности с leetcode успешно бы отсеяла данных персонажей.
atomic1989
Статья классная и в точку. Сам проходил собеседования, в которых спрашивали вещи, которые не то что нельзя применять в реальной жизни, а надо бить по рукам. Лично как по мне, сеньор разработчика стоит больше спрашивать про архитектуру, давать задачи по этой тематике. Уточнять детали предыдущего опыта, какие проблемы решали, как решали. Многие моменты забываются. В университете щелкал на раз два дифференциальные уравнения, интегралы. А если сейчас дать в лоб решить уравнение, буду пеньком)
Raimon
Я долгое время тоже гонял кандидатов только по теории. Сейчас же 50% это обсуждение опыта в различных областях, некоторые теор вопросы по платформе/языку.
Остальные 50% это лайв кодинг. И я скажу там человека очень хорошо видно.
Я никогда не требую полного знания какого либо апи, то есть файловое, бд, cериализация. Апи я предлагаю додумать, если кандидат не помнит точного.
Я обычно предлагаю какое-то простое базовое задание, потом вокруг него можно задать много вопросов: как тестировать, что будет узким местом и почему, как ускорить, что может упасть, дизайн апи, стоит ли делать async/await… потом могу попросить реализовать одну из предложенных кандидатом улучшений.
Все это делается в дружественной атмосфере, чтобы свести волнение кандидата к минимуму.
В целом формат интервью, список тем, вопросов, и задания на написание кода сильно зависят от требований к позиции на которую человек рассматривается, цели интервью и времени которое выделено на интервью.
dimalu85
Для меня путь от младшего сотруника к старшему — это как путь от ЧТО кодить к ЗАЧЕМ кодить.
Winnie13
Возможно, я старовер, но в модельном примере с учительницей, я бы на месте нанимателя просто нанял бы её на испытальный срок просто по факту рекомендации и банальной беседы, цель которой была бы вовсе не понимание её, так сказать, «технических навыков» (для этого у меня есть рекомендация от источника, вызывающего доверие, + понимание того факта, что сам я не обладаю должной экспертизой, чтобы эти навыки должным образом оценить), а цель такой беседы — просто понимание того, что мы (коллектив и она) друг другу подходим с т.з. как раз нетехнических факторов. Цирк с «уроком» устраивать бы не стал. Это просто оскорбительно, в конце концов.
С опытными программистами я поступал бы так же.
Daemonis
Всех 500 кандидатов?
Winnie13
Если на конкретную позицию опытного разработчика образовался список из 500 кандидатов, то, значит, уже что-то пошло не так с процессом найма.
В сущности, если искать человека на позицию из числа проверенных рекомендательных источников, то во-первых, откуда там взяться сотням кандидатов. А во-вторых, цель же всего мероприятия — не посмотреть всех потенциально подходящих кандидатов на рынке, а нанять первого подходящего. Т.е. это вообще часто не параллельный смотр списка кандидатов, а последовательный перебор тех, кто появляется на входе. Часто с матчем уже на первом кандидате (как, кстати, и в примере с учительницей).
А так да, если на столбе повесить объявление «ищется опытный разработчик, дорого», то возможно и будет 500 кандидатов, но 490 из них — это вообще будут пройдохи, а из оставшихся 10 подходить будут только 1-2 — ну и ещё попробуй их из общего списка отфильтруй. IMHO ни один метод поточного тестирования не даёт нужных результатов — в особенности с опытными людьми.
Daemonis
Вы, как заправский сеньор, решаете не ту задачу, которую вам поставили :) Если вы можете просто нанять проверенного друга, проблема вообще не стоит.
kraidiky
Как заправский сеньёр он сводит задачу к готовой библиотеке. :)
Идёте в Библиотеку, берёте там книжку "Законы Паркинсона" Открываете там главу «ОКОНЧАТЕЛЬНЫЙ СПИСОК, или Принципы отбора кадров» И читаете там подробнейший разбор того, что именно вы делаете не так. :)
P.S. Про найм по знакомству там тоже есть в конце главы. :)
Winnie13
Как заправский сеньор, я не подменяю настоящую задачу другой, «более интересной».
Если я ищу человека, то я хочу найти как можно быстрее того, кто подходит, и потратить на это минимум усилий. Идеально, вот прям с первого раза. И так, чтобы потом не переделывать [задачу, разумеется].
Устраивать смотрины всего города наобум, попутно решая технический вопрос организации этих смотрин — это не задача. Это просто неудачный метод её выполнения.
kraidiky
Этому, собственно и посвящена эта глава в сборнике. :)
Причём пол главы объяснению менеджерам почему настоящая задача состоит именно в этом, а не в отсматривании на очном собеседовании 500 человек.
Daemonis
Это все прекрасно. Но в реальности бывает так, что друзья, друзья друзей, друзья друзей друзей закончились, а нанимать все равно кого-то надо. А как ты вакансию не составь, на нее неизбежно придет 100500 людей, и отсеивать неподходящих все равно придется.
Winnie13
Не то, чтобы я сводил вопрос к тому, что нанимать надо исключительно друзей друзей — это просто был пример из статьи, когда первая соискательница пришла по рекомендации, и менеджер разумный в описанных условиях должен был бы её просто нанять на испытательный срок, и не городить чепухи. Почти наверняка, позиция была бы закрыта, и ничего делать бы вовсе не пришлось.
Но, если уж ограничиться одними только рекомендациями проверенных источников, то я не вполне понимаю, как они могут закончиться? Как бы высоко вы ни забрались, объём команды, в которой вы кого-то будете нанимать будет составлять 10, максимум 20 человек. Причём не все ж сразу. Остальных нанимать должны не вы. При этом жизнь идёт своим чередом, число проверенных источников растёт, число проверенных людей тоже. По идее этот охват должен расти намного быстрее, чем менеджер «переводит» людей в своей команде, иначе такой менеджер действительно переводит людей без кавычек.
IMHO как ни крути. Если на входе много кандидатов, значит что-то не так с процессом найма. Или не там ищутся, или не те ищутся, или не тем ищутся, или требования неясны, ну и т.д.
kvas
20 лет опыта программирования и я вполне нормально отношусь к программированию на собеседованиях — это весело и молодёжно. Не все сеньоры ненавидят собеседования с кодингом.
Задачу домой — тоже ок, но это немного другой вид спорта и он тестирует другой набор навыков. Что клёво в лайв-кодинге — это то что можно вместе подумать над задачей и сразу посмотреть как кандидат мыслит и как он общается. А это тоже важные навыки для программистов.
Ваш пример про учительницу не совсем аналогичный, так как кодинг-задачи на интервью гораздо проще чем боевое программирование. А попросить учительницу объяснить умножение столбиком, чтобы посмотреть как она объясняет — это по-моему ок.
Ещё одно важное замечание про кодинг-интервью: люди, которые участвовали в соревнованиях по программированию, умеют лайв-кодинг гораздо лучше обычных программистов и стоит делать на это поправку. Ну и понятно что не кодингом единым ограничивается работа программиста, особенно если он сеньор, так что не стоит всё время собеседования на это тратить.
kraidiky
А у меня за всю карьеру из случаев кодинга на дом только один был результативный, и одновременно он же единственный был реально интересным челенджем. Дано было словарь на 50 тысяч слов и нужно было построить кроссворд на поле 100х100 по некоторым усложнённым правилам. Типа кто быстрее. Мой результат был лучший среди всех претендентов, с трудом заставил себя оторваться от задачки на третий день. Но и задачку эту придумал для отбора основатель компании, сам в прошлом программист.
А большинство случаев надомного кодинга, — это когда девочка HR всё равно не способная понять что там написано, вставляет в собеседование такой этап, потому что по имеющимся у неё знаниям просто не способна отличить программиста от бобра строящего плотину в лесу. Ну и нафига тогда в этой процедуре такая девочка? Часто вообще аутсорсер, кстати.
Tantrido
Жизненно, конечно бывало. Нормальную работу как раз находил там, где давали реальное задание и его можно было выполнить спокойно дома за день или, если большое, за неделю, если тестовое оплачивалось.
KEKSOV
Единственный вопрос, который можно и нужно задавать кандидату любого уровня — расскажите, что происходит с момента, когда вы кликнули в адресную строку браузера, набрали в ней адрес google.com (нажали Enter) и моментом, когда на экране отобразилась страница поиска. Ответ может быть бесконечным, некоторые его части, если до них дойдёт дело, можно будет номинировать на Нобелевскую премию.