If a C programmer asks "do you want to see something cool?", run away.
--John Van Enk

Friday, October 20, 2017

О найме

В последнее время все популярнее становится разнообразные ИТ профессии и так как мне, так уж сложилось, больше приходилось собеседовать кандидатов чем собеседоваться самому то напишу ка я краткий список того что я ожидаю от кандидата на всех этапах - от резюме и до самого собеседования.

Резюме

Основная задача резюме - "продать" вас рекрутеру. Большинство рекрутеров не отстреливают в технологиях и легко могут перепутать Rust с REST (true story) и при просмотре резюме/профиля в Linkedin ориентируются на buzzwords. Если искомый buzzword найден (пусть будет React, full-stack) то дальше такое резюме/профиль пересылается кому-то из комманды в которую нужно нанять человека и кто понимает в технологиях. Если этот человек я - то я смотрю на наличие релевантного опыта с интересующими технологиями. Большинство рекрутеров почему-то считает что опыт измеряется годами. Я считаю что опыт измеряется колличеством траблов/челенджей которых пришлось разрешить на предыдущих проектах. Если вы 10 лет работаете на одном и том же проекте в maintenance режиме (и у вас нет сайд проектов), то я могу подумать что вам нравится low-challenge среда и тогда нам не по пути. 

В Objective я ожидаю увидеть название конкретной позиции/респонсибилити, которая интересна кандидату, а не булшит типа "развиваться в динамично развивающейся компании". 

В Working experience не надо расписывать подробно все проекты, которыми вы занимались на протяжении последних 5-10-20 лет, если они не связаны никак с той позицией на которую вы претендуете и провоцировать меня на вопросы вроде отличия pascal от cdecl если я увижу упоминание о Delphi, например. Достаточно указать промежуток времени и название компании - я все равно постараюсь найти общих знакомых и узнать их мнение о вас как о разработчике :). Проекты же которые связаны с релевантной технологией (допустим web dev в широком смысле слова) - стоит описать поподробнее (если позволяет NDA) и упомянуть стек технологий, т.к. часть собеседования будет строится вокруг предыдущего опыта - я попытаюсь выяснить насколько глубоко вам удалось разобраться с той или иной технологией.

Если есть отдельный раздел Buzzwords с тематической групировкой технологий с которыми вы работали/разбирались - хорошо. Нет - ничего страшного.

Постарайтесь уместить все на 2 листа, т.к. уже 3м начинает клонить в сон в 95% случаев. еще в 99% - на 4м.

Если для вас есть какие-то sensitive/неприемлимые моменты во время работы (например не переносите маты) - обязательно укажите.

Тестовое задание

Лично у меня очень неоднозначное отношение к тестовому заданию. Если собеседуюсь я, то за тестовое берусь в случае одного из двух:
1) мне очень интересен проект (обычно становится ясно после собеседования с техническим специаллистом)
2) компания оплачивает время, потраченное на выполнение тестового задания, согласно оговоренного рейта.

Если я проверяю тестовое то ожидаю увидеть следующее:
1) Анализ problem domain - задайте доп вопросы вместо того чтобы строить предположения, выясните в чем конкретно состоит задача (например поиск Longest common subsequence)  какие методы подходят для ее решения и оцените временя необходимое для имплементации.
2) README - с описанием того как это все привести в движение (собрать, развернуть и т.п) и какие инструменты для этого нужны. Учтите что (если вы пишете на С++ например) у кого-то может не быть чем открыть ваш project.sln потому не плодите лишних зависимостей.
3) Тесты - функциональные и/или юнит
4) Реализованное решение должно корректно работать (в соответствии с описанием в тестовом задании)
5) Грамотное проектирование - как минимум не плодите сущностей на все случаи жизни, которые умеют делать "все" и даже немножечко больше (ну а вдруг понадобится?).
6) Clean code

Собеседование

Задача кандидата на собеседовании - "продать" себя убедив интервьюера в том что он именно тот кто им нужен. Задача интервьюера - понять кто перед ним - инженер или маркетолог/сейлз и определить сможет ли он решать бизнес задачи поставленные перед коммандой не вынося при этом всем мозг. В моей практике было несколько собеседований когда интервьюеры видимо полагали что их задачей было доказать собственное интеллектуальное превосходство любой ценой. Хорошо что они меня так и не наняли.

Не знать правильного ответа на собеседовании - это нормально, не нормально - опустить руки и не пытаться проанилизировать вопрос чтобы найти один или несколько возможных вариантов ответа.

Писать код на листике - тоже нормально, он может не компилироваться/выполняться, но он должен отражать идею решения задачи. Сомневаюсь что если я поставлю перед вами ноутбук с текстовым редактором, то вы сможете сделать там что-то большее чем просто побибикать, учитывая кастомный конфиг vim :D.

Если вы приврали в резюме, то во время собеседования эта ложь проявится, потому иногда лучше меньше да лучше.

Thursday, March 23, 2017

This Week I Learned (TWIL) #1


  • Статья Let’s stop copying C и ответ на нее Let’s Stop Bashing C
  • Where’s the Template? - работая над модернизацией galib наткнулся на разные модели инстанцирования шаблонов, больше имеет исторический интерес, наверное.
  • Наша Вселенная просто потрясающе большая, ум даже отказывается адекватно воспринимать подобные размеры. 



Thursday, February 9, 2017

c++ ecosystem pain points

Последние несколько месяцев я снова связан с разработкой на C++ (и C). Пришлось вспоминать подзабытые навыки и приобретать новые знания. Будучи причастным к ruby community последние несколько лет и немного к Go позволяет взглянуть на разработку на C++ несколько под иным углом. Основное наблюдение - большое колличество времени тратится не продуктивно.