Эволюций взглядов на образование в IT

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

• (долгие годы борьбы) Есть профессия и наука называющаяся Computer Science, только профессионалы пишут правильные программы

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

• (коммерческий чёс, последние лет 15) "Войти в IT" (я вот не помню у, IT спрашивали - хочет ли индустрия, чтобы в нее входили таким образом). -- образование не нужно, главное способность пройти интервью, есть куча курсов где этому учат. Любить компьютеры стыдно, надо любить деньги, спорт, путешествия.

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

Лично мне больше всего нравился этап №3, но не то чтобы у меня кто-то спрашивал совета.

Когда-то давно, авто тесты, разного рода сканеры и и такие процедуры как pull request review придумали для того чтобы ускорить процесс разработки в целом и особенно усколрить и упростить процесс выкатывания новых релизов.

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

Где мы свернули не туда?

Смог сформулировать достаточно давнее наблюдение. Рисование диаграм не всем дается. На самом деле нарисовать четкую и понятную диаграмму не так просто даже для простых случаев "Вот эти два сервиса обмениваются данными через RabbitMQ".

Наиболее распространенные ошибки

1. Раскрашиваем в цвета и добавляем финтифлюшки там где это не требуется. Да цвет может помочь в понимании, но лишняя раскраска и иконки может сбивать с толку.

2. Рисуем много лишних деталей. Два сервиса обмениваются сообщениями через RabbitMQ, давайте нарисуем еще VPC, availability zone вокруг этого и еще кучу разных шутк, которые там конечно присутствуют, но к делу не имеют отношения. Каждая диаграмма должна иллюстрировать строго тот аспект для которого она предназначена, что плавно подводит нас к третьему пункту.

3. Диаграмма это история которую один инженер рассказывает другим инженерам. История рассказывается с определенной целью, она должна донести message. Если это про то как данные идут от пользователя к сервисам через RabbitMQ, то эта история должна четко читаться с диаграммы.

NB: Не спрашивайте почему RabbitMQ а не SQS - так история сложилась.

Второй вариант еще не самое худшее, что может быть, тут по крайней мере пункт 3 - история более или менее присутсутвует.

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

Обычно сценарий выглядит так. Давайте мы вместо того чтобы тестировать end-2-end сделаем мок сервиса и относительно него будем разрабатывать и тестировать. Причин делать так может быть много и часто без моков вооще никуда. Например у сервиса относительно которого мы работает в принципе нет тестовой среды и доступен только прод. Или есть, но все работает очень медленно и нестабильно и только под ВПН заказчика и только с фиксированого IP

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

Еще раз это понятная проблема и в общем понятно как с ней бороться. Беда начинается когда команды принимают один замоканный ответ за эталон поведения сервиса.

Короче когда слышу на звонках слово мок у меня глаз начинает дергаться.

Недавно заходил пить чай к коллеге IT-шнику из другой компании. Зашла речь о струкртуре рынка труда в IT. Коллега неожиданно в обсуждении сказал "Но ведь 99% всего программирования это сайты для продажи чего-то, а их легко автоматизировать, так что много программистов не нужно ... далее как водится речь пошла о ChatGPT"

Это напомнило мне разговор в начале 2000-х где другой коллега рассказывал мне что Delphi это вообще игрушка, на Delphi никто не пишет и все программы написаны на C++. Аргумент был такой - ну посмотри, вот из того что у тебя установленно на компьютере, все написано на С++. Я к тому времени уже успел посмотреть на внутреннее устройство IT нескольких крупных предприятий и звучало аргумент несколько смешно.

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

"Плагины к Вордпрессу, вот где деньги! Я уже 2 года в IT все в совершенстве изучил и у меня есть плагин за 10 баксов который даже покупают, это дает мне пассивный доход и скоро я стану миллионером"(С) реальный персонаж.

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

Надо разработать класс который запоминает текстовые заметки к точкам на карте. Одна точка - одна заметка. Карта дискретная, 10,000 на 10,000 точек. Заметок всего ожидается несколько дюжин, максимум 100-200 штук.

Класс должен имплементировать следующий интерфейс

public interface MapService {

    void addLabel(int x, int y, String label);

    String fetchLabel(int x, int y);

}

addLabel - сохраняет заметку для точки на карте, перетирая предыдущую если она есть

fetchLabel - возвращает заметку для точки на карте, если заметки нет, возвращает null

Вопрос - какую структуру данных в памяти следует использовать для хранения данных

Уточнение которое надо задать после ответа на первый вопрос. Требования дополнились и теперь надо имплементировать еще один метод

List<String> fetchAllLabelsSorted();

Метод возвращает все заметки какие есть в порядке их близости к центру координат - точке (0,0)

Бонус: В плюс идет если кандидат спросит по какой метрике считать близость к центру.

Вопросы к собеседованию (#1)

Вопрос про реляционным БД. Уровень - продвинутый. Однозначно верного ответа на вопрос по ходу дела нет, но интересен ход мысли интервьюируемого.

Дано: трех звенная архитектура - клиент, load balancer, несколько stateless серверов, реляционная БД (пусть будет postgres, но критично)

В БД есть таблицы school и subject

У subject поле school_id может быть null - это значит, что предмет относится ко всем школам ассоциации школ. Если school_id не null значит предмет специфичен только для этой школы.

Надо реализовать ограничение:

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

Например:

1. У школы id:42 есть предмет "математика викингов" - нельзя создавать еще один предмет "математика викингов" для этой же школы. Но другие школы такой предмет создавать могут

2. Есть предмет "геометрия" у которого school_id is null. Т.е. предмет относится ко всем школам. В таком случае нельзя создать еще один предмет "геометрия" ни в ассоциации, ни в одной из школ. Это имя полностью уникально.

Вопрос: Как собственно такое ограничение реализовать. Какие есть возможные варианты.

Бонус: В плюс идет вопрос кандидата - "что делать если у школы есть предмет геометрия и теперь такой предмет надо сделать на уровне ассоциации".