Программист и блогер Яков Сироткин рассказал на своей странице в Facebook об особенностях пройденных интервью с потенциальными работодателями.
Как я искал работу
Недавно я нашел новую работу и в процессе познакомился поближе с петербургским рынком труда для программистов на Java. Я могу выделить несколько стадий общения с потенциальными работодателями, о которых хочу рассказать. При этом я не буду приводить примеры конкретных компаний и постараюсь не рассказывать о своих индивидуальных особенностях.
Размещение резюме на HH.ru и отклик на вакансии
Как только программист обновляет своё резюме на HH.ru, он сразу попадает в поле зрения рекрутёров. Если остается свободное время, то можно откликаться на вакансии компаний. При этом нужно следить, чтобы количество приглашений на интервью не превысило вашу пропускную событий. Связи и HR-бренды при этом особого значения не имеют, потому что большинство вакансий открыто в компаниях, которые не очень известны на рынке.
Общение с HR
Теоретически я допускаю, что есть HR, которые принимают решения и задают вопросы исключительно по делу, просто я не понимаю истинный смысл этих вопросов. Возможно, я и с такими HR общался, но в целом разговоры с HR оставили у меня впечатление пустой болтовни. Хочу отметить, что в некоторых компаниях HR уже научились работать без телефона, хватает общения через e-mail.
20-минутные суровые испытания
Некоторые компании довольно жёстко отсеивают кандидатов на ранних стадиях, через короткое телефонное интервью или небольшие опросники. Может показаться, что так они теряют много хороших программистов, спрашивая довольно специфичные вещи. Но я считаю, что лучшие специалисты знают очень много и в результате такого отбора сильно поднимается уровень кандидатов на интервью.
Интервью
Традиционно интервью считается ключевым этапом при приёме на работу. Есть разные традиции относительно необходимого количества интервью, но некоторые компании в Питере уже научились принимать решение после одной встречи. Достигается это за счёт того, что кандидат сразу разговаривает с достаточно квалифицированными специалистами и они задают хорошие вопросы.
Тестовые задания
Пожалуй, тестовые задания — самая спорная из практик при отборе кандидатов. Полученные мной тестовые задания привели к самым разным последствиям: серия интервью, предложение о работе, молчание со стороны работодателя и одно задание я делать поленился. Пожалуй, можно ещё добавить случай, когда тестовое задание я не заслужил.
Возникает вопрос: как найти мотивацию сделать тестовое задание, если есть риск, что его просто проигнорируют? Посмотрите на постановку задачи: можно ли её расценивать как результат хорошей работы менеджера или тимлида? Если тестировщику дать постановку задачи и ваш код, сможет ли он протестировать соответствие кода постановке? Если ответы на эти вопросы положительные — тогда можно надеяться, что ваша работа не пропадет впустую. Если текст задания умещается в 5 строчек, API не специфицирован и выполненное задание является только поводом для начала разговора, не стоит сильно надеяться на этого работодателя.
Есть соблазн написать серию советов о том, как правильно набирать программистов, но я этого делать не буду. У всех компаний свой бизнес, разные требования к кандидатам, и у программистов совсем разные навыки и способности. Пускай все набирают так, как умеют, а рынок подкорректирует.
Добавить 20 комментариев
Что-то Яша зачастил со сменой работы.
А есть статьи про то, как найти работу так, чтобы не менять ее через каждые два года?
А зачем? Если нравится так. Пришёл, помог, ушёл.
А что в этом плохого-то? На моей практике, большинство проектов «взлетали» (или не взлетали) как раз примерно за 1,5-3 года (понятно, что бывают гораздо длиньше, но именно мне — не попадались). А дальше — тупое и унылое сопровождение, где даже и дорогой разраб обычно не нужен, да и скучно одно и то же пилить по 10 лет. Получается, пришел, поработал над проектом, пошел куда-то дальше. Плюс, нередко при смене работы можно продавить какую-то прибавку.
Другое дело, что у него как-то всё слишком кратко и поверхностно написано, общие слова. Любой жуниор, проделав задачу поиска работы один раз, и так узнает всё там написанное и плюс тележку сверху.
делаем вывод, что если человек в ответ на предложение сделать тестовое задание начинает бурно рефлексировать и генерировать поток отмазок, то тестовые задания действительно неплохо выполняют задачу по отсеиванию ненужных кандидатов.
и нужных то же (чаще и больше). Т.к. не хватает специалистов уровня midle+, на на одного кандидата 3-7 интересных приглашения. Если компания «не работа мечты» или резкая прибавка к зп (например 1.5x-3x), то приглашение от компании с тестовым заданием попадает сразу в «не интересные» приглашения. Зачем заморачиваться с тестовым заданием, если можно не заморачиваться, а еще походить и повыбирать более жирное место?
в смысле более жирное? типа где больше платят, там верят на слово?
Он там написал что не сделал одно тестовое задание из множества (другие сделал). Потока отмазок и рефлексии не заметил. Вполне логично, что в процессе поиска работы, кандидат общается с несколькими компаниями, время ограничено и все тестовые задания не переделать. Причем, в некоторых компаниях, тестовое задание тянет на целый рабочий день, а то и на два. Я вообще удивляюсь тому, что их кому-то еще дают. Особенно на уровне выше мидла. Зачем давать тестовое задание человеку с 10+ лет опыта в индустрии и полным гитхабом кода?
Вообще, за всю жизнь я видел только одно достойное тестовое задание, да и то — в шведской компании. Чаще всего это какая-нибудь крайне трудоемкая лажа, которая зачастую еще и оценивается неадекватно, т.к. проверяющий забыл как писать код самостоятельно, либо ему просто лень тратить больше десяти секунд на проверку решения.
Хм, и как работодатель относится к полному гитхабу кода? Ну, при условии, что он наполняется прямо в процессе работы у этого работодателя. Вот он смотрит, задачи, дедлайны, комиты, все дела. И тут краем глаза видит, что и на «персональные» репозитории этот же сотрудник себе тоже что-то регулярно комитит. И у него по идее должно закрасться сомнение, а достаточно ли усердно сотрудник трудится именно над его платным проектом?
> И у него по идее должно закрасться сомнение, а достаточно ли усердно сотрудник трудится именно над его платным проектом?
А если он вдруг заметит, что сотрудник после работы посещает бассейн, то у него должно закрасться сомнение? А если он вдруг заметит, что сотрудник пришел на работу в 9, а ушел в 6? О боже, у этого негодяя хватает сил смотреть сериал после работы, значит он точно недорабатывает, из него еще столько можно выжать! xD
Для программистов всех уровней есть пузомер с тестовыми заданиями по всем языкам программирования и бд всех уровней сложности, с него можно брать вопросы для собеседования, если вы выполните их сами перед постановкой кандидату, то сможете посмотреть на порой нетривиальные ответы на задания остальной публики.
https://www.hackerrank.com
Т.е. вы искренне не понимаете разницы между бассейном (активным отдыхом), сериалом (пассивным отдыхом) и программированием (высушенными за день мозгами продолжаем еще и дома грызть кактус)?
Работал я однажды у такого работодателя. До сих пор плАчу от мысли, как же безвременно они развалились. Уже бы пару своих проектов запилил. Подскажите, где еще такие лопоухие водятся? Уж больно короток период полураспада у них (совпадение, не думаю)…
Я понимаю разницу, просто утрирую. Если ваша работа заключается в монотонном и однообразном написании багфиксов с 9 до 5, то возможно, все так и есть. Приходить с такой работы и заниматься тем же самым наверное не стоит.
Но вот делать какой-либо продукт — это совсем другой опыт. Тут обычно не нужно впахивать. Тут важно постоянно делать небольшие изменения, на протяжении длительного периода времени. Эти изменения накапливаются и получается что-то стоящее (если вы знаете что делаете), либо вы получаете опыт, который на работе не получить. Тратить много времени за один раз — не требуется. Каждый человек тратит уйму времени впустую, каждый день. При этом многие успешные OpenSource проекты компактны и могут быть написаны одним человеком, скажем LMDB это чуть больше 10К LOC. Это можно написать за год, тратя по 30 минут в день.
Пожалуйста, если вам нетрудно, познакомьте меня с человеком, способным в одиночку за год выдать 10KLOC нетривиального отлаженного кода на С, хотя бы тратя и 3 часа в день. Я был бы счастлив быть представлен такому и непременно взял бы автограф.
Или, возможно, вы имели в виду, что 30 минут в день он занимается _вводом_ строк, а всю оставшуюся часть суток их обдумыванием? Но даже в этом случае это очень хороший программист, 40 _отлаженных_окончательно_ строк на С в день (ну, один день в неделю же он занимается чем-то помимо программирования?) — отличная производительность. Правда, возникает вопрос, чем же он занимается на основной работе?
> Пожалуйста, если вам нетрудно, познакомьте меня с человеком, способным в одиночку за год выдать 10KLOC нетривиального отлаженного кода на С, хотя бы тратя и 3 часа в день.
https://www.openhub.net/p/akumuli — в среднем 10К LOC в год (в 18-м году почему-то openhub не считал статистику). Причем я не трачу 3-часа в день даже близко. Не трачу даже один час в день, КМК.
Поймите меня правильно, это не в укор очень симпатичному проекту (почитал код, понравился) — но вот я сейчас наскоро загнал весь проект в Scitools UInderstand и посчитал метрики.
Строк кода на C++/C в проекте — 26 793 (не считая пробелы и комментарии), это включая _все_ тесты. Я правильно понял, что это вы в одну голову написали и отладили за ~2.5 года, тратя по полчаса в день? По крайней мере, такой вывод можно сделать из вашего утверждения.
Смотрел тут — https://www.openhub.net/p/akumuli/analyses/latest/languages_summary
Там видно что 14-15, 15-16 — примерно по 10К, 16-17 — чуть меньше.
> Я правильно понял, что это вы в одну голову написали и отладили за ~2.5 года, тратя по полчаса в день?
Некоторые части еще и полностью переписал. В среднем 30 минут, да. Что такого то?
Потому что это получается в среднем 1 минута на содержательную строку кода, _вместе_ с придумыванием архитектуры, дизайном системы, отладкой, тестированием, прогонами, всей вспомогательной работой и т.п., да ещё и помимо основной работы.
Да вы, батенька, у нас Лев Толстой, Линус Торвальдс и Гай Юлий Цезарь в одном флаконе.
Скажем так, придумывание архитектуры и дизайн системы шли в бэкграунде и не были ограничены никакими временными рамками. Ну плюс еще опыт. Скажем, я занимался системами хранения данных, сжатием и информационным поиском. Поэтому многие вещи не пришлось придумывать с нуля. Заниматься отладкой приходится редко. Вспомогательная работа выполняется на CI (2.5 часа молотит).
Просто вы выше говорили про «полный гитхаб кода», и я не знаю, может на C 10 тысяч строк — это много, а в бизнес-коде это вообще ни о чем. :) Это не в укор вам или ортодоксальным насисьникам в целом, видимо там в вашем мире всё как-то очень сильно по-другому. Я например, несколько лет назад мерял свою производягу, у меня получалось набрасывать 460 SLOC в день, это без вычета выходных и прочего. Это не говнокод и не копипаста, крепкий середнячок, как вы понимаете, в условиях жестких временных рамок, накладываемых бизнес-средой, всегда есть много возможностей сильно улучшить качество, нет только физической возможности для этого. И это примерно соответствует тому, как я мерял свои проекты еще и 10 лет назад, там тоже получалось примерно полмульта за кажется 3 года, не помню просто.
Так что в моём понимании «полный гитхаб кода» — это вот примерно хотя бы сотня-другая тыщ. Сами понимаете, если РД такое увидит (особенно в реалтайме), у него мощно полыхнет :)))) и никакие россказни про басик и сериалы не проканают, если только он с моском дружит. :)))
А вообще да, гитхаб прикольная штука. Там на одной только неспешной контрибуции можно неплохо прокачать вот это вот неявное рузумэ. Я недавно только туда зарегался, и уже кучку проектов опылил, даже не напрягаясь. :)