Live coding в українських ІТ-компаніях. Коли й навіщо використовувати підхід

Live coding, або ж on-the-fly programming, just in time programming, conversational programming — підхід, коли один розробник пише код, а інші спостерігають за цим у режимі реального часу.

Ми запитали в ІТ-компаній, чи використовують вони live coding у роботі, коли саме й навіщо. Крім того, з’ясували, які переваги та недоліки підходу виділяють ІТ-спеціалісти. Цікаво, що live coding під час співбесіди економить час, а під час навчання, навпаки, вимагає багато часу. Також айтішники зазначають, що практика може виявитись стресовою для кандидатів під час співбесіди.

Отже, розберімось, які задачі допоможе розв’язати лайв-кодинг.

Денис Яковенко, CEO & Co-Founder у FasterThanLight

Компанію заснували два розробники, що встигли побувати по обидва боки барикад на співбесідах. Саме тому live coding як один з етапів рекрутингу з’явився в компанії з самого початку. Процес налаштовано так: рекрутер призначає онлайн-зустріч, від кандидата потрібна година часу, тихе місце, стабільний інтернет і зацікавленість у вакансії. З боку компанії — два технічних спеціалісти та підготовлена заздалегідь задача (максимально наближена до тих, що розв’язують на реальних проєктах, попередньо вирішена та обговорена розробниками компанії). При цьому ми дозволяємо користуватися будь-якими джерелами інформації.

Мета live coding — зрозуміти логіку кандидата, подивитись, як він буде розв’язувати задачу, які методи та підходи використовуватиме. Не завжди людина знаходить повне рішення, але навіть у такому разі ми бачимо рівень знань, зазвичай цього достатньо, щоб вирішити, чи пропонувати офер.

Основна перевага і причина використання live coding — незначні часові витрати, потрібна всього година. Також це змога побачити фахівця за роботою (чи гуглить і що саме, чи використовує hot keys, чи ставить питання і які), прокоментувати та обговорити його рішення. Якщо говорити про тестове завдання, то на це йде більше часу: щоб його створити, кандидату — виконати, розробнику — перевірити. Крім того, невідомо, чи людина сама виконувала тестове, чи хтось їй допомагав.

Проте в live coding є і недоліки. Ця практика може бути стресовою для кандидата, у нього може бути не готовий сетап (не працює мікрофон, не має IDE, бо взяв ноутбук брата, з технічних причин не шериться екран), або ж він може бути втомленим саме в цей момент і кодити добре не вийде.

Владислав Клименко, Front-end Engineer в BetterMe

Сейчас при найме разработчиков в Web-команду мы пробуем формат без тестовых заданий, ведь у кандидатов не всегда есть время на них, а достойных легко упустить. Процесс найма инженера в BetterMe состоит из скрининга, собеседования, bar raising и тестового дня в команде.

На собеседовании мы больше общаемся, чем кодим. Конечно, даем несколько технических задач для оценки мышления, но не уделяем этому слишком много внимания. Ведь часто они нерелевантны будущей рутине. Ключевой этап — тестовый день. Десяти техническим задачам мы предпочтем пару часов лайв-кодинга на живом проекте.

Как проходит тестовый день? Один из специалистов рассказывает о проекте и процессах в команде, берет задачу из спринта и работает над ней вместе с кандидатом. У нас нет закрепленных разработчиков, которые проводят тестовые дни на регулярной основе, обычно мы выбираем накануне одного человека, у которого в спринте есть подходящая задача (можно быстро погрузиться) и время.

Сразу видно, как человек чувствует себя в нашем темпе, как быстро включается в контекст. Мы понимаем, насколько комфортно нам работать с кандидатом и наоборот: он знакомится с командой, архитектурой проекта, особенностями будущей работы. Некоторые кандидаты сами настаивают на этом этапе. Так что такая практика хорошо себя зарекомендовала.

Также мы получаем положительный фидбэк, специалисты отмечают, что наши интервью не похожи на интервью с другими компаниями, так как есть возможность обсудить подходы, побрейнштормить и вести дискуссию.

Богдан Серенков, Engineering Manager в Provectus

Live coding в Provectus — это парное программирование и обучение. На проекте, который я менеджу, у джунов периодически возникают затруднения при работе с платформой: местами они могут сталкиваться с легаси, кодом, не покрытым тестами и так далее. Соответственно, в этом всём нужно разбираться, и не всегда разработчик уровня Junior или Middle способен справиться с задачей с ходу. Таким образом, необходимо дополнительное обучение.

Создавать формальный курс под специфические задачи проекта и для небольшого количества людей нецелесообразно. И тут на помощь приходит парное/групповое программирование (оно же live coding), когда более опытный с точки зрения проекта или общей технической экспертизы разработчик делится подходами и наработками. Вместе начинающий и опытный специалисты могут написать несколько строчек кода, обсудить альтернативные варианты и в целом понять образ мышления друг друга.

Регулярную практику live coding в Provectus ввели около трех лет назад. Мы обратили внимание на то, что передачу опыта иногда приходится искать в кухонных разговорах. Как тимлид, я понимал, что многим некомфортно искать нужные ответы именно так и они предпочтут «закопаться», чем спрашивать. Так появилась идея проработать эти технические моменты, а заодно раскрепостить сотрудников и по фану совместно порешать задачки. И мы ввели практику live coding.

Для этого мы в последнее время используем новый инструмент совместного программирования , который доступен прямо из PHPStorm. Процесс очень прост. Сотрудники, заинтересованные в решении определенного класса задач (скорее всего, это нечто узконаправленное, а не общетехническое из разряда «как написать свой первый юнит-тест»), присоединяются к live coding. Зачастую это прикладная задача или особенности прикладных подходов на проекте, разобрать которые лучше с человеком с опытом. При этом менторство происходит органично и параллельно с решением текущих задач. Что более важно, ребятам не скучно во время live coding. Ведь мы решаем реальные задачи, а не просто разбираем теорию.

Среди недостатков live coding — на него необходимо время. А это может привести к дефициту времени у менторов, так что важно все организовать таким образом, чтобы наставник минимально отвлекался от решения актуальных задач и не было bottleneck на проекте. Чтобы этого избежать, лайв-кодинг планируется немного заранее, как правило, сразу до/после обеда или начала/окончания рабочего дня. Иными словами, эта активность проходит в пределах рабочего дня, но вместе с каким-то другим перерывом, дабы не дергать ментора лишний раз.

Также парное программирование хоть и основано на практике, но не имеет смысла без параллельного системного обучения базовым техническим вещам. И это, конечно, ответственность обучающегося.

Но и результаты от live coding вполне очевидные. За 2–3 года джуны в нашей команде, которые это регулярно практикуют, выросли до уровня уверенных мидлов.

Артем Савенков, Front-end Team Lead в HYS Enterprise

Мне кажется, что live coding как этап интервью наиболее эффективный и красноречивый. В коде видно стиль, уровень и скорость мышления, находчивость, даже софт скилы кандидата. Все-таки программисты — это в первую очередь интеллектуалы, которых не должно бросать в дрожь от написания кода. Live coding экономит время с обеих сторон, а оценивает навыки не хуже тестовых заданий.

Под каждый уровень специалиста мы готовим задачу (алгоритм). Размещаем на live coding сервисе (пробовали Codeinterview, CodePen, или же простое «расшарить экран») и отправляем кандидату. Даем 15–20 минут на выполнение.

Перед тем как давать алгоритм специалисту, я либо сам его решаю, либо прошу своих коллег по команде. Они дают фидбэк по сложности и времени. В спокойной обстановке эти алгоритмы решаются сравнительно быстро, до 5 минут. Остальное время дается с учетом того, что кандидат может чувствовать себя не очень комфортно, что-то нужно будет обсудить, поискать и так далее. В целом 20 минут — это максимум, которого достаточно для того, чтобы понять, может человек решить задачу или нет.

В конце мы просим оценить time-complexity собственного решения, предложить варианты оптимизации. Рассказать, почему код не сработал или что нужно было бы дописать. Опытный интервьюер не только оценит итоговое решение, но и проанализирует, как кандидат шел к нему: внимание к деталям задачи, какие вопросы задавал, гуглил ли что-то. Ведь специалист — это не только про код, но и про способность эффективно выполнить задание, изыскав все недостающие части.

Если говорить о недостатках, то live coding — это определенный уровень стресса. Встречаются кандидаты, которые очень тревожатся. За этой тревогой или неуверенностью мы можем пропустить специалиста, который в спокойной обстановке или при достаточном количестве времени горы свернет. Но таких меньшинство. Задача интервьюера — в первые минуты почувствовать человека, наладить коммуникацию так, чтобы он чувствовал себя комфортно, не боялся задавать вопросы. Кому-то нужно что-то подсказать, с кем-то пошутить.

Главный плюс — эффективность. Это быстро, понятно и недорого (обеим сторонам).

Дмитрий Мустафин, Java Team Lead в HYS Enterprise

Необходимость введения live coding частично была обусловлена удаленной работой. Если раньше кандидаты приходили на собеседование в офис и писали код, грубо говоря, на бумажке, то теперь они просто делают это онлайн. На самом деле, это важный процесс, он помогает познакомиться со стилем специалиста, посмотреть на то, как он мыслит. Написание кода занимает практически 50% времени от всего собеседования.

Я считаю, что основной минус в том, что это все же не живое общение. Да и присутствуют все недостатки удаленной связи: помехи, сбои и так далее.

Из плюсов — все преимущества удаленной связи. Например, то, что и кандидаты, и интервьюеры находятся в удобной и спокойной обстановке.

Олександр Кулик, iOS Team Lead в Uptech

Live coding став невіддільною частиною рекрутингу кандидатів у нашій компанії з 2018 року. Так ми хотіли додати елементи парного програмування у процес інтерв’ю. Наразі він має вигляд технічного завдання, яке ми просимо людину виконати разом з нашими розробниками.

Як правило, завдання — це два невеликі проєкти, що містять технічні завдання та юніт-тести для їх перевірки. Кожне завдання розраховано на 90 хвилин парного кодингу. З нашого боку залучено два розробники — по одному на кожне завдання. Вони активно беруть участь в обговоренні розв’язку задач і можуть самі пропонувати рішення, допомагаючи кандидату, якщо той зайшов у глухий кут.

Ми ніколи не даємо монотонних завдань на кшталт реалізації однотипних елементів інтерфейсу застосунку. Вони зазвичай не є цікавими для кандидатів, а тому людина швидко втрачає інтерес до їх вирішення. Натомість більш звичними темами завдань є: запити, пагінація, структура представлення даних. Такі питання тримають увагу всіх учасників лайв-кодингу, а також дають змогу оцінити мислення кандидата та його вміння орієнтуватися в незнайомій ситуації. Сам процес для нас головніший за результат завдання.

Важливо й те, що завдання не мають єдино правильного рішення, тому для більшості з них у нас немає заздалегідь підготовлених розв’язків для розробника-інтерв’юера. Це допомагає побудувати роботу з кандидатом як діалог на рівних.

Переваги:

  • Економія часу: за пів години лайв-кодингу ми дізнаємося про кандидата те, що звичайно перевіряють багатьма етапами інтерв’ю та тестовими завданнями.
  • Нетривіальні завдання, що демонструють логіку та адаптивність мислення кандидата.
  • Особисте спілкування з людиною, де ми бачимо soft skills в дії. Як вона розв’язує проблеми, її ентузіазм і взаємодію з командою. У результаті нам вдається наймати спеціалістів, в компетенції яких ми впевнені.

Недолік назву всього один: це окремий етап рекрутингу, на який потрібно виділяти час розробників. Проте завдання, які ми вирішуємо у цьому форматі, не є суто алгоритмічними, їх не можна розв’язати вивченою формулою з підручника.

Така практика дає змогу сфокусуватися на перевірянні важливих практичних навичок кандидата — вмінні логічно мислити та обдумано ухвалювати проєктні рішення.

Влад Балабаш, Senior JS Developer/Team Lead в AB Soft

В первую очередь я использую live coding в процессе собеседований. На интервью можно попросить кандидата решить задачу на алгоритмы. Например, на поиск пересечения двух массивов. И благодаря live coding проследить, как человек мыслит, какие подходы к решениям задач использует. И на основании этого сделать вывод, какую практическую базу он имеет. К тому же это пример хорошей задачи, потому что она может встретиться кандидату на проекте.

В реальном мире, помимо собеседований, я использую live coding на занятиях в IT-школе, где преподаю Front-еnd. В основном с его помощью я показываю ученикам, как решить ту или иную задачу.

Для меня live coding — это отличный показатель умения решать задания в реальном времени. Но есть и обратная сторона — он занимает много времени.

Максим Федоряка, Software Engineer (iOS) в Innovecs

В Innovecs регулярно проводять live coding-сесії — ведучими виступають експерти компанії, а онлайн-трансляція та запис доступні для всіх охочих на YouTube-каналі. Наприклад, нещодавно в InnoHub (власна локація Innovecs для онлайн- та офлайн-івентів) організували лайв-кодинг-сесію з шести етапів. Мета — навчити учасників створювати власну краудфандингову платформу з нуля і до запуску, використовуючи тільки С#. Раніше проводили сесії, присвячені особливостям SwiftUI та створенню мультиплеєрної гри на Unity без «костилів».

Обираючи тему для лайв-кодингу, в Innovecs передусім орієнтуються на професійні та особисті вподобання спікерів, адже вони точно знають, яка тема наразі найбільш актуальна для ринку та колег, що буде справді цікаво побачити наживо на кодинг-сесії.

Первый шаг лайв-кодинг-сессии — выбор темы, которая будет интересна аудитории. Второй — прописывание тезисов, которые мы обсуждаем и утверждаем с ивент-командой в чате в MS Teams. Для сессий я выбираю небольшой тестовый проект, поэтому чаще всего мне хватает одного вечера, чтобы подготовиться.

В день проведения лайв-кодинга я заранее прихожу в InnoHub, чтобы проверить, все ли работает с технической точки зрения. Удобно, когда организация на высшем уровне и не занимает много времени. На мой Mac установили программу для передачи изображения беспроводным образом — чтобы все выглядело опрятно.

Что касается результатов, то лайв-кодинг-сессии полезны не только аудитории, они приносят пользу и мне, поскольку я глубже понимаю какие-то вещи. Это приятный бонус как для портфолио, так и для меня лично. Провести ивент для 50 человек — это круто. Сессии — это живое общение, где после выступления люди могут задать любые интересующие вопросы.

Для меня главные принципы хорошей сессии — крепкая структура и интересная подача. Мини-история, которую ты рассказываешь в течение часа, должна быть привязана к реальному миру. Скучные кодинг-видео есть в изобилии на YouTube, и чаще всего это монотонное комментирование. Здесь нужен сторителлинг, который вовлечет каждого зрителя.

Стив Джобс когда-то говорил, что многие идут от технологии и пытаются понять, как продать это клиенту. А нужно наоборот — понять, что нужно клиенту, а затем создавать или выбирать технологии. Я по этому принципу иду от проблемы, которую нужно решить, к технологии и ее решению. Я никогда не иду по сценарию «вот есть штука, с ней можно делать вот что». Выбираю проблему, а поверх нее накладываю решение технологией. Причем порой решения может и не быть.

Марія Кот, Recruitment Director в Luxoft Ukraine

Live coding в компанії іноді використовують під час клієнтських або технічних інтерв’ю. Загального правила, як і коли це проводити, у Luxoft немає, керуємося case-by-case підходом, залежно від проєкту, замовника та специфіки посади, на яку претендує кандидат.

Мета — переконатися, що людина знає не тільки теорію, і подивитись, як вона мислить, як на практиці розв’язує задачі та наскільки уважна до деталей.

Завдання зазвичай типові алгоритмічні, з HackerRank або схожих ресурсів, і не займають багато часу. Повне інтерв’ю, що охоплює теорію та практику, триває орієнтовно годину, максимум півтори.

Бувало й таке, що кандидати з кодинг-інтерв’ю не впоралися, хоча й показували до цього хороші результати. Технічні інтерв’юери та клієнти розуміють, що не всі люди можуть писати код у реальному часі, адже будь-яка співбесіда для більшості спеціалістів — це стресова процедура. Тому ми, як правило, даємо кандидату другий шанс.

Попри те, що під час live coding-сесій ми можемо одразу визначити рівень практичних навичок спеціаліста, цей підхід має свою специфіку, зокрема:

  • Певний рівень стресу через обмеження в часі, тому, ймовірно, кандидат може не впоратись із завданням.
  • Це вимагає ретельної підготовки кількох задач, які б враховували специфіку проєкту, технічні аспекти. При цьому кандидат не має писати багато коду.
  • Задачі мають постійно змінюватись і додаватись нові. Найкраще, якщо це програма з помилкою, яку потрібно виправити, або простий функціонал, який треба змінити.
👍НравитсяПонравилось4
В избранноеВ избранном2
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


34 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Всегда давал задачи лайвкодинга на собеседованиях. Мое правило: не напрягать человека, существенно занижать планку сложности, беседовать и поддерживать в процессе.

Сам с удовольствием проходил лайвкодинг, собеседуясь в качестве кандидата. Для меня это интересный вызов, и заодно можно посмотреть, насколько адекватен интервьюер.

Не вижу в этом никакой проблемы вообще, и наоборот, считаю это правилом хорошего тона.

Жалкая пропаганда и попытка в вести «Новую нормальность» для разработчиков с другой стороны качество украинской школы = дно.

так что для джуниор/мидл уровня ещё может быть оправдано.

На одном анонимном форуме фаанговцев есть правило хорошего тона писать статы LC. Посмотрел профили линкедина адвокатов лайв-кодинга. Очень хотелось бы увидеть сколько авторы нагриндили задачек, и с каким аксептансом.

На счет второго варианта, когда кандидат проводит весь день на работе и выполняет задания. Я считаю, что такая практика имеет смыл, при условии , что кандидату будет оплачен этот рабочий день, в независимости от результатов.

Наркоманская статья (похожа на пропаганду), если есть две вакансии ± похожие по смыслу люди пойдут туда, где нет лайв Кодинга, ибо стресовать ни к чему :) достаточно хороших технических, архитектурных вопросов и узнать следует ли человек гайдлайнам по стилю кодинга.

Редакція ДОУ, раз ви написали матеріал про компанії, які охоче використовують live coding, то для повноти картини потрібно розповісти про тих компаніях, які його не використовують і чому.

Проте в live coding є і недоліки. Ця практика може бути стресовою для кандидата, у нього може бути не готовий сетап (не працює мікрофон, не має IDE

Можливо, в цій компанії і використовують IDE, але зазвичай на співбесідах заборонено використовувати IDE, пишеш код в звичайному онлайн-редакторі, іноді просто в Google Docs.

Почему запрещено использовать IDE? Если человек может из предлагаемого списка методов IDE выбрать правильный/нужный , то в чем проблема? Ведь работодателю нужно максимально быстрое и качественное время результата выполненной работы. Сами технологии, того же IDE, приучают не тратить время на топтание клавиш. Голова программиста должна быть сосредоточена на главной общей цели программы/результата. Или нет?

Технічна співбесіда — це як казино) Ти граєш за правилами співрозмовника.
Зазвичай просто говорять — ось вам посилання на онлайн-редактор, пишіть код там, а ми подивимося.

З боку компанії — два технічних спеціалісти та підготовлена заздалегідь задача (максимально наближена до тих, що розв’язують на реальних проєктах, попередньо вирішена та обговорена розробниками компанії)

Скільки я не участвовав в співбесідах, але реальних завдань на live coding не бачив. Як правило це обхід дерева або щось на зразок

auto1.com — сюди більш-менш реальні задачі на лайвкодінгу. В ІДЕ причому

У меня был случай, дал объявление по работе с Microsoft Excel, привел пример своего написанного расчета зарплаты в Microsoft Excel (www.youtube.com/watch?v=n-uNQSmsSAU), на макросах. В реальном банке считали таким файлом зарплату. Там просто, без беременных, больничных и отпусков. И вот я пришел на собеседование, какая-то фирма продавала запчасти и им нужен был человек, который будет строчными функциями Excel менять одни подстроки на другие, или заменять какие-то части подстрок. Я функциями строк не работал, но легко бы освоил их. В результате мне отказали в работе. Вот такие бывают тесты онлайн кодинга.

Если кандидат, в своей программной практике по жизни, не пользовался той же «пузырьковой сортировкой», но в общем помнит что это и о чем, а ему ее задали на таком онлайн-кодинге. Для кандидата, судя по всему, это будет мощный стресс, это равносильно вспомнить-придумать самому такой метод. Или рекурсивный вызов, кандидат избегал таких вызовов в своем программировании, так как это может привести к переполнению стека, поэтому делал так код, чтобы без рекурсивных вызовов. А ему дали такое задание, выполнит ли он его?
То есть, подобные онлайн-кодинги это больше отобрать тех, кто знает и практикует тоже самое, что и те, кто их тестирует. Думаю, что водителю с опытом, проще пояснить новые функции автомобиля, для которого они впервые, и он освоит их, чем искать того, кто это уже знает.

не пользовался той же «пузырьковой сортировкой»
это будет мощный стресс

То може і не потрібен такий кандидат для якого пузирьок буде «мощним стресом»?

рекурсивный вызов, кандидат избегал таких вызовов в своем программировании, так как это может привести к переполнению стека

І натомість робив що — цикл зі стеком? Чи які там техніки економії стека є?

Для меня самый адекватный подход у BetterMe. Действительно, у других компаний не встречала подобного, но мне кажется за день можно составить впечатление как о кандидате, так и о компании.

В первую очередь я использую live coding в процессе собеседований. На интервью можно попросить кандидата решить задачу на алгоритмы. Например, на поиск пересечения двух массивов. И благодаря live coding проследить, как человек мыслит, какие подходы к решениям задач использует. И на основании этого сделать вывод, какую практическую базу он имеет. К тому же это пример хорошей задачи, потому что она может встретиться кандидату на проекте.

Может, я что-то не так понимаю, потому что не дружу с JS, но вроде как это решается библиотечными функциями, судя по беглому исследованию вопроса?.. Зачем в реальных проектах писать велосипед?

не має IDE

То есть, компания не предоставляет онлайн платформу для проведения live coding с заготовленными задачами? Честно говоря, ещё такого не встречал.

чи використовує hot keys

О_О

Не к теме статьи, просто забавная история устройства в Luxoft.

Общаюсь с техническими специалистами (будущими коллегами из команды, куда собеседуюсь), рассказываю, что умею, отвечаю на вопросы.
В какой-то момент меня спрашивают: «А Python хорошо знаешь?»
Я достаю мобильный телефон и говорю: «Сейчас покажу вам мобильное приложение, которое написал на Python»
А они такие: «Аа, так ты этот, извращенец? Отлично, ты нам подходишь»))

Вероятно, это заменило live-coding на питончике)

Зря они так сделали. Я вот периодически пишу на Python. И оно работает. Но показывать внутренности я бы не стал :)

Прямо зараз лайв стрім мого скрінкаста по розробці гри на Флатер: youtu.be/jSqRqTQANCo

Уже записав штук 15, треба і на роботі таке робити

странно что нет упоминания какой скин использует IDE и размер шрифта.

чи використовує hot keys

мне один раз поставили на вид — «не испльзует хоткеи, значит страдает продуктивность». блин вам нужен инженер или мартышка чтобы тексты быстро печатать? не взяли, но я и рад.... с такими запросами наверное там и все остальное не очень хорошо

Я конечно понимаю негодование, впрочем, как и право работодателя хотеть хоть навыки шитья крестиком. Но хоткеи — это же удобно! Эстетику vim/emacs я не разделяю, но тех же хоткеев дублирования/удаления/перемещения строки часто не хватает вне IDE, когда пишешь текст хотя бы вот здесь, например.

Оно удобно пока не начинаются хоткеи из трех а то и четырех клавиш которые хрен запомнишь, если это редкая команда . Но я запомнил как выйти из vi 😂 важный навык для выживания

Но я запомнил как выйти из vi 😂 важный навык для выживания

Я каждый раз гуглю. Но меня в ssh раз в год заносит, впрочем.

смотря какие хоткеи, если вместо ctrl+c и ctrl+v использовать контекстное меню, то это диагноз.

использую IDE от JetBrains, часто используемые хоткеи для меня это:
ctrl+W(+несколько нажатий W выделяет больше): выделить слово, второй раз W — выделить до конца строки, третий раз W — выделить всю строку.
ctrl+Y: удалить строку
ctrl+D: дублировать строку
ctrl+R: find and replace
shift+F6: переименовать функцию/переменную во всему файлу (проекту)
ctrl+shift+Up (down): поменять местами строки с верхней (нижней)
shift+alt+ left(right): переместить курсор на предыдущую (следующую) позицию
double shift: поиск файла по имени
ctrl+shift+F: поиск по файлах в проекте, или по указанной директории

имхо все хоткеи выше очень экономят время

ага вот только на маке все немного по другому — cmd+shift+F поиск в файлах но cmd+alt+O поиск по имени а ctrl+alt+O — оптимизация импортов (одной клавишей ошибся и совсем другой результат да?) /. а когда работаешь на двух системах, иногда проще ткнуть меню чем помнить как сейчас в данный момент вызывается эта команда. был случай когда мне на интервью дали мак и вот там я запутался в клавишных командах

там можно выбрать раскладку хоткеев

В итоге: Это когда на собесе тебя просят что-то типа развернуть бинарное дерево(утрирую, просто задачка с гугла), а потом ты сидишь и фиксаешь баги годами в коде, где вообще никогда не было никаких бинарных деревьев.

Також це змога побачити фахівця за роботою (чи гуглить і

Вау, на лайф-кодинг оказываеться гуглить можно О_о.

Коли я вчився в універі, найскладнішим у нас був екзамен у однієї викладачки, яка дозволяла на ньому користуватися взагалі от всім, чим хочеш — шпаргалками, конспектом, книжками. (Гуглити б теж, напевно, дозволяла б, якби тоді були смартфони і мобільний інтернет :) ). Але ти мав потім усно розповісти всю теорію своїми словами, вирішити задачу і пояснити як ти це зробив, а потім ще відповісти на 150 додаткових питань. Цей екзамен був значно крутіший тих, де викладачі хотіли побачити лише переписаний «по пам’яті» конспект їхніх лекцій.

ну это будет близко очень к «боевым» рабочим задачам, когда в дверь ломится какой-то ОМОН, я согласен.

если это полная имитация рабочей среды, то почему бы нет. на работе ж гуглить не запрещают, вопрос решенный за минуту гугления дешевле обходится чем вымученый из головы за 4 часа. а платят нам по сути за время , так что сферическому заказчику выгоднее если программист нагуглит, чем будет изобретать велосипед

Кстати, гуглить и работать с результатами нагугленного — тоже навык. Было дело даже соревнования по скоростному гуглению проводились (например)

нас в универе учили — работать с источниками информации — главный скилл инженера :-0

Подписаться на комментарии