Обобщая свой опыт проведения технических собеседований: задание должно быть сформулировано так, чтобы для решения требовалась не очень сложная композиция из базовых элементов и приемов, которые неизбежно закрепляются на уровне рефлексов при регулярном использовании.
Поэтому у меня на собеседовании (Java) кандидат пишет код в IDE по своему выбору, имеет право смотреть в документацию и искать в интернете, а чтоб закодить решение ему нужны только базовые компоненты JDK, а так же JUnit.
Следующим уровнем может стать обсуждение решения. Ожидается, что кандидат видит границы его применимости, рассуждает о плюсах и минусах, предлагает улучшения, альтернативу, или даже обоснованно защищает свое решение.
Я до сих пор не перестаю удивляться, насколько хорошо итоги собеседования в таком формате коррелируют с трудовыми успехами.
Уровень ложно отрицательных ошибок оценить не могу.
Ну вот. ) Хотел поделиться аналогичным опытом, но смысла уже нет - вы меня опередили. И это хорошо. Тот самый код я не имею возможности опубликовать ни по техническим, ни по юридическим причинам, мне бы пришлось его пересочинить.
Десять лет назад я создал очень похожий инструмент. Javers тогда уже существовал, но его версия была меньше чем 1.0.0, то есть не production ready.
Изначально назначение у инструмента было другое - обеспечение конкурентной работы.
Объект не сохранялся в БД напрямую. Вместо этого под распределенной блокировкой вычислялся дифф между исходной и измененной версией объекта, и далее дифф применялся к актуальной версии объекта, которая и сохранялась в БД. Сохранялись в БД и диффы, которые в дальнейшем можно было использовать при расследовании разного рода инцидентов, а так же для восстановления исторических версий объекта, которые могли быть нужны для разного рода миграций.
Таким образом, несколько юзеров могли одновременно отредактировать разные поля, одновременно сохранить объект, и ничьи изменения не терялись в результате гонки.
Опытный разработчик может возразить, что правильный способ обеспечения конкурентной работы - это команды, а не вот это вот всё поверх CRUD'а, и я с ним соглашусь.
Первый раз поиграл мозгом. Верный ответ нашел, но было тяжко.
Почесал репу, и выработал такой подход:
Сначала ввожу четыре слова, которые подобраны так, чтоб перебрать все гласные без повтора букв.
Далее этого пробую искать пятое слово по вхождению и исключению букв из первых четырех, вот этот сервис неплохо подходит. Зачастую на этом этапе правильный ответ очевиден.
Но если поиск возвращает много результатов, то для его сужения выбираю слово с другими согласными с помощью того же сервиса, после чего снова повторяю поиск по вхождению и исключению.
Одна неудача за всё время. Времени на сей комментарий потратил больше, чем на 5 раундов игры.
Перепробовав несколько разных библиотек для маппинга, я пришел к выводу - лучший маппер из объекта в объект - это маппер, написанный вручную.
Вот причины:
Во-первых, библиотечный маппер не дает большой экономии, т.к. объем неизбежных тестов почти всегда существенно больше объема вручную написанного маппера.
Во-вторых, рано или поздно в недрах бибилиотечного маппера магия дает сбой, и приходится тратить время, чтоб понять, что же пошло не так, а то и костыль сбоку городить.
В-третьих, сложные мапперы, написанные вручную, можно декомпозировать, и тогда появляется возможность тестировать элементы композиции отдельно и саму композицию на моках, что зачастую позволяет уменьшить количество тестов или их сложность.
В-четвертых, библиотечный маппер привносит дополнительную когнитивную сложность и минимум одну дополнительную зависимость. На долгоживущих проектах любая зависимость зачастую является миной замедленного действия.
В-пятых, IDE при рефакторинге может не подхватить строковые литералы, символизирующие имена полей и методов. А вот если бы были тесты...
Но этот все не отменят пользы от такого рода мапперов, если перечисленные недостатки не имеют значения в силу специфики проекта.
Смысл - убедиться, что кандидат способен быстро закодить элементарные вещи. На мой взгляд, для разраба выше джуна это одно из базовых требований.
Я встречал людей, претендовавших на сеньора, при этом на словах даже превосходящих Льва Толстого, а на деле не способных пользоваться стандартной библиотекой. Как таких отсеивать без лайвкодинга - не очень понятно.
Похоже, я неверно понял ваш коммент. Фразу "Когда я был девелопером, я писал 100-500 строчек в день. Сейчас, когда дорос до техлида пишу в 3 раза больше, ..." я прочитал так, будто в роли техлида вы стали писать больше кода в 3 раза.
Неоднократно встречал заведомо неоптимальный код, который мог бы быть написан с теми же трудозатратам, но гораздо оптимальнее по скорости или памяти (например, неверно выбран контейнер). Спрашиваешь автора, как же так - а он начинает объяснять, мол, преждевременная оптимизация - зло. Зла не хватает.
Нужно же как то фильтровать кандидатов. ) К сожалению, никто не умеет нанимать малоизвестных, но толковых разработчиков прицельно. Если никто не знает, как правильно фильтровать, то какая разница как? Тем более, что это про программирование, а не про мячики от гольфа в автобусе и круглые люки. Прогресс.
Пришли однажды юзеры с жалобой - жмешь кнопку, говорят, и понять невозможно, что происходит, покуда операция не завершится.
Ок, мы сочинили прогресс индикатор в виде окошка, где есть горизонтальная полосочка, символизирующая процент прогресса, а так же текстовое поле с названием текущей операции.
Откуда брать процент? Насочиняли всякой сложной логики, как учитывать распараллеливаемые операции, как вложенные, что делать, если текущая операция добавит другую (дада, прогресс откатывался) и еще всякие интересные кейсы.
Юзеры довольны, разработчики - нет. Подсчет процента оказался сложным.
В один прекрасный момент я просто выбросил всю сложную логику.
Вместо нее начал считать так: от момента начала операции в течении ожидаемого максимального времени операции (эмпирическое значение, десятки секунд) процент равномерно бежит от 0 до 60, далее - каждые 10 секунд добавляется по проценту, и так до 99.
Спасибо, хорошо сформулировали. )
Провожу технически интервью с лайвкодингом.
Кандидаты с ChatGPT отличаются от прочих.
Во-первых, они подтормаживают. Не сильно, но заметно.
Во-вторых, они набирают код как текст.
Обобщая свой опыт проведения технических собеседований: задание должно быть сформулировано так, чтобы для решения требовалась не очень сложная композиция из базовых элементов и приемов, которые неизбежно закрепляются на уровне рефлексов при регулярном использовании.
Поэтому у меня на собеседовании (Java) кандидат пишет код в IDE по своему выбору, имеет право смотреть в документацию и искать в интернете, а чтоб закодить решение ему нужны только базовые компоненты JDK, а так же JUnit.
Следующим уровнем может стать обсуждение решения. Ожидается, что кандидат видит границы его применимости, рассуждает о плюсах и минусах, предлагает улучшения, альтернативу, или даже обоснованно защищает свое решение.
Я до сих пор не перестаю удивляться, насколько хорошо итоги собеседования в таком формате коррелируют с трудовыми успехами.
Уровень ложно отрицательных ошибок оценить не могу.
Купил бы, если б девайс был совмещен со считывателем отпечатка пальца.
Не ложусь раньше, чем начинаю отчетливо хотеть спать.
Засыпаю хорошо, но график получается сильно плавающий. )
"Женщину вынули, автомат засунули."
Ну вот. ) Хотел поделиться аналогичным опытом, но смысла уже нет - вы меня опередили. И это хорошо. Тот самый код я не имею возможности опубликовать ни по техническим, ни по юридическим причинам, мне бы пришлось его пересочинить.
Десять лет назад я создал очень похожий инструмент. Javers тогда уже существовал, но его версия была меньше чем 1.0.0, то есть не production ready.
Изначально назначение у инструмента было другое - обеспечение конкурентной работы.
Объект не сохранялся в БД напрямую. Вместо этого под распределенной блокировкой вычислялся дифф между исходной и измененной версией объекта, и далее дифф применялся к актуальной версии объекта, которая и сохранялась в БД. Сохранялись в БД и диффы, которые в дальнейшем можно было использовать при расследовании разного рода инцидентов, а так же для восстановления исторических версий объекта, которые могли быть нужны для разного рода миграций.
Таким образом, несколько юзеров могли одновременно отредактировать разные поля, одновременно сохранить объект, и ничьи изменения не терялись в результате гонки.
Опытный разработчик может возразить, что правильный способ обеспечения конкурентной работы - это команды, а не вот это вот всё поверх CRUD'а, и я с ним соглашусь.
Одной ладонью можно хлопнуть, например, по любому предмету, или даже по части тела, округлые и мягкие для этого недурно подходят.
Поленился писать код.
Первый раз поиграл мозгом. Верный ответ нашел, но было тяжко.
Почесал репу, и выработал такой подход:
Сначала ввожу четыре слова, которые подобраны так, чтоб перебрать все гласные без повтора букв.
Далее этого пробую искать пятое слово по вхождению и исключению букв из первых четырех, вот этот сервис неплохо подходит. Зачастую на этом этапе правильный ответ очевиден.
Но если поиск возвращает много результатов, то для его сужения выбираю слово с другими согласными с помощью того же сервиса, после чего снова повторяю поиск по вхождению и исключению.
Одна неудача за всё время. Времени на сей комментарий потратил больше, чем на 5 раундов игры.
Перепробовав несколько разных библиотек для маппинга, я пришел к выводу - лучший маппер из объекта в объект - это маппер, написанный вручную.
Вот причины:
Во-первых, библиотечный маппер не дает большой экономии, т.к. объем неизбежных тестов почти всегда существенно больше объема вручную написанного маппера.
Во-вторых, рано или поздно в недрах бибилиотечного маппера магия дает сбой, и приходится тратить время, чтоб понять, что же пошло не так, а то и костыль сбоку городить.
В-третьих, сложные мапперы, написанные вручную, можно декомпозировать, и тогда появляется возможность тестировать элементы композиции отдельно и саму композицию на моках, что зачастую позволяет уменьшить количество тестов или их сложность.
В-четвертых, библиотечный маппер привносит дополнительную когнитивную сложность и минимум одну дополнительную зависимость.
На долгоживущих проектах любая зависимость зачастую является миной замедленного действия.В-пятых, IDE при рефакторинге может не подхватить строковые литералы, символизирующие имена полей и методов.
А вот если бы были тесты...Но этот все не отменят пользы от такого рода мапперов, если перечисленные недостатки не имеют значения в силу специфики проекта.
Смысл - убедиться, что кандидат способен быстро закодить элементарные вещи. На мой взгляд, для разраба выше джуна это одно из базовых требований.
Я встречал людей, претендовавших на сеньора, при этом на словах даже превосходящих Льва Толстого, а на деле не способных пользоваться стандартной библиотекой. Как таких отсеивать без лайвкодинга - не очень понятно.
Похоже, я неверно понял ваш коммент. Фразу "Когда я был девелопером, я писал 100-500 строчек в день. Сейчас, когда дорос до техлида пишу в 3 раза больше, ..." я прочитал так, будто в роли техлида вы стали писать больше кода в 3 раза.
Дорос до тех-, а потом и тимлида, писал кода больше, чем любой из разрабов на проекте, переписывался с менеджерами, вел документацию.
У меня так же было. А потом я выгорел.
Лучше проверять не наличие конкретных знаний, а способность их применять.
Можно, например, предложить кандидату на обзор кусок забагованного кода, для починки которого без понимания устройства HashMap не обойтись.
Этот подход хорош еще и возможностью интегрировать несколько проверок.
Неоднократно встречал заведомо неоптимальный код, который мог бы быть написан с теми же трудозатратам, но гораздо оптимальнее по скорости или памяти (например, неверно выбран контейнер). Спрашиваешь автора, как же так - а он начинает объяснять, мол, преждевременная оптимизация - зло. Зла не хватает.
Не хочу огорчать вас отказом!
Нужно же как то фильтровать кандидатов. ) К сожалению, никто не умеет нанимать малоизвестных, но толковых разработчиков прицельно. Если никто не знает, как правильно фильтровать, то какая разница как? Тем более, что это про программирование, а не про мячики от гольфа в автобусе и круглые люки. Прогресс.
Пришли однажды юзеры с жалобой - жмешь кнопку, говорят, и понять невозможно, что происходит, покуда операция не завершится.
Ок, мы сочинили прогресс индикатор в виде окошка, где есть горизонтальная полосочка, символизирующая процент прогресса, а так же текстовое поле с названием текущей операции.
Откуда брать процент? Насочиняли всякой сложной логики, как учитывать распараллеливаемые операции, как вложенные, что делать, если текущая операция добавит другую (дада, прогресс откатывался) и еще всякие интересные кейсы.
Юзеры довольны, разработчики - нет. Подсчет процента оказался сложным.
В один прекрасный момент я просто выбросил всю сложную логику.
Вместо нее начал считать так: от момента начала операции в течении ожидаемого максимального времени операции (эмпирическое значение, десятки секунд) процент равномерно бежит от 0 до 60, далее - каждые 10 секунд добавляется по проценту, и так до 99.
С тех пор прошел год. Никто не жаловался.
Джунов можно использовать для обучения толковых спецов основам менеджмента.