Старый способ
Обычно техническое собеседование начинается с чего-то подобного: «Напишите функцию, изменяющую порядок слов в строке». Следующие полчаса или час кандидат пишет что-то на доске (или в текстовом документе, если ему повезёт). Такой подход плох по множеству причин:
- Вопросы повторяются, и кандидаты часто упорно практикуются в запоминании ответов. Вы проверяете их навыки или их способность запоминать ответы?
- Задачи часто бывают с подвохом и требуют «озарения», чтобы придумать решение O(log(n)). За время собеседования истинное озарение почти никогда не посещает даже самых умных кандидатов.
- Он смещает баланс силы в пользу интервьюера. Кому понравится неуклюже писать код перед глазами судьи, от которого зависят ваши профессиональные перспективы на несколько лет?
- Написание кода на доске или даже в текстовом документе — неестественный и медленный процесс. В своей повседневной работе никто не пишет черновики кода на доске или в «Блокноте». На самом деле люди набрасывают код в IDE, активно пользуясь Google.
Путь получше
Вместо того, чтобы заставлять кандидата писать код, попробуйте предложить ему прочитать готовый код и рассказать о том, что он делает и как работает. Это даёт очень большие преимущества:
- Чтение проверяет самые фундаментальные навыки. Чтение кода — это приблизительно 95% того, что разработчик делает на работе. Даже если он пишет новый код, устраняет баги или создаёт документацию, он постоянно читает. Какие способности нужны кодеру, чтобы хорошо читать код? Вот два важных навыка: 1) Способность запоминать переменные и расположение стеков, и 2) Способность обобщать фрагмент кода после того, как разработчик его понял. Я могу запомнить вопросы с собеседований по кодингу, но я не могу подготовиться к тому, что мне дадут какой-то произвольный код (если только не буду просто постоянно писать и читать код). По сути, подделать эти навыки невозможно.
- Чтение кода намного эффективнее, чем написание. Кандидат может многое сказать о своих навыках программирования за первые пять минут чтения кода, потому что чтение практически на порядок величин быстрее написания. В собеседовании с чтением я могу пройтись по пяти важным темам за то же время, которое потребуется тому же человеку для написания кода изменения порядка символов в строке.
- По сравнению с написанием кода чтение меньше напрягает кандидатов. Стресс — враг интервьюера, потому что он повышает уровень адреналина, что сильно снижает IQ, из-за чего вы будете упускать хороших кандидатов. Кандидаты предпочитают читать не только потому, что им не приходится напряжённо писать код, но и потому, что интервьюер может легко подстраивать вопросы по чтению под уровень навыков кандидата. (В такую подстройку можно включить и написание кода, если вам кажется, что кандидат этого хочет.)
Как я делаю это на практике
Вот практические советы по тому, как я провожу собеседования:
- Для каждого нового цикла собеседований я создаю набор упражнений «предскажи результат выполнения», которые поначалу очень просты, а потом становятся сложнее. Сейчас мой набор упражнений начинается с простейшего вызова функции, продолжается многоуровневыми вызовами функций, затем рекурсией, затем побочными эффектами. Обычно это «фальшивые» функции, которые должны обеспечить кандидату быстрый успех, а мне дать представление о том, как будет проходить дальнейшее собеседование. Для более сложных вопросов я беру код из проектов, которые я писал. Мои текущие «сложные» вопросы исследуют навыки создания абстракций во время чтения, а также отслеживания асинхронных операций. (Также для чтения можно использовать процедуры без названий, исполняющие хорошо известные алгоритмы наподобие сортировок или обхода дерева, и просить кандидатов искать баги по выводимым ошибкам.)
- Прежде чем задавать свои вопросы кандидатам, я калибрую задачи на своих коллегах, чтобы получить реалистичное представление о том, как измерять навыки кандидатов. Кроме того, калибровка вопросов позволяет мне совершенствовать их и избавиться от непонятных моментов.
- В начале собеседования я объясняю:
- Я не проверяю знание синтаксиса. Считайте меня поисковиком Google с искусственным интеллектом, и я просто отвечу вам, что делает какая-то функция или оператор.
- Я не ожидаю от вас, что вы закончите задание, потому что с этим никто не справляется. Мы просто остановимся через 20 минут.
- Я не ожидаю от вас, что вы получите правильные ответы. Если ответ будет неверным, мне бы хотелось, чтобы вы вернулись назад и «отладили» свои рассуждения. Для меня это столь же ценно, как и всё остальное.
- Проверка будет проходить так:
- Я показываю закомментированную строку кода, вызывающую некую функцию и возвращающую вывод.
- Кандидат читает код и предсказывает вывод
- Я раскомментирую строку и запускаю программу, чтобы он увидел ответ.
- Если ответ отличается от предсказания кандидата, он возвращается обратно и объясняет, почему так получилось.
- Я даю кандидату 20 минут на то, чтобы он продвинулся настолько, насколько он сможет. Это даст мне время задать дополнительные вопросы. В отчёте о собеседовании я пишу, как далеко добрался кандидат и какие слабые и сильные стороны он продемонстрировал.
Очевидно, что эти особые навыки кодинга — не единственное, что нужно проверять на собеседованиях. Знания предметной области и соответствие корпоративной культуре тоже важны, однако мне кажется, что чтение отлично позволяет отсеивать кандидатов, не соответствующих по самым важным параметрам.
Возможно, кто-то из вас хочет знать, как развить свои навыки, чтобы хорошо проходить такие собеседования. Мой ответ прост — пишите много кода, потому что ничто не заменит регулярную практику. Как практиковаться? Проще всего — разрабатывать нетривиальные хобби-проекты, которые вам интересны. Игру, веб-сайт, приложение — всё, что угодно. Стремитесь уделять интересному вам коду по 4-8 часов в неделю и превратите его в то, что вам нравится использовать и чем вы гордитесь. (Кроме того, стоит захостить проект куда-нибудь и выложить исходники на Github, чтобы будущие работодатели могли видеть вашу активность и понять, как вы работаете.)
Комментарии (57)
Draedan
11.05.2022 11:12Нужны примеры. Если это что-то простое, то может быть, для собеседования джуна пойдет. А если начинается что-то сложное, к примеру рекурсия с 10-уровневой сложностью с какими-то подводными камнями, я просто скажу, что надо запустить и подебажить.
Возможно, кто-то из вас хочет знать, как развить свои навыки, чтобы хорошо проходить такие собеседования. Мой ответ прост — пишите много кода, потому что ничто не заменит регулярную практику. Как практиковаться? Проще всего — разрабатывать нетривиальные хобби-проекты, которые вам интересны. Игру, веб-сайт, приложение — всё, что угодно. Стремитесь уделять интересному вам коду по 4-8 часов в неделю и превратите его в то, что вам нравится использовать и чем вы гордитесь. (Кроме того, стоит захостить проект куда-нибудь и выложить исходники на Github, чтобы будущие работодатели могли видеть вашу активность и понять, как вы работаете.)
А вот это вообще бред, как по мне) Я развиваю свои навыки что бы работать, а не что бы проходить собеседования) И хобби у меня не программирование. Мое мнение сформировалось давно и никогда не менялось- узнавать новое и развиваться надо на рабочем месте, а не в свое свободное время. Если вы конечно не позиционируете себя как супер звезду за 200 баксов/час, тогда да.
DenisSel
11.05.2022 11:15+2Использую подобный же метод как и описывает автор, для себя внес несколько моментов чтобы выбирать наиболее релевантных кандидатов:
1) Код для чтения беру непосредственно из проекта над которым в последствии придется работать кандидату, абстрактый код не использую. Это дает возможность сразу проверить насколько человек знаком с используемым стеком и применяемыми паттернами.
2) Обязательно спрашиваю как данный функционал можно реализовать по-другому, что можно улучшить. Позволяет понять опыт кандидата и его предпочтения в работе.
3) Показываю ТЗ функционала и предлагаю кандидату от мидл+ и выше его спроектировать и бъяснить, без написания кода. Позволяет понять насколько кандидат понимает плюсы и минусы различных вариантов архитектуры
ncix
11.05.2022 11:29Мой любимый вопрос при найме разработчиков на технологию Х - рассказать основные недостатки этой технологии Х. Действительно опытный разработчик знает слабые места любимого языка или фреймворка. Но, из практики, затруднения с этим вопросом испытывают 9 из 10 соискателей.
KongEnGe
11.05.2022 12:04+7"основные" -- это нехороший такой маркер, предполагающий наличие конвенционального ранжированного списка; корректнее, видимо, спрашивать с явным акцентом на личное мнение кандидата о слабых сторонах
ncix
12.05.2022 13:24Задавать провокационные, неточные или некорректные вопросы - тоже прекрасная практика на собеседовании. Важно как соискатель будет реагировать. У вас реакция педантичного человека, это, как правило, ценное качество для разработчика.
misato
12.05.2022 08:06+1Тоже всегда задаю вопрос "почему X - плохой язык программирования?", и могу подтвердить, что большинство кандидатов заранее не готовятся к нему. Тем не менее, по ответам можно судить о том, что человек считает важным в своей практике, и сколько у него реального опыта.
N-Cube
11.05.2022 11:55+7Я показываю закомментированную строку кода, вызывающую некую функцию и возвращающую вывод.
Нет слов. Так и хочется автору оригинала показать строку кода, скажем, в коде PostgreSQL, а он пусть расскажет, что там «некие функции» внутри делают.
SadOcean
11.05.2022 17:55+2Слушайте, но это же на самом деле будет то, чем занимаются программисты PostgreSQL
Конечно, там может попадется какая нибудь невероятная штука с фантастическими формулами оптимизации структур данных и ассемблерными вставками для ускорения индексов
Но в остальном - неплохо, чтобы опытный разработчик действительно мог посмотреть на эту структуру и в первом приближении сказать, что она делает, на что рассчитывать, какие данные использует и т.д.N-Cube
11.05.2022 20:51+2Знаете, вот попробуйте посмотреть на реализацию пространственного индекса в PostgreSQL, и сказать, как же сложный пространственный запрос отработает в реальных случаях… притом, что планировщик PostgreSQL недетерминированный, то есть план исполнения принципиально непредсказуем. В SQLite, кстати, планировщик детерминированный и отлично исполняет те же самые сложные пространственные запросы. Почему вот так - да исторически сложилось, надо интервью с основателями проектов читать, а не код, то есть идеология важнее реализации, просто умение прочитать код вас не приблизит к пониманию устройства и работы сложного продукта. Более того, в коде любого сложного проекта вы найдете кучу логических ошибоки недочетов, которые статическими анализатором и прочим не находятся, и продукт работает.
ermouth
12.05.2022 02:16В SQLite, кстати, планировщик детерминированный
N-Cube
12.05.2022 08:13По вашей ссылке же написано: «When the Query Planner Stability Guarantee (QPSG) is enabled SQLite will always pick the same query plan for any given SQL statement».
ermouth
12.05.2022 08:38+1The QPSG is disabled by default. It can be enabled at compile-time using the SQLITE_ENABLE_QPSG compile-time option, or at run-time by invoking sqlite3_db_config(db,SQLITE_DBCONFIG_ENABLE_QPSG,1,0).
Надо очень хорошо представлять себе, что этот флаг есть, чтобы получить детерминизм планировщика.
N-Cube
12.05.2022 09:35Конечно! Выше я с первого комментария и писал о том, что просто читать код - недостаточно :)
SadOcean
12.05.2022 22:42Я ведь не сомневаюсь, что есть сложные участки кода, которые не то что не поймешь с первого взгляда, а вообще концептуально можно не понять.
Но речь ведь не про это, то как человек будет разбирать этот код - вот что важно.
Не важно, что планировщик недетерминированный, важно, что этот код - планировщик запросов, он по определенному (может быть крайне сложному) алгоритму разбирает и устанавливает запросы.
Именно это должен понять этот человек и назвать другие свойства этого кода. Например, что в этот компонент поступают запросы, которые парсятся в Модуле Х
А модуль Z валидирует запросы, проверяя, что поля и таблицы в распаршенном запросе существуют.N-Cube
13.05.2022 09:07В реальном мире планировщики запросов СУБД пишут единицы, а используют миллионы разработчиков, и читают этот код для того, чтобы оптимизировать свои запросы - а для этого нужно очень детально понимать происходящее. Помнится, в свое время я несколько недель убеждал самого создателя SQLite (разными тестами производительности с патчем и без него), что мой патч принесет значительное ускорение работы модуля полнотекстового поиска FTS3 (который я сам использую вообще для пространственной индексации геохэшей). А чтобы этот патч сделать, я месяц или два общался с инженером Google, кто этот модуль исходно создал, потому что использованная там концепция индексного мультидерева мне вообще нигде ранее не встречалась (отлично работает на огромных базах). Ну и что кто-то глянет в код и без тестирования и обсуждения с авторами кода все правильно поймет и сможет оптимизировать свои запросы имеющимися средствами или создать соответствующие оптимизирующие патчи (которые ничего не ломают, вдобавок) - это вряд ли. А зачем иначе в код смотреть?
SadOcean
13.05.2022 14:32Ну так вы по сути приводите пример, когда Frontend разработчику задают задачи на высоконагруженные параллельные вычисления.
Зачем тогда показывать этот код?
Если вы берете разработчика на поддержку условной MS SQL, то это большой проект, и там много частей.
Наверное есть люди, которых нанимают из расчета, что он сможет улучшить эти крутые алгоритмы, тогда наверное ему нужно и код показывать и про алгоритмы спрашивать.
Но другие разработчики должны работать над инфраструктурой, и им можно показать код, отвечающий за сетевые соединения к БД, или за работу с файлами.N-Cube
13.05.2022 17:03В том и дело, что надо показать «правильный» код - соответствующий и решаемым задачам и знаниям специалиста. Просто показать даже отличный и релевантный код - не годится. Ведь один специалист (в реальной работе) пойдет гуглить решение, а другой заглянет в исходники языка программирования, СУБД, и так далее. Очевидно, что первый способ поплоше и побыстрее для простых и маловажных задач, зато второй годится для тех задач, где качество результата стоит потраченного времени. Притом второй способ зачастую быстрее первого - хотя бы потому, что второй специалист явно намного опытнее. Так, может, пусть человек сам подумает и покажет свой код, по которому и задавать вопросы?
firegurafiku
11.05.2022 12:16+4В своей повседневной работе никто не пишет черновики кода на доске или в «Блокноте».
А я вот пишу, на бумаге и в Notepad++, псевдокодом, с сокращениями. Так ведь удобнее думать, нет? Понять, что от чего должно зависеть, прикинуть, какие у класса должны быть методы и как вообще лучше разбить задачу на классы.
Сколько лет вижу в статьях этот аргумент, столько лет понять не могу: люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?
Pab10
11.05.2022 13:23+6Ээээ... Головой?-) Написать класс сразу по месту без реализации методов куда проще, чем делать это 2 раза, первый раз в черновике, второй раз в приложении. Если класс настолько велик, что его не получается удержать в голове - это попахивает проблемами проектирования, не?
Схемы и рисунки никто не отменял, но писать черновик на каждую строчку кода на мой вкус ЭРЕБОР :)
firegurafiku
11.05.2022 13:58+1Если класс настолько велик, что его не получается удержать в голове - это попахивает проблемами проектирования, не?
Имхо, как раз на этапе проектирования черновик полезнее всего. Допустим, хотите вы добавить какую-то новую функциональность: открываете чистую вкладку в блокноте, пишете пример-другой кода так, как если бы то, что вы хотите спроектировать уже было готово, рядом прикидываете, какие классы нужны, в какие неймспейсы их поместить, что должно быть внутри этих классов, долго выбираете всему этому как можно более логичные и последовательные имена, перераспределяете области ответственности, смотрите, что можно декомпозировать и переиспользовать.
Для всего этого IDE не нужна и будет только мешаться.
lair
11.05.2022 22:14+3рядом прикидываете, какие классы нужны, в какие неймспейсы их поместить, что должно быть внутри этих классов, долго выбираете всему этому как можно более логичные и последовательные имена, перераспределяете области ответственности, смотрите, что можно декомпозировать и переиспользовать.
А зачем это делать до написания кода? Сколько раз я пытался так делать, каждый раз получалось нечто, что было далеко от результата.
Намного проще написать тест, от него публичное апи (или сразу апи, если нет возможности написать тест), от него уже пишем внутренности, декомпонуя их по ходу дела.
Для всего этого IDE не нужна и будет только мешаться.
Почему мешаться-то?
firegurafiku
11.05.2022 23:01А зачем это делать до написания кода?
Например, для того, чтобы заранее определиться с именами классов и файлов и поменьше переименовывать потом в процессе. Переименовывать файлы при рефакторинге неудобно, потому что затрагивает систему контроля версий. Ещё имена имеют тенденцию цепляться друг за друга, поэтому может получиться, что из-за одного непродуманного названия нужно будет переименовать дюжину файлов и кучу переменных внутри них.
Почему мешаться-то?
Потому что агрится на псевдокод и отвлекает внимание инспекциями и подчёркиваниями. Если же лень покидать IDE, я частенько открываю многострочный комментарий прямо по месту и в нём уже прикидываю алгоритм, а потом переношу в код.
lair
11.05.2022 23:04+1Например, для того, чтобы заранее определиться с именами классов и файлов и поменьше переименовывать потом в процессе.
А все равно придется переименовывать. Тру стори.
Переименовывать файлы при рефакторинге неудобно, потому что затрагивает систему контроля версий
Вот для таких случаев есть интерактивный ребейз и фиксап.
из-за одного непродуманного названия нужно будет переименовать дюжину файлов и кучу переменных внутри них.
… и это само по себе займет несколько секунд с современными средствами рефакторинга.
Потому что агрится на псевдокод и отвлекает внимание инспекциями и подчёркиваниями.
Я не предлагал писать псевдокод, я предлагал писать апи и комментарии. Ну и да, я это часто делаю в виде "написал вызов — нажал на кнопку "создать метод по вызову" ", так что IDE только помогает.
Ellinist
11.05.2022 13:31+5Мне кажется, просто есть разные люди. У кого-то сильно развито пространственное мышление и ему не нужно рисовать все на бумажке, а кто-то не видит внутренность, пока не нарисует.
Лично я программирую в IDE, но иногда, это правда, приходится и рисовать (но редко). Честно говоря иногда даже запускаю Excel, чтобы посмотреть, как он рисует график и сравнить его с программным результатом.
SadOcean
11.05.2022 17:58Так и в IDE можно писать сокращениями, можно на уровне компонентов, можно на уровне интерфейсов
Это ведь тоже редактор.
Я иногда рисую блок-схемы и иногда вспомогательное, но обычно это требуется, когда разбираешь сложный чужой проект. Для добавления новых компонентов, когда часть архитектуры и связей уже простроена, обычно хватает схемы в голове и написания классов-пустышек с полями и пустыми методами.
lair
11.05.2022 22:11Сколько лет вижу в статьях этот аргумент, столько лет понять не могу: люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?
Схемы и рисунки мне нужны крайне редко, а когда нужны, я на бумажке на рисую. А большую часть времени я нужный код пишу сразу в IDE, если надо — то комментируя.
ncix
12.05.2022 13:32люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?
Да у вас, батенька, задатки настоящего системного архитектора ))
Al-Capona
11.05.2022 12:54+19Зачастую, интервью сегодня, это возможность для "вахтёра":
1) унизить кандидата тупыми задачками, которые не используются в продакшене;
2) "поржать над д**илом" и потом рассказывать везде, что "нет программистов";
3) не допустить собственного взаимозамещения квалифицированным кадром;
4) делать вид, что "работа кипит, собеседования проводятся", чтобы и дальше "доить" зарплату из денег акционеров компании, в которой иерархия пофигизма на всех уровнях.
В тендерах монополистов, человеко-час программиста в смете заложен в размере 50 долларов. На этих зарплатах сидят кузены-свахи-любовницы, а по факту, за мизер от этого оборота, идёт на оплату дистанционников, которые и делают всю чёрную работу.
В итоге, качество продукта г**но, текучка естественна, стек раздут до небес. Но цель достигнута - бабло акционеров равномерно распределяется среди избраных.
Это всё мне приснилось, если что.
HellWalk
11.05.2022 16:50-1В итоге, качество продукта г**но, текучка естественна, стек раздут до небес.
Такой финал получается даже без "кузены-свахи-любовницы" и "иерархии пофигизма"
Я все больше отмечаю то, что рабочая культура становится нетерпима к любому негативу вообще. Соответственно, если нашел какой-то баг - лучше молчать о нем, чем на очередном дейлике сказать "а знаете, у нас тут ошибка в функционале".
А если появляется кто-то, кто каждый день что-то находит (потому что он внимательный и не равнодушный к проекту), и не стесняется говорить об этом - то на этого человека уже смотрят косо - мол тут мы без него хорошо сидели и делали вид что все классно, а он нам всю малину портит.
И это даже если не задавать вопроса "а кто виновен в баге" - такие вопросы повышают нетерпимость еще в 100 раз. Хотя, казалось бы, с точки зрения логики и качества продукта - именно так стоило бы выявлять самых плохих программистов и увольнять их. Но чаще увольняют (а точнее не берут) тех, кто не соответствует неписанным правилам компаний (будь всегда на позитиве, всегда делай вид, что все хорошо, и т.д.)
k0rinf
11.05.2022 19:19+5Увольнять за баги нужно только в том случае, если этот баг вылился в какие то серьезные проблемы для компании, и при этом вина уволенного для всех очевидна и неоспорима. Во всех остальных случаях разбираться "а кто виновен в баге", не очень продуктивно для команды. Лучше поставить вопрос по другому "как нам всем вместе сделать так, чтобы багов в проде больше никогда не было". Собрать все предложения, и уже отсюда двигаться в сторону увеличения качества.
HellWalk
12.05.2022 09:28Да, да, классическая мантра. Мы команда, будем работать лучше и т.д.
Только какая мотивация у программиста, который пишет код тяп-ляп и постоянно генерирует баги в такой ситуации меняться? Никакой.
k0rinf
12.05.2022 11:39+2Мантра стала классикой не просто так, а по вполне объективным причинам. Когда вы начнете выяснять "а кто виновен в баге", то вы можете столкнуться с тем что все начнут указывать друг на друга. Программист скажет это тестировщик плохо тестировал, тестировщик скажет это плохо код ревью провели, менеджер скажет что это тимлид виноват в том что нанял такого программиста, тимлид скажет что это архитектор так спроектировал систему. Архитектор скажет что виноват прошлый разработчик который уже уволился и т.д. И для чего все это делать? чтобы в итоге что? Какой итог вы хотите получить? Хотите чтобы в команде все друг друга ненавидели или хотите растерять всю экспертизу при высокой текучке кадров?
Мы с вами говорим о сферическом коне в вакууме. Цена бага в коде для космического корабля, и цена бага на сайте регионального салона красоты очень разная. Как и квалификация разработчиков которые нужны для этой работы. Плюс, надо понимать, какие стадии проходит код до выкладки в прод. А есть ревью? Почему баг не нашли там? А есть автотесты? Почему они не показали что есть баг? А есть отдел тестирования? почему он не нашел этот баг? А есть система мониторинга? почему из нее не прилетел алерт, чтобы быстро пофиксить баг? Да и даже если все это есть, то все ровно баг может оказаться в проде. Потому что просто невозможно покрыть тестами все возможные кейсы. Всегда есть вероятность получить баг в коде, хоть у джуна, хоть у сеньора.
Если в проекте ни как не работают с качеством, то как вы можете уволить разработчика за баг? Тем более баг ведь может быть вообще не в вашем коде, а в какой то библиотеке или фреймверке, в конце концов баг может быть даже в компиляторе. Посмотрите к примеру как релизят языки программирования, фреймверки или операционные системы. Там же постоянно после релиза определенной версии, в последующем релизят патчи с исправлениями багов или проблем с секьюрностью. И это вполне нормально, и никого за это не увольняют.HellWalk
12.05.2022 12:22-1Хотите чтобы в команде все друг друга ненавидели
Ненависть не возникает без причины. И если когда все молчали о проблемах, все было как бы хорошо, а когда о проблемах начали говорить - все стали ненавидеть друг друга - значит коллектив был изначально "с гнильцой"
Это чем-то напоминает пословицу "помолчи, за умного сойдешь", у которой есть и обратная сторона, о которой, почему-то, мало кто говорит - кто-то выглядит умным только потому, что молчит.
По этому я всегда за то, чтобы люди много говорили и высказывали свое мнение.
А есть ревью? Почему баг не нашли там? А есть автотесты? Почему они не показали что есть баг? А есть отдел тестирования? почему он не нашел этот баг? А есть система мониторинга?
Вооооот, я очень люблю говорить о причинах багов, потому что они приводят к таким вот темам. Ведь есть очень много программистов которые тесты не пишут, и считают мол а зачем, и так норм.
И это вполне нормально, и никого за это не увольняют.
На самом деле увольняют. Более того, я наблюдаю забавный подход, когда два человека могут писать код тяп-ляп, но одного увольняют, а другого нет. Почему? А потому что один работает в компании уже долго (и коллектив стесняется сказать, что код который он пишет говно), а другой пришел недавно - он еще не стал товарищем и с ним легко прощаются.
С другой стороны, я согласен с тем, что надо сильно постараться, чтобы человека уволили. И это тоже проблема, которая создает почву для "специалистов", которые специализируются на прохождении собеседований. По принципу главное собеседование пройти, а там пофигу, хрен они меня уволят.
KongEnGe
12.05.2022 13:06Смысл другой: как не дать впредь написать плохой код даже если кузен/сваха/любовница очень к этому стремится :)
Gutt
12.05.2022 15:21Только какая мотивация у программиста, который пишет код тяп-ляп и постоянно генерирует баги в такой ситуации меняться?
Мотивация -- не тратить в будущем бюджет времени, выделенного на новые фичи, на исправление старых косяков. И обычно это не мантра, а процесс, описывающий действия, необходимые для недопущения багов -- например, обязательность граничных тестов для всех методов и т. п. Если у вас есть обязательный процесс, вы же не будете его просто игнорировать? Это "недопущение в будущем" выражается не правильными словами, а вполне конкретными обязательными действиями, и хочешь не хочешь, но делать это придётся.
HellWalk
13.05.2022 12:57Если у вас есть обязательный процесс
А если его нет? В том то и дело, что пока все считают, что все хорошо (в то время, когда не хорошо), то и ничего в процессах выстраивать и не нужно.
Мотивация -- не тратить в будущем бюджет времени
Пфффф, так люди как раз и не тратят свое время. Они быстренько тяп-ляп делают задачу, и готово. А когда проект превращается в груду костылей и багов просто переходят в другую компанию.
AlexWoodblock
11.05.2022 19:22+2А еще интересно, встречается ли использование литкод-задач, как способ снизить зарплату.
"Ой, вы очень здорово знаете непосредственно то, с чем будете работать, но вот на этапе кодинга вживую не сумели повторить алгоритм выбора уникальных волшебных чисел из массива за O(1) по алгоритму Херкина-С-Горкина, боюсь, мы можем вам предложить только на 20% меньше изначально заявленной зарплаты."
ncix
12.05.2022 13:34Зачастую, интервью сегодня, это возможность для "вахтёра"
А вы не пробовали порефлексировать, почему вдруг вы стали априори так негативно к собеседованию относиться? С чего все началось?
amarao
11.05.2022 13:24+3Идея очень интересная. В принципе, код можно даже заранее отдать, чтобы человек прочитал его в спокойной обстановке. А вот обсуждать код можно будет уже в интерактиве.
Офигенно, спасибо.
AlexZaharow
11.05.2022 14:22+1У меня есть ещё предложение. Спросить, а не пишет ли претендент себе какие-то утилитки для работы и автоматизации? Это тоже вполне может показать насколько человек знаком с работой программиста. Далеко не всё в работе разных IDE или в обработке исходных данных для программ реализовано под конкретные задачи.
da-nie
11.05.2022 17:44+2Чтение кода — это приблизительно 95% того, что разработчик делает на работе.
А у меня наоборот, 95% я код пишу (из времени работы с кодом, потому что есть ещё время на планирование устройства программ внутри). Но я практически один работаю — сам себе архитектор, сам себе программист, сам себе идеолог функционирования устройства ( самое крупное, что я писал содержит около 400 классов и около 100 000 написанных строк ). Всё хочу посмотреть, как в больших командах разработку делают, но так и не собрался.SadOcean
11.05.2022 18:01+1Если вы не делаете проекты-однодневки, то весьма вероятно, что вы тоже большую часть времени все же читаете.
Просто если код свой, то он не вызывает при чтении такого когнитивного сопротивления - ты всегда помнишь, где что и как задумывалось.
Но по мере роста проекта и, тем более по мере роста команды, приходится читать все больше кода других людей (в том числе себя 4 месяца назад), что реально и вызывает ту самую боль.
Особенно отчетливо это видно, когда приходишь на чужой проект.da-nie
11.05.2022 18:26+1Так в заголовке написано «чтобы найти хороших разработчиков, заставьте их читать чужой код», следовательно, в статье речь о чужом коде? Свой-то уж точно разработчик прочтёт и через 4 месяца и через год. Ну так вот, чужой код я читаю 5% от всего. И эти 5% — это интерфейсы соединения его с моим.
SadOcean
11.05.2022 18:05+2Согласен с тезисами автора.
Читать код - одна из самых важных и самых сложных обязанностей программиста.
Собственно именно когнитивное сопротивление при чтении чужого кода порождает такие эффекты, как "фатальный недостаток ПО", "Давайте все отрефакторим" и "Тут проще переписать с нуля"
А многие практики и паттерны программирования настроены именно на то, чтобы снизить этот процесс, максимизировав количество нового кода и минимизировав количество изменений существующего.
Рекомендации SOLID направлены на хорошую декомпозицию, чтобы можно было не разбираться во всем коде, а только в его участке, а многие паттерны ООП (типа стратегии/состояния) - на то, чтобы добавлять компоненты рядом и легко их встраивать, а не переписывать существующие.
misato
12.05.2022 08:14+1Лет пять уже использую эту практику. Ливкодинг - это слишком много стресса, и может отсеять волнительных, но потенциально полезных людей, а вот чтение кода - это и интереснее, и проще, и не менее показательно. И соглашусь, читать код приходится не меньше, чем писать, и не только в зрелых проектах с большим количеством легаси, но и в тех, которые делаются "с нуля". Как минимум, почти каждый день надо участвовать в простейшем код-ревью и согласовывать свой код с тем, что написали коллеги.
Кроме того, подготовить хорошее задание на чтение кода проще, чем задачку на кодинг. Например, в моём скрипте для интервью я заранее заложил все проблемы, умение избегать которых я считаю критически важным, и мне не нужно надеяться на то, что в процессе решения задачи кандидат с ними столкнётся и успешно обойдёт.
В общем, масса полезных преимуществ в таком подходе.
RomeoGolf
12.05.2022 18:00+1Для каждого нового цикла собеседований я создаю набор упражнений «предскажи результат выполнения»
Вот терпеть не могу такие задачи... В реальности у меня задача строго обратная - по известному (требуемому) результату сделать код, которого ещё нет. А не по имеющемуся коду угадать результат. Если у меня есть чужой код, я сначала запущу его, посмотрю результат, потом буду думать, обмазывать его тестами и логами. А многие задачи на "угадай результат"сделаны настолько ректально (причем, намеренно), что мне такое и в голову не придет, зачем мне знать, что этот чудо-код сделает, если у меня он никогда не встретится? А если в чужом проекте встретится, я немедленно этот ужас перепишу. Неужели эта угадайка может реально что-то сказать о кандидате? Ну, максимум некоторые синтетические примеры покажут знание стандарта наизусть, и что, это действительно важно?
На тестовом, по результатам которого я сменил работу, мне дали заготовку небольшого проекта и задачу, которую проект должен выполнить, надо было дописать и при необходимости исправить. По-моему, неплохой вариант...
lair
12.05.2022 21:13+1Если у меня есть чужой код, я сначала запущу его, посмотрю результат
Это если вы можете его запустить, а не так, что он находится в недрах системы, куда фиг так просто попадешь.
У меня регулярно бывает задача понять, что же делает код.
Butterfly_M
13.05.2022 10:35+1когда я пишу сам для себя то мне никто не задает дурацкие вопросы. Мой ответ это тот результат, который выдает моя прога и то время, которое она тратит на расчет. а если кто-то хочет от менгя еще чего-то, то пусть идет лесом.
saipr
Тут недавно прочитал:
Как это контрастирует с вашим мнением:
И я на вашей стороне. Вообще умение читать код на вскидку дорогого стоит. И сколько можно найти полезного.
GooG2e
Ну кстати переложил чисто по ощущениям это на себя (у меня небольшой опыт походов по интервью, но есть некоторый опыт преподавания) - кажется так реально намного меньше напрягаешься. Да и по факту ведь реально большую часть времени код анализируется, чем собственно дописывается.
P.S. Что интересно я обычно примерно также проверяю у студентов семинары при защите. Прошу сказать, что делает код написанный ими, в примерах, как изменить его поведение. Вопросы обычно на одну строчку кода, но очень быстро показывает кто и на какую глубину разобрался в задаче.
domix32
Главное не забывать, что это перевод
saipr
Спасибо. Что-то задумался.
SIMPLicity
Спасибо, что обратили внимание.
... и я сразу расстроился ...
PS Предполагается что интервьюер следует общепринятым шаблонам записи кода.