В RSDN-овском сраче (откуда проистекает и предыдущая заметка) высказал несколько вещей, которые на первый взгляд могут выглядеть странно. Может даже сложиться впечатление, что они противоречат друг другу. Попробую раскрыть тему и пояснить что к чему.
Итак, вещь первая: при смене фреймворка знания предыдущего фреймворка оказываются бесполезными. Например, опыт в MFC окажется бесполезным при работе с Qt, опыт работы с Qt окажется бесполезным при работе с Asio, опыт с Asio окажется бесполезным при работе с FFMPEG и т.д., и т.п.
Да, столь резкая смена (Qt на Asio и Asio на FFMPEG) запросто возможна при смене предметной области.
При этом нужно разделять опыт, относящийся к конкретному инструменту, и опыт, относящийся к предметной области. Так, если человек впервые начал писать GUI с использованием MFC, то этот человек узнает многое не только про MFC, но и про UI вообще.
В частности, он узнает, что окна бывают разные, что может быть SDI, может быть MDI, могут быть немодальные диалоговые окна, могут быть модальные, может быть общее меню приложения, может быть локальное контекстное меню, что у контроллов на форме есть фокус и что перемещение фокуса происходит в определенном порядке, и т.д., и т.п.
Так вот, глупо отрицать, что часть опыта, полученного при разработке GUI на MFC останется актуальным и при разработке GUI на Qt. Только вот это будут именно что знания UI (и, отчасти, UX), а не MFC.
Как раз таки знания именно MFC при переходе на Qt нужно будет выбросить из головы и чем быстрее это произойдет, тем лучше.
Вещь вторая: разработчику нужны знания фреймворка X, если этого разработчика берут туда, где фреймворк X используется.
Грубо говоря, если контора разрабатывает приложение на Qt, то им нужен разработчик, который уже знает Qt. И эти знания желательно иметь здесь и сейчас.
Конечно, подход, когда "возьмем толкового чувака с опытом в MFC, а Qt он быстро освоит" так же имеет право на жизнь. И ниже я выскажу свое мнение почему такой подход может быть выгоден. Но тут нужно понимать, что когда программист не имеет хороших знаний нужного вам инструмента, то некоторое время этот программист не будет оправдывать вложенные в него средства.
Для меня лично оказалось странным, что такое простое и (на мой взгляд) логичное требование воспринимается излишне жестким. Мол, главное -- это фундаментальные знания, алгоритмы там, структуры данных и пр. А уж знание фреймворка "поднимается с пола" запросто.
Толчком к написанию этого поста стал фрагмент из текущего рабочего проекта. На работе я пытаюсь спроектировать хитрый диспетчер для SObjectizer-а, который бы обеспечивал работу привязанных к диспетчеру агентов на строго определенном контексте с дополнительными действиями между обработкой событий агентов. У диспетчера есть ряд методов, которые должны быть реализованы для привязывания/отвязывания агентов. В попытке написать реализации этих методов я поймал себя на том, что ошибся в своих предположениях: думал, что они все будут вызываться на контексте одной и той же нити, но забыл, что один из них вызывается из другой нити. Однако, поскольку изначально я об этом знал, но просто забыл, то вовремя вспомнил.
А теперь представим, что подобную задачу решал бы человек, который бы "поднимал с пола" знания SObjectizer-а уже по ходу работы с проектом. Во-первых, ему могло бы вообще не хватить знаний чтобы представить, что для решения очередной задачи может быть применен собственный диспетчер. Во-вторых, он мог вообще не представлять себе то, что разные методы диспетчера вызываются в разных местах, т.к. это довольно-таки редкие знания, нужные далеко не всем и далеко не всегда.
Другой пример, из уже из Asio. Для меня в свое время стало неожиданным открытием то, что при отмене таймера все равно вызывается completion handler, но со специфическим error code. И это открытие заставило меня переписать некоторое количество кода.
Думаю, что подобных примеров можно привести массу для любого фреймворка.
Поэтому я и придерживаюсь мнения, что когда нам нужен программист со знанием X, то знания X у соискателя должны присутствовать. И это знания не уровня "точное название функции F и точный список всех ее аргументов", а понимание того, что функция F есть, предназначена для того-то и того-то, и имеет некоторые особенности. Причем далеко не всегда нужно знать даже название функции F. Скажем, я всегда путаю название функции в SObjectizer, которая отвечает за создание mchain-а: create_mchain или make_mchain, мне постоянно приходится заглядывать в документацию. Но зато помню, что функция для создания mchain-а есть.
Теперь на счет того, почему иногда выгодно взять человека без знаний фреймворка X.
Просто потому, что у программистов кроме знаний есть качества. Например, надежность и ответственность. Честность. Порядочность. Настойчивость. Трудолюбие. Коммуникабельность. Обучаемость. И т.д., и т.п.
Проекты начинаются для того, чтобы достичь цели, что бывает непросто. А когда непросто, то на первый план выходят качества, которые работают в сложных ситуациях. Типа надежности, настойчивости и ответственности.
Когда проект начинает критически зависеть от таких качеств, то имеет смысл брать людей, обладающих нужным нам качествами, пусть даже без нужных знаний. Знания-то приобрести можно, пусть даже на это потребуется время. А вот приобрести качества, которых изначально нет... Вот это вряд ли.
Вещь третья: нет смысла проверять знания фреймворка на собеседовании вопросами о деталях. Т.е. спрашивать на собеседовании "а какая функция делает то-то и то-то" или даже "а напишите нам фрагмент кода, который делает то-то и то-то", на мой взгляд, бессмысленно. Особенно если мы собеседуем человека уровня senior и выше.
Объяснения моей точки зрения простые:
- мелкие детали легко отыскиваются в документации или в Google. Кроме того, чем с большим количеством задач человек сталкивался, тем меньше мелких деталей у него в памяти остается. Эти несущественные знания (по крайней мере у меня) быстро вытесняются более важными вещами;
- собеседование -- это стресс сам по себе. В реальной работе мы пишем код совсем в других условиях. И, если мы ориентируемся на то, как человек пишет простой код в условиях стресса на собеседовании, то мы проверяем совсем не тот критерий, который нам нужен. Да, многие хорошие программисты напишут нормальный код и на собеседовании. Но далеко не все. И, главное, есть риск взять плохого программиста, который хорошо выдерживает стресс собеседования.
Поэтому-то я и считаю, что распрашивать на собеседовании про мелкие детали фреймворка X не есть хорошая идея. Уровень владения инструментом быстро выясниться на испытательном сроке -- вы же будете смотреть код, который пишет новый человек, не так ли? Значит все и увидите.
Естественно, на собеседовании нужно постараться выяснить, действительно ли за "знанием X" или "опытом программирования на X в течении 5 лет" стоит то, что нам нужно или нет. Но это делается несколько другими методами, чем выяснением мелких деталей или написанием игрушечных фрагментов кода.
К сожалению, тема того, как на собеседовании выяснить уровень владения фреймворком X, слишком большая и сложная. Так что здесь даже не буду пытаться. Приношу свои извинения, нельзя объять необъятного в рамках небольшого поста.
Вот, пожалуй, и все, что хотел сказать. Возможно, даже сейчас изложенные вещи могут показаться противоречащими друг другу. Если так, то извините, я старался :(
Да, все вышесказанное базируется на основании собственного опыта (и в качестве программиста, и в качестве тимлида).
2 комментария:
По факту, в большинстве случаев, оцениваются лишь конкретные навыки и послужной список. Оценка упомянутых личностных качеств (порядочность, настойчивость и т.д.) - весьма редкое явление, к большому сожалению. Причина, на мой взгляд, на поверхности: стремление к взаимозаменяемости кадров - "мне не важно какой ты хороший, мне важно, чтобы работа делалась; ничего личного, просто бизнес".
Ещё один любопытный парадокс - вопросы не по теме. Это когда, например, кандидата, претендующего на роль сетевого программиста, начинают заваливать вопросами про деревья.
А ещё не редко бывает, что собеседования или проверки тестовых заданий проводятся далеко не экспертами, но, к сожалению, уполномочены отсеивать кандидатов, которые потенциально на голову выше их. Увы.
@Dmitry Igrishin
Про личные качества я упомянул исходя вот из какого сценария: для проекта берут людей не по объявлению, а по рекомендации. Если за человека поручаются те, кто с ним раньше работал, то такие поручения важнее, чем конкретные знания этого человека на данный момент. Ибо если человек уже зарекомендовал себя как тот, кто способен вытянуть проект из задницы (или не дать проект туда уронить), то это стоит очень и очень дорого. Дороже, чем владение Asio или Qt.
А так-то да, проверить качества на собеседовании вряд ли возможно.
Отправить комментарий