Комментарии 42
Емли интервьюер достаточно квалифицирован, чтобы задать такие вопросы – скорее всего, либо разговор дойдёт и до них, либо он оценит способность кандидата на них ответить косвенно.
Это как с маленьким тестовым заданием – конечно, на решение смотрят (совсем уж негодные кандидаты отсеиваются сразу), но в первую очередь это тема для обсуждения: если у нас такие-то изменения в задаче – как поменять код, ну и т.п.
Вместо вопроса «Как нам установить куки?» - «Для чего нам нужны куки? Зачем их придумали? Какой пласт потребностей они закрывают?». - Ну это уже бизнес требования по сути)
А кто будет задавать такие вопросы, если собеседующий сам на них ответить не может? Или если и ответит, то что-то вроде: потому, что best practice / так написано в книге какого-нибудь Мартина или банды четырёх.
Как ни странно, в маленьких компаниях с этим дела лучше обстоят. Там обычно самый главный тимлид собеседует. А в больших конторах, где рядовым сотрудникам (пусть даже в звании "старший сениор") дополнительно вменяют обязанности проводить собесы (может даже за доплату), эти сотрудники как раз среднего уровня. Единственно, на "архитектурном собесе" может быть матёрый (если собеседование многоэтапное).
толковый собеседующий - редкость, увы. чтобы задавать вопросы, исходя из повествования кандидата, самому собеседующему необходимо иметь знания. поэтому зачастую встречаются любители опросников, прикрывающие свои опросники козырной шестеркой под названием "ну нам же нужна единая шкала для оценки?". так и находят друг друга любители цифровизации умений кандидата и кандидаты-манчкины. плохо это или хорошо покажет только время.
Адский экспрешен, который в жизни не встретить
Вот вам экспрешен (без полного контекста, ибо тот слишком велик), который мне в жизни не просто встретился, но и отнял у меня некоторое количество этой самой жизни:
v = (0, o[w(109)]) (function (e) {
const t = w;
var n;
return (null !== (n = e[t(427)]) && void 0 !== n ? n : 'GET') [t(218)]()
}(t)Хорошее знание синтаксиса, позволяющее подобные вещи распарсить в уме, может сохранить немало времени и нервов если с ними придется (а за пять лет опыта хоть раз да придется) столкнуться.
А зачем? Исходники потерялись?)
Классный кусок кода про который можно спрашивать на собеседовании "что с ним не так". Даже можно без контекста.
Странно как он у вас скомпилился – с минификацией, но без оптимизации.
ЗЫ: А вообще вы этим комментом, наверное, сделали больно всем, кому по какой-то причине доводилось подобный выхлоп вебпака дебажить)))
спасибо Вселенной, что я не программирую на джаваскрипте
А это разве валидный код?
Вопросы нужно строить в прямой зависимости от предполагаемого уровня квалификации сотрудника. Так если человек отлично мыслит, а по трудоустройству ему накидают задач на решение которых не нужно думать или размышлять, тогда проявятся прелести неудачного найма. Но если у сеньора спрашивать только теорию и термины, тогда найм будет также неудачным. Чтобы найм был удачным важно соизмерять требования к кандидату с предполагаемыми задачами и выстраивать на этом стыке интервью.
Кто бигдатой занимается, в курсе что недообучение лучше чем переобучение так как всегда можно дообучать на новых данных.
[ирони]все дураки - один я умный, ща я докажу[/ирони]
дайте гражданину на код ревью код из репозитория, который писал джун, а потом сеньор все перечеркал пока объяснял почему джун-обезьяна. Бывают ситуации, когда одно взгляда достаточно чтобы понять дичь. соотв. подготавливаем пачечку таких кейсов и начинаем их обсуждать.
тут все нормально? если нет, то почему? чем это грозит и не грозит? что надо исправить?
если чувак заметил все лулзы джуна - значит чувак мидл.
если мидла успешно поправил - значит он сеньор.
если сеньора поправил - зовите Джигурду - пляшите джигу! Ущипните себя, возможно вы спите или под кайфом.
Вопросы вида “зачем нам нужен...” – это когнитивная пропасть для человека с философским складом ума. Если верить Будде, в конечном итоге – чтобы увеличить страдания живых существ.
Рассуждая поближе к материальному, это ж не тестируемый придумал и ввёл в обращение, например, протокол http. Может, он ему и вовсе не нужен. И даже скорее всего.
Я утверждаю, что нас в значительной степени окружают вещи, придуманные не очень умными людьми из совершенно ошибочных соображений. Не надо искать в этом высший смысл. (Другое дело, куда эти вещи кто потом приспособил. Вот Колумб, скажем, стремился убить и ограбить побольше индусов, а в результате открыл путь в Америку; если бы он занимался программированием, наверняка до сих пор мы бы прокладывали путь в США, обращаясь к методу toIndia (2)).
Короче, вопросы о побудительных причинах для того или иного решения обычно не имеют не то чтобы верифицируемых, а хотя бы просто общепринятых ответов. Поэтому я думаю, что это плохие вопросы. “Зачем” – вообще самый когнитивно токсичный вопрос.
Вопрос “что будет содержать переменная в данном случае?” имеет однозначный ответ, этот ответ легко проверяем, а результат теста поэтому справедлив. А все философские рассуждения о целях программирования могут по сути показать только то, на одной или на разных волнах мыслят спрашивающий и отвечающий, что непонятно зачем нужно.
Last but not least. В ответах на вопрос “Зачем” наивысший балл всегда получит GPT. А вот на конкретике простым резонёрством не проедешь.
А вот на конкретике простым резонёрством не проедешь.
да запросто ;))
я однажды затроллил интервьювера тем что начал сним спорить о том задаваемый им глупый вопрос некорректен и такая ситуация должна быть исправлена и не допущена в принципе, и смысла искать костыльное решение под такую задачу это очень плохо и пощряет омнокод, по этому нет смысла даже рассуждать о причинах и способах решения подобных вещей
собственно на любую тему можно так выехать при небольшим опытом в риторике
кстати очень спасает на тупых собесах где интервюверы сами не знаю зачем задают академические-синтетические вопросы не имеющие смысла в реальной разработке
Интервьюер, со своей стороны, мог просто поставить в ответ прочерк. Тут смотря на кого попадёте.
Регулярно таких кадров собеседую, которые мне рассказывают про миры розовых пони и про то, как всё должно быть по букварю. В ответ на просьбу подумать и придумать решение в конкретной специально созданной искусственной ситуации. Собеседование они не проходят, как не способные к мыслительной деятельности. Не проблема, когда программист чего-то не знает, проблема, когда программист не способен думать и искать решение в рамках поставленных условий.
В ответ на просьбу подумать и придумать решение в конкретной специально созданной искусственной ситуации
Задания надо давать реальные, а не синтетически-тупые, очень сильно нервирует
обеседование они не проходят, как не способные к мыслительной деятельности
отлично, нечего работать в конторе где интервьювер не может придумать на собесе задачу которая не имеет адекватного решения в рамках бизнеса
Грубо говоря если я приду устраиваться админом и меня будут просить например сделать тулзу которая насильно подавляет обновления у винды и динамически блочит в фаерволле сайты апдейтов… я буду спорить в рамках того что это задача решается совершенно другим способом НЕЗАВИСИМО от того как технически решать конкретно эту задачу, просто потому что эта задача — бред сумасшедшего, и если в конторе есть такие задачи то мне с ней не по пути если "мыслительный процесс" подразумевает исполнение таких задач без попыток эскалировать решение ситуации которая вызывает такие задачи и решать ей другими методами.
А если интервьювер не в состоянии объяснить почему он предлагает решить бредовую задачу и начинает отмазываться "специально созданной ситуацией, инопланетяне прилетели и украли ИДЕ, вы должны помнить синтаксис языка наизусть, и не доступна половина системных либ простопотомушта" (с) — то он тупо профнепригоден
во вспомнил, спорил на интервью, когда мне сунули кусок кода с sql injection и начали просить его улучшить, причем решение существенно ухудшало этот самый injection, на что я резонно указал что именно та задача нерешаема, на что инервьювер начал говорит "та это норм, мы закроем на это глаза, надо решить такую задачу!" — прям рукалицо
искать решение в рамках поставленных условий.
решение бывает административное или архитектурное, а не тимлид/рп сказал ты обязан сделать так как он сказал, тимлид и РП могут ошибаться и важно уметь им на это указать
Да, примерно такой же поток бреда я получаю от как-бы "синьоров" неспособных распечатать словарь в консоль. Они надувают щеки, стучат ножкой и брызжут слюной, прямо как вы сейчас. И всё это потому, что они балаболы, а не программисты, программировать не умеют и могут только пыль в глаза пускать.
программировать не умеют и могут только пыль в глаза пускать.
ну я в менеджмент и пошел в итоге ;)
а если серьезно, если бы я не умел программировать, я бы наверное не был бы сейчас сеньором-лидом с ЗП по верхней планке для РФ и опытом работы в разных конторах, я чисто рядовым сеньором года 4 проработал… в разных конторах и в очень крупных и в стартапах и в забугорных в т.ч.
хотя да, именно как программист я вероятно буду слабоват по вашим меркам, по этому я ушел в лиды и менеджмент
но вот смотря в разных конторах на разных людей, тупое умение программировать — это очень мало, надо еще о проекте и бизнесе немного думать, а не печатать словарь в консоль. и я скорблю что подавляющее число коллег вообще не думают за рамками описанной задачи слово в слово
вот у меня есть сотрудник в команде, неплохой миддл, но ему задачи надо описывать прям скурпулезно… вплоть до тупейших деталей в стиле "построил дом, сделай лестницу и дверь и лесенку к ней и чтобы в дверь можно было войти"… оставил его тут одного на две недели, описал задач… он наваял огроменный крутой модуль, с тестами, с доками и… даже не удосужился подумать что его надо было интегрировать вместо старой реализации… хотя в задаче это было
уже год с ним мучаюсь… вот он никогда сеньором не станет, хоть 20 лет опыта у него будет
мне кажется вопрос "зачем?" один из важнейших в IT и вообще в жизни. Сколько раз он меня спасал он придурашных задач, которые решение исходной проблемы клиента, протащив её через жернова аккаунт-менеджеров, ПМов, аналитиков и прочих, превращали в сущий ад.
Это всё, конечно, хорошо, но примерно половина тех, кто приходит собеситься на синьора не справляется с заданием: распечатайте в консоль словарь в виде строк "{ключ} = {значение}", все значения скаляры. Я не шучу. Мне начинают рассказывать, что в работе такое не нужно и вообще можно просто весь словарь сразу вывести и т.д.
Так что, неча на зеркало пенять, коли рожа крива. Пока кандидаты будут нагло врать в резюме, я буду долбать их задачками, которые позволяют понять, что они из себя представляют и умеют ли они кодировать хотя бы на уровне студента.
А что касается алгоритмов, 90% "синьоров" в принципе не знает теорию сложности и что такое "O". Давать им какие-то алгоритмические задачи вообще бессмысленно.
в принципе не знает теорию сложности и что такое "O"
"Моя прелесть"? Да знают они, знают, все это кино смотрели.
, 90% "синьоров" в принципе не знает теорию сложности
90% сеньёров это за последние 20 лет ни разу не понадобилось. А то, что не нужно SQL select писать внутри цикла - они и без этой теории знают. А ещё они знают, что тормоза будут вовсе не от того, какой именно алгоритм сортировки используются, а от того, в каком месте он используется. И для этого не нужно знать теорию сложности или О. Для этого нужно иметь опыт и думать головой.
Ага, а потом такие опытные квадраты пишут там, где можно за линейное время. И это ещё не самый плохой вариант, бывает и хуже. Просто потому, что не знают, как оценить сложность написанного ими.
Эти опытные понимают, что не нужно заниматься преждевременной оптимизацией, пока в этом не появилась необходимость. Потому, что знают, что скорее всего оптимизировать придется совсем не тут, где сейчас кажется. Поэтому тут и сейчас лучше написать так, что бы было максимально понятно. А всякие хитрые и скоростные алгоритмы понадобятся потом, но это не точно.
Речь не про оптимизацию, а, например, про линейный поиск по массиву в цикле, когда можно было set использовать. Т.е. про изначально неправильный выбор структуры данных от незнания.
Хватит натягивать сову на глобус, оправдывая лень и безграмотность. Специалист, который отказывается изучать азы своей профессии, плохой специалист. Обычно к такому склонны те, кто не получил профильное образование (но это не всегда так, конечно же).
Это именно то, что отличает инженера (SWE) от ремесленника-кустаря.
например, про линейный поиск по массиву в цикле, когда можно было set использовать
А можно и не использовать, если в предполагаемом массиве будет всего лишь два элемента. Я же написал, головой думать надо, а не верить в святого мартина и банду четырех.
Если бы у бабушки был член, то это был бы дедушка. Я пишу про ситуацию, когда нужно использовать. Не надоело демагогией заниматься?
Вам бы опыта поднабраться, а то туда же, собеседовать лезете. Бедная компания, для которой вы собеседуете, и бедные кандидаты. Впрочем компанию не жалко - сами виноваты. А вот кандидатов всё же жалко.
Рекомендую вам читать ваш же совет регулярно. Тогда, возможно, вы когда-нибудь соберетесь освоить базовые для професии знания и вырастите из говнокодера кустаря-любителя в инженеры.
Уже только тот факт, что вы в интернете решили писькой померяться с незнакомым человеком, достаточно красочно вас характеризует.
Когда я провожу интервью, меня интересует во-первых, честность и самооценка, во-вторых, ход мыслей кандидата.
Прежде чем задать сложный вопрос, я всегда спрашиваю, насколько сам кандидат считает себя экспертов в этой теме. А когда я задаю вопрос типа, "нихрена не работает", то тут уже мне интересна самостоятельность кандидата и готовность к командному взаимодействию, а не то, решит ли он эту надуманную проблему.
Вопросы, ответы на которые можно найти в Гугле за три минуты никогда не задаю. Если такой вопрос возникнет в производственном процессе, то за те же три минуты ответ найдется. Интересно понимание концепций, а не зазубренные факты.
Странная рекомендация. Начну с начала. Зачем собеседуем?
Мы пытаемся понять, подходит ли кандидат в команду. Кандидат пытается понять, надо ему или нет. Если сосредоточится на первой части, то логично прийти на собеседование со списоком вопросов, которые должны обеспечить получение информации о кандидате и сравнить его с другими.
И тут очевидно торчат ушки некоторой систематизации вопросов, их категоризации. И применения простого и всегда работающего принципа "в хорошем вопросе половина правильного ответа". На собеседовании еще проще, так как мы ж не задаем вопрос про неизвестное нам. Мы знаем, если ты тимлид, что должно быть в ответе.
Все. Зная ответы, строим вопросы так, чтобы либо их получить, либо получить четкий сигнал, что кандидат этого не знает.
Как именно? Предполагается, что тим лид уже умеет говорить с людьми, и в состоянии лидить разговор, чтобы прийти тому, что ему надо.
А в статье ... зачем придумали http? Кому это было надо? Спроси меня такое, я подумаю, что с той стороны сидит идиот 60+, которому реально хочется получить буквальные ответы на эти вопросы и поговорить о временах, когда трава была зеленее и дальше по списку
Честно сказать, у вас в айти очень странные собесы.
Я работаю проектировщиком и недавно главный специалист с 20 летним стажем спросил "а в каком документе у нас требования к деформационным швам на бетон?". А это ну типа основы, в вузе преподают. Я уверен, что то похожее бы спрашивали на собеседованиях в строительные конторы, если бы они были похожи на айтишные собесы.
То есть этот глав спец такое интервью провалил бы, а он очень умный мужик, у него можно многому научиться.
Мне кажется, через какое-то время и в айти тоже откажутся от теоретических вопросов, и будут только вопросы в духе "как бы вы справились с такой то ситуацией".
Я потому и указал выше, что бессмысленно задавать на собеседовании вопросы, ответы на которые гулятся за минуту. Пусть сотрудник гуглит эти вопросы и дальше. То что часто надо - запомнит, редко - не фиг голову забивать.
А вот выяснить, что кандидат вообще понимает необходимость деформационных швов и причины, по которым их делают - уже другое дело. Потому что без этого он может вообще о них забыть.
Публикации
Пожалуйста, чаще спрашивайте кандидата на собеседовании: «Зачем? Для чего?»