Другое дело, что далеко не все конторы до этого додумались
Когда у вас поток по 2-3 кандидата в неделю, то оказывается, что дело не в «конторы не додумались». В крупных организациях на 1000+ разрабов поток бывает и по 10 кандидатов в неделю.
Хороший девелопер может не написать код, а может и написать. Разве нужна эта лотерея?
Дак если бы был способ надёжно, без лотереи, узнать уровень кандидата — все бы им пользовались.
Давать для вайт боард кодинг можно лишь простейшие задачи(fuzz bizz, проверка строки на палиндром) для проверки, а умеет ли кандидат вообще писать код, в принципе?
Согласен, именно о таких задачах я и писал. У меня личный критерий отсечения «сложных» задачи — попросить коллегу-мидла на обеденном перерыве накатать решение. В спокойных условиях, за чашечкой чая. Если за 10 минут не вышло — задача плохая, т.к. при стрессе вперемешку с обсуждениями и мыслями вслух, кандидат будет писать её минут 40.
Со студентами-олимпиадниками есть отдельная проблема: они очень хорошо пишут код на листочке, решают алгоритмические задачки на раз и вообще влёт проходят типичные «гугл-фейсбук-эппл»-собеседования. Для таких товарищей есть секции по архитектуре и проектированию. Жаль, не во всех организациях при приёме эти секции проводят (я не про отдельную встречу на час-два, а хотя бы рассуждения минут на 15).
Ну и студентов настолько больше, чем молодых senior-разрабов, что обычно если видишь молодого парня, бодро пишущего код от руки, то вывод (изредка неверный) сам напрашивается, это да.
Тоже встречался с таким (в качестве кандидата). В таких историях есть сильные косяки от интервьюеров:
Из четырёх людей трое докапывались чуть ли не до запятой
Я и мои коллеги-интервьюеры никогда не считаем это проблемой, т.к. ясное дело, что если человек пропустил точку-с-запятой в конце строки, то это либо от концентрации на самой задаче, либо от волнения. И то, и другое — вполне ожидаемо на собеседовании, так что лично я просто указываю кандидату, мол «запятую потеряли» — и даже не успеваю сказать где именно, а человек уже исправил. Если же интервьюер просто говорил «у вас программа работает некорректно» и ждёт исправления запятой — это косяк скорее интервьюера, нежели кандидата, т.к. таким образом ничего полезного не выясняется, а время (и нервы) тратятся.
минут 35-40 я тупо писал и правил код
Это вообще треш. Если решение занимает несколько листов А4 (ну или несколько исписанных досок) — это крайне плохая задача для собеседования. Вариант, что «кандидат настолько плох, что не догадался до короткого решения» я откидываю, т.к. головоломки с коротким и элегантным решением ничего полезного не проверяют. У задачи должно быть изначально видно либо короткое, либо эффективное решение.
Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда.
А вот тут я не согласен. На личном очень неприятном опыте убедился, что есть люди, которые могут объяснить решение, но не способны написать рабочий код. То баги сажают, то не компилируется под какие-то платформы, то просто пишут код, который делает совсем другое. Давно (ещё когда не было опыта собеседования) по ошибке брал таких людей (мол, главное чтоб соображал, а код написать кто угодно сможет) и для организации это выходило очень дорого.
Это говорит об их невоспитанности, а не о профессионализме. Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?
Насколько я понимаю, этим жёстким типам никогда не хотелось попасть в такие организации, как Microsoft, Google, Яндекс и т.п. (если речь идёт про SWE).
Если честно, не очень понимаю — каким образом? Это не риторический вопрос, мне действительно интересно мнение.
На мой взгляд — толковый кандидат легко напишет на бумаге нужный код. Или я что-то упускаю?
Собеседования «на доске» очень полезны. Лично я, когда провожу собеседования, обязательно даю задачу, которую надо написать «без гугла». Желательно — на листке бумаги. Потому что когда человек пишет рукой на листке бумаги — у него нет возможности что-то легко поправить, где-то вставить строчку кода. Большинство это понимают сразу и сначала планируют решение, а потом уже его пишут. Я таким образом проверяю не способность кандидата (например) развернуть список, а оцениваю опыт написания кода в целом. Опытный разраб для простых задач сразу знает, сколько ему нужно переменных, какие циклы будут и т.п. — у него во время написания кода уже в голове цельная картинка и он её просто переносит на бумагу. А вот джун такой картинки не имеет — он по ходу додумывает решение, где-то что-то подправляет. Иногда джун даже не может удержать всё решение в голове (а это крайне важное умение для того, чтобы писать код без багов — иначе всегда будут пропущенные корнер-кейсы). К слову, для решения задач на бумаге я никогда не даю что-то «головоломистое» — только базовые вещи, чтобы senior писал «от руки» решение за пару минут.
Если это несложно сделать — думаю, многим будет интересно увидеть более полный лидерборд (например, топ100 или, в идеале, всех участников) с их решениями.
По поводу метрик и лидербордов в целом — у винрейта как метрики есть немало проблем (если интересно — могу более подробно описать). В качестве хорошей и проверенной альтернативы советую посмотреть на TrueSkill от Microsoft.
Интересная идея, но 10 игр — мало. Кажется, что доверительный интервал мат. ожидания для винрейта будет слишком большим: отправил одно и то же решение два раза подряд, в первый раз было 992е место, во второй раз 251е. Но если для итоговых результатов будет игра «каждый с каждым по одному разу», то таких проблем не будет.
Предлагаю скомпилировать сишный код с "-Ofast -march=native", ассемблерный код получится намного интереснее. Помимо этого, если у вас проц от Intel, имеет смысл скомпилить через icc.
Из курса алгебры я помню, что отношение частичного порядка — это отношение, которое является рефлексивным (a >= a), транзитивным (a >= b, b >= c => a >= c) и антисимметричным (a >= b, b >= a => a = b). Отношение строгого порядка — это отрицание какого-то отношения частичного порядка.
Теперь попробуем его упорядочить. То есть найти способ найти следующую пару чисел n и m, зная предыдущую
Само это высказывание выглядит неверным. Рациональные числа упорядочены, но не получится найти «следующую пару».
Возможно, Вам стоило бы найти другой термин для того, что хотелось описать.
Потому что мы хотим узнать, отработала ли функция нормально (в данном случае — удалось ли создать поток). Т.е. pthread_create() возвращает код ошибки (или 0 в случае успеха). Если его не возвращать, то требовалось бы либо передавать этот код через одну из переменных, либо через какое-то глобальное значение. Возвращать статус исполнения — самый частый подход, поэтому его придерживались и здесь тоже.
Когда у вас поток по 2-3 кандидата в неделю, то оказывается, что дело не в «конторы не додумались». В крупных организациях на 1000+ разрабов поток бывает и по 10 кандидатов в неделю.
Почерк практически у всех плохой — это норма. Если что-то написано непонятно — интервьюер уточнит (а что ему ещё остаётся).
Интересное сравнение, надо бы запомнить.
Дак если бы был способ надёжно, без лотереи, узнать уровень кандидата — все бы им пользовались.
Согласен, именно о таких задачах я и писал. У меня личный критерий отсечения «сложных» задачи — попросить коллегу-мидла на обеденном перерыве накатать решение. В спокойных условиях, за чашечкой чая. Если за 10 минут не вышло — задача плохая, т.к. при стрессе вперемешку с обсуждениями и мыслями вслух, кандидат будет писать её минут 40.
Ну и студентов настолько больше, чем молодых senior-разрабов, что обычно если видишь молодого парня, бодро пишущего код от руки, то вывод (изредка неверный) сам напрашивается, это да.
Я и мои коллеги-интервьюеры никогда не считаем это проблемой, т.к. ясное дело, что если человек пропустил точку-с-запятой в конце строки, то это либо от концентрации на самой задаче, либо от волнения. И то, и другое — вполне ожидаемо на собеседовании, так что лично я просто указываю кандидату, мол «запятую потеряли» — и даже не успеваю сказать где именно, а человек уже исправил. Если же интервьюер просто говорил «у вас программа работает некорректно» и ждёт исправления запятой — это косяк скорее интервьюера, нежели кандидата, т.к. таким образом ничего полезного не выясняется, а время (и нервы) тратятся.
Это вообще треш. Если решение занимает несколько листов А4 (ну или несколько исписанных досок) — это крайне плохая задача для собеседования. Вариант, что «кандидат настолько плох, что не догадался до короткого решения» я откидываю, т.к. головоломки с коротким и элегантным решением ничего полезного не проверяют. У задачи должно быть изначально видно либо короткое, либо эффективное решение.
А вот тут я не согласен. На личном очень неприятном опыте убедился, что есть люди, которые могут объяснить решение, но не способны написать рабочий код. То баги сажают, то не компилируется под какие-то платформы, то просто пишут код, который делает совсем другое. Давно (ещё когда не было опыта собеседования) по ошибке брал таких людей (мол, главное чтоб соображал, а код написать кто угодно сможет) и для организации это выходило очень дорого.
Насколько я понимаю, этим жёстким типам никогда не хотелось попасть в такие организации, как Microsoft, Google, Яндекс и т.п. (если речь идёт про SWE).
На мой взгляд — толковый кандидат легко напишет на бумаге нужный код. Или я что-то упускаю?
По поводу метрик и лидербордов в целом — у винрейта как метрики есть немало проблем (если интересно — могу более подробно описать). В качестве хорошей и проверенной альтернативы советую посмотреть на TrueSkill от Microsoft.
Само это высказывание выглядит неверным. Рациональные числа упорядочены, но не получится найти «следующую пару».
Возможно, Вам стоило бы найти другой термин для того, что хотелось описать.