лайфкодинг что это в образовании
Я пришел на собеседование с лайвкодингом — и меня с позором размазали
Если взять все собеседования, которые когда либо проходили у людей, и расставить их в порядке от лучшего к худшему — то на самой последней строчке окажется мое. Это было давно. Я уже умел разрабатывать, но совершенно не разбирался в собесах — и, слепой от желания получить оффер, пропустил все тревожные звоночки.
На первом же созвоне прошло сложное техническое интервью — что нормально — но только в самом конце его объявили «первым этапом, скринингом». Второй этап вел эйчар, третий — настоящие посланники ада. Два человека наперебой заваливали техническими вопросами про дотнет, не давали ни подумать, ни ответить и переходили к следующему.
Я справился странно. Именно странно. На несколько вопросов, которые дотнетчик не может не знать я ответил неправильно, на несколько таких, которые знает далеко не каждый, я ответил хорошо. Вот так бывает, я не сказал, что такое финалайзер, потому что начинал учиться с плюсов, и запомнил его как деструктор. Зато рассказал про поколения в сборщике мусора.
Я был ослеплен «успехом» и согласился на финальный этап — лайвкодинг. И вот там мне и пришлось переосмыслить значение слова «жопа».
Я был полон энтузиазма, потому что это не первый лайвкодинг в моей жизни, в моем родном городе меня уже просили писать код на бумажке, и все было нормально. Я полистал свои книжки по сишарпу, поубирал всякую хрень с рабочего стола, заварил себе гигантскую кружку кофе, и пошёл на созвон.
Скайп, тёмный экран, голоса — один за другим мне представляются интервьюеры. Ни одного из них не было на предыдущих этапах. Четыре штуки. Объясняют правила игры, говорят, что могу думать сколько угодно, что никто не давит, код пиши там где привык, так, как привык. Можешь гуглить все что хочешь. Но есть одно ключевое условие: задачу нужно решать в манере TDD.
— Ты уже работал с этим? Как это первый раз слышишь, что у нас такое требование? У нас все работают только по такой методологии. Ты тоже будешь. Вот тебе «простейшая университетская задачка», приступай.
Задача и правда была простой. Надо было написать парсер выражений, начать с простейших «1+2», а закончить настолько глубоко, насколько возможно за отведенные два часа.
Механизмы в моей башке заскрипели: так, просто сложение сделать невероятно легко, вычитание тоже, умножение потребует порядка действий — только оно стоящее. Если я не сделаю им умножение, они меня пошлют. Твою мать, читал же месяц назад про паттерн интерпретатор, они точно ждут именно его. Блин, я не помню как его делать! Сколько я уже думаю? Несколько минут? Они посчитают, что я идиот. Блин-блин-блин, если я сейчас же не начну хоть что-то писать, мне конец.
— Какие-то проблемы, Филипп?
Ну всё. Они все уже решили. Хотя нет, может они просто участливые? Да пиши же ты уже код.
Дрожащими ватными руками я нажимаю «Add file». Боже ж ты мой, как его назвать? Какой-нибудь экспрешн парсер! Стоп. В дотнете же есть родные штуки для распаршивания выражений. Они точно ждут не велосипедиста, а умного разраба, который пойдет и применит готовое решение. Открываю гугл, начинаю вбивать.
— Филипп, что вы делаете?
— Я вспомнил, что в дотнете были готовые решения под такие задачи, хочу ознакомиться с ними.
— Нет, Филипп, нас не интересует готовое решение. Пожалуйста, озвучивайте нам свои мысли, чтобы не тратить наше и ваше время.
Ооох, братан, если бы ты слышал мои мысли сейчас, интервью бы давно закончилось. Но бог с тобой. Создаю файлик, начинаю описывать интерфейс парсера.
— Филипп, что вы делаете?
— Я прикидываю структуру решения, пишу код, чтобы все в голове встало по местам, и я понял с какой стороны заходить.
— Филипп, я просто напоминаю вам, что у нас в компании применяется методология TDD, и мы в первую очередь хотели бы увидеть, насколько вы хороши именно в этом.
А я хочу увидеть, как тебе хлещут дохлой мороженной рыбиной по морде. Создаю файлик с тестом. Я не знаю, зачем. Уже очевидно, что никуда я не прошел. Туплю в нагенеренный студией код теста, одну минуту, две, три. Слышу возмущенное покашливание из скайпа. Господи, ну почему они не могли прислать на это интервью людей с предыдущего? Чтобы хотя бы один человек с той стороны экрана знал, что я блин не самый тупой человек на земле, и действительно кое-что знаю. Для этих, я определенно стал конченным дном.
Такими размышлениями была забита моя голова, когда руки вдруг начали писать какой-то код. На той стороне скайпа одобрительно захмыкали. Я написал тест, который тестирует несуществующий класс, нащелкал решарперовых хоткеев, класс сгенерился, дописал в нем, собственно код сложения. Выдохнул, почувствовал моральный подъем.
Запускаю тест — ничего не происходит. Вообще ничего, список прогнанных тестов пустой. Запускаю ещё раз, то же самое. Господь всемогущий, меня прокляли. Тесты не запускаются! Они не падают, они просто не запускаются!
Пытаюсь запустить не решарпером, а студией. Не работает. Пишу новый тест, он тоже не запускается. Это невозможно, но это происходит со мной, на кодинг интервью, студия, решарпер или дотнет сломались, и у меня не запускаются тесты.
— Филипп, вы забыли добавить модификатор public к тесту.
—…
—…
— processing…
Я понял. Выругался. Замьютил микрофон, выругался покрепче. Вернул микрофон. Добавил public, тест прошел. Я начал писать тест на вычитание. И вдруг как гром среди ясного неба:
— Филипп, наше интервью подошло к концу, огромное вам спасибо за потраченное время, мы сообщим вам о решении!
А я уже знал как все сделать. Я решил задачу в голове, но они этого не увидели — они увидели, как я кучу времени писал сложение. Куда вообще все это время делось?! Видимо я слишком долго тупил в моник, размышляя о том, что они обо мне думают.
Со мной, конечно, никто не связался. Это они очень правильно сделали. Ведь если бы они меня приняли, я бы разыскал этих людей в офисе, взял за яйца, и заставил писать код.
С тех пор я ни разу не соглашался на такие штуки. Я построил себе хорошую карьеру, сейчас сам управляю людьми, нанимаю их. И у меня нет проблем с самооценкой. Но если меня снова загнать на такое интервью, мне кажется, все вернется.
Понятно, что это моя проблема. Может дело в слабой психике, может слишком сильный синдром самозванца, может какие-то особенности характера, я не знаю. Но точно знаю, я такой не один. Нас много, и мы не становимся от этого дерьмовыми разработчиками.
Рынок огромный, мы найдем себе работу, но осадочек останется. Этот собес был лет пять назад, но он меня кошмарит до сих пор. Недавно я говорил со своим хорошим другом, который живет в США, и он рассказал мне, что у них мода на лайвкодинг проникла в каждый даже самый маленький стартап.
Американцы американцами, бог с ним. Вот чего я действительно боюсь, что у нас, как блин всегда, все всё скопируют, и на гигантском рынке не останется ни одного места, куда можно попасть без лайвкодинга. И я очень сомневаюсь, что все резко научатся проводить их так, чтобы не было адского давления.
Вы вот не любите нытье, а я не люблю, когда что-то работает плохо. Если люди, которые проводят лайвкодинг интервью в РФ, начнут давать кандидатам опцию с тестовым заданием, никто от этого не проиграет.
На правах рекламы
Мощные виртуальные серверы с процессорами AMD EPYC для разработчиков. Частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.
❓ Почему нельзя соглашаться на тестовый кодинг во время собеседования
Перевод публикуется с сокращениями, автор оригинальной статьи Dr Stuart Woolley.
Ленивый подход
Когда инженера-программиста просят выполнить конкретную задачу: написать алгоритм генерации факториалов (очень распространенное задание) или сортировки (одно/двусвязного) списка, никто не думает, что можно легко подготовиться и это не даст никакого представления о навыках кандидата, кроме силы механического запоминания.
Во время работы в одной компании автор обсуждал с коллегой процесс собеседования, которое они проходили в крупном хедж-фонде. Ко всем задаваемым техническим вопросам он был готов, т.к. сотрудник компании порекомендовал книгу с вопросами и ответами к собеседованию. Это была не только пустая трата времени, но и полное непонимание рекрутером компании уровня знаний кандидата. Коллега уволился через год из-за низкой технической планки по найму специалистов и постоянной неэффективной практики управления проектами.
Использование памяти
То же самое рассуждение относится и к программированию алгоритма на определенном языке. Ни один инженер-программист, работающий в реальном мире, не написал бы код без проверки синтаксиса (например, встроенного в автодополнение кода), без ссылки на техническую документацию или без копирования использования реализованного решения там, где это применимо. Не нужно изобретать велосипед.
При всей практической применимости, работа с синтаксисом конкретного ЯП основана на использовании и опыте. В то время как интервьюер может думать, что тестирование кандидата на синтаксические нюансы конкретного языка является показателем его понимания – автор материала категорически заявляет, что даже используя язык почти тридцать лет, он все еще регулярно ошибается в синтаксисе.
По мере того как карьера программиста развивается и он знакомится с новыми языками, автор регулярно путается между синтаксическими нюансами C, C++ и Objective-C. Не из-за того, что он ужасный инженер-программист, а потому что есть масса знаний, которые держатся в голове и ими нужно правильно воспользоваться в нужный момент. Хороший инженер-программист часто не знает ответа на конкретный вопрос с самого начала, но определенно знает, где искать ответ.
Общие задачи
Немного ранее мы говорили об изобретении велосипеда. Например, если вы работаете с языком C и вам необходима процедура для взаимодействия с последовательным портом, не нужно переписывать ее с нуля, если только ситуация этого специально не требует. Если нужен парсер JSON, просто возьмите уже созданный файл из библиотеки. Скорее всего он давно используется, полностью протестирован и имеет подробную (и правильную) документацию.
Вряд ли в современной программной инженерии можно встретить обычную задачу, которая либо уже не автоматизирована в написанной библиотеке, либо решение которой не является широкодоступным в алгоритмической форме.
Дискуссия-дискуссия-дискуссия
Автор полностью поддерживает выяснение того, знает ли свой предмет человек, с которым вы беседуете, но использование любого из вышеперечисленных методов совершенно бесполезно.
Например, простая дискуссия об используемых в современной программной инженерии парадигмах кодирования, о том, будет ли конкретный язык хорошим выбором для конкретной реализации, или уместна ли конкретная методология разработки программного обеспечения – это гораздо более полезные и острые темы для обсуждения.
Проведите дискуссию, чтобы выделить общие области, посмотрите, как кандидат понимает новые проблемы и, возможно, альтернативные новые методы решения старых. Как он видит развитие вещей, как бы он начал что-то решать. Оставайтесь открытыми, держитесь подальше от подробностей и мелочей. Stuart Woolley постоянно удивляется, что многие считающиеся перспективными и лидирующими в своей области компании все еще прибегают к устаревшим, монотонным и совершенно предсказуемым методам найма, которые мало что значат для оценки реальной технической ценности.
Собеседование с кем-то, у кого есть список технических вопросов – это почти всегда нежелание затягивать дискуссию по какому-то одному вопросу. Это часто показывает, что интервьюер может не полностью понять, о чем он спрашивает, и любой ответ, который точно не совпадает с написанным в его сценарии, будет классифицирован как неправильный.
Заключение
Некоторые компании перешли на более эффективные методы, другие, возможно, не дотянут до цели. Поэтому не связывайте отношения (особенно длительные) с работодателями, которые следуют устаревшей практике найма, настаивают на тестах и заданиях по программированию.
Если вы новичок в этой игре, то, возможно, вы не в том положении, чтобы отказываться от интервью – рассматривайте это как опыт. Пройдите через него, получите навыки, узнайте как можно больше, и если работа вас разочарует, просто двигайтесь дальше. По мере продвижения вперед ваша уверенность будет расти вместе со знаниями и опытом. В конце концов компания получает выгоду от вас, поэтому вы должны в равной степени получать выгоду от компании.
Если вы думаете, что вы достойный работодатель, и не можете понять, почему отличные кандидаты продолжают уходить, стоит в срочном порядке пересмотреть практику найма.
Статьи
Конвергентное образование: как применять новый подход на обычных уроках
Конвергентный подход вызывает большое количество вопросов. Что это? Почему междисциплинарность стала важна сейчас? Как привнести конвергенцию в обычный урок?
Чтобы лучше понять важность междисциплинарного подхода, нужно начать от развития научного знания. В мере развития науки и техники постоянно сменяются два противоположных процесса: интеграция и дифференциация. Дифференциация возникает, когда появляются новые области знания, которые нужно исследовать, а интеграция – когда возникает необходимость обобщить и надежно обосновать знания, добытые в узких областях.
Это нормальный процесс для научного знания. Так, например, интеграция наук проходилась в эпоху Возрождения, а за ней в XVII – XX веках последовала масштабная научная дифференциация. Сейчас снова начался процесс интеграции научных теорий и подходов в самых разных областях, ученые хотят разработать единую теорию поля – теорию, которая смогла бы объединить все фундаментальные взаимодействия на физико-математическом уровне.
Процесс интеграции и дифференциации научного знания
Таким образом, конвергентность или междисциплинарность – это отражение процесса объединения научных знаний и интегративного характера современного научного знания. И школа должна обучать именно этому новому научному знанию, однако важной составляющей конвергентного подхода является неразрывность предмета и способов его подачи: описывать природный мир «как он есть сам по себе», вне учета его восприятий людьми, почти невозможно. Научные знания обретают смысл, преломляясь в сознании личности конкретного человека.
Однако применить междисциплинарный подход в школе сложно в том числе и из-за дифференцированного подхода к освоению учебных предметов: выигрывая в узких знаниях одной науки, мы можем проигрывать в создании целостной картины мира у обучающихся.
Валентина Смелова, кандидат педагогических наук, доцент кафедры педагогических технологий непрерывного образования, основываясь на собственных научных разработках и многолетнем педагогическом опыте предложила схему междисциплинарного подхода, которая может помочь учителю сделать уроки более конвергентными, не изменяя при этом фундаментальных основ преподавания и методики:
Система конвергентного подхода в образовании
Междсциплинарный подход включает в себя самостоятельные, но взаимосвязанные модули:
Междпредметные связи — наиболее разработанная в педагогической теории и практике методическая область. Например, это рассмотрение одного явления с точек зрения разных наук: функционирование гормонов в теле человека с точки зрения и биологии, и химии.
Межпредметная интеграция – это создание целостных учебных дисциплин, в которых будет отражены системы фундаментальных закономерностей развития науки. Так, во время занятий с детьми в Центре проектного творчества «Старт-Про» были проведены уроки, сочетающие в себе и взгляд на предметы искусства, и биологию: «Сытый голодному не товарищ. Изобразительное искусство на уроках биологии», «Свет бел, да люди черны: Птицы в картинах В. Васнецова», «Все боятся пауков больше всех на свете! Коррекция эмоционального фона на уроках биологии».
Конвергенция в образовании – это построение целостных учебных дисциплин, в которых интегрируются научные знания и технологические достижения на основе фундаментальных закономерностей развития естественных наук и NBIC-технологий (нанотехнологий, биотехнологии, информационных и когнитивных технологий) и в которых будут отображаться взаимопроникновения наук и технологий в ходе прогрессивного развития человечества.
Теперь сделать собственные уроки более междисциплинарными стало проще. А если хотите стать настоящим профи в конвергентном образовании, то у нас есть курсы, которые будут полезны:
Live coding на собеседованиях: разбираем плюсы и минусы
Иногда от желаемого оффера отделяет только… live coding. В одних компаниях кандидатов могут попросить написать немудреный кусок кода в реальном времени ещё до технического собеседования. В других позовут на live coding этап уже после всех туров интервью, чтобы 100% быть уверенным в выбранном кандидате. В любом случае, быть готовым к такому формату общения с нанимателем – значит повысить свои шансы на оффер.
Как часто «живое программирование» используется при поиске разработчиков, как устроено «собеседование в прямом эфире» и реально ли к нему успешно подготовиться? Задали вопросы Group Manager Виктории Балакшиной и Department Manager Дмитрию Кремезу.
Дмитрий Кремез
Department Manager iTechArt
Department Manager iTechArt c 2020 года. Применяет live coding на собеседованиях с 2017 года. Называет такой формат собеседований «более лояльным к кандидату»
Виктория Балакшина
Group Manager iTechArt
Group Manager iTechArt с 2017 года. Практикует live coding собеседования с 2018 года. Считает live coding одним из «наиболее органичных вариантов собеседования»
Как часто и для какого уровня соискателей в вашей команде предлагается пройти live coding?
ДМИТРИЙ КРЕМЕЗ: Я стараюсь применять live coding в виде одной несложной задачки для всех уровней от Junior до Senior/Lead. Практическое решение задачи показывает, как человек мыслит, как принимает задание, какие уточняющие вопросы задает, какие предлагает идеи.
ВИКТОРИЯ БАЛАКШИНА: На мой взгляд, это лучше всего работает для разработчиков уровня Middle и выше, хотя Junior разработчиков тоже просим решить практическое задание. При этом есть определенная разница в заданиях для начинающих разработчиков и для тех, у кого уже есть опыт. В первом случае оцениваются знания синтаксиса языка, ООП, умение писать структурированный код. Во втором случае предлагаются уже более комплексные задания для оценки компетенций в тех технологиях, с которыми кандидат ранее работал.
Сколько длится такое собеседование? Как много специалистов при этом присутствует и в каком формате соискатель получает обратную связь?
ДМИТРИЙ КРЕМЕЗ: Длится live coding часть в среднем 15-30 минут. Обычно это несложная задачка, которую можно решить за 5-10 минут, но мы даем запас времени, если кандидат пойдет не по правильному пути, плюс время на общение и обсуждение. Присутствуют все те же люди, что были на интервью до этого: технический специалист, руководитель, рекрутер. Звонок проходит в Skype, в качестве площадки для live coding я использую https://codeinterview.io/, там же кандидат и получает обратную связь.
ВИКТОРИЯ БАЛАКШИНА: Длительность live coding этапа зависит от задачи и соискателя, минимально 20 минут, максимально доходило до 50.
Такая длительность обусловлена тем, что во время решения задачи мы задаем достаточно много вопросов по теоретической части: одно дело писать код, а другое – понимать, как именно отрабатывают механизмы технологии под капотом. При этом, если у человека что-то не получается, мы всё равно помогаем решать задачу. Важно продвинуть кандидата дальше в решении, чтобы подвести ход собеседования к определенному скоупу вопросов.
Обычно на собеседовании помимо рекрутера присутствует технический специалист и будущий руководитель. В основном вопросы задаёт технический специалист, но я тоже часто включаюсь с уточняющими вопросами. Более того, по некоторым технологическим направлениям могу проводить собеседования и сама 🙂
После собеседования стараемся всегда давать развернутую обратную связь. Иногда предоставляем её и в формате рекомендаций со ссылками на полезные ресурсы.
В каких случаях live coding – единственный верный способ проверки компетенций, а для каких специальностей такой формат не подходит?
ДМИТРИЙ КРЕМЕЗ: Любая проверка знаний должна быть комплексной, невозможно оценить кандидата только одним способом. Мы не придумываем тут что-то сверхъестественное, используем те же методики и способы, что используются на западе нашими клиентами и другими компаниями.
ВИКТОРИЯ БАЛАКШИНА: Live coding – не единственный возможный вариант проверки технического уровня. Но по мне, это просто более органичный вариант собеседования, потому что другой вариант – просто сухой разговор о технических вещах на уровне определений или про узкие/воображаемые кейсы.
Некоторая часть разработчиков считает тестовые задания и live coding архаизмом. Как часто приходится бороться с возражениями от кандидатов на счёт этапа с live coding?
ДМИТРИЙ КРЕМЕЗ: Ни разу не сталкивался с полным непринятием. Порой были некоторые отрицания и нежелание напрягаться и решать задачу, обычно из-за того, что кандидат не хотел вникать. После тактичного рассказа, для чего нам это нужно и что мы этим проверяем, кандидаты соглашаются с аргументами и приступают к решению, и это были единичные случаи.
Был обратный случай: за время интервью не смогли полностью определиться и изучить кандидата. Решили дать задание на дом, где-то 4 часа кодинга. Кандидат отказался, сказав, что не берет и не решает задания такого объема. Для нас это был индикатор, что человек не сильно стремиться в нашу компанию. С другой стороны, я понимаю человека, 4 часа работы – это довольно много личного времени. Поэтому я считаю проверку через live coding более лояльной к кандидату + повторюсь, мы понимаем, что live coding – это стресс, поэтому даем не сложное задание и стараемся всячески помочь и направить кандидата по верному пути решения.
ВИКТОРИЯ БАЛАКШИНА: Тестовые задания и правда могут быть избыточными, так как зачастую требуют от 4х до 8ми часов времени. С учетом того, что кандидаты на момент поиска работы зачастую трудоустроены, то эти 4-8 часов будут распределены или на вечернее время, или на выходные. По этой причине стараюсь их избегать. А вот live coding как часть интервью не требует от кандидатов дополнительных временных затрат.
Отказы от live coding получаем редко. Как правило, такое случается, если кандидат попросту не имеет технической возможности писать код в момент собеседования (проходит интервью с телефона/планшета).
Кстати, по моему опыту, люди чаще отказываются от собеседования на английском, чем от кодирования 🙂
Как кандидату подготовиться к такого рода собеседованию? На что обратить особое внимание?
ДМИТРИЙ КРЕМЕЗ: Сегодня есть много ресурсов где можно готовиться к live coding интервью, из популярных: http://leetcode.com/, https://www.hackerrank.com/, https://www.codewars.com/. Не думаю, что стоит уделять этим ресурсам много времени.
Обратить внимание нужно на другое: не стесняться задавать вопросы, делать ошибки, общаться и стараться найти решение. Интервьюеры сами заинтересованы помочь кандидату решить задачу, поэтому не стоит относиться к live coding как к тесту, проверке. Это скорее возможность поработать над задачей вместе с людьми, с которыми вам в будущем предстоит работать. Воспринимайте это как pair programming.
ВИКТОРИЯ БАЛАКШИНА: Прежде всего, подготовить техническую возможность кодить. С учетом наличия таких ресурсов, как codeshare, будет достаточно иметь монитор и клавиатуру.
В остальном подготовка к собеседованию с этапом live coding не должна отличаться от подготовки к обычному собеседованию. Причина в том, что в качестве задач подбираем такие проблемы, с которыми разработчики сталкиваются ежедневно, и избегаем алгоритмические, олимпиадные задачи.
Моя главная рекомендация – в процессе решения задачи рассуждать вслух и задавать уточняющие вопросы. Если человек выслушал условие задачи молча, молча начал писать код и так же молча закончил – в 99% случаев задача будет решена неверно.
И, конечно, важно не нервничать и не ожидать (по крайней мере, в нашей компании) каких-то подвохов. По крайней мере мы со своей стороны стараемся создать спокойную и партнерскую атмосферу во время решения задач.
Смотри наши IT-вакансии в Минске и других городах, выбирай и откликайся!