Честный ответ это уже весьма неплохо, но обычно стараемся выбрать более свежую тему а не код 10-ти летней давности.
Мой подход не догма, основная его идея в том что обсуждение задачки уровня FizzBuzz может быть неплохо для джуна, но для разработчика с опытом эта задача слабо полезна чтобы понять его уровень и знания.
Наилучшим подходом я считаю обсуждение реальных решенных задач и реального кода который написал кандидат. Программирование на бумажке на мой взгляд не может дать того же представления потому что для решения например сложной задачи надо потратить только пару часов для обдумывания подходящей структуры данных или например удачных абстракций. Такие задачи можно предлагать как тестовое задание (но многие не захотят его делать) или попросить кандидата показать какие либо примеры его кода.
А вот программировать на бумажке совсем не обломно — я всегда уболтаю интервьювера что синтаксис не важен, а параметры «вот примерно такие, но точно не помню».
А могли бы вы привести типичный пример задачи которую вам не обломно запрограммировать на бумажке?
Такой подход хорошо работает в больших компаниях когда у вас есть возможность держать открытую вакансию несколько месяцев. А также у вас есть достаточное количество кандидатов. В небольших компаниях это может быть несколько расточительно. Мне надо делать проекты вот прямо сейчас, и вобщем-то без разницы если человек например заикается, но при этом может писать нормальный код
В моем случае это не требование, а скорее дополнительный плюс. Понятно что мы не откажем человеку просто потому что у него нет хороших примеров опенсорс кода. Просто в таком случае на собеседовании прийдется обсуждать уже задачу предложенную нами. А это может вводить кандидатов в стресс и они могут показывать худший уровень чем могли бы. Т.е. у меня обычно подход такой:
1) Найти пример из прошлого опыта кандидата который бы показывал релевантные мне навыки и опыт. Обсудить этот пример кода для того чтобы понять почему были приняты те или иные решения и насколько глубоко канидат разбирается в смежных темах. Основная идея в том что разговор на знакомую кандидату тему позволяет ему расслабится и вспомнить реально интересные вещи из его опыта.
2) Если такого примера сходу найти не удается то предложить какую нибудь другую задачу. Задачу из нашего практического опыта либо более синтетическую но затрагивающую интересные мне темы
Тезис «опенсорс имеет лучшее качество кода» кажется мне крайне сомнительным
Да возможно я излишне оптимистичен насчет качества кода. Из моего опыта я сталкивался с качественными проектами, но понятно что бывают варианты и хуже.
В хороших закрытых проектах с техническим общением и код ревью тоже все в порядке.
Возможно, но вы об этом не узнаете пока не спросите. В опенсорсных проектах это сразу видно глазами.
Моя основная идея не в том что участие в опенсорс проектах гарантирует высокое качество кандидата. А в том что вы можете своими глазами посмотреть на код который пишет кандидат и оценить его. Это намного лучше чем предлагать синтетические задачки и ждать что найдется кандидат который угадает что именно вы хотите услышать от него.
Да такой подход предполагает больший расход времени и усилий со стороны нанимающей компании т.к. надо потратить время и разобраться в том коде который собственно прислал кандидат. Зато он позволяет примерно оценить какой именно код кандидат будет писать в случае найма. Т.к. уже приводили примеры случаев когда кандидаты зазубривали все стандартные вопросы и успешно проходили собеседование, а на испытательном сроке выяснялось что они собственно не умеют программировать.
В итоге, чтобы адекватно оценить опыт участия кандидата — надо изучить эти опенсорс-проекты, и вычленить его вклад туда, и опять же оценить этот вклад.
Конечно нужно, в этом же и смысл. Вы можете легко открыть комиты этого человека и посмотреть что именно он делал. Посмотреть качество именно его реквестов. Если опенсорс проект состоит из дикости и костылей, и человек только увеличивал количество дикости и костылей, конечно такой разработчик вам не нужен.
Гораздо проще и экономнее по времени это выяснить на собеседовании, задав нужные вопросы.
Спорный вопрос, собеседования надо назначать выделить для этого удобное всем время. Бегло глянуть несколько комитов от кандидата как правило не занимает много времени, а уже позволяет составить первое впечатление. В дальнейшем на собеседовании можно дополнительно задать вопросы по тем или иным вещам и например обсудить спорные моменты. Из моего опыта это очень хорошо в моральном плане т.к. вы не пытаетесь задавить кандидата своими знаниями или вопросами по незнакомой ему теме, а наоборот общаетесь на тему которую он знает и это помогает ему лучше показать его реальный уровень.
С другой стороны, если это состоявшийся специалист, с большой долей вероятности он в опенсорсах не участвует по одной простой причине — ему за это не платят.
Тут думаю у каждого свой собственный опыт. Мне например нравятся мои текущие/прошлые места работы именно потому что там в рамках рабочего времени можно вносить вклад в том числе в опенсорс. Т.е. у нас либо часть проекта имеет открытый код (в последнем проекте 90% кода открыто) либо же можно тратить время на улучшения опенсорсных библиотек используемых на проекте
Открыл соответствующий МР. Из моих выводов:
1) Вы принимали участие в достаточно сложных проектах. Это говорит о том что вы можете разбираться в большой кодовой базе и вносить в нее изменения.
2) Данный реквест по максимуму сохраняет обратную совместимость. Тоже плюс вам
3) Реквест был на ревью длительно время (около 6 месяцев вроде). Это говорит о вашем терпении и способности вести нудные технические дискуссии с индусами на англ. языке.
Из того что мне не понравилось сходу:
1) Реквест очень большой по обьему. Посмотрел что там большая часть диффа это изменения xml тестов. Я бы обязательно спросил почему нельзя было сделать его меньше и вмерджить частями.
2) В реквесте много комитов "Merge from master" и как минимум один фикс комит после ошибочного мерджа. Тут я бы спросил почему сделано именно так. Либо вы не умеете пользоваться git rebase и тогда это серьезный минус в моих глазах. Либо же это может быть политикой конкретного репозитория.
Я очень давно писал на C# и поэтому не берусь судить качество кода, но возможно предложил бы обсудить почему отдельные моменты сделаны именно так.
Вцелом даже такой комит в моих глазах является очень большим плюсом Вас как кандидата и если бы я нанимал C# разработчиков то думаю минут 20 мы могли бы его обсуждать
Об этом собственно и речь в статье. Подобный подход очень хорошо отсекает недостаточно квалифицированных кандидатов, но одновременно с этим он с большой вероятностью отсечет и квалифицированных ребят которые по какой то причине не смогли сходу предложить решение вашей задачи. Простой пример — толковый человек может не написать сходу сортировку двухсвязного списка и потратит много времени чтобы сделать более-менее толковое решение. Исходя из этого вы эту задачу оцените условно на 3 из 5. При этом время уже будет потрачено и вы не сможете пообщаться на более сложные темы и не узнаете что человек например хорошо разбирается в работе ядра линукс или еще каких то сложных и глубоких темах которые вам возможно актуальны на текущей работе. Т.е. если вам надо чтобы на работе человек решал олимпиадные задачки — спрашивайте на собеседовании олимпиадные задачки, а если надо чтобы человек писал драйвера — спрашивайте про драйвера
Могли бы вы более детально раскрыть свою мысль про опенсорс проекты? Из моего опыта:
1) Опенсорс проекты как правило имеют лучшее качество кода. Соответственно человек который в них участвовал как правило имеет более высокие навыки чем человек который писал закрытый код
2) Участие в опенсорс проектах предполагает следование определенному принятому флоу разработки как правило включая в себя техническое общение и процесс код ревью.
3) Моральный аспект — участие в опенсорс проектах показывает что человек стремится развиваться и в том числе развивать экосистему разработки.
Понятно что не каждый разработчик много часов в день уделяет вкладу в опенсорс (если это не входит в его должностные обязанности). Но очень часто бывает необходимость починить какой то баг в открытой библиотеке или добавить какой то несложный функционал который нужен на текущем проекте.
Мое ИМХО что как раз участие в опенсорс является отличным (хотя и не единственным) критерием зрелости специалиста
Можно попросить человека поделится ссылками на код который он писал в рамках каких то опенсорс проектов. Если человек не участвовал в написании опенсорс проектов то в моих глазах это вцелом минус, но если очень надо можно попросить его выполнить несложное тестовое задание. Как вы сами сказали человек знает про SOLID и у него есть опыт работы, т.е. крайне маловероятно что он не может написать FizzBuzz или посмотреть на подсказки в IDE — это может даже джун. Но при этом весьма вероятно что человек волнуется и изза этого не может решить даже простейшие задачи. Зато в спокойной обстановке легко с этим справится
Как пример можно торговать цифровыми товарами. Разработка ПО сейчас отлично оплачивается и вероятно будет еще долгое время. Экпорт цифры с Марса достаточно дешев (длинные пинги не в счет) так что думаю варианты найти можно при желании
Следующий критерий это способность рассуждать и обучаемость. Т.е. предложить задачу которую Вы не знаете и послушать Ваши рассуждения о том как Вы бы ее решали.
Или спросить о том какие технологии вы изучаете прямо сейчас и почему.
Т.е. условно оценивают 1) базовые знания 2) способность обучаться 3) софт-скиллы
Тут вопрос в том нужно ли вообще в вашей базе смотреть на много обьектов сразу? Допустим каждая запись это уникальный заказ или что-то в этом духе. Тогда вам достаточно знать что у нее уникальный uuid и это гарантируется индексом. А смотреть на несколько сразу вам все равно не интересно т.к. одна операция выполняется только с одним заказом. В таком случае иметь несколько ид явно плохая идея т.к. появляется возможность ошибиться и например сгенерить для двух разных uuid одинаковые числовые ид.
Этот вывод дают докладчики в своем видео… Понятно что с простыми примерами эффект не так заметен. Как раз там они и говорят что он начинает заметно проявлятся именно на достаточно большой кодовой базе.
Из моего опыта:
При написании даже несложного асинхронного кода можно получить очень странные ошибки которые связаны с попыткой переноса типов не реализующих Send через точку await (например обычный синхронный MutexGuard). ИМХО в этом месте компилятор выдает очень странные и неочевидные сообщения об ошибках до понимания которых я дошел только сильно позже когда разобрался как именно работают Futures.
Тут как раз хорошо иллюстрируется идея что можно взять программу допустим на питоне (или С++) и написать за 10 минут, а на Расте это займет час. Но мало кто в работе пишет программы за 10 минут и выбрасывает...
А вот если взять уже программу которую на Питона надо писать хотя бы 1000 часов…
То внезапно окажется что такую же на Раст можно написать за 700. Потому что экономится куча времени на дебаге и рефакторинге.
Box::leak тоже сейф функция. Понятно что никто не мешает сделать утечку памяти если очень хочется… Но в таком случае это довольно явно происходит и такое сложно сделать непреднамеренно. Вот пример про циклические структуры согласен это больше похоже на случай где можно непреднамеренно допустить утечку памяти. Но вцелом должна быть очень веская причина использовать именно такие структуры и как правило это признак плохого проектирования (из моего опыта)
Утечки как бы тоже являются… у каждого обьекта строго определен owner и когда он выходит из области видимости то обьект автоматически освобождает ресурсы. Соответственно при написании тривиального кода утечка не может возникнуть. Скорее всего утечки были связаны с какими нибудь механизмами использующими unsafe либо как вариант с отсутствием или неправильной реализацией трейта Drop
Честный ответ это уже весьма неплохо, но обычно стараемся выбрать более свежую тему а не код 10-ти летней давности.
Мой подход не догма, основная его идея в том что обсуждение задачки уровня FizzBuzz может быть неплохо для джуна, но для разработчика с опытом эта задача слабо полезна чтобы понять его уровень и знания.
Наилучшим подходом я считаю обсуждение реальных решенных задач и реального кода который написал кандидат. Программирование на бумажке на мой взгляд не может дать того же представления потому что для решения например сложной задачи надо потратить только пару часов для обдумывания подходящей структуры данных или например удачных абстракций. Такие задачи можно предлагать как тестовое задание (но многие не захотят его делать) или попросить кандидата показать какие либо примеры его кода.
А могли бы вы привести типичный пример задачи которую вам не обломно запрограммировать на бумажке?
Такой подход хорошо работает в больших компаниях когда у вас есть возможность держать открытую вакансию несколько месяцев. А также у вас есть достаточное количество кандидатов. В небольших компаниях это может быть несколько расточительно. Мне надо делать проекты вот прямо сейчас, и вобщем-то без разницы если человек например заикается, но при этом может писать нормальный код
Если уже речь зашла о Java, то надо требовать ентерпрайз решение, а не эту детскую поделку.
Ответил на такой же вопрос в другой ветке — https://habr.com/ru/company/skillfactory/blog/538240/#comment_22568614
В моем случае это не требование, а скорее дополнительный плюс. Понятно что мы не откажем человеку просто потому что у него нет хороших примеров опенсорс кода. Просто в таком случае на собеседовании прийдется обсуждать уже задачу предложенную нами. А это может вводить кандидатов в стресс и они могут показывать худший уровень чем могли бы. Т.е. у меня обычно подход такой:
1) Найти пример из прошлого опыта кандидата который бы показывал релевантные мне навыки и опыт. Обсудить этот пример кода для того чтобы понять почему были приняты те или иные решения и насколько глубоко канидат разбирается в смежных темах. Основная идея в том что разговор на знакомую кандидату тему позволяет ему расслабится и вспомнить реально интересные вещи из его опыта.
2) Если такого примера сходу найти не удается то предложить какую нибудь другую задачу. Задачу из нашего практического опыта либо более синтетическую но затрагивающую интересные мне темы
Ну я пока не настолько заинтересован Вас нанимать, чтобы вчитываться в детали :) тем более я давно не пишу на обоих этих языках.
Да возможно я излишне оптимистичен насчет качества кода. Из моего опыта я сталкивался с качественными проектами, но понятно что бывают варианты и хуже.
Возможно, но вы об этом не узнаете пока не спросите. В опенсорсных проектах это сразу видно глазами.
Моя основная идея не в том что участие в опенсорс проектах гарантирует высокое качество кандидата. А в том что вы можете своими глазами посмотреть на код который пишет кандидат и оценить его. Это намного лучше чем предлагать синтетические задачки и ждать что найдется кандидат который угадает что именно вы хотите услышать от него.
Да такой подход предполагает больший расход времени и усилий со стороны нанимающей компании т.к. надо потратить время и разобраться в том коде который собственно прислал кандидат. Зато он позволяет примерно оценить какой именно код кандидат будет писать в случае найма. Т.к. уже приводили примеры случаев когда кандидаты зазубривали все стандартные вопросы и успешно проходили собеседование, а на испытательном сроке выяснялось что они собственно не умеют программировать.
Конечно нужно, в этом же и смысл. Вы можете легко открыть комиты этого человека и посмотреть что именно он делал. Посмотреть качество именно его реквестов. Если опенсорс проект состоит из дикости и костылей, и человек только увеличивал количество дикости и костылей, конечно такой разработчик вам не нужен.
Спорный вопрос, собеседования надо назначать выделить для этого удобное всем время. Бегло глянуть несколько комитов от кандидата как правило не занимает много времени, а уже позволяет составить первое впечатление. В дальнейшем на собеседовании можно дополнительно задать вопросы по тем или иным вещам и например обсудить спорные моменты. Из моего опыта это очень хорошо в моральном плане т.к. вы не пытаетесь задавить кандидата своими знаниями или вопросами по незнакомой ему теме, а наоборот общаетесь на тему которую он знает и это помогает ему лучше показать его реальный уровень.
Тут думаю у каждого свой собственный опыт. Мне например нравятся мои текущие/прошлые места работы именно потому что там в рамках рабочего времени можно вносить вклад в том числе в опенсорс. Т.е. у нас либо часть проекта имеет открытый код (в последнем проекте 90% кода открыто) либо же можно тратить время на улучшения опенсорсных библиотек используемых на проекте
Открыл соответствующий МР. Из моих выводов:
1) Вы принимали участие в достаточно сложных проектах. Это говорит о том что вы можете разбираться в большой кодовой базе и вносить в нее изменения.
2) Данный реквест по максимуму сохраняет обратную совместимость. Тоже плюс вам
3) Реквест был на ревью длительно время (около 6 месяцев вроде). Это говорит о вашем терпении и способности вести нудные технические дискуссии с индусами на англ. языке.
Из того что мне не понравилось сходу:
1) Реквест очень большой по обьему. Посмотрел что там большая часть диффа это изменения xml тестов. Я бы обязательно спросил почему нельзя было сделать его меньше и вмерджить частями.
2) В реквесте много комитов "Merge from master" и как минимум один фикс комит после ошибочного мерджа. Тут я бы спросил почему сделано именно так. Либо вы не умеете пользоваться git rebase и тогда это серьезный минус в моих глазах. Либо же это может быть политикой конкретного репозитория.
Я очень давно писал на C# и поэтому не берусь судить качество кода, но возможно предложил бы обсудить почему отдельные моменты сделаны именно так.
Вцелом даже такой комит в моих глазах является очень большим плюсом Вас как кандидата и если бы я нанимал C# разработчиков то думаю минут 20 мы могли бы его обсуждать
Об этом собственно и речь в статье. Подобный подход очень хорошо отсекает недостаточно квалифицированных кандидатов, но одновременно с этим он с большой вероятностью отсечет и квалифицированных ребят которые по какой то причине не смогли сходу предложить решение вашей задачи. Простой пример — толковый человек может не написать сходу сортировку двухсвязного списка и потратит много времени чтобы сделать более-менее толковое решение. Исходя из этого вы эту задачу оцените условно на 3 из 5. При этом время уже будет потрачено и вы не сможете пообщаться на более сложные темы и не узнаете что человек например хорошо разбирается в работе ядра линукс или еще каких то сложных и глубоких темах которые вам возможно актуальны на текущей работе. Т.е. если вам надо чтобы на работе человек решал олимпиадные задачки — спрашивайте на собеседовании олимпиадные задачки, а если надо чтобы человек писал драйвера — спрашивайте про драйвера
Могли бы вы более детально раскрыть свою мысль про опенсорс проекты? Из моего опыта:
1) Опенсорс проекты как правило имеют лучшее качество кода. Соответственно человек который в них участвовал как правило имеет более высокие навыки чем человек который писал закрытый код
2) Участие в опенсорс проектах предполагает следование определенному принятому флоу разработки как правило включая в себя техническое общение и процесс код ревью.
3) Моральный аспект — участие в опенсорс проектах показывает что человек стремится развиваться и в том числе развивать экосистему разработки.
Понятно что не каждый разработчик много часов в день уделяет вкладу в опенсорс (если это не входит в его должностные обязанности). Но очень часто бывает необходимость починить какой то баг в открытой библиотеке или добавить какой то несложный функционал который нужен на текущем проекте.
Мое ИМХО что как раз участие в опенсорс является отличным (хотя и не единственным) критерием зрелости специалиста
Можно попросить человека поделится ссылками на код который он писал в рамках каких то опенсорс проектов. Если человек не участвовал в написании опенсорс проектов то в моих глазах это вцелом минус, но если очень надо можно попросить его выполнить несложное тестовое задание. Как вы сами сказали человек знает про SOLID и у него есть опыт работы, т.е. крайне маловероятно что он не может написать FizzBuzz или посмотреть на подсказки в IDE — это может даже джун. Но при этом весьма вероятно что человек волнуется и изза этого не может решить даже простейшие задачи. Зато в спокойной обстановке легко с этим справится
Как пример можно торговать цифровыми товарами. Разработка ПО сейчас отлично оплачивается и вероятно будет еще долгое время. Экпорт цифры с Марса достаточно дешев (длинные пинги не в счет) так что думаю варианты найти можно при желании
Следующий критерий это способность рассуждать и обучаемость. Т.е. предложить задачу которую Вы не знаете и послушать Ваши рассуждения о том как Вы бы ее решали.
Или спросить о том какие технологии вы изучаете прямо сейчас и почему.
Т.е. условно оценивают 1) базовые знания 2) способность обучаться 3) софт-скиллы
Тут вопрос в том нужно ли вообще в вашей базе смотреть на много обьектов сразу? Допустим каждая запись это уникальный заказ или что-то в этом духе. Тогда вам достаточно знать что у нее уникальный uuid и это гарантируется индексом. А смотреть на несколько сразу вам все равно не интересно т.к. одна операция выполняется только с одним заказом. В таком случае иметь несколько ид явно плохая идея т.к. появляется возможность ошибиться и например сгенерить для двух разных uuid одинаковые числовые ид.
Этот вывод дают докладчики в своем видео… Понятно что с простыми примерами эффект не так заметен. Как раз там они и говорят что он начинает заметно проявлятся именно на достаточно большой кодовой базе.
Из моего опыта:
При написании даже несложного асинхронного кода можно получить очень странные ошибки которые связаны с попыткой переноса типов не реализующих Send через точку await (например обычный синхронный MutexGuard). ИМХО в этом месте компилятор выдает очень странные и неочевидные сообщения об ошибках до понимания которых я дошел только сильно позже когда разобрался как именно работают Futures.
Посмотрите вот эту статью и видео ради интереса — https://habr.com/ru/company/rambler_group/blog/533268/
Тут как раз хорошо иллюстрируется идея что можно взять программу допустим на питоне (или С++) и написать за 10 минут, а на Расте это займет час. Но мало кто в работе пишет программы за 10 минут и выбрасывает...
А вот если взять уже программу которую на Питона надо писать хотя бы 1000 часов…
То внезапно окажется что такую же на Раст можно написать за 700. Потому что экономится куча времени на дебаге и рефакторинге.
Box::leak тоже сейф функция. Понятно что никто не мешает сделать утечку памяти если очень хочется… Но в таком случае это довольно явно происходит и такое сложно сделать непреднамеренно. Вот пример про циклические структуры согласен это больше похоже на случай где можно непреднамеренно допустить утечку памяти. Но вцелом должна быть очень веская причина использовать именно такие структуры и как правило это признак плохого проектирования (из моего опыта)
Утечки как бы тоже являются… у каждого обьекта строго определен owner и когда он выходит из области видимости то обьект автоматически освобождает ресурсы. Соответственно при написании тривиального кода утечка не может возникнуть. Скорее всего утечки были связаны с какими нибудь механизмами использующими unsafe либо как вариант с отсутствием или неправильной реализацией трейта Drop