Что: 7cdc4d886c28ff3b454a20f3328c9b6f5ff69036
Когда: 2020-09-30 10:28:36+03:00
Темы: hate python
Снова про гугл-программистов
Случайно на Хабре снова зашёл про очень комментируемую статью про
гугл-программистов (953263ef84e79ba5f4a01ea16d93da378da9bfae) и вижу что
там очень заплюсованы комментарии говорящие что, мол, если на
собеседовании попросят ручку и бумажку, то можно сразу валить. Я немного
шокирован. Что за фигня!?
Мы на работе на собеседовании Python junior-ов просили на бумажке делать
генераторы по xrange, декораторы. Нам (ok, лично мне, говорю за себя)
насрать знает ли человек в общих чертах что такое генератор или
декоратор. Он может не помнит откуда импортируется wraps. Но, если он в
общих чертах не в состоянии с ходу написать подобные вещи, то это значит
что вместо того, чтобы быстро и шустро писать код, он будет по
полчаса/полдня колупаться с написанием декоратора. А мы ищем того, кто
может писать код хоть с какой-то скоростью. Мы верим что он рано или
поздно справится, но важен вопрос производительности. Если
range+генератор не может с ходу сделать, то нам проще никого не брать,
ибо помощи как от козла молока.
Можно ли на словах описать range/генератор/декоратор? Не представляю
как. Это базовые вещи которые реально показывают а вообще трогал ли ты
код или нет. Ты можешь начитаться, но пока ты не писал ничего -- ты не
сможешь на листке это с ходу повторить, что выдаст тебя как человека
только прочитавшего книжку, но совершенно не умеющего фигачить и
фигачить код. На листке я спрашиваю о написании shell-скриптов с find,
sed-ом. В теории много кто знает как оно работает, но в shell-е, пока
сам не поработал с ним достаточно -- не будешь знать о массе подвохов,
не сможешь их учесть в однострочниках на бумажке (это просто глупо
подобные вещи в слух описывать), что выдаст тебя как не имеющего опыт в
shell-е. Или вот на бумажке прошу описать весь процесс получения сайтика
когда в броузере вбиваем какой-то URL. Это можно и без бумажки, но с ней
проще. Или вопрос о том как делать балансировку, отказоустойчивость и
прочее: да без иллюстраций на бумажке мы, люди, просто запутаемся в том
кто куда чего предложит вставить в сети из серверов, маршрутизаторов и
балансировщиков всяких. Если мы хотим узнать понимание человека про
namespace-ы в Python, то задолбаешься объяснять какой код нужно
представить человеку чтобы дать ответ понимания области видимости.
Зачем мы это спрашиваем? Не для того чтобы отсеять потому что "не знаешь
shell". Не для того чтобы сказать что "ба, да ты не помнишь
functools библиотеку название!" (я и сам сейчас не уверен оттуда ли
wraps (да и так ли он пишется)). А для того чтобы понимать насколько
много нам будет с ним мороки и кривой обучения, чтобы понять стоит ли он
того. Никто не спрашивает точных знаний опций в find: ког��а меня
собеседовали в Yandex, то я забабахал ровно один find+exec, объяснив
почему не xargs и прочее, честно признавшись что я не помню точно
название флагов типа atime (чаще я это делаю на уровне zsh), но мне
сказали что дальше вопросы по shell будут излишни, ибо и так всё
отлично и видно что человек в состоянии написать код, без гугляжа в
течении полудня.
На собеседовании в NetStream/ivi меня спрашивали про Django, но по
знанию её архитектуры. Откуда импортируются Middleware или
TemplateContextProcessor-ы? И так ли последнее слово пишется? Да я
понятия не имею, ибо это у меня дополняется в Vim. Но главное что я знаю
про эти части Django. А код в Django -- дело второстепенное. По поводу
git-а и rebase-а в нём значительно проще нарисовать как что куда и
откуда будет расти в истории коммитов. Тут ручка нужна. Меня только на
текущем месте работы ни о чём техническом не спрашивали, но, потому что
поверили, что весь мой выложенный код по GoVPN, написан мной, можно даже
и сроки и скорость разработки оценить по истории коммитов. И вряд ли
подобные проекты с чьей то помощью будут писаться.
Собеседовали мы одного на senior-а. Он не смог в VoIP IM-е написать
задачку по range+генератор. Ok, допустим он опытный разраб, но именно на
Python его не имеет, новое для себя решил попробовать. Но у того в
резюме было много опыта по Python, насколько помню. Никто из нас не
поверил в это в итоге. Точнее может Python человек и трогал, но про
генераторы, iterator, iterable и разницу между ними и их устройство он
не в курсе. Как бы, после какого-то момента времени, рано или поздно,
работая с Python, об этом узнаешь. Одному человеку на собеседовании на
senior мы поверили на слово по поводу знания shell, что было нашей
большой ошибкой и нужна была бумажка, где лично я бы моментально выявил
(потом уже глядя на его код) его непонимание работы shell как такового.
Но это я к тому, что наш опыт говорит что бумажка даже для таких нужна,
ибо люди могут врать и лгать. Если я беру фрезеровщика, то я рад что он
прочитал кучу книг по этому и видел как на станке работают. Я тоже уйму
раз видел как папа забивает гвозди в доски. Но когда сам берёшь в руки
молоток, то это как бы совсем по другому. И нам не нужен фрезеровщик
многократно всё переделывающий, перепроверяющий -- мы ищем такого, кто
вжих-вжих и отточил деталь.
Всё это речь в основном про junior-ов была. Я думаю каждый человек не
раз встречался с тем, что он про себя уверен что что-то понимает как
работает и он разобрался в этом. Но когда начинаешь объяснять, как тебе
казалось, простые вещи кому-то другому, то обнаруживаешь что у тебя
что-то не сходится, что-то не состыковывается и ты уже понимаешь что не
понимаешь нифига. Вот и бумажка с простыми вещами -- показывает
действительно ли у тебя есть опыт. Я ни разу не встречал и не слышал
чтобы спрашивали про конкретные названия библиотек или функций.
В комментариях на Хабре вижу что один пишет:
Знание функций стандартной библиотеки и используемого фреймворка
дает беглость. — Есть некоторая разница, пишешь нужную функцию
сразу, или тратишь на поиск как-там-она-называлась пусть даже 10
секунд. Потому что эти секунды накапливаются.
на 100% согласен, лучше и не скажешь. Ответ:
Какие то тысячные доли процента времени разве что. Пишет код
программист гораздо меньше чем читает.
ну а это уже может быть сказано только вот гугл-программистом.
Бред/заблуждение челов��ка на самом деле не имеющего опыта быстрого
написания кода. Хотел сказать "написания кода", но... если человек
всегда писал через google, то он наверное даже не в курсе как пишут
"нормальные", понимающие программисты.
Дальше там комментарии про знания типов данных. В том же Python, куча
особенностей при работе с ними. Старый добрый def foo(default=[]) и
сколько времени будет потеряно на отлов багов из-за такой функции или
тратиться времени разраба во время ревью на объяснение в чём тут проблема.
Я только на 20-ом экране комментариев остановился, но вижу что там есть
и противоположные веяния: минусуют тех кто боится показать свой код или
как он работает, плюсуют тех кто не понимает что тут такого. Тут вот
есть справедливость :-). Хотя, ужас, я смотрю на карму в Хабре :-).
Дальше читать уже лень, но как-будто подтверждается и выясняется откуда
у нас столько низкоквалифицированных кадров, и почему так мало
ПОНИМАЮЩИХ что они творят (с def foo(default=[])) и делающих
качественный код быстро.
И всё это пока только про тупой кодинг. Даже не вспоминаю про
архитектуру программ. В NetStream/ivi мне задавали вопрос: вот мне
поставили задачу написать IM -- как бы я это сделал? Ну и подбрасывали
уточнения что нужен web-интерфейс например, и т.д.. Тут бумажку мы не
использовали, хотя с ней могло быть проще. Но это просто офигенный
вопрос который покажет какой опыт есть у разработчика, с чем он
сталкивался. Даже такие простые задачи неопытные не смогут решить и это
нормально. Но одно дело когда человек может в голове прикидывать где у
него будет бутылочное горлышко или где нужно отказоустойчивость
добавить, а где он просто и не видит что возникнут проблемы. Или как
минимум нужно понимать что задачи для миллиардов каких-нибудь горячих
записей в БД решаются иначе чем для пары тысяч, умещающихся в SQLite в
памяти.
Там много говорят про выдачу IDE/ПК вместо бумаги. Наверное
взаимозаменяемый вариант. Но я не слышал и не встречал никого кто бы был
или проводил такое собеседование. Как-то... блин, дикость какая-то. В
бывшей команде у каждого человека совершенно разные предпочтения и
настройки в его редакторе и его среде (Emacs, Vim без Escape клавиши,
default-ное Ubuntu говно, и другие отточенные под человека Vim-ы). У
меня Vim и zsh использует внутри себя. Даже цветовая подсветка у одних
дико раздражающая для одних (я чуть ли не физические страдания испытываю
глядя на Vim-ы одних коллег, а они в свою очередь страдают глядеть в мой).
Вообще вне всяких сомнений большинство из нас бы только страдал без
своей рабочей среды, где поведение даже базовое (Escape в Vim) может
отличаться. Тогда имеет смысл запускать какой-нибудь блокнот/Nano. Но...
тогда какой смысл в компьютере? Я больше нервов потрачу на то, что
каждое моё нажатие будет делать не то что делается у меня. У меня тоже
чем-то IDE -- LSP стоит, который вызывается и ведёт себя не как по
default-у, которого, в общем-то в vim-lsp, и нет. Но, мне не приходилось
работать с людьми которые использовали бы IDE -- все от него
отказывались, переходя на тюнингованные Vim/Emacs. Но нужно и учитывать
специфики задач в которых я кручусь. Наверное где-то IDE будет лучше.
Остальные сотни комментариев читать уж лень. Я только сильнее убедился в
ручке и бумажке, чтобы, как минимум, отсеять этих "нафиг базовые знания
языка, мне IDE поможет, всё равно я в основном только читаю код".
Кстати, решил проверить а так ли это что программист больше читает. В
целом, безусловно, это так. Но есть моменты когда ты долгое время только
пишешь, а потом уже годами это поддерживаешь (читая). Наверное своё
единственное (и достойное) творение за всю мою жизнь это PyDERASN. Ровно
две недели написания. С того момента он безусловно дорабатывался, но
лишь незначительно. Была РОВНО одна серьёзная бага, но которая для наших
задач на практике -- не проявилась бы никогда. С самой первой версии
PyDERASN его можно было бы вообще не трогать -- абсолютно вообще! Он
полностью устраивал всем, выполнил задачу и написан с самого начала без
ошибок, можно сказать. Ровно 14 дней. Самый первый коммит в нём
(законченная версия): 11645 insertions. Перевод одной библиотеки рабочей
с pyasn1 на pyderasn: 1444 insertions(+), 2071 deletions(-) -- считаю
что 1500 строк добавил. Перевод основного проекта: 2690 insertions(+),
3141 deletions(-) -- считаю что 2800 строк добавил. И ещё одна
библиотека с pyasn1 на pyderasn: 737 insertions(+), 524 deletions(-) --
считаю что 700 добавил. Итого, чуть округлив в большую сторону (ведь
сколько нажатий ещё делается для открытия файлов, навигации, в shell),
это 1200 строк в день, 150 строк в час, при 8 часовом дне. У меня был
куда больший рабочий день, но 150 строк/час я даже литературным текстом,
который просто изливается, не всегда успеваю набирать. Это конечно код,
Python код, поэтому он существенно более "разряжен" чем литературный, но
преобладающая часть времени реально была потрачена на сплошное
написание+редактирование, а не вычитку. И это сразу готовый качественный
продукт. Не спорю что больше такого у меня в жизни не случалось, это был
пик моей деятельности, но обычный средний разработчик, в состоянии
делать, тратя время на редактор и сплошной набор. Чем быстрее ты
сделаешь прототип запускаемый, тем больше времени будет на размеренную
его оптимизацию, переделку, доделку, на время тестирования и понимания
подвохов. А неспешно муслёкать IDE -- проект, его прототип, выйдет
только к моменту когда у того, кто быстро смог его наговнякать и вбить в
компьютер, уже будет N-ая итерация его переделки и улучшения. Быстро
уметь работать тоже бывает нужно ещё как. Бывают случаи когда или ты
успеваешь предоставить прототип работающий (пускай и без тестов и где
шаг в сторону -- 500-ка) и тем самым получишь "заказ", или, если не
успеешь, то можешь даже не начинать браться за попытку отхватить этот
заказ, который дальше уже можешь размеренно делать. Но это конечно не
есть желаемая норма такого труда, но средний программист (как я) может
так делать, а IDE тормоз, принципиально отказывающийся изучать то с чем
работает -- нет. Почему у меня PyDERASN вышел даже хорошо работающим
сразу же и под Py2 и под Py3? Потому что я знал много особенностей,
потому что был опыт. IDE о подводных камнях не подскажет ничего.
From: David Rabkin Date: 2020-10-04 16:40:44Z Ох, субъективная тема найма. Я прошел сотни интервью и провел десяток, не нанял ни одного :-) Из моего опыта, так называемая, «химия» работала, когда ты чувствуешь совпадение. Как правило, нет. Вот этот твой текст (с которым я согласен) из всех моих десяти-двадцати прошлых и нынешних начальников поняли бы двое. И за этих двух я благодарен судьбе. Твой начальник читает твой блог? Были у меня работы, где надо было писать код быстро и каждый день, где код-ревью растягивались на несколько дней, потому что они были круты и правильны. Это—лучшие места. Десять процентов! Остальное—корпоративная культура, бесполезные митинги, перекладывание ответственности, бесконечные обсуждения очевидных вещей. Я люблю shell-программирование, но это редко требуется в крупных C++/Java проектах на пару сотен человек. То есть, есть один такой, а остальные 199 пилят что-то в «Визуал Студио» или «Эклипсе». Я могу предположить, что в Московской области культура разработки элитна, и поэтому, высока. У нас тут, в Израиле, каждый дворник—основатель стартапа. И это хорошо для бизнеса и развития, но плохо для культуры разработки. Поэтому от нас: ICQ, PHP, Btrfs, KVM. И все. Остальные 99 процентов израильского программистского рынка—Интел, Майкрософт, Эппл. И один процент дворников—стартаперов.
From: Sergey Matveev Date: 2020-10-04 17:21:51Z
From: David Rabkin Date: 2020-10-06 12:03:16Z >Ух, я у себя насчитал всего 8 интервью Как может быть восемь, если в одну компанию, как минимум три: тим лидер, его начальник, эч ар? Я плохо интервью прохожу. >Ну... ты слишком хорошего мнения о МО, как мне кажется Наверное, я загнул. Про МО я по Хабру сужу :-)
From: Sergey Matveev Date: 2020-10-06 15:41:42Z
Сгенерирован: SGBlog 0.34.0