$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
бесполезная трата времени и своего и кандидата.
Если решение гуглится — то суть интервью проверить умеет ли кандидат гуглить, вы же ищете не Full StackOwerflow разработчика?
А элегантность решения — это ваше субъективное мнение, вы так будете искать разраба который думает примерно как вы, теме же разработчискими шаблонами. 80% за то, что вы отклоните кандидата, который решает задачки как программер-олимпиадник быстро, грубо и эффективно или кандидата который предложит решение выполняющую требования задания но используя совершенно иной продход.
Но скорее всего большенство действительно сильных и грамотных программистов после получения задания — забъют на него и на собеседование то же, так как есть предложения на рынке где не требуют решения ДЗ и ЗП выше.
$>Преследуемые цели:
$>- не устраивать экзамен
Хмммм...
прям представил себе: кандидат, тяните билет
Кстати. Надо на собеседовании над кандидатами поприкалываться.
Здравствуйте, ssp_alex, Вы писали:
_>Если решение гуглится — то суть интервью проверить умеет ли кандидат гуглить,
Если умеет самостоятельно нагуглить оптимальное решение и понять, такой по сути и нужен.
_>А элегантность решения — это ваше субъективное мнение
Это мое субьективное определение оптимального по времени и памяти и корректного для corner cases решения, на любом языке из длинного списка.
_>80% за то, что вы отклоните кандидата, который решает задачки как программер-олимпиадник
Задача отсеять кандидата, неспособного самостоятельно решить поставленную задачу.
_>прям представил себе: кандидат, тяните билет _>Кстати. Надо на собеседовании над кандидатами поприкалываться.
Нужно найти годных коллег, на которых
можно раскидать задачи.
$>Здравствуйте, ssp_alex, Вы писали:
_>>Если решение гуглится — то суть интервью проверить умеет ли кандидат гуглить,
$>Если умеет самостоятельно нагуглить оптимальное решение и понять, такой по сути и нужен.
_>>80% за то, что вы отклоните кандидата, который решает задачки как программер-олимпиадник
$>Задача отсеять кандидата, неспособного самостоятельно решить поставленную задачу.
Вот в чем закавырка — кандидат может нагуглить оптимальное решение и даже объяснить его, и может даже к месу говорить много умных слов и владеть терминологией, но при этом он запросто может оказаться неспособным решать поставленные задачи. Как показывает практика — таких полно, и что обидно — они не хотят ни меняться и ни учиться. С этим самая засада.
Возможно будет лучший вариант — заранее предупредить, что будет задание на кодерство и сказать в какой области IT. А на собеседовании давать решаемую задачку с ограниченным временем на выполенение и несколькими вариантами, тут можно увидеть — способен думать кандидат или нет, может он решать задачи, как решает, пишет код аккуратно или небрежно, решение сопровождаемое или одноразовое. Хотя мне кажется я вольными словами пересказываю "Путь программиста" в части проведения собеседования.
$>Чувакам с C++, налепившим пачку синглтонов в пределах процесса, и не знакомых с DI, лучше открыть для себя этот самый DI.
Конечно это круто, но как ты собираешься прокидывать объект который нужен в разных компонентах? Тот же логер или сборщик телеметрии, например.
Здравствуйте, Kernan, Вы писали:
K>Конечно это круто, но как ты собираешься прокидывать объект который нужен в разных компонентах? Тот же логер или сборщик телеметрии, например.
The injector tracks the dependencies for each type and uses bindings to inject them. This is the core of Guice, although you rarely interact with it directly. This "behind-the-scenes" operation is what distinguishes dependency injection from its cousin, the service locator pattern.
$>The injector tracks the dependencies for each type and uses bindings to inject them. This is the core of Guice, although you rarely interact with it directly. This "behind-the-scenes" operation is what distinguishes dependency injection from its cousin, the service locator pattern.
$>
Ага, т.е. для service locattor'а я явно запрашиваю интерфейсы и потом конструирую объект,т.е. он выдает тип по интерфейсу, а DI конструирует объект без моего вмешательства, так?
Здравствуйте, Sharov, Вы писали:
S>Ага, т.е. для service locattor'а я явно запрашиваю интерфейсы и потом конструирую объект,т.е. он выдает тип по интерфейсу, а DI конструирует объект без моего вмешательства, так?
DI инициализирует зависимости в правильной последовательности (привет топологическая сортировка) и передает их в конструктор. Единичные явные вызовы интерфейса- точка входа.
$>DI инициализирует зависимости в правильной последовательности (привет топологическая сортировка) и передает их в конструктор. Единичные явные вызовы интерфейса- точка входа.
Правильная посл-ть задается сигнатурой конструктора, а вот что делать, если у нас два типа реализуют соотв. интерфейс? Как DI решит эту проблему?
Здравствуйте, Sharov, Вы писали:
S>$>DI инициализирует зависимости в правильной последовательности (привет топологическая сортировка) и передает их в конструктор. Единичные явные вызовы интерфейса- точка входа.
S>Правильная посл-ть задается сигнатурой конструктора,
S> а вот что делать, если у нас два типа реализуют соотв. интерфейс? Как DI решит эту проблему?
Поставить на соответствующий аргумент конструктора аннотацию с ключом для DI.
$>Дискас.
Самую тупую и унылую работу в офисе на полный день(с почасовой оплатой, по которой в удачный месяц выходило 40тр), я нашел сделав домашнее задание, а потом успешно пройдя трехчасовое собеседование с около 50 вопросами.
Опыта тогда было 4 года, срочно нужна была работа.
Как бы поступил сейчас, если бы мне дали домашнее задание?
Да просто! Тупо дал бы встречной задание. Я тоже хочу знать, с кем мне придется работать и что за говнокод меня ждет.
И, естественно, их задание не стал бы делать. Если только не пообещают мильены денег.
Мы предлагаем решить задачу на дому, срок не ставим, но по нашим оценкам, человеку с искомыми скилами хватит и часа для ее решения. Задача простая, "прикладная" без требований хитрых алгоритмов и прочих подговырок. Задача дается опционально "Для сокращения времени технического интервью мы можем дать вам задачу на дом." Но. Если человек, взявший решать ее, но не сделавший от слова совсем, отсеивается.
Пришедший с "готовым" решением на собеседовании проходит "Code Review". Задаем вопросы по тестовому покрытию, по производительности и т.п.
Какое-то время отказывались от задач на дому. Кандидаты приходили сильно слабее.
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, $$, Вы писали:
G>$>Здравствуйте, Gradiens, Вы писали:
G>$>Спрашивать про аргументы методов imho моветон.
G>Конечно, спрашивать синтаксис — моветон. Кроме того, это абсолютно бесполезно. G>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы. G>И опять-таки, это всего лишь пример. Я уверен, существуют вопросы получше ))
Вопросы такого рода как правило бесполезны (за несколькими исключениями).
Знание платформы (тем более таких gotcha вещей, которые к тому же не особо имеют значение, т.к. оставлять какую-то существенную логику в деструкторе это вообще моветон).
Это все существенно менее важно чем знание алгоритмов, структур данных и способности сдизайнить что-нибудь полезное.
В крупных компаниях людей нередко нанимают без знания определенной платформы, если человек толковый, у него займет несколько месяцев чтобы освоиться в любой платформе.
Исключения — это когда человек нанимается в небольшую компанию и/или стартап, где есть временные или финансовые ограничения, и нужно чтобы он эффективно работал с первого же дня.
Второе исключение — это когда человек берется на позицию типа тех лида в проекте, соотвественно от него ожидается очень хорошее понимание платформы.
Здравствуйте, VladiCh, Вы писали:
VC>Вопросы такого рода как правило бесполезны (за несколькими исключениями). VC>Знание платформы (тем более таких gotcha вещей, которые к тому же не особо имеют значение, т.к. оставлять какую-то существенную логику в деструкторе это вообще моветон).
Вот, этот вопрос как раз и провоцирует подобного рода беседу. VC>Это все существенно менее важно чем знание алгоритмов, структур данных и способности сдизайнить что-нибудь полезное. VC>В крупных компаниях людей нередко нанимают без знания определенной платформы, если человек толковый, у него займет несколько месяцев чтобы освоиться в любой платформе. VC>Исключения — это когда человек нанимается в небольшую компанию и/или стартап, где есть временные или финансовые ограничения, и нужно чтобы он эффективно работал с первого же дня.
По моему опыту — как раз наоборот.
В стартапе нужно быть "и швец и жнец и на дуде игрец". Нужно, чтобы толковый человек умел быстро разбираться на поверхностом уровне с разными технологиями, мог бы скрестить ужа с ежом и занять рынок получившейся колючей проволокой.
А в больших и стабильных компаниях ищут людей на конкретный стек и/или конкретную предметную область.
Вот зачем большой компании брать джависта и переучать его в дотнетчика или наоборот, дотнетчика в джависта? Проекты пилятся годами, резкие изменения маловероятны, и многолетний опыт на стеке является важнейшим фактором при найме.
Если человек толковый, то через пару месяцев он, конечно, освоится. Но все равно его трудоспособность будет много меньше тех, кто работает с платформой годами. На полную мощность человек выйдет +- через год. Ну, и зачем компании его нанимать, если на рынке есть такие же кандидаты, только с опытом на нужном стеке?
Кроме того, структуры данных и алгоритмы явно переоценены. В большинстве мест хватит базовых знаний. То есть понимать алгоритмическую сложность конечно надо, знать как использовать имеющиеся в фреймворке списки, хеш-таблицы надо, но уметь реализовывать 100500 алгоритмов сортировки и вращать деревья — нафиг.
Я за 15 лет ни разу не встретился с необходимостью реализации какого-то классического алгоритма. Все уже украдено написано до нас, проще использовать существующее.
Зато много раз сталкивался с тормозами, где тупо грабли в виде O(n^2) вместо O(n). И для исправления знания алгоритмов как-то не особо нужны. Нужно просто самые базовые знания. А также сталкивался с разными вещами типа съедания приложениям памяти, связанным, например, с тем, что "куча" растет из-за "больших" объектов и после сборки мусора не дефрагментируется. Или с тем, что многопоточное приложение тупит не из-за плохих алгоритмов, а из-за сборки мусора, потому что происходит масса аллокаций памяти. И надо не искать более эффективный алгоритм, а тупо переписать без аллокаций памяти.
Я вот думаю, если меня перекинуть на джаву, код я смогу писать с первого дня. А вот разгребать вышеописанные проблемы — вряд ли. Наоборот, без достаточного опыта я их только создам.
VC>Второе исключение — это когда человек берется на позицию типа тех лида в проекте, соотвественно от него ожидается очень хорошее понимание платформы.
И тут, я считаю, все наоборот.
Ну, то есть тех лид безусловно должен знать свой огород, но также должен быть технически разносторонне развитым. Чтобы принимал взвешенные стратегические решения, а не использовал молоток для забивания шурупов только потому, что молоток — его любимый инструмент.
$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
$>Преследуемые цели:
$>- не устраивать экзамен
$>- дать шанс освежить в памяти базовые структуры данных. Чтобы не было неожиданностью требование знать bigO notation.
$>Дискас.
Я тут начал такой эксперимент: первый созвон на 20-30 минут — за жизнь, за опыт, про технологии в целом. А дальше — явно спрашиваю у кандидата что он предпочитает — поупражнятся с задачками/дизайном или взять задание на дом, а потом созвониться и обсудить решение/код итп. Пока народ выбирает задание на дом! Задание на дом стараюсь выбрать приближенное к проблемам которые мы решаем, на несколько часов работы, +-.
C опытными спецами с релевантным опытом такое не нужно, это больше для молодежи или "универсальных солдатов".
Здравствуйте, Faland, Вы писали:
F>C опытными спецами с релевантным опытом такое не нужно, это больше для молодежи или "универсальных солдатов".
Это про булькавшихся в болоте устаревших технологий годами, ничего более ниасиливших? Если на поддержку кала мамонта, наверное разумно- нормальный программист заскучает и свалит с такого.
$>Здравствуйте, Faland, Вы писали: F>>C опытными спецами с релевантным опытом такое не нужно, это больше для молодежи или "универсальных солдатов".
$>Это про булькавшихся в болоте устаревших технологий годами, ничего более ниасиливших? Если на поддержку кала мамонта, наверное разумно- нормальный программист заскучает и свалит с такого.
Нет, cкорее так:
Пример: скажем, нам надо (Modern C++/video/streaming) человека. Можно просто сильный С++, если готов разобраться с видео по ходу дела.
Если апплаится чувак с хорошим реальным опытом (Modern C++ / Video) — будем спрашивать по С++ и предметной области. Если он варился в болоте и не развивался — вопросы по Modern C++ и современным видео технологиям быстро выявят правду.
Если апплаится "просто сильный С++, готов разобраться" — тогда надо погонять немного, чтобы понять — а сможет ли разобраться. Ну и к общепрограммистским скиллам уже требования повыше, чтоб скомпенсировать отсутствие доменной экспертизы.
А вообще, не все же сервисы для сайтиков клепают, полно областей где требуется не один год чтоб действительно понимать всю систему и быть способным что-то серьезно менять.
Я например на проекте 4 года, только недавно достиг такого понимания которое позволяет менять архитектуру, переписывать какие-то части полностью итп.
Во многом конечно из-за легаси-говнокода изначального, накуевертили больше миллиона строк на четырех языках, но если бы все писали качественно сначала — проект бы не выстрелил вовремя и текущего отдела вообще бы не было...
Здравствуйте, Faland, Вы писали:
F>А вообще, не все же сервисы для сайтиков клепают, полно областей где требуется не один год чтоб действительно понимать всю систему и быть способным что-то серьезно менять.
Ох как высокомерно. Гугл и Яндекс, например,"сервисы для сайтиков клепает".
Суть вашего фильтра- давать предпочтение кандидатам с недавним опытом по используемым у вас технологиям.
У нас то же самое похоже что предварительный фильтр, а потом на собеседовании вопросы "на кодинг" ставят кандидатов в тупик. Очевидно, нормальных кодеров срезали ещё на просмотре резюме (без N лет опыта на такой-то версии ангулара и CSS).
F>Я например на проекте 4 года, только недавно достиг такого понимания которое позволяет менять архитектуру, переписывать какие-то части полностью итп. F>Во многом конечно из-за легаси-говнокода изначального, накуевертили больше миллиона строк на четырех языках, но если бы все писали качественно сначала — проект бы не выстрелил вовремя и текущего отдела вообще бы не было...
Это обычная история. Сначала непонятно, куда оно всё выедет и что полезно, а что нет.
$>Здравствуйте, Faland, Вы писали:
F>>А вообще, не все же сервисы для сайтиков клепают, полно областей где требуется не один год чтоб действительно понимать всю систему и быть способным что-то серьезно менять.
$>Ох как высокомерно. Гугл и Яндекс, например,"сервисы для сайтиков клепает".
Что-то мне подсказывает что те кто работу каждый год меняют в Гуглах-Яндексах не работают, а если и работали — ничего серьезного там сделать не успели. Да и не про то речь вообще, ты сам первый начал про "болото и сидение на одном месте помногу лет"
$>Суть вашего фильтра- давать предпочтение кандидатам с недавним опытом по используемым у вас технологиям.
$>У нас то же самое похоже что предварительный фильтр, а потом на собеседовании вопросы "на кодинг" ставят кандидатов в тупик. Очевидно, нормальных кодеров срезали ещё на просмотре резюме (без N лет опыта на такой-то версии ангулара и CSS).
При чем здесь определенные версии фреймворков? Речь идет про наличие и отсутствие доменной экспертизы. Но на онсайте код пишут все, если что.
