Как стать автором
Обновить

Комментарии 67

Тут недавно прочитал:


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

Как это контрастирует с вашим мнением:


попробуйте предложить ему (кандидату) прочитать готовый код и рассказать о том, что он делает и как работает.

И я на вашей стороне. Вообще умение читать код на вскидку дорогого стоит. И сколько можно найти полезного.

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

P.S. Что интересно я обычно примерно также проверяю у студентов семинары при защите. Прошу сказать, что делает код написанный ими, в примерах, как изменить его поведение. Вопросы обычно на одну строчку кода, но очень быстро показывает кто и на какую глубину разобрался в задаче.

Главное не забывать, что это перевод

Спасибо. Что-то задумался.

Спасибо, что обратили внимание.

... и я сразу расстроился ...

PS Предполагается что интервьюер следует общепринятым шаблонам записи кода.

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

Возможно, кто-то из вас хочет знать, как развить свои навыки, чтобы хорошо проходить такие собеседования. Мой ответ прост — пишите много кода, потому что ничто не заменит регулярную практику. Как практиковаться? Проще всего — разрабатывать нетривиальные хобби-проекты, которые вам интересны. Игру, веб-сайт, приложение — всё, что угодно. Стремитесь уделять интересному вам коду по 4-8 часов в неделю и превратите его в то, что вам нравится использовать и чем вы гордитесь. (Кроме того, стоит захостить проект куда-нибудь и выложить исходники на Github, чтобы будущие работодатели могли видеть вашу активность и понять, как вы работаете.)

А вот это вообще бред, как по мне) Я развиваю свои навыки что бы работать, а не что бы проходить собеседования) И хобби у меня не программирование. Мое мнение сформировалось давно и никогда не менялось- узнавать новое и развиваться надо на рабочем месте, а не в свое свободное время. Если вы конечно не позиционируете себя как супер звезду за 200 баксов/час, тогда да.

Вы мне сейчас своим комментарием, кажется открыли глаза, и убрали пару фобий.

Спасибо вам от всей души!

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

И, признаться честно, смотря иногда на код проектов, в которых работали люди, у которых пет-проекты таки есть, я могу сказать, что это им вообще не помогло написать хорошее и надёжное решение :)

Использую подобный же метод как и описывает автор, для себя внес несколько моментов чтобы выбирать наиболее релевантных кандидатов:

1) Код для чтения беру непосредственно из проекта над которым в последствии придется работать кандидату, абстрактый код не использую. Это дает возможность сразу проверить насколько человек знаком с используемым стеком и применяемыми паттернами.

2) Обязательно спрашиваю как данный функционал можно реализовать по-другому, что можно улучшить. Позволяет понять опыт кандидата и его предпочтения в работе.

3) Показываю ТЗ функционала и предлагаю кандидату от мидл+ и выше его спроектировать и бъяснить, без написания кода. Позволяет понять насколько кандидат понимает плюсы и минусы различных вариантов архитектуры

Мой любимый вопрос при найме разработчиков на технологию Х - рассказать основные недостатки этой технологии Х. Действительно опытный разработчик знает слабые места любимого языка или фреймворка. Но, из практики, затруднения с этим вопросом испытывают 9 из 10 соискателей.

"основные" -- это нехороший такой маркер, предполагающий наличие конвенционального ранжированного списка; корректнее, видимо, спрашивать с явным акцентом на личное мнение кандидата о слабых сторонах

Задавать провокационные, неточные или некорректные вопросы - тоже прекрасная практика на собеседовании. Важно как соискатель будет реагировать. У вас реакция педантичного человека, это, как правило, ценное качество для разработчика.

Может для вас это эффективно, но вы вынуждаете соискателей постоянно ждать подвоха в ваших вопросах. Это не менее некомфортно, чем обсуждаемое написание кода.

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

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

Если к собеседованию нужно заранее готовиться -- это не ваша вакансия :)

Ну так в этом и смысл ты идешь на вакансию которая чуть выше чем ты, чтобы там развиваться, а работать там где ты всё знаешь и умеешь скучно.
Реалии таковы что сейчас собесы разрабов в формате экзаменов, к экзаменам тоже не нужно готовится?

Реалии таковы, что подавляющее большинство нанимателей и близко не фаанги, чтобы крутить носом и обоснованно устраивать цирк на входе. Как и большинство кандидатов ищут себе место продажи имеющихся навыков 40 часов в неделю без мыслей о работе вне этого времени.

"Подготовки" -- это все из области показать себя лучше, чем ты есть. И этот обман себя и нанимателя целесообразен совсем не всегда.

Если бы у меня спросили такое, я бы ответил "Как вы изменяете степень полезности языка программирования?". Потому как в указанной постановке вопроса отсутствуют любые критерии хорошести. Вот спросили бы вы "почему язык Х плох для написания сайта?" - я бы ещё понял)

И это довольно полезный ответ, который показывает вас как человека, который привык размышлять над выбором инструмента, подходящего под решение задачи, и не пытается всё долбить привычным микроскопом или молотком.

Я показываю закомментированную строку кода, вызывающую некую функцию и возвращающую вывод.

Нет слов. Так и хочется автору оригинала показать строку кода, скажем, в коде PostgreSQL, а он пусть расскажет, что там «некие функции» внутри делают.

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

Знаете, вот попробуйте посмотреть на реализацию пространственного индекса в PostgreSQL, и сказать, как же сложный пространственный запрос отработает в реальных случаях… притом, что планировщик PostgreSQL недетерминированный, то есть план исполнения принципиально непредсказуем. В SQLite, кстати, планировщик детерминированный и отлично исполняет те же самые сложные пространственные запросы. Почему вот так - да исторически сложилось, надо интервью с основателями проектов читать, а не код, то есть идеология важнее реализации, просто умение прочитать код вас не приблизит к пониманию устройства и работы сложного продукта. Более того, в коде любого сложного проекта вы найдете кучу логических ошибоки недочетов, которые статическими анализатором и прочим не находятся, и продукт работает.

По вашей ссылке же написано: «When the Query Planner Stability Guarantee (QPSG) is enabled SQLite will always pick the same query plan for any given SQL statement».

The 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).

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

Конечно! Выше я с первого комментария и писал о том, что просто читать код - недостаточно :)

Я ведь не сомневаюсь, что есть сложные участки кода, которые не то что не поймешь с первого взгляда, а вообще концептуально можно не понять.
Но речь ведь не про это, то как человек будет разбирать этот код - вот что важно.
Не важно, что планировщик недетерминированный, важно, что этот код - планировщик запросов, он по определенному (может быть крайне сложному) алгоритму разбирает и устанавливает запросы.
Именно это должен понять этот человек и назвать другие свойства этого кода. Например, что в этот компонент поступают запросы, которые парсятся в Модуле Х
А модуль Z валидирует запросы, проверяя, что поля и таблицы в распаршенном запросе существуют.

В реальном мире планировщики запросов СУБД пишут единицы, а используют миллионы разработчиков, и читают этот код для того, чтобы оптимизировать свои запросы - а для этого нужно очень детально понимать происходящее. Помнится, в свое время я несколько недель убеждал самого создателя SQLite (разными тестами производительности с патчем и без него), что мой патч принесет значительное ускорение работы модуля полнотекстового поиска FTS3 (который я сам использую вообще для пространственной индексации геохэшей). А чтобы этот патч сделать, я месяц или два общался с инженером Google, кто этот модуль исходно создал, потому что использованная там концепция индексного мультидерева мне вообще нигде ранее не встречалась (отлично работает на огромных базах). Ну и что кто-то глянет в код и без тестирования и обсуждения с авторами кода все правильно поймет и сможет оптимизировать свои запросы имеющимися средствами или создать соответствующие оптимизирующие патчи (которые ничего не ломают, вдобавок) - это вряд ли. А зачем иначе в код смотреть?

Ну так вы по сути приводите пример, когда Frontend разработчику задают задачи на высоконагруженные параллельные вычисления.
Зачем тогда показывать этот код?
Если вы берете разработчика на поддержку условной MS SQL, то это большой проект, и там много частей.
Наверное есть люди, которых нанимают из расчета, что он сможет улучшить эти крутые алгоритмы, тогда наверное ему нужно и код показывать и про алгоритмы спрашивать.
Но другие разработчики должны работать над инфраструктурой, и им можно показать код, отвечающий за сетевые соединения к БД, или за работу с файлами.

В том и дело, что надо показать «правильный» код - соответствующий и решаемым задачам и знаниям специалиста. Просто показать даже отличный и релевантный код - не годится. Ведь один специалист (в реальной работе) пойдет гуглить решение, а другой заглянет в исходники языка программирования, СУБД, и так далее. Очевидно, что первый способ поплоше и побыстрее для простых и маловажных задач, зато второй годится для тех задач, где качество результата стоит потраченного времени. Притом второй способ зачастую быстрее первого - хотя бы потому, что второй специалист явно намного опытнее. Так, может, пусть человек сам подумает и покажет свой код, по которому и задавать вопросы?

В своей повседневной работе никто не пишет черновики кода на доске или в «Блокноте».

А я вот пишу, на бумаге и в Notepad++, псевдокодом, с сокращениями. Так ведь удобнее думать, нет? Понять, что от чего должно зависеть, прикинуть, какие у класса должны быть методы и как вообще лучше разбить задачу на классы.

Сколько лет вижу в статьях этот аргумент, столько лет понять не могу: люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?

Ээээ... Головой?-) Написать класс сразу по месту без реализации методов куда проще, чем делать это 2 раза, первый раз в черновике, второй раз в приложении. Если класс настолько велик, что его не получается удержать в голове - это попахивает проблемами проектирования, не?

Схемы и рисунки никто не отменял, но писать черновик на каждую строчку кода на мой вкус ЭРЕБОР :)

Если класс настолько велик, что его не получается удержать в голове - это попахивает проблемами проектирования, не?

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

Для всего этого IDE не нужна и будет только мешаться.

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

А зачем это делать до написания кода? Сколько раз я пытался так делать, каждый раз получалось нечто, что было далеко от результата.


Намного проще написать тест, от него публичное апи (или сразу апи, если нет возможности написать тест), от него уже пишем внутренности, декомпонуя их по ходу дела.


Для всего этого IDE не нужна и будет только мешаться.

Почему мешаться-то?

А зачем это делать до написания кода?

Например, для того, чтобы заранее определиться с именами классов и файлов и поменьше переименовывать потом в процессе. Переименовывать файлы при рефакторинге неудобно, потому что затрагивает систему контроля версий. Ещё имена имеют тенденцию цепляться друг за друга, поэтому может получиться, что из-за одного непродуманного названия нужно будет переименовать дюжину файлов и кучу переменных внутри них.

Почему мешаться-то?

Потому что агрится на псевдокод и отвлекает внимание инспекциями и подчёркиваниями. Если же лень покидать IDE, я частенько открываю многострочный комментарий прямо по месту и в нём уже прикидываю алгоритм, а потом переношу в код.

Например, для того, чтобы заранее определиться с именами классов и файлов и поменьше переименовывать потом в процессе.

А все равно придется переименовывать. Тру стори.


Переименовывать файлы при рефакторинге неудобно, потому что затрагивает систему контроля версий

Вот для таких случаев есть интерактивный ребейз и фиксап.


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

… и это само по себе займет несколько секунд с современными средствами рефакторинга.


Потому что агрится на псевдокод и отвлекает внимание инспекциями и подчёркиваниями.

Я не предлагал писать псевдокод, я предлагал писать апи и комментарии. Ну и да, я это часто делаю в виде "написал вызов — нажал на кнопку "создать метод по вызову" ", так что IDE только помогает.

Видимо вы просто визуал

Мне кажется, просто есть разные люди. У кого-то сильно развито пространственное мышление и ему не нужно рисовать все на бумажке, а кто-то не видит внутренность, пока не нарисует.

Лично я программирую в IDE, но иногда, это правда, приходится и рисовать (но редко). Честно говоря иногда даже запускаю Excel, чтобы посмотреть, как он рисует график и сравнить его с программным результатом.

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

Сколько лет вижу в статьях этот аргумент, столько лет понять не могу: люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?

Схемы и рисунки мне нужны крайне редко, а когда нужны, я на бумажке на рисую. А большую часть времени я нужный код пишу сразу в IDE, если надо — то комментируя.

люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?

Да у вас, батенька, задатки настоящего системного архитектора ))

Все смешалочь в кучу, кони люди. IDE, псевдокод, схемы и рисунки - это 4 разных инструмента)

Я вот почти не пишу псевдокод, и уж тем более не у доски перед кучей людей. Равно как и никогда не нахожусь в ситуации, где я должен сразу написать правильное или хотя бы последовательное решение.

Иногда я тупо рисую все сущности перед собой и затем пытаюсь комбинировать их в неком магическом интуитивном порыве, не особо задумываясь о последствиях. Цена ошибки - ноль. Никто не будет оценивать мои непоследовательные каракули из которых я "через связь с космосом" получу финальное решение.

А такое случается постоянно, потому как я не умею решать задачу "сверху-вниз" (от общего к частному) или "снизу-вверх". Мой процесс мышления для стороннего наблюдателя выглядит наверное хаотичным перебором, потому как я делая предположение, смотрю в голове на всё "дерево последствий", нахожу там подходящий "лист" с приближенным результатом и думаю, как бы мне изменить свое решение сверху, чтобы результат-таки совпал с нужным мне.

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

Зачастую, интервью сегодня, это возможность для "вахтёра":
1) унизить кандидата тупыми задачками, которые не используются в продакшене;
2) "поржать над д**илом" и потом рассказывать везде, что "нет программистов";
3) не допустить собственного взаимозамещения квалифицированным кадром;
4) делать вид, что "работа кипит, собеседования проводятся", чтобы и дальше "доить" зарплату из денег акционеров компании, в которой иерархия пофигизма на всех уровнях.

В тендерах монополистов, человеко-час программиста в смете заложен в размере 50 долларов. На этих зарплатах сидят кузены-свахи-любовницы, а по факту, за мизер от этого оборота, идёт на оплату дистанционников, которые и делают всю чёрную работу.

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

Это всё мне приснилось, если что.

Лучший за неделю коммент.

В итоге, качество продукта г**но, текучка естественна, стек раздут до небес. 

Такой финал получается даже без "кузены-свахи-любовницы" и "иерархии пофигизма"

Я все больше отмечаю то, что рабочая культура становится нетерпима к любому негативу вообще. Соответственно, если нашел какой-то баг - лучше молчать о нем, чем на очередном дейлике сказать "а знаете, у нас тут ошибка в функционале".

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

И это даже если не задавать вопроса "а кто виновен в баге" - такие вопросы повышают нетерпимость еще в 100 раз. Хотя, казалось бы, с точки зрения логики и качества продукта - именно так стоило бы выявлять самых плохих программистов и увольнять их. Но чаще увольняют (а точнее не берут) тех, кто не соответствует неписанным правилам компаний (будь всегда на позитиве, всегда делай вид, что все хорошо, и т.д.)

Увольнять за баги нужно только в том случае, если этот баг вылился в какие то серьезные проблемы для компании, и при этом вина уволенного для всех очевидна и неоспорима. Во всех остальных случаях разбираться "а кто виновен в баге", не очень продуктивно для команды. Лучше поставить вопрос по другому "как нам всем вместе сделать так, чтобы багов в проде больше никогда не было". Собрать все предложения, и уже отсюда двигаться в сторону увеличения качества.

Да, да, классическая мантра. Мы команда, будем работать лучше и т.д.

Только какая мотивация у программиста, который пишет код тяп-ляп и постоянно генерирует баги в такой ситуации меняться? Никакой.

Мантра стала классикой не просто так, а по вполне объективным причинам. Когда вы начнете выяснять "а кто виновен в баге", то вы можете столкнуться с тем что все начнут указывать друг на друга. Программист скажет это тестировщик плохо тестировал, тестировщик скажет это плохо код ревью провели, менеджер скажет что это тимлид виноват в том что нанял такого программиста, тимлид скажет что это архитектор так спроектировал систему. Архитектор скажет что виноват прошлый разработчик который уже уволился и т.д. И для чего все это делать? чтобы в итоге что? Какой итог вы хотите получить? Хотите чтобы в команде все друг друга ненавидели или хотите растерять всю экспертизу при высокой текучке кадров?

Мы с вами говорим о сферическом коне в вакууме. Цена бага в коде для космического корабля, и цена бага на сайте регионального салона красоты очень разная. Как и квалификация разработчиков которые нужны для этой работы. Плюс, надо понимать, какие стадии проходит код до выкладки в прод. А есть ревью? Почему баг не нашли там? А есть автотесты? Почему они не показали что есть баг? А есть отдел тестирования? почему он не нашел этот баг? А есть система мониторинга? почему из нее не прилетел алерт, чтобы быстро пофиксить баг? Да и даже если все это есть, то все ровно баг может оказаться в проде. Потому что просто невозможно покрыть тестами все возможные кейсы. Всегда есть вероятность получить баг в коде, хоть у джуна, хоть у сеньора.

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

Хотите чтобы в команде все друг друга ненавидели

Ненависть не возникает без причины. И если когда все молчали о проблемах, все было как бы хорошо, а когда о проблемах начали говорить - все стали ненавидеть друг друга - значит коллектив был изначально "с гнильцой"

Это чем-то напоминает пословицу "помолчи, за умного сойдешь", у которой есть и обратная сторона, о которой, почему-то, мало кто говорит - кто-то выглядит умным только потому, что молчит.

По этому я всегда за то, чтобы люди много говорили и высказывали свое мнение.

А есть ревью? Почему баг не нашли там? А есть автотесты? Почему они не показали что есть баг? А есть отдел тестирования? почему он не нашел этот баг? А есть система мониторинга?

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

И это вполне нормально, и никого за это не увольняют.

На самом деле увольняют. Более того, я наблюдаю забавный подход, когда два человека могут писать код тяп-ляп, но одного увольняют, а другого нет. Почему? А потому что один работает в компании уже долго (и коллектив стесняется сказать, что код который он пишет говно), а другой пришел недавно - он еще не стал товарищем и с ним легко прощаются.

С другой стороны, я согласен с тем, что надо сильно постараться, чтобы человека уволили. И это тоже проблема, которая создает почву для "специалистов", которые специализируются на прохождении собеседований. По принципу главное собеседование пройти, а там пофигу, хрен они меня уволят.

Смысл другой: как не дать впредь написать плохой код даже если кузен/сваха/любовница очень к этому стремится :)

Только какая мотивация у программиста, который пишет код тяп-ляп и постоянно генерирует баги в такой ситуации меняться?

Мотивация -- не тратить в будущем бюджет времени, выделенного на новые фичи, на исправление старых косяков. И обычно это не мантра, а процесс, описывающий действия, необходимые для недопущения багов -- например, обязательность граничных тестов для всех методов и т. п. Если у вас есть обязательный процесс, вы же не будете его просто игнорировать? Это "недопущение в будущем" выражается не правильными словами, а вполне конкретными обязательными действиями, и хочешь не хочешь, но делать это придётся.

Если у вас есть обязательный процесс

А если его нет? В том то и дело, что пока все считают, что все хорошо (в то время, когда не хорошо), то и ничего в процессах выстраивать и не нужно.

Мотивация -- не тратить в будущем бюджет времени

Пфффф, так люди как раз и не тратят свое время. Они быстренько тяп-ляп делают задачу, и готово. А когда проект превращается в груду костылей и багов просто переходят в другую компанию.

А еще интересно, встречается ли использование литкод-задач, как способ снизить зарплату.

"Ой, вы очень здорово знаете непосредственно то, с чем будете работать, но вот на этапе кодинга вживую не сумели повторить алгоритм выбора уникальных волшебных чисел из массива за O(1) по алгоритму Херкина-С-Горкина, боюсь, мы можем вам предложить только на 20% меньше изначально заявленной зарплаты."

Только так и используется.

Зачастую, интервью сегодня, это возможность для "вахтёра"

А вы не пробовали порефлексировать, почему вдруг вы стали априори так негативно к собеседованию относиться? С чего все началось?

Идея очень интересная. В принципе, код можно даже заранее отдать, чтобы человек прочитал его в спокойной обстановке. А вот обсуждать код можно будет уже в интерактиве.

Офигенно, спасибо.

У меня есть ещё предложение. Спросить, а не пишет ли претендент себе какие-то утилитки для работы и автоматизации? Это тоже вполне может показать насколько человек знаком с работой программиста. Далеко не всё в работе разных IDE или в обработке исходных данных для программ реализовано под конкретные задачи.

Чтение кода — это приблизительно 95% того, что разработчик делает на работе.


А у меня наоборот, 95% я код пишу (из времени работы с кодом, потому что есть ещё время на планирование устройства программ внутри). Но я практически один работаю — сам себе архитектор, сам себе программист, сам себе идеолог функционирования устройства ( самое крупное, что я писал содержит около 400 классов и около 100 000 написанных строк ). Всё хочу посмотреть, как в больших командах разработку делают, но так и не собрался.

Если вы не делаете проекты-однодневки, то весьма вероятно, что вы тоже большую часть времени все же читаете.
Просто если код свой, то он не вызывает при чтении такого когнитивного сопротивления - ты всегда помнишь, где что и как задумывалось.
Но по мере роста проекта и, тем более по мере роста команды, приходится читать все больше кода других людей (в том числе себя 4 месяца назад), что реально и вызывает ту самую боль.
Особенно отчетливо это видно, когда приходишь на чужой проект.

Так в заголовке написано «чтобы найти хороших разработчиков, заставьте их читать чужой код», следовательно, в статье речь о чужом коде? Свой-то уж точно разработчик прочтёт и через 4 месяца и через год. Ну так вот, чужой код я читаю 5% от всего. И эти 5% — это интерфейсы соединения его с моим.

Согласен с тезисами автора.
Читать код - одна из самых важных и самых сложных обязанностей программиста.
Собственно именно когнитивное сопротивление при чтении чужого кода порождает такие эффекты, как "фатальный недостаток ПО", "Давайте все отрефакторим" и "Тут проще переписать с нуля"
А многие практики и паттерны программирования настроены именно на то, чтобы снизить этот процесс, максимизировав количество нового кода и минимизировав количество изменений существующего.
Рекомендации SOLID направлены на хорошую декомпозицию, чтобы можно было не разбираться во всем коде, а только в его участке, а многие паттерны ООП (типа стратегии/состояния) - на то, чтобы добавлять компоненты рядом и легко их встраивать, а не переписывать существующие.

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

Кроме того, подготовить хорошее задание на чтение кода проще, чем задачку на кодинг. Например, в моём скрипте для интервью я заранее заложил все проблемы, умение избегать которых я считаю критически важным, и мне не нужно надеяться на то, что в процессе решения задачи кандидат с ними столкнётся и успешно обойдёт.

В общем, масса полезных преимуществ в таком подходе.

Для каждого нового цикла собеседований я создаю набор упражнений «предскажи результат выполнения»

Вот терпеть не могу такие задачи... В реальности у меня задача строго обратная - по известному (требуемому) результату сделать код, которого ещё нет. А не по имеющемуся коду угадать результат. Если у меня есть чужой код, я сначала запущу его, посмотрю результат, потом буду думать, обмазывать его тестами и логами. А многие задачи на "угадай результат"сделаны настолько ректально (причем, намеренно), что мне такое и в голову не придет, зачем мне знать, что этот чудо-код сделает, если у меня он никогда не встретится? А если в чужом проекте встретится, я немедленно этот ужас перепишу. Неужели эта угадайка может реально что-то сказать о кандидате? Ну, максимум некоторые синтетические примеры покажут знание стандарта наизусть, и что, это действительно важно?

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

Если у меня есть чужой код, я сначала запущу его, посмотрю результат

Это если вы можете его запустить, а не так, что он находится в недрах системы, куда фиг так просто попадешь.


У меня регулярно бывает задача понять, что же делает код.

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

В статье сильно не хватает конкретных примеров, так-то всё кажется логичным в теории и хочется согласиться.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории