Комментарии 45
>1. Он предлагает несколько решений
А если он не просто знает несколько решений, а может выбрать лучшее и предложит только его?
>4. Он рефакторит с умом
>Большинство соискателей любят добиваться того, чтобы решение заработало, после чего расслабляются и вздыхают с облегчением, удачно все >завершив. Это хорошо, но редко этого достаточно, чтобы немедленно получить предложение о найме.
Т.е. я, например, правильно решил тестовое задание, написав при этом приличный по виду запаху код, и этого недостаточно? Нужно еще изобразить что я очень люблю рефакторить?
Если в этот момент еще и появляется Необходимость рефакторить — я ж сам себя спрошу, а нафига я так фигово фиговый код то написал.
А если он не просто знает несколько решений, а может выбрать лучшее и предложит только его?
>4. Он рефакторит с умом
>Большинство соискателей любят добиваться того, чтобы решение заработало, после чего расслабляются и вздыхают с облегчением, удачно все >завершив. Это хорошо, но редко этого достаточно, чтобы немедленно получить предложение о найме.
Т.е. я, например, правильно решил тестовое задание, написав при этом приличный по виду запаху код, и этого недостаточно? Нужно еще изобразить что я очень люблю рефакторить?
Если в этот момент еще и появляется Необходимость рефакторить — я ж сам себя спрошу, а нафига я так фигово фиговый код то написал.
Классическая компания, которой надо угодить и угадать её «хотелки и перделки». Уверен, что они отсекают не разобравшись хороших специалистов
У меня на собеседовании как-то раз был примерно такой случай (обсуждали моё тестовое задание):
-Скажите, а вот тот код который вы написали, вы не хотите его отрефакторить?
-Нет
-Но как же, вы же просто скопипастили эти две строчки 4 раза!
-Да
-И вы не хотите вынести их в процедуру!?
-Нет, мне же не придётся поддерживать этот код.
-Но это же не красиво!
-Этот код идеально выполняет поставленные задачи. В связи с отсутствием развития этого кода в будущем, не считаю целесообразным выполнять пустую работу, и стремиться к какой-то мифической красоте.
-Но как же, но это же не правильно (и дальше паника в глазах собеседующего меня тим лида)
-Скажите, а вот тот код который вы написали, вы не хотите его отрефакторить?
-Нет
-Но как же, вы же просто скопипастили эти две строчки 4 раза!
-Да
-И вы не хотите вынести их в процедуру!?
-Нет, мне же не придётся поддерживать этот код.
-Но это же не красиво!
-Этот код идеально выполняет поставленные задачи. В связи с отсутствием развития этого кода в будущем, не считаю целесообразным выполнять пустую работу, и стремиться к какой-то мифической красоте.
-Но как же, но это же не правильно (и дальше паника в глазах собеседующего меня тим лида)
Это позволяет нам оценить производительность программиста, основываясь исключительно на времени выполнения задания: если все решено меньше, чем за час, мы будем довольны
А если потом в реальной работе программист решает задачу вот так, за час, а после этого тратит еще три раза по часу, чтобы сделать код не просто рабочим но и правильным/красивым/обобщенным и т.п., вместо того, чтобы потратить сразу два или два с половиной часа и сделать все то же самое? Насколько объективна оценка программиста с позиции такой «производительности»?
Вместо тысячи слов:
Скорость программирования в реальной жизни и в кино
Скорость программирования в реальной жизни и в кино
hackertyper.com для быстрого написания кода.
В точку. Иногда полдня сидишь и думаешь, чтобы написать потом строчек 50 а то и меньше в сумме)))
Вообще в программировании хороший, надежный и качественный код в незнакомом контексте быстро не пишется. Это аксиома.
Относительно «быстро» писать качественный код можно лишь хорошо владея всем аспектами проекта — бизнес, дизайн, технологии, нефункциональные требования, принятые конвенции, процесс и тп.
А оценивать программиста по скорости работы — тут скорее к «индусам» — тяп-ляп и готово — закрыл требования а дальше хоть трава не расти.
Относительно «быстро» писать качественный код можно лишь хорошо владея всем аспектами проекта — бизнес, дизайн, технологии, нефункциональные требования, принятые конвенции, процесс и тп.
А оценивать программиста по скорости работы — тут скорее к «индусам» — тяп-ляп и готово — закрыл требования а дальше хоть трава не расти.
Объективная оценка обычно и не нужна, поскольку требования к процессу субъективны. Грубо, в одном проекте аджайл, в другом водопад.
>«Соискатели, которые рассматривают в рамках задачи весь предоставленный код, — а не только тот, который мы попросили их написать, — будут действовать так же и в работе с реальным продуктом, когда присоединятся к нашей команде.»
Совершенно не согласен.
Люди на собеседованиях обычно ведут себя не так, когда уже устроены на работу. Волнение, мотивация и прочие факторы никто не отменял и они влияют на результат.
Очень ошибочно думать, что на собеседовании человек будет точно таким же, как на работе.
Совершенно не согласен.
Люди на собеседованиях обычно ведут себя не так, когда уже устроены на работу. Волнение, мотивация и прочие факторы никто не отменял и они влияют на результат.
Очень ошибочно думать, что на собеседовании человек будет точно таким же, как на работе.
Я так понимаю этой компании не важен стайл гайд и другие аспекты уже существующего кода. Вот представляю компания нанимает такого программиста и он переписывает весь код вокруг потому что тот не соответвует его представлениям, не нравятся имена переменных или ещё что то…
НЛО прилетело и опубликовало эту надпись здесь
Так как вы аргументируете можно конечно всё аргументировать, но я говорю не про рефакторинг (об этом пункт 4 поста) или создание нового API, а про вмешательство в новую код-базу со своими правилами. Мне было например как минимум не удобно если бы пришёл новичок и начал переправлять код который я или мои коллеги написали в едином стиле проекта на свой лад. Точно тогда когда меня клиенты просят внести изменения или что то добавить в их проект, я пишу код в том стиле в каком он написал в проекте, даже если он мне не нравится. Когда этот код меня ну уж сильно бесит или я вижу что клиент готов платить за улучшение (и потраченное на это время), я предлагаю ему рефакторинг. Было бы не очень хорошо с моей стороны начать всё переделывать, что бы когда придёт третий человек он увидел два стиля кода и начал придумывать свой третий.
«Зина, в печку ее!!» — Собачье сердце.
Набор тестовых задания с неясными критериями и требованиями один из худших способ поиска программиста.
А как же опыт работы, интересные задачи и то как соискатель их решил, его «философия» программирования, а также десяток других интересных тем для обсуждения на собеседовании?
Печаль…
Набор тестовых задания с неясными критериями и требованиями один из худших способ поиска программиста.
А как же опыт работы, интересные задачи и то как соискатель их решил, его «философия» программирования, а также десяток других интересных тем для обсуждения на собеседовании?
Печаль…
Дополню свой комментарий.
Вот приходишь на собеседование к таким товарищам с резюме в котором куча ссылок на open source проекты, демо-проекты, статьи и прочее.
Тебе в морду пихают лист с задачами, которые нужно решить за несколько часов, при том что этого времени особо то и нет, а на вопрос «Вы мое резюме смотрели, проходили по ссылкам, читали статьи?» получаешь ответ, вроде «Не смотрел».
Вопрос: какого фига??
Вот приходишь на собеседование к таким товарищам с резюме в котором куча ссылок на open source проекты, демо-проекты, статьи и прочее.
Тебе в морду пихают лист с задачами, которые нужно решить за несколько часов, при том что этого времени особо то и нет, а на вопрос «Вы мое резюме смотрели, проходили по ссылкам, читали статьи?» получаешь ответ, вроде «Не смотрел».
Вопрос: какого фига??
Как же всякие эйчары любят халявить и пытаться рассматривать людей, как некие детали конструктора. В общем, мне начинает казаться, что крупные бизнес конторы мечтают превратить программистов в аналогов водителей, полностью на корню сведя всю непредсказуемость и творческую составляющую работы.
Отсюда напрашивается вывод, что если не хочется окостенеть, хочется постоянного развития, то нужно двигаться в сторону или R&D контор или же независимой разработки и участия в хакатонах и всяких краудфандинговых проектов.
Отсюда напрашивается вывод, что если не хочется окостенеть, хочется постоянного развития, то нужно двигаться в сторону или R&D контор или же независимой разработки и участия в хакатонах и всяких краудфандинговых проектов.
А хакатоны могут быть надежным источником дохода? У меня как далекого от профессионального программирования человека было впечатление, что хакатоны это эдакие развлекательно-познавательные программистскые тусовки.
Есть еще один вариант — создать свой интернет бизнес проект и программировать в удовольствие, получая деньги. А не искать «контору».
>>Другие члены вашей команды отводят вас в сторону со словами «Мы должны нанять эту девушку»
Охх.))) У автора перевода как-то незаметно получилось очень юморнОе предложение
Охх.))) У автора перевода как-то незаметно получилось очень юморнОе предложение
Соискатели, которые решают проблему, а затем без передышки берутся рефакторить код, — специалисты совсем другой категории.
Ага, вызываешь сантехника и даёшь тестовое задание на два часа, он сразу пошлёт в одно место.
НЛО прилетело и опубликовало эту надпись здесь
В прошлом году я собеседовал настолько старательного, усердного и профессионального в своей работе программиста, что он создал полный Javadoc с комментариями к своему коду прежде, чем счел задачу выполненной. Он даже написал полностью автоматизированные unit-тесты и проверил процент покрытия ими кода. Когда я вернулся в комнату по истечении 2 часов, он неистово стучал по клавиатуре, и я было решил, что у него проблемы с выполнением задания, но на самом деле он как раз добавлял HTML-форматирование в свой Javadoc
Пример задания, которое можно понять, выполнить, покрыть тестами, сгенерировать документацию и высчитать покрытие за 2 часа?
Судя по наличию по крайней мере нескольких юнит-тестов и не 100% покрытия задача сама по себе не маленькая. Больше похоже на кулстори.
Напишите три базовых сортировки?
И потом для каждой из них можно запилить отдельный тест)
И потом для каждой из них можно запилить отдельный тест)
Как тут нам поможет вычисление покрытия? Типа вот тут получение пивота для квиксорта не покрыли — вы нам не подходите.
Ещё один бесящий меня момент — помнить алгоритмы, которые ты никогда не пишешь в своей жизни, а используешь готовые. Меня сходу можно отсеять в таких компаниях. И не страшно за 10-летний опыт разработок, умение оптимизировать/профилировать сложные запросы, главное — это решение тестового задания, предназначенного для только получивших диплом выпускников матвузов.
На трезвую голову хороший рефактор не написать. На пьяную, кстати, тоже.
Удивляет, что эта компания во время теста не стреляет над ухом из пистолета и не выдергивает стул.
Чем игра с тестами намного интереснее поговорить с кандидатом и попросить рассказать и показать что то на что он потратил не 2 часа а значительно больше времени. Там и код увидишь, и стиль написания и умение объяснять можно оценить. Люди на собеседовании могут просто волноваться и это будет мешать им что то написать так как они это могут в спокойной обстановке. Человек может не знать чего то одного но прекрасно уметь учиться и осваивать новое. Тесты при приёме это тупое решение в лоб, способ прикрыть собственное незнание, т.к. сам наверняка это задание уже обсосал. Если уж хочется тестов то садись с человеком вместе и пробуй написать что то вместе, обсуди с ним создание напр. какого то класса а потом раздели работу и вместе с ним попиши, попробуй потом состыковать Ваш совместный труд, посмотри как человек может работать в паре, насколько он полезен, инициативен и дружелюбен. Я знаю достаточно людей, профи в языке и предмете но которых я никогда не возьму в комманду только по одной простой причине, они хотят все сделать сами, а при попытке разделить их работу с кем то ещё возникают проблемы.
Ок, исходим из предположения, что человек при найме будет себя проявлять так же как на собеседовании, а теперь по пунктам:
1)
2) Javadoc ещё ладно, не так много времени займёт. Но полная документация и тесты… Я не говорю, что их не надо делать, но когда стоит выбор перед тестами/документацией и, собственно, написанием кода, то я бы поставил на код. Может у меня всё так неудачно складывалось, но времени на тесты/доки всегда не хватало. Даже если нет дедлайна, то начальство всегда хочет больший функционал, нежели тесты и т.п.
3)
4) *Тут должна быть цитата Кнута про оптимизацию*, которая к рефакторингу, собственно, тоже относится.
5) Кофе вкусный готовит? Красиво поёт? Честно, я этот пункт не совсем понимаю )
1)
Недавно я собеседовал программиста, который решил весь набор задач дважды: один раз итеративным способом, второй — рекурсивным. Я сразу же предложил ему работу. Умение находить несколько решений проблемы — навык, который инженерам приходится применять каждый день.На проекте он точно так же будет по 2 раза всё делать и тратить в 2 раза больше времени? Да нет, дело даже не в этом. Главное — объяснить, то есть, лучше, если он сделает всего 1 вариант, но объяснит почему. Даже если этот вариант не самый оптимальный, то его способность к рассуждению я, как наниматель, больше бы оценил.
2) Javadoc ещё ладно, не так много времени займёт. Но полная документация и тесты… Я не говорю, что их не надо делать, но когда стоит выбор перед тестами/документацией и, собственно, написанием кода, то я бы поставил на код. Может у меня всё так неудачно складывалось, но времени на тесты/доки всегда не хватало. Даже если нет дедлайна, то начальство всегда хочет больший функционал, нежели тесты и т.п.
3)
Наймите их — и они, вероятно, будут творить чудеса с вашим продуктом, делая гораздо больше поставленной задачи и внося улучшения туда, где они нужны.Мне от сотрудника надо, чтобы он задачу выполнял, а не какие-то там чудеса творил. Просишь нарисовать окно новое у дизайнера, а он потратит в 2 раза больше времени, только потому что рисовал какую-то фентифлюшку совершенно не нужную, которую никто не просил, но ему, видите ли, «так подсказало сердце».
4) *Тут должна быть цитата Кнута про оптимизацию*, которая к рефакторингу, собственно, тоже относится.
5) Кофе вкусный готовит? Красиво поёт? Честно, я этот пункт не совсем понимаю )
После выполнения задания
1. Помоет пол у рабочего места
2. Покрасит лавочку
3. Переведет старушек через дорогу
…
Профит ;)
1. Помоет пол у рабочего места
2. Покрасит лавочку
3. Переведет старушек через дорогу
…
Профит ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пять признаков того, что вы должны сейчас же нанять этого программиста