![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Сферическое программирование в вакууме
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
arilou вчера поднял вопрос о том, насколько разумно требование предоставлять образец кода на собеседованиях. Да, значительная часть кода пишется под работодателей, которые от предоставления такового будут не в восторге.besm6 и vitus_wagner тут же предложили радостный выход - предоставлять код из OpenSource проектов, который туда попал. Да, все противоречия таким образом вполне снимаются. Правда, оба они не остановились на достигнутом, заявив, что программист, у которого нет кода в OpenSource-проектах - не настоящий, но эту реплику я склонен воспринимать скорее как признак идеологической позиции.Итак, тезис первый.
Программист - не дятел, который если не долбит, то он умер. И программировать в нерабочее время может, но не обязан. Особенно если в рабочее ему программировать хватает. Я могу предъявить сколько-то скриптов, написанных для автоматизации задач жены, но это - скорее случайность.
Тезис второй.
Не все OpenSource-проекты одинаково полезны. При попытках отправить патч в различные я наблюдал 4 позиции
1. Принять патч после переписки. Самая простая и понятная.
2. Принять патч к сведению, через какое-то время выпустить новую версию, в котором интерфейс, предложенный в патче, будет переименован нафиг.
3. Не принимать патч, но реализовать свой, дающий тот же функционал. Патч в этом случае используется как ТЗ/основа для ТЗ.
4. Разработчик в гибернации, на патчи не реагирует.
Желающие сами могут сделать вывод о продуктивности посылки патча.
Тезис третий, главный.
От программиста на работе требуется писать поддерживаемый код. Потому что времена солистов, к счастью, прошли. Поэтому вопросы на собеседованиях "Что означает это выражение - переменную или функцию" для меня имеют один однозначный ответ: "Автора этой строчки надо уволить нафиг". Да, и к большинству нестандартных и к половине высокоуровневых идиом это тоже относится - код, написанный человеком, перечитавшим Александреску, в отличие от кода человека, остановившегося на Саттере или Мейерсе, скорее всего к поддержке непригоден.
А от веб-программистов разумно требовать хотя бы структуру нижележащей базы. Потому как из этого можно понять степень ясности мышления.
no subject
no subject
С точки зрения нанимателя ошибкой первого рода является взять плохого программиста, а ошибкой второго рода - не взять хорошего. Поэтому отборочный процесс, который заведомо отсеет всех плохих программистов, но заодно отсеет и некоторых хороших, лучше, чем процесс который пропустит некоторых плохих, но не упустит ни одного хорошего.
Давай разберемся со шляпами
Первый тезис - с позиции условно-абстрактной. Да, у нанимаемого она такой может быть. Вообще жизнь больше работы, и для вас с Раном это тоже так, иначе бы спорить с вами было бы бессмысленно.
Второй - он в тезисы попал зря. Это иллюстрация к соотношению жизни и модели.
А третий тезис - он с точки зрения что программиста-коллеги, что руководителя. Собственно, ради него все и написано.
Всегда должен быть человек, который закроет дырку в коде. А дырка там есть с вероятностью 1, просто туда еще никто не проваливался, или текущий владелец кода ее затыкает быстро.
Я согласен с тем, что брать надо программиста не ниже какого-то уровня. Так вот, уровень определяется умением писать поддерживаемый код. С низким порогом вхождения в оный код. С понятными архитектурными концепциями, в частности.
А теперь прикинь сам - какой объем кода надо для этого представить и проанализировать. А отсеять можно проще - предъявив кусок кода на разбор и объяснение.
Re: Давай разберемся со шляпами
Поэтому и есть соблазн самому не возиться с анализом представленного кода. А воспользоваться результатами работы других людей. Если какая-то опенсурсная команда приняла от этого человека код, значит есть подозрение, что они сочли его поддерживаемым.
Re: Давай разберемся со шляпами
no subject
no subject
За время испытательного срока плохой программист получает зарплату, которая не окупается его трудом.
За время испытательного срока хороший программист, вместо которого взяли плохого, находит себе другую работу и перестаёт быть доступным для найма (либо его надо перекупать, увеличивая ФОТ).
После увольнения плохого программиста, не прошедшего испытательный срок, руководителю опять приходится заниматься поисками работников и собеседованиями, отнимая время от собственно руководства разработкой...
В общем, даже с испытательным сроком лучше, конечно, сразу взять хороших людей. Жаль, что это идеальная ситуация и, следовательно, обычно недостижимая.
no subject
Однако, если есть сильные сомнения в нём - можно начать с небольших задач, чтобы коммиты были часто - и посмотреть, что он делает в реальных условиях (а не что он предоставит на показ - тоже есть разница).
С испытательного срока можно выкинуть, не дожидаясь окончания.
no subject
А основной риск нанимателя, на мой взгляд, не в том, что месяц зарплату впустую платил, а в том, что на лечение последствий от взаимодействия неудачно подобранного программиста с системой можно потом потратить несравнимо больше ресурсов.
no subject
no subject
no subject
no subject
на текущем рынке мне проще взять одного плохого и одного хорошего и плохого выгнать через месяц...
Так как ошибки второго рода уже, увы, дороже.
Кстати, я на собеседовании вообще не прошу показать код - нужные мне навыки проверяются совсем другим способом.
no subject
no subject
Если код написан на Java, то с вероятностью примерно 100 процентов я смогу в нём разобраться и причесать, не думаю что найдётся много людей, которые понимают любой C++ код.
У нас люди пишут код на собеседовании. Лично я известный фанат TopCoder.
no subject
no subject
no subject
no subject
Т.е. дублирование, которое лечится только такими вот функциями - это весьма возможно ошибка проектирования.
no subject
no subject
Не, я не спорю, всяко бывает. Без конкретики решения тут не подсказать.
no subject
Сейчас, правда, я код с людей не прошу, а задаю две простые задачки. Одна алгоритмическая, на сообразительность; вторая про SQL — тоже на живость ума и владение чем-то большим, чем простым select * from t where a = 5... Обе увидены и "спёрты" из ЖЖ двух разных деятелей ;)
Так вот, вчера из 4 кандидатов двое обе эти задачки успешно отщёлкнули и стали потенциальными сотрудниками.
А на их код я посмотрю потом. Я ещё даже толком не смотрел код системы, которую мне надо принять от текущих разработчиков :)
no subject