о программировании
Jan. 25th, 2008 01:11 pmВчера разговорился с коллегой из отделения Гугла в одной европейской стране. Он жаловался, что трудно найти инженеров - кандидатов, которые хотя бы как-то подходили, почти нет. Я спросил, в чем дело, и он объяснил, что выпускники университетов в его стране обычно считают, что писать код - ниже их достоинства, и что вообще "карьера" несовместима с такими занятиями; они хотят быть не то мелкими начальниками, не то "архитекторами". Им прямо в университете, дескать, так и говорят: получите свою степень магистра - больше вам программки писать не придется. Конечно, с работой в Гугле это все никак не сочетается.
У нас в Израиле тоже есть схожие проблемы, хоть и не в таких масштабах. Время от времени попадаются кандидаты, которые не просто не могут написать простой код на бумаге (не могут-то многие), но еще и возмущаются тем, что от них этого просят. Однажды кандидат долго расспрашивал меня, просто не желая поверить, что так может быть: "неужели меня, после PhD и постдока, посадят писать код, как какого-то мальчишку? Должны же у вас быть какие-то должности типа архитектора или системного аналитика! Нет, ну я могу писать код, но я этого не делал много лет и не в этой области лучше всего проявляются мои способности".
В Гугле все инженеры пишут программы, включая любого рода тим-лидеров, включая и ученых, нанятых на ставку "research scientist". Нет никаких "архитекторов" и "аналитиков", которые сами думают, а код за них пишут другие. Те же люди, которые придумывают дизайн какой-то системы, вместе с другими ее воплощают.
Я, кстати, не уверен, что так лучше. Мне лично такое порядок работы очень по душе, но я не готов заявить, что он объективно приводит к лучшим результатам, чем более иерархичное устройство с "архитекторами". Несоменно, есть места и есть обстоятельства, где такое устройство очень хорошо работает. Но я лично не хотел бы быть "архитектором".
У нас в Израиле тоже есть схожие проблемы, хоть и не в таких масштабах. Время от времени попадаются кандидаты, которые не просто не могут написать простой код на бумаге (не могут-то многие), но еще и возмущаются тем, что от них этого просят. Однажды кандидат долго расспрашивал меня, просто не желая поверить, что так может быть: "неужели меня, после PhD и постдока, посадят писать код, как какого-то мальчишку? Должны же у вас быть какие-то должности типа архитектора или системного аналитика! Нет, ну я могу писать код, но я этого не делал много лет и не в этой области лучше всего проявляются мои способности".
В Гугле все инженеры пишут программы, включая любого рода тим-лидеров, включая и ученых, нанятых на ставку "research scientist". Нет никаких "архитекторов" и "аналитиков", которые сами думают, а код за них пишут другие. Те же люди, которые придумывают дизайн какой-то системы, вместе с другими ее воплощают.
Я, кстати, не уверен, что так лучше. Мне лично такое порядок работы очень по душе, но я не готов заявить, что он объективно приводит к лучшим результатам, чем более иерархичное устройство с "архитекторами". Несоменно, есть места и есть обстоятельства, где такое устройство очень хорошо работает. Но я лично не хотел бы быть "архитектором".
no subject
Date: 2008-01-28 09:55 pm (UTC)А ещё интересно, вот если к примеру взять quicksort и двух испытуемых: первый человек набросает быстренько классический алгоритм, а второй реализует вариацию с использованием in-place partition алгоритма, предпочтителен второй или первый?
Из своего опыта: когда что-то обсуждаешь с программистом, действительно проще на бумажке набросать кусочек кода, так быстрее и понятнее. Но ради экономии времени я зачастую специально опускаю в таком коде всё, что выпадает из эпицентра идеи (проверки и т.п.). Я думаю, что точно то же самое происходит почти со всеми, кто привык писать код на бумажке. И на собеседовании с этим может случиться недоразумение, человеку сложно будет сломать собственный паттерн и писать рукой синтаксически правильно и с обработкой ошибок.
no subject
Date: 2008-01-28 10:23 pm (UTC)В вопросе с quicksort предпочтительно сделать то, что попросили :) конечно, это хорошо, если правильно сразу напишет in-place, но если сначала набросает классический, а я попрошу сделать in-place, и он правильно сделает - тоже хорошо.
Я понимаю, что тянет сосредоточиться на главном и набросать псевдокод. Но вопрос на coding - не проверка алгоритмических знаний, а проверка именно умения писать настоящий правильный корректный код. Видеть в нем off-by-1 ошибки. Делать обработку ошибок, если надо. Итд. Иногда на таком вопросе вообще просят написать что-то тривиальное с алгоритмической точки зрения. Например, (придумываю из головы, это не реальный вопрос, но похож по сложности на реальный) написать функции добавления и удаления элемента из отсортированного двоичного дерева (без балансирования). Чего уж проще. Но надо определить структуру элемента на данном языке (например, на C++ с указателями), написать эти две фунцкии, каждую строчек на 10, проверить все граничные значения (что если все дерево NULL?), придумать, возвращать ли ошибку, если удалить не смог, потому что не нашел, и объяснить свой выбор, правильно обработать граничный случай на листьях дерева, итд. И все это сделать не мгновенно, нет, но не очень медленно, достаточно уверенно и понимая, что делаешь (а это сразу видно). Есть огромное количество людей, которые казалось бы все знают, и алгоритмы все найдут, и с PhD, и с опытом и все на свете, а не могут это сделать.
no subject
Date: 2008-01-28 11:54 pm (UTC)Есть ощущение, что на собеседовании в Google гораздо проще будет боевому программисту, потратившему на освежение в памяти основных алгоритмов, теории графов и всякой хорошей алгебры пару месяцев (тут я согласна с