Я даю тестовые задания

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

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

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

Само собой:

• задание я даю тем кандидатам, которые поленились описать свой опыт в резюме (кем работал — программистом, что делал — программировал)

• техническое задание решается за 10 минут тем кто знает решение, либо за 1 час тем кто не знает но хочет

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

• в результате должна появиться примерно страничка написанного кода на пару методов

И нет, это не олимпиадное программирование с LeetCode, а обычно что‑то из наболевших рабочих вопросов.

Примеры таких тестовых тем:

1. нестандартный валидатор

2. какие индексы поставить на табличке и почему

3. пагинатор на больших таблицах

4. сложный запрос или несколько отдельных

5. интерфейс для классов, делающих то‑то (привет PSR)

6. есть такие данные, нужно найти вот это (привет алгоритмы)

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

Отличия рефакторинга от переписывания

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

Основное отличие от переписывания — внесённые изменения не требуют менять смежные модули, которые не подвергались рефакторингу.

Примерно как ремонт квартиры — после ремонта окна и двери стоят на том же месте, несущие стены и коммуникации не затронуты, а внутри стало приятнее.

И тут же признаки того, что рефакторинг пошёл не по плану:

• Забыли какой‑то ранее работающий функционал.

• Полезли ошибки в других местах.

При правильном планировании и последовательном проведении рефакторинга допустить такие ошибки довольно сложно.

План работ определяет область для изменений и её границы, в результате получаем набор точек (методов), которые останутся неизменными. Это границы изменяемого кода.

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

Таким образом, в каждый момент времени код сохраняет свою работоспособность и не теряет связанности.