avva: (Default)
[personal profile] avva
Вчера разговорился с коллегой из отделения Гугла в одной европейской стране. Он жаловался, что трудно найти инженеров - кандидатов, которые хотя бы как-то подходили, почти нет. Я спросил, в чем дело, и он объяснил, что выпускники университетов в его стране обычно считают, что писать код - ниже их достоинства, и что вообще "карьера" несовместима с такими занятиями; они хотят быть не то мелкими начальниками, не то "архитекторами". Им прямо в университете, дескать, так и говорят: получите свою степень магистра - больше вам программки писать не придется. Конечно, с работой в Гугле это все никак не сочетается.

У нас в Израиле тоже есть схожие проблемы, хоть и не в таких масштабах. Время от времени попадаются кандидаты, которые не просто не могут написать простой код на бумаге (не могут-то многие), но еще и возмущаются тем, что от них этого просят. Однажды кандидат долго расспрашивал меня, просто не желая поверить, что так может быть: "неужели меня, после PhD и постдока, посадят писать код, как какого-то мальчишку? Должны же у вас быть какие-то должности типа архитектора или системного аналитика! Нет, ну я могу писать код, но я этого не делал много лет и не в этой области лучше всего проявляются мои способности".

В Гугле все инженеры пишут программы, включая любого рода тим-лидеров, включая и ученых, нанятых на ставку "research scientist". Нет никаких "архитекторов" и "аналитиков", которые сами думают, а код за них пишут другие. Те же люди, которые придумывают дизайн какой-то системы, вместе с другими ее воплощают.

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

Date: 2008-01-28 09:55 pm (UTC)
From: [identity profile] katja-i.livejournal.com
То-есть псевдокод (который imho самый удобный для "рукой по бумаге") в данном случае не годится?

А ещё интересно, вот если к примеру взять quicksort и двух испытуемых: первый человек набросает быстренько классический алгоритм, а второй реализует вариацию с использованием in-place partition алгоритма, предпочтителен второй или первый?

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

Date: 2008-01-28 10:23 pm (UTC)
From: [identity profile] avva.livejournal.com
Псевдокод не годится, да.

В вопросе с quicksort предпочтительно сделать то, что попросили :) конечно, это хорошо, если правильно сразу напишет in-place, но если сначала набросает классический, а я попрошу сделать in-place, и он правильно сделает - тоже хорошо.

Я понимаю, что тянет сосредоточиться на главном и набросать псевдокод. Но вопрос на coding - не проверка алгоритмических знаний, а проверка именно умения писать настоящий правильный корректный код. Видеть в нем off-by-1 ошибки. Делать обработку ошибок, если надо. Итд. Иногда на таком вопросе вообще просят написать что-то тривиальное с алгоритмической точки зрения. Например, (придумываю из головы, это не реальный вопрос, но похож по сложности на реальный) написать функции добавления и удаления элемента из отсортированного двоичного дерева (без балансирования). Чего уж проще. Но надо определить структуру элемента на данном языке (например, на C++ с указателями), написать эти две фунцкии, каждую строчек на 10, проверить все граничные значения (что если все дерево NULL?), придумать, возвращать ли ошибку, если удалить не смог, потому что не нашел, и объяснить свой выбор, правильно обработать граничный случай на листьях дерева, итд. И все это сделать не мгновенно, нет, но не очень медленно, достаточно уверенно и понимая, что делаешь (а это сразу видно). Есть огромное количество людей, которые казалось бы все знают, и алгоритмы все найдут, и с PhD, и с опытом и все на свете, а не могут это сделать.

Date: 2008-01-28 11:54 pm (UTC)
From: [identity profile] katja-i.livejournal.com
Понятно, спасибо. Насчёт PhD - тут конечно нет никакой гарантии. Не далее как год назад попал нам тут в руки проект, единственным автором которого был PhD, причём именно по профилю человек, Computer Science. Дыры в простейших алгоритмах именно на проверках, ну а код такой, что даже обфускатора не надо :)

Есть ощущение, что на собеседовании в Google гораздо проще будет боевому программисту, потратившему на освежение в памяти основных алгоритмов, теории графов и всякой хорошей алгебры пару месяцев (тут я согласна с [livejournal.com profile] dm_lihachev, всё это используется в достаточно редких случаях и просто-напросто забывается), нежели свеженькому PhD с недостаточным опытом разработки.

December 2025

S M T W T F S
  123 4 56
78 9 10 11 1213
1415 1617181920
21 22 23 24 2526 27
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Dec. 28th, 2025 03:26 pm
Powered by Dreamwidth Studios