Нормально ли накручивать опыт в резюме?
Последние полтора, может два года, с этой темой мощно вошел в индустрию Антон Назаров, вызвав такое бурление, что до сих пор земля дрожит. Правда сам я наблюдал за это со стороны, не участвуя и не особо вникая в то, что происходит на полях ютуба. При этом я давно хотел с ним поболтать и недавно позвал его в подкаст. Запись будет уже скоро, а пока я к ней готовлюсь, то смотрю видео, видео с Антоном, которые мне показались наиболее интересными.

Начинал я это смотреть скорее с нейтральным отношением, потому что накрутка опыта не является чем-то специфическим для его комьюнити. В штатах это давно поставлено на поток, так или иначе все это делалось то тут то там. Да, Антон придал этой теме ускорение, но я рассматриваю его деятельность как производную сложившейся экономической ситуации и подозреваю что дальше будет только больше. Не было бы его, был бы кто-то другой (и они есть, но про это меньше знают и говорят). А в “правильное” устройство мира я не верю, жизнь сложная штука, а наша задача адаптироваться и кто эффективнее и быстрее это делает, тот оказывается дальше.

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

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

При этом такой подход, конечно же, порождает перекосы на местах. Тут не поспоришь. И как бы Антон не говорил в видео “я не призывал их так делать, это их решение”, прилетать будет всегда ему, потому что кто ведет людей, всегда получает за их поступки. Я точно так же могу сказать, что некоторые ребята так много топят за то что я говорю в своих компаниях, что при имени “кирилл” их начинает трясти.

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

p.s. Кстати я тут организовал страничку в vk если вдруг кому интересно можно подписаться там: https://vk.com/orgprog

Тесты до кода без TDD (твиттер-тред)

Я часто пишу тесты до кода, но при этом не работаю по TDD. Почему?

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

Что еще хуже. Фактически TDD, в таком виде, уводит от главной цели тестирования – максимально дешево убедиться в том что код выполняет свою задачу ради которой он вообще пишется. В итоге программист незаметно для себя начинает думать не о пользователях, а внутренних деталях

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

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

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

Из последнего примера. Последние три месяца мы разрабтывали систему приемки документов от студентов, в которой в итоге сотня роутов, 68 моделей и около 50 тысяч строк кода (laravel/php + react/ts). Понимание доменной области приходило в процессе кодинга, поэтому можно сказать что мы двигались немного в слепую, дорабатывая систему по ходу. И я сошел бы с ума делая все это без тестов, так как проект часто менялся, но сама модель нет, скорее происходило расширение и иногда расщепление сущностей. Мы написали около 300 интеграционных тестов, которые выглядят примерно так:

    #[Test]
    public function store(): void
    {
        // TODO: check for new college without templates
        $uploadedFile = UploadedFile::fake()->create('file.txt');
        $attrs = Arr::except(ContractTemplate::factory()->raw(), ['college_id']);
        $body = [
            'college_contract_template' => [
                ...$attrs,
                'uploaded_file' => $uploadedFile,
            ],
        ];

        $response = $this
            ->actingAs($this->owner)
            ->post($this->route('college.admin.contract_templates.store'), $body);

        $response->assertSessionHasNoErrors();
        $response->assertRedirect();

        $template = $this->college->contractTemplates()->latest()->first();
        $this->assertModelExists($template);

        $this->assertFieldsEqual($attrs, $template);

        $this->assertModelExists($template->file);
        Storage::assertExists($template->file->path);
        $this->assertEquals($uploadedFile->name, $template->file->file_name);
    }

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

И вот что по этому поводу сказал Kent Beck (спойлер: мне платят не за тесты) https://gist.github.com/jordelver/3818839

p.s. Какое соотношение тестов к коду в вашем проекте?

Немного отвлеченный пост. Слухи о том что ютуб могут отрубить становятся все громче, поэтому я начал активнее развивать сообщество в VK. Не знаю как оно пойдет дальше, но если вы сидите в вк или рассматриваете его как запасной аэродром, то обязательно подпишитесь https://vk.com/orgprog Помимо прочего, там удобно слушать видео выложенные в виде подкастов. Кстати, по идее, сегодня будет следующий выпуск. Анонсирую когда зарелизим.

И исчо) я решил по полной вкладываться в развитие сообщества программистов, которые хотят дойти до топовых позиций. Контент будет немного смещаться в сторону помощи работающим девам на начальных и мидл позициях вырасти через прокачку продуктового мышления (бизнес + маркетинг + продукт), через технический рост без булшита (учим то что реально помогает и нужно в повседневной работе). По пути возможно появление каких-то воркшопов, курсов и даже консультаций. Поделитесь в комментариях, насколько вам это интересно. Всем чмоки!

Ссылки: Телеграм | Youtube | Подкаст

https://www.youtube.com/watch?v=ImHSnB-uLd4 Второе видео на моем канале, где мы с Мишей Фесенко обсуждаем инжиниринг в букинге. Миллионы строк на перле, тысячи факсов, зарплата, найм, культура devops и многое другое!

Воу, неожиданно сегодня вышел выпуск со мной в мы обречены https://www.youtube.com/watch?v=40QghvScTew

> В первом после долгого перерыва выпуске наши авторитетные эксперты составили для вас список из 10 языков программирования, которые в 2024 году являются самыми высокооплачиваемыми и востребованными на рынке.

Кажется неплохо получилось и самое прикольное что мы все втроем у кого брали интервью говорим разные вещи) Вроде все записи вышли, переключаюсь на свой контент послезавтра!

Совершенный код: отделяем получение данных от их использования

Есть такой код, который я называю "код, который заставляет себя переписывать". Этот код не выглядит плохо и про него нельзя сказать сразу, что он делает что-то плохое. Проблемы проявляются позже — в тот момент, когда нужно внести изменения либо отладить его.
Рассмотрим пример. В проектах Хекслета студенты часто пишут подобный код:

document.getElementById('spinner').classList.add('d-none');

На первый взгляд ничего криминального. Здесь извлекается DOM элемент с идентификатором spinner и затем к нему добавляется новый класс d-none. Теперь представьте, что кроме добавления нового класса, нужно удалить старый. В таком случае код выше часто переписывают следующим образом:

document.getElementById('spinner').classList.add('d-none');
document.getElementById('spinner').classList.remove('d-flex');

Да, не все его так напишут. Но, всё же, как показывает практика, многие просто скопируют строчку и поменяют только последнюю часть. Сразу бросается в глаза, что произошло дублирование. Причём работа с DOM — недешёвая операция. Такое дублирование приводит к замедлению кода, иногда значительному.

Посмотрев на этот код, можно подумать, что это косяк того программиста, что выполнил дублирование. Отчасти это так, но проблема глубже. Исходная строчка была написана так, что она "заставляет" переписывать код при любом повторном обращении. В этом коде выполняется сразу две операции:

• Извлечение данных
• Манипуляция данными

Как правило, первая операция делается ровно один раз, а вот манипуляций может быть много. Причём обычно они появляются не сразу, а накапливаются в процессе жизни кода. Это значит, что код в любом случае придётся переписать.
Поэтому всегда стоит сразу разделять получение данных и их использование:

const spinnerElement = document.getElementById('spinner'); // получение
spinnerElement.classList.add('d-none'); // использование

Не стоит беспокоиться, что кода станет на одну строчку больше. Это тот самый случай, когда "больше — лучше". Во-первых, у выбранных данных появляется имя (переменная). Благодаря именованию сразу понятно, что это такое, с какой сущностью имеем дело. Во-вторых, в этом коде не появилось дополнительной логики. И он легче читается. Ещё один плюс — проще отладка.
Ниже ещё примеры, которые я извлёк из реальных проектов специально для данной статьи.

// Неправильно
const { output } = state.fileTabsInfo.tabs.find(tab => tab.id === 'output').result;

// Правильно
const outputTab = state.fileTabsInfo.tabs.find(tab => tab.id === 'output');
const { output } = outputTab.result;

// Неправильно
const html = document.querySelector('#alertBox').innerHTML;

// Правильно
const alertElement =  document.querySelector('#alertBox'); // получение
const html = alertElement.innerHTML; // использование

// Неправильно
const name = User.find(5).getName();

// Правильно
const user = User.find(5); // получение
const name = user.getName(); // использование

// Неправильно
const newUrl = `${url.parse(address).protocol}//${url.parse(address).host}`;

// Правильно
const urlParts = url.parse(address);
const newUrl = `${urlParts.protocol}//${urlParts.host}`;

p.s. Домашнее задание: поправьте в своем проекте 2 места, разделив получение данных и использование

Ссылки: Телеграм | Youtube | Подкаст

Партнерка Хекслета и Волчья стая

Вчера произошел курьезный случай в канале Антона Назарова, куда он запостил вот такое https://t.me/m0rtymerr_channel/1646 с вопросом, как вы думаете кто это? Мне стало интересно и я пошел посмотреть комментарии. Там начали называть, в том числе, школы и в какой-то момент промелькнул Хекслет. Как интересно подумал я, пока ниже не увидел ответ Антона “это они”. Я аж подпрыгнул на этом моменте. Внутри компании нет людей, которые занимаются подобными механиками продвижения, поэтому я сразу написал в рабочий чат, чтобы узнать что происходит.

В общем совместный ресерч + доп инфа от Антона показали, что это веб-мастер, который зарабатывает на партнерских программах. Наша партнерка добавлена через популярный на рынке https://advcake.com/ где тусует большое количество веб-мастеров, которые, как правило, привлекают трафик через свои сайты, например рейтинги курсов.

Неприятно то, что он в личке Антону представился как сотрудник Хекслета, что конечно же не правда. Но хорошо что, разобрались. Приятно, то что аудитория Антона Хекслет знает и знает про его репутацию, потому что в комментариях это многих удивило. Будте на чеку. Я уверен что этот веб-мастер пошел много куда + он не один такой.

p.s. На следующей неделе выйдет видео с Антоном, которое мы с ним недавно записали. Подпишитесь на ютуб https://www.youtube.com/@mokevnin/featured чтобы не пропустить ;)

Ссылки: Телеграм | Youtube | Подкаст

5 советов по проектированию функций, которые значительно улучшат ваш код (твиттер-тред)

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

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

Клавиатура, в свою очередь, состоит из деталей, которые тоже имеют достаточно высокий уровень абстракции: микросхема, мембраны, корпус, индикаторы. Все это на поверхности и достаточно далеко от реально протекающих процессов внутри

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

Из этого вытекает логичное, но, почему-то, редко обсуждаемое правило. На самом верхнем уровне, проектирование кода должно идти от слоев, которые 1) имеют четко выраженную ответственность 2) оперируют только абстракциями более низкого уровня 3) не прыгают через уровни

В самом общем виде эта мысль описана в SOC https://en.wikipedia.org/wiki/Separation_of_concerns… Примерами здесь служат: модель OSI, HTML/CSS, Миксины и многое другое. Это очень близко нашей теме, хотя и не один в один. Плюс хорошая адаптация к коду от Мартина: Принцип Single Level Of Abstraction

Возникает вопрос, а на что конкретно ориентироваться чтобы создавать функции хорошо? И у меня есть ответ. Существует довольно много простых и не очень принципов, которые определяют как лучше проектировать функции. Большая часть из них универсальна и подходит для всех языков

Начнем с самого главного правила в программировании: отделение чистого кода от кода с побочными эффектами или "функциональное ядро и императивная оболочка". Чтобы понять о чем тут идет речь, поговорим о том, что такое чистые функции.

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

Побочные эффекты – влияние функции на внешнее окружение: модификация глобальных переменных, аргументов переданных по ссылке, ввод/вывод (чтение и запись файлов, сеть, консоль и т.п), вызов внутри себя других функций с побочными эффектами

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

Эта логика, сама по себе, не имеет отношения к коду. Она, часто, существует на уровне документов и спецификаций, ее понимают заказчики бизнеса и ради нее, собственно, софт и пишется.

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

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

Другой важный принцип проектирования функций Command-Query Separation (CQS). Он не совсем про слои, но очень в тему. Обычно звучит так: "задавая вопрос, не изменяй ответ". То есть геттеры не должны менять состояние, это противоречит их сути и может ломать детерминированность

Ссылки: Телеграм | Youtube | Подкаст

Как научиться слепой печати на клавиатуре

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

• Хорошая техника позволяет сократить количество ошибок
• С опытом скорость набора текста станет выше
• При необходимости достаточно легко учатся новые алфавиты

Как это работает?

Слепой набор включает в себя несколько важных компонентов:

Постановка рук. Выпирающие полоски на клавишах F и J — это специальные метки, показывающие место для указательных пальцев в состоянии покоя. Постановка рук — это первое с чего начинают практику слепого набора.

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

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

Наиболее эффективный набор в слепом режиме происходит когда пальцы постоянно чередуются. Попробуйте проверить это сами. Наберите слово "папа" указательным пальцем левой руки (эти буквы находятся в его зоне), а затем слово "гага" (указательные пальцы обоих рук).
Большинство раскладок проектировалось с учетом этого фактора, например, раскладка ЙЦУКЕН. А вот QWERTY создавалась слишком давно, когда приходилось учитывать другие факторы (например, залипание клавиш), и это отразилось на эффективности. Поэтому были созданы альтернативные раскладки, такие как DVORAK и Colemak. Вот что написано в Википедии по поводу последней:

• Скорость. Быстрее QWERTY и несколько быстрее Дворака, так как в Colemak разгружены мизинцы и чаще применяется чередование рук.
• Эргономичность. 10 наиболее распространённых букв английского языка и клавиша Backspace расположены на втором (домашнем) ряду клавиатуры. В Colemak домашний ряд используется в среднем на 3 % чаще, чем в раскладке Дворака, и 40 % чаще, чем в QWERTY. Благодаря этому при печати на Colemak пальцам приходится меньше перемещаться, чем при печати на QWERTY.

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

Как научиться?

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

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

Ссылки: Телеграм | Youtube | Подкаст

Чему можно научиться у миграций Rails

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

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

В большинстве фреймворков (в микрофреймворках это не так) этот механизм встроенный, но иногда идет как отдельная часть, как в spring boot.

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

Генерация

Rails это db first фреймворк (как. и большинство), то есть модели работают базируясь на структуре базы данных, а не база данных меняется под структуру как в entity framework или django. Поэтому миграцию нужно генерировать самостоятельно, фреймворк этого не сделает.

Большая часть фреймворков может генерировать модель через cli, но далеко не все позволяют указывать набор полей который нужно сгенерировать:

bin/rails generate model Product name:string description:text category:references

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

Автооткат

Сама миграция не содержит привычных up и down. Внутри нее только один метод change. Rails умеет автоматически откатывать почти все, но работает это если мы используем его dsl для описания миграции, чистый sql не подойдет

class CreateProducts < ActiveRecord::Migration[7.1]
  def change
    create_table :products do |t|
      t.string :name
      t.text :description

      t.timestamps
    end
  end
end

Если нужно всегда можно реализовать up и down отдельно

Схема

Вещь, которую после Rails внедрили многие фреймворки, например, Laravel (но сделано это довольно хреново). После того как накатывается миграция, rails автоматически обновляет файлик со схемой schema.rb. Этот файлик позволяет легко увидеть а чо там в базе без необходимости туда лезть. Он автоматически используется при накатывании проекта с нуля или в старте тестов. Работает это так: сначала грузим схему, затем миграции, которые добавились, но еще не применялись в текущем окружении. Наличие такой схемы позволяет легко удалять миграции, которые уже были накачены в продакшене.

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

Еще больше ништяков можно прочитать в офигенном гайде: https://guides.rubyonrails.org/active_record_migrations.html

Удаление

Помимо генераторов в рельсе реализован механизм удаления сущностей, например если я сделаю bin/rails destroy model Product, то она удалит все связанные сущности включая миграции. Это очень удобно когда идет активное добавление новых сущностей и возникают ошибки в именовании. Использовать этот механизм для моделей можно только если это локальные изменения.

Накат/Откат

Кроме простого накатить и откатить, в rails есть возможность указывать количество шагов отката и даже команда redo, которая перенакатывает нужное количество миграций (мне этого капец как не хватает в других местах).

bin/rails db:rollback STEP=3
bin/rails db:migrate:redo STEP=3

p.s. Поделитесь крутыми фишками миграций в ваших фреймворках

Ссылки: Телеграм | Youtube | Подкаст

Ну вы поняли да? https://www.youtube.com/watch?v=dJXV5Y1Pnc8 На самом деле, я попытался собрать от Антона предложения по тому "а как все же сделать чтобы было хорошо" и у нас получился довольно интересный разговор. Мы даже егэ там перемыли

Увидел ссылку на прекрасный пост 2016 года в жж про то как нанимать, который не могу не опубликовать (пришлось чуть подрихтовать чтобы влезло):

1. Читаем резюме. Вырезал чтобы влезло

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

3. Задаем несколько вопросов как в №2, но по теме данной позиции и копаем вглубь пока лопата не зазвенит. Причем годятся любые вопросы, ответы на которые практически невозможно запомнить всухую. "А вы помните в каком релизе там фундепы внедрили?" Правильный ответ "что-то типа NNN или около того, но потом пришлось обратно всем откатываться, потому что оказывается что фундепы сломали тайпчекер, как оно тесты-то прошло, бгггг". Очень хорошо идут вопросы из резюме кандидата (из №2) но в приложении к технологиям из №3: "а вот вы рассказывали что вы делали ХХХ, а как бы вы сделали тоже самое, но уже с использованием YYY, которое нам нужно?". Тут люди очень часто заводятся и начинают увлеченно "проектировать" ибо чувствуют себя в своей тарелке. Вообще говоря, на этом месте иногда можно и закончить и послать человеку оффер (ну или наоборот), если повезет.

4. Даем тестовое задание. Тестовое задание не должно быть больше 8 часов при требуемом вами уровне квалификации, а лучше меньше. Идеально - 4-5. Если есть возможность - не говорить кандидату на этапе №2 сколько именно вы рассчитываете займет задание. Просто отделайтесь "небольшое" и попросите его на этапе №5 оценить время самому. Я стараюсь иметь бюджет на оплату тестовых заданий и плачу по разумной рыночной ставке, чтобы человеку было не обидно и замечено что люди даже за небольшие деньги гораздо внимательнее относятся к выполнению, включается психологический паттерн "работа". Задание даю так, чтобы его можно было сделать за отведенное время аккуратно, без висящих соплей. Стараюсь давать из существующего проекта, либо что-то новое (поскольку заплачено, то не стыдно и использовать будет) либо уже существующее (зато есть reference implementation и можно отдать на глубокое ревью тому, кто писал оригинал). Задание должно быть вырезано из существующего проекта аккуратно и не требовать экзотического тулинга и строго заданных ОС. Человек будет делать задание из дома, а там у него может не быть рабочего окружения, а просто игровой компутер с виндой. Можно дать доступ на EC2 инстанс, где уже все готовое установлено, а потом его просто убить. Задача должна быть реальная, делать что-то полезное, а не сортировать массив пузырьком, прости господи.

5. Ревью задания с кандидатом. Почему вы сделали так, а не иначе, что бы вы сделали если бы было больше времени, покрытие тестами, точки интеграции в "большой" проект, то есть обычная рабочая рутина. Посмотреть как человек вертится, как и что предлагает, насколько хорошо оценивает риски, и т.д. Желательно конечно убедиться что задание компилируется, работает и делает что обещано 🙂

p.s. https://kika.livejournal.com/152388.html

Ребят, хочу порекомендовать канал https://t.me/MicroservicesQuestions в котором собираются вопросы с собеседований и архитектурные решения связанные с базами данных, распределенными системами и проблемами микросервисных проектов. Рекомендую подписаться если вы готовитесь к собесам или учитесь решать подобные задачи. Из последних тем там:

> Взаимно-рекурсивные внешние ключи
> Каскадное удаление за один запрос
> Caching patterns

Bootstrap подходит только для админок

Хекслет и все его сайд-проекты: cv.hexlet.io, code-basics.com, codebattle.hexlet.io, guides.hexlet.io реализованы с помощью Bootstrap. Причем, в основном, это стандартный бутстрап

Почему мы это делаем?

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

Это особенно важно, учитывая, что для современных it-бизнесов наиболее критичная метрика — time to market, то есть скорость, с которой изменения доставляются до пользователей. Быстрые и частые релизы позволяют не тратить время на ненужные вещи и делать только то, что пользователям нужно по-настоящему.

С плюсами понятно, а что насчет минусов? Ведь сайт выглядит не “круто”.

Как показывает практика, влияние дизайна на успешность продукта нередко переоценивается. Более того, на Хекслете происходит ровно наоборот. Сейчас дизайн более стандартный для Bootstrap, чем был в начале 2018 года (у нас была попытка сделать что-то совсем своё), и мы получаем много положительных отзывов:

> Хороший материал, интересные задачи, приятный интерфейс - мне нравится

Но еще большему числу людей это вообще не важно:

> Перебрал и попроходил множество курсов, детально или пробно. Hexlet наиболее интересен и продуктивен для меня, поскольку дает обучение не языку, а программированию, даже не программированию, а образу компьютерного мышления. Это более значимо и важно как база для дальнейшего движения, по моему мнению.

Наличие контента и его качества решают

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

Проще и быстрее написать свое

Проще ли написать свое? Конечно! Если у вас стоит задача прямо здесь и сейчас заверстать какой-то кусок, который решает конкретную задачу, то намного проще накидать пару-тройку своих классов и радостно перейти к следующей задаче.

Но у любого решения есть своя цена. В первом приближении все выглядит хорошо, но что если глянуть глубже и дальше?

Как только в проекте появляется своя верстка, то все, кто не принимают участие в ее создании, будут вынуждены ждать тех, кто ее пишет. То есть замедляется time to market. Чем больше верстка заточена под конкретные ситуации, тем меньше возможностей для маневра.

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

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

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

Ссылки: Телеграм | Youtube | Подкаст

Где вы сейчас работаете и чем там занимаетесь? (твиттер-тред)

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

Самое страшное когда говорят "начну с самого начала". Началом может оказаться школьные годы и долгий тернистый путь к себе настоящему. Однажды чувак мне сказал "щас я коротко про себя расскажу". Через 30 минут пришлось его останавливать.

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

Часть разработчиков на этот вопрос начинает ответ примерно так: "я пилю микросервис". Как в том недавнем твите что дело ни в чем, дело в самом пилении микросервисов. Ответ понятный, но слишком технический, еще непонятно что за компания и предметная область, но уже пошли детали.

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

Идеальный ответ звучал бы примерно так: "Работаю в компании Хекслет. Это онлайн-школа программирования. Здесь учатся с нуля и повышают квалификацию. Я занимаюсь онлайн-редактором, в котором выполняются практики после уроков и курсов".

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

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

После бизнеса можно переходить к техническим деталям. Что за команда, какую задачу она выполняет и какие технологии использует. Но без фанатизма, рассказывать версии языков и библиотек не надо, а то есть любители. Особенно в джаве. Любое название сопровождается версией)

Кстати бывают ситуации, когда от человека крайне сложно добиться ответа на вопрос, а что же они делают, не с точки зрения кода, а с точки зрения смысла. Что за подсистему они делают, как она связана с остальной частью. Встречается редко, но все же.

Встречаются ответы "да ничем интересным не занимаемся, давайте лучше расскажу про предыдущую работу". Тут не знаю как реагировать, но ответ вызывает вопросы. Почему так получилось? А, вообще, не верю что вот прямо вообще ничего интересного.

Кстати самый, пожалуй, популярный ответ: переписываем на микросервисы. Тема тоже настолько интересная, что заслуживает отдельного треда. Кстати пару историй про микросервисы я рассказывал на недавней конференции techleadconf. Рекомендую к просмотру

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

Ссылки: Телеграм | Youtube | Подкаст

А тем временем вышло видео на ютуб канале: https://www.youtube.com/watch?v=vXrru_QZ31E Обязательно посмотрите, там мы говорим про переход из разработки в менеджмент и сопутствующие проблемы. Разбираем немного Германию и штаты)