Комментарии 35
Хм. Так и делаю, когда требуется отсобеседовать человека. Просто скидываю краткое описание одного старого проекта и прошу рассказать, как эта вся хрень должна работать. Без кода, просто как сделать в теории. Собеседую в основном на Друпал, так что тут заодно и степень погружения можно проверить — насколько человек ориентируется вообще, а не просто долбит код. Проект такой, что местами надо юзать готовые модули (свои писать долго и дорого), а что-то однозначно надо дописать самому. Вот как-то так оно и происходит.
Иногда, кстати, кандидаты выдают довольно неожиданные решения.
Иногда, кстати, кандидаты выдают довольно неожиданные решения.
Ваш подход немного отличается от предложенного мной, но это отличие важно. Суть в том, что обсуждается реальный проект, который вы вот прямо сейчас открыли на экране и этот проект делали не вы. Это достаточно сильно меняет вещи. Мало кто захочет обсужадть ваш старый проект, по которому вы все знаете и своего мнения по его реализации скорее всего не измените, а кандидат должен быстренько вникнуть и угадать, как вы что в нем сделали, чтобы ответ вам понравился.
Ставьте друг друга в равные положения и обретете понимание в беседе :)
Я извиняюсь за возможную грубость, но я был на подобном собеседовании, я его прошел, но не скажу, что мне это понравилось. Человека было тяжело переубедить в чем то относительно реализаций, т.к. он заранее занял позицию «я уже такое сделал, а ты теперь расскажи как я это сделал и почему я молодец». Естественно, все зависит от того, как вы проводите собеседование, но я надеюсь, вы уловили, то что я хотел вам сказать.
Как добавление к посту: не стоит обсуждать проекты, которые вы сами уже реализовали, скорее всего, ваше мнение будет предвзятым по отношению к ответам кандидата
Ставьте друг друга в равные положения и обретете понимание в беседе :)
Я извиняюсь за возможную грубость, но я был на подобном собеседовании, я его прошел, но не скажу, что мне это понравилось. Человека было тяжело переубедить в чем то относительно реализаций, т.к. он заранее занял позицию «я уже такое сделал, а ты теперь расскажи как я это сделал и почему я молодец». Естественно, все зависит от того, как вы проводите собеседование, но я надеюсь, вы уловили, то что я хотел вам сказать.
Как добавление к посту: не стоит обсуждать проекты, которые вы сами уже реализовали, скорее всего, ваше мнение будет предвзятым по отношению к ответам кандидата
Это да, такая опасность есть. Но стараюсь избегать.
Я вообще стараюсь на соискателя не давить в этом плане. Мне просто интересно оценить потенциальную работоспособность того, что он предложит. Я также спрашиваю о возможных подводных камнях, которые в его решении, возможно, не учтены, или о которых он не упомянул. Мне интересен подход к реализации, я не требую полного решения задачи. Одни пытаются использовать чистый РНР, другие комбинируют это с уже известными решениями на Друпале (причём сами используемые решения могут быть довольно разными).
И да, после того, как я понял, что и как человек предлагает сделать, я предлагаю тот подход, который реально задействован на том проекте (естессна, я не говорю, что это делал я) и прошу оценить такой вариант. Вы знаете, пару косяков уже нашёл :)
Кстати, по чужому проекту у того, кто проводит собеседование, зачастую тоже уже есть своё мнение, так что в этом плане подход не особо отличается.
Я вообще стараюсь на соискателя не давить в этом плане. Мне просто интересно оценить потенциальную работоспособность того, что он предложит. Я также спрашиваю о возможных подводных камнях, которые в его решении, возможно, не учтены, или о которых он не упомянул. Мне интересен подход к реализации, я не требую полного решения задачи. Одни пытаются использовать чистый РНР, другие комбинируют это с уже известными решениями на Друпале (причём сами используемые решения могут быть довольно разными).
И да, после того, как я понял, что и как человек предлагает сделать, я предлагаю тот подход, который реально задействован на том проекте (естессна, я не говорю, что это делал я) и прошу оценить такой вариант. Вы знаете, пару косяков уже нашёл :)
Кстати, по чужому проекту у того, кто проводит собеседование, зачастую тоже уже есть своё мнение, так что в этом плане подход не особо отличается.
Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!
Сам в том месяце как раз устраивался по вакансии этой. Многие работодатели как раз задавали вопросы вроде: «А вот в том-то приложении есть то-то и то-то. Смогли бы вы сделать это? Если да, то как? Какие сроки? Поддержка какой версии Андройд?» Довольно неплохой подход к собеседованию.
Про Android при собеседовании стоит отдельно поговорить о поддержке разных версий Android. Какими средствами этого добиться? Поговорить о support library, о других либах для поддержки старых устройств вроде ActionBarSherlock.
Сам часто спрашиваю такие вопросы на собеседованиях, но только после знания «платформы». Как сделаете — вопрос, больше подходящий для Senior-позиций. Если человек «плавает» в знании платформы, то как он сможет принять адекватные решения при проектировании?
ИМХО При Вашем подходе получается, что нужно нанимать человека под конкретную задачу с конкретными требованиями, и, по окончании проекта, расставаться с ним. Я, конечно, утрирую, но Вы предлагаете что-то вроде такого: «специалист по отрисовке красных параллельных линий на синем фоне». Почему расставаться? Потому что на желтом фоне он уже не сможет ничего нарисовать…
Ситуация может поменяться, вплоть до смены языка программирования, платформы, операционной системы и т.д. (со мной был такой случай, когда изначально стояла задача писать ПО под Windows (C#/.NET4.0), а вышло под Linux (C++/Qt)). Поэтому, я считаю, что важнее гибкость мышления и быстрая обучаемость, нежели доскональное знание платформы и языка.
Ситуация может поменяться, вплоть до смены языка программирования, платформы, операционной системы и т.д. (со мной был такой случай, когда изначально стояла задача писать ПО под Windows (C#/.NET4.0), а вышло под Linux (C++/Qt)). Поэтому, я считаю, что важнее гибкость мышления и быстрая обучаемость, нежели доскональное знание платформы и языка.
С другой стороны, если человек глубоко изучил один инструмент, то это хороший признак того, что он в будущем сможет изучить и другие инструменты.
Ну для «вышло» существует контрактная форма взаимоотношений.
А при чем тут это? При Вашем подходе я просто потерял бы работу. А получилось все очень хорошо: компания получила продукт, я получил бесценный опыт… Плюс, как и написал Shedal выше, переписать проект из C# в Qt вышло не так уж и сложно.
А непредвиденные ситуации бывают, тут уж ничего не поделаешь, и если прятаться за контракт, подавать в суд и т.д., ИМХО с таким человеком мало кто будет работать…
А непредвиденные ситуации бывают, тут уж ничего не поделаешь, и если прятаться за контракт, подавать в суд и т.д., ИМХО с таким человеком мало кто будет работать…
Вы не боитесь, что при данном подходе вы откажетесь от кандидата, который имеет не самый большой опыт на данной платформе, но способен хорошо и быстро обучаться?
Условно говоря, платформе Андроид не так уж много лет исполнилось.
И не от всех программистов следует ждать досконального знания фрагментов и апи-левелов — многие из них последние 5 лет работали не для андроида.
Если вам соискатель скажет: «я не программировал на андроиде вообще, но 5 лет назад со мной был случай — мне поручили такое приложение написать на WinCE, и я впервые увидев эту платорму написал это за X месяцев — вот оно — смотрите»
Условно говоря, платформе Андроид не так уж много лет исполнилось.
И не от всех программистов следует ждать досконального знания фрагментов и апи-левелов — многие из них последние 5 лет работали не для андроида.
Если вам соискатель скажет: «я не программировал на андроиде вообще, но 5 лет назад со мной был случай — мне поручили такое приложение написать на WinCE, и я впервые увидев эту платорму написал это за X месяцев — вот оно — смотрите»
Чаще бывает другой случай — кандидат приходит и говорит, что он — Гуру вообще и пишет под платформу технологию последние 26 лет, но вот чем абстрактный класс отличается от интерфейса© не знает.
Если вам соискатель скажет: «я не программировал на андроиде вообще, но 5 лет назад со мной был случай — мне поручили такое приложение написать на WinCE, и я впервые увидев эту платорму написал это за X месяцев — вот оно — смотрите»
А можно нанять программиста, последние 3 года писавшего под Android, который это же приложение сделает за неделю. Я утрирую конечно, но всё же…
Тут важен опыт. Если человек не работал с платформой, но быстро учится, то да, он может быстро освоиться, даже написать приложение какое-то, вот только он не знает ничего о подводных камнях и т.д.
Поэтому человек с опытом и хорош, так как он знает о многих подводных камнях, особенностях, возможностях платформы и т.п.
Вы серьезно считаете, что человек который писал под разные платформы будет очень долго учиться кодить под андроид? Качество кода и хорошие привычки (типа написания тестов и тд). похоже не сильно котируются сейчас. Зато человек, который «х*як-х*як и в продакшен» всегда на коне =)
Я считаю, что человек, который пишет преимущественно под одну платформу (и разбирается в ней) лучше, чем человек, «который писал под разные платформы», но не достиг высокого уровня ни в одной.
Согласен) В сегодняшних реалиях разработка — это бизнес, поэтому требуется максимально быстро создать продукт, а приоритет отдается визуальной оболочке, нежели качеству кода…
Звездная команда не всегда нужна, иногда это плохо. Если все проектировщики, все очень общительные -> постояные споры. Нужен один два проектировщика, остальные — реализаторы. Реализатор не обязательно тупой и не может проектировать, но обязательно умеющий реализовывать любую придуманую архитектуру, обучаем и покладист. Может быть даже ни разу не социальным, главное управляем.
IMHO, не очень хорошая идея. Придет человек вроде меня и спросит: а такое «Вконтакте»? Вот я понятия не имею, что там за приложение, зачем оно нужно и что от него требуется. Конечно же если вы собираетесь делать подобное приложение, то вам и не подойдет такой программист. Поэтому если и использовать подобный подход, то не «берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение», а берем именно то приложение, функциональность которого схожа с будущими задачами для этого программиста.
Когда я устраивался на работу, собеседование тоже начиналось со стандартного листочка с вопросами по языку и вариантами ответов. Но на каждый вопрос задавали дополнительные вопросы — «Почему именно этот вариант?», «А как бы вы это реализовали?», «А почему дизайнеры языка решили это сделать именно так, а не иначе?», «Может знаете, как с этим дела в других языках?» и даже самый банальный вопрос разворачивался в довольно интересное обсуждение
Поддерживаю автора, но обычно я давал такие задания кандидатам на дом, неделя максимум, потом собеседовал по написанному коду. Очень помогает отсеивать некомпетентных разработчиков. Единственное, я немного не согласен с тем, что надо давать большое приложение — у многих уже есть работа, а если еще есть дети или другие интересы, очень сложно выкроить время. На Западе на это вообще смотрят очень категорично, и отказываются делать задание, если оно в сумме отнимет много времени на разработку. Так что для себя я выбрал критерий — если я смог бы это сделать менее чем за 8 часов, тогда можно давать — сутки кандидат сможет выкроить.
Еще бы я добавил в задание немного методологических нюансов, как например, потребовать чтобы кандидат залил свой проект на DVCS-хостинг (github, bitbucket etc), и чтобы было покрытие юнит-тестами (не обязательно 100%, но как минимум backend-функционал). Если это библиотека, можно потребовать автогенерируемую документацию. Т.е. посмотреть, насколько качественно умеет кандидат делать приложения, не только внутренний код, но и другие вещи, являющиеся атрибутами хорошо разработанного продукта.
Еще бы я добавил в задание немного методологических нюансов, как например, потребовать чтобы кандидат залил свой проект на DVCS-хостинг (github, bitbucket etc), и чтобы было покрытие юнит-тестами (не обязательно 100%, но как минимум backend-функционал). Если это библиотека, можно потребовать автогенерируемую документацию. Т.е. посмотреть, насколько качественно умеет кандидат делать приложения, не только внутренний код, но и другие вещи, являющиеся атрибутами хорошо разработанного продукта.
Самое главное — архитектура ПО, а кодеров хоть г… на. Некоторые умеют и очень даже красиво писать код и бить себя в грудь, но то что они делают с архитектурой, это полное дилетантство.
А некоторые архитекторы, не могут так быстро кликать по клаве и нормально излагать свои мысли в речи, но то что они творят с архитектурой — это одно совершенство.
Так что все эти собеседования — это одно большое недоразумение. Надо смотреть по портфолио и работе.
Алмаз — тяжело найти. А г всегда много, иногда даже в очень неплохой упаковке
А некоторые архитекторы, не могут так быстро кликать по клаве и нормально излагать свои мысли в речи, но то что они творят с архитектурой — это одно совершенство.
Так что все эти собеседования — это одно большое недоразумение. Надо смотреть по портфолио и работе.
Алмаз — тяжело найти. А г всегда много, иногда даже в очень неплохой упаковке
И если компания набирает проект «по собеседованию» Пипец такому проекту.
Я бы никогда не набирал так команду. Всегда надо анализ. В компании MS вообще 30% состава программеров — это аутисты, которые два слова связать не могут, зато они любую задачу развяжут в несколько раз быстрее, элегантнее и с меньшим количеством не нужного кода. (в google тоже таких любят)
Я бы никогда не набирал так команду. Всегда надо анализ. В компании MS вообще 30% состава программеров — это аутисты, которые два слова связать не могут, зато они любую задачу развяжут в несколько раз быстрее, элегантнее и с меньшим количеством не нужного кода. (в google тоже таких любят)
По портфолио и работе разве что в исходники смотреть, бывают внешне нормальные приложения, а в исходники заглянешь — тьма тьмущая и сразу понятно, почему функционал внедряется медленно и тд и тп. К тому же, как вы поймете, какю роль человек играл в реализации проекта из портфолио, приукрасить в любят.
Поэтому и предлагаю обсуждать на примере реального проекта архитектурные моменты + реализации определённых, интересующих вас вещей.
Качество кода — тестовое задание, небольшой проект на день работы, как по мне — оптимальный вариант.
Поэтому и предлагаю обсуждать на примере реального проекта архитектурные моменты + реализации определённых, интересующих вас вещей.
Качество кода — тестовое задание, небольшой проект на день работы, как по мне — оптимальный вариант.
Да портфолио и чужое можно взять (вы не поняли суть моего поста), лучше уже «знать» того кого хочешь. Переманить.
Тогда можно твердо быть уверенным, что проект получиться не хуже чем у конкурента, у которого переманили архитектора.
А собеседование можно проводить на прием секретарш.
Когда я набираю персонал я уже знаю кого беру. И результаты проектов всегда прогнозируемые.
Тогда можно твердо быть уверенным, что проект получиться не хуже чем у конкурента, у которого переманили архитектора.
А собеседование можно проводить на прием секретарш.
Когда я набираю персонал я уже знаю кого беру. И результаты проектов всегда прогнозируемые.
Спасибо за подборку вопросов, очень ценно! Осталось теперь каким-нибудь образом всему этому научиться…
Идея, я считаю, в целом очень правильная.
Идея, я считаю, в целом очень правильная.
Не понял, а чем плох robospice?
Или «серьезные» android программисты должны сами иметь/разработать свою библиотеку для REST?
Или «серьезные» android программисты должны сами иметь/разработать свою библиотеку для REST?
Я же не говорил, что он плох, я написал:
Я не против его использования, но только если оно аргументированно. Просто так затаскивать такую библиотеку в проект не стоит, т.к. потом сменить ее на что-то другое (если потребуется) будет очень проблематично, вот и все :)
Могу вас успокоить, у нас в проектах robospice используется. Но скажем, я обычно сам пишу работу с сетью и кешем запросов, т.к. уже не раз наталкивался на особенности работы серверной стороны, то gzip для определенных запросов, то заголовки подменить и т.д. и т.п., ну и кеш, соответственно, тоже часто надо тюнить под проект, естественно, у меня для этого есть свои наработки.
Из накипевшего, под windows phone недавно вообще пришлось запилить свою библиотеку для загрузки и кеша картинок: https://github.com/artem-zinnatullin/jet-image-loader/ (это к фразе о своих библиотеках)
Сразу обговорите по поводу серьезных библиотек, которые разработчик хочет затащить в проект (про серьезные, я имею в виду те, которые жестко связывают руки в дальнейшем, например Robospice, ActionBarSherlock (я в курсе про ActionBarCompat), AndroidAnnotations, etc)
Я не против его использования, но только если оно аргументированно. Просто так затаскивать такую библиотеку в проект не стоит, т.к. потом сменить ее на что-то другое (если потребуется) будет очень проблематично, вот и все :)
Могу вас успокоить, у нас в проектах robospice используется. Но скажем, я обычно сам пишу работу с сетью и кешем запросов, т.к. уже не раз наталкивался на особенности работы серверной стороны, то gzip для определенных запросов, то заголовки подменить и т.д. и т.п., ну и кеш, соответственно, тоже часто надо тюнить под проект, естественно, у меня для этого есть свои наработки.
Из накипевшего, под windows phone недавно вообще пришлось запилить свою библиотеку для загрузки и кеша картинок: https://github.com/artem-zinnatullin/jet-image-loader/ (это к фразе о своих библиотеках)
Ясно.
Я спросил, потому что на сам смотрю в сторону robospice. И не хотелось бы после того как освою плеваться и выпиливать её)
Я спросил, потому что на сам смотрю в сторону robospice. И не хотелось бы после того как освою плеваться и выпиливать её)
Ещё лучше — обсудить с кандидатом его собственный код.
Собеседование это итак стресс, а тут ещё и чужое приложение придумывать.
Все те советы из статьи — только не на чужом коде, а на коде который уже написал кандидат. Т.е. просишь прислать примеры работ и их же с ним обсуждаешь. И тестовое не нужно — т.к. код уже есть. И есть что обсуждать, не растекания мыслью по древу — код уже есть.
Я так собеседую по скайпу, уходит минут 20, очень эффективно.
Собеседование это итак стресс, а тут ещё и чужое приложение придумывать.
Все те советы из статьи — только не на чужом коде, а на коде который уже написал кандидат. Т.е. просишь прислать примеры работ и их же с ним обсуждаешь. И тестовое не нужно — т.к. код уже есть. И есть что обсуждать, не растекания мыслью по древу — код уже есть.
Я так собеседую по скайпу, уходит минут 20, очень эффективно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Re: Собеседование разработчика (альтернатива/дополнение)