На собеседовании я всегда начинаю разговор с вопроса "где вы сейчас работаете и чем там занимаетесь?". Вопрос простой, но при большой выборке скапливается довольно много интересных, смешных и грустных ответов. Ниже я расскажу о всяких забавных ситуациях и об идеальном ответе =>
Самое страшное когда говорят "начну с самого начала". Началом может оказаться школьные годы и долгий тернистый путь к себе настоящему. Однажды чувак мне сказал "щас я коротко про себя расскажу". Через 30 минут пришлось его останавливать
В любом случае, многие рассказывают про весь свой путь чуть ли не с самого первого дня работы программистом. Как собеседующий я бы хотел пропустить эту часть и говорить про текущую работу, так как это съедает кучу времени. Если понадобиться уйти в прошлое, то я задам вопрос.
Часть разработчиков на этот вопрос начинает ответ примерно так: "я пилю микросервис". Как в том недавнем твите что дело ни в чем, дело в самом пилении микросервисов. Ответ понятный, но слишком технический, еще непонятно что за компания и предметная область, но уже пошли детали
Технические детали важны, но потом. Сначала надо понять, а что условия в которых пилится микросервис. Это финтех? фудтех? эдтех? фриланс? И тут внезапно выясняется что часть людей вообще слабо представляет себе где они работают. Для меня это сигнал таск-ориентированности в работе
Идеальный ответ звучал бы примерно так: "Работаю в компании Хекслет. Это онлайн-школа программирования. Здесь учатся с нуля и повышают квалификацию. Я занимаюсь онлайн-редактором, в котором выполняются практики после уроков и курсов".
На этом этапе я могу уйти немного в обсуждение бизнеса, так я могу понять насколько человек понимает предметную область и, в целом, ей интересуется. Важно когда программисты видят связь между тем что они делают и деньгами компании, а так же пользой которую они причиняют
Немалый процент людей на этом вопросе впадает в ступор и начинает сбивчиво говорить какие-то обрывочные вещи сразу отовсюду потом резко останавливаются и говорят "я не понимаю вопрос, можно ли уточнить". Тогда приходится разделять и спрашивать отдельно: "что делает компания?"
После бизнеса можно переходить к техническим деталям. Что за команда, какую задачу она выполняет и какие технологии использует. Но без фанатизма, рассказывать версии языков и библиотек не надо, а то есть любители. Особенно в джаве. Любое название сопровождается версией)
Кстати бывают ситуации, когда от человека крайне сложно добиться ответа на вопрос, а что же они делают, не с точки зрения кода, а с точки зрения смысла. Что за подсистему они делают, как она связана с остальной частью. Встречается редко, но все же.
Встречаются ответы "да ничем интересным не занимаемся, давайте лучше расскажу про предыдущую работу". Тут не знаю как реагировать, но ответ вызывает вопросы. Почему так получилось? А, вообще, не верю что вот прямо вообще ничего интересного.
Кстати самый, пожалуй, популярный ответ: переписываем на микросервисы. Тема тоже настолько интересная, что заслуживает отдельного треда. Кстати пару историй про микросервисы я рассказывал на недавней конференции techleadconf. Рекомендую к просмотру
Еще из шокирующих трендов: микрофронтенды и количество разработчиков на одну страницу. Все больше и больше сервисов, в которых целые команды фронтендеров отвечают за формирование одной двух страниц на сайте. Может это и правильный путь, но я пока еще не привык к такому
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Через час-два тред про функции. Многим кажется, что функции это просто, но нет. Хорошие функции выглядят просто, но реализовать их тяжело. Какими руководствоваться правилами? Об этом и поговорим. #functions
Поехали! Обычно, от функций ожидают сокращения дублирования кода. Да, функции устраняют дублирование, но лишь в дополнение к тому, зачем они нужны. Настоящий смысл функции – повышение уровня абстракции. Звучит немного абстрактно, поэтому раскроем подробнее =>
Мир сложная штука, но эта сложность спрятана за простыми и понятными вещами. Например, работать с клавиатурой может даже ребенок, но лишь потому что она хорошо спроектирована и прячет от нас детали реализации. Нам не нужно знать физических законов для ее использования
Метатред по серии "Автоматное программирование". Рассказываю тут про флаговое программирование, явно выделенное состояние, автоматы на бекенде, автоматы на фронтенде и кидаюсь кучей полезнях #FSM
1. Автоматы как способ моделировать процессы вокруг нас
И так поехали тред про конечные автоматы (fsm, state machines). Одной из ключевых тем в разработке софта касающуюся всех программистов без исключения. Будет много примеров для разных языков. После этого треда вы, вероятно, увидите мир другими глазами. Лайк, шер, алишер, погнали!
Существует заблуждение что автоматы это что-то, из математики, не имеющее отношение к реальной жизни. Их используют в лексическом анализе для написания парсеров. Многие помнят лабы на си, где нужно было разбирать строчку. Да это тоже автоматы, но совсем другие.
Мы же поговорим об автоматах с точки зрения моделирования бизнес-процессов, которые мы программисты по большей части и программируем. Сразу предупрежу, что тема автоматов ну очень глубокая, они бывают совсем разные и к ним нужен разный подход. Поэтому что-то останется за кадром
Про TDD. Я часто пишу тесты до кода, но при этом не работаю по TDD. Почему? Небольшой тред
TDD подразумевает мелкое движение по функциям, которое во многом сфокусировано на внутренних модулях и юнит тестах. Такие тесты быстро приходят в негодность и требуют их постоянного переписывания, что, вообще говоря, мешает разработке, так как нужно постоянно их перерабатывать.
Что еще хуже. Фактически TDD, в таком виде, уводит от главной цели тестирования – максимально дешево убедиться в том что код выполняет свою задачу ради которой он вообще пишется. В итоге программист незаметно для себя начинает думать не о пользователях, а внутренних деталях
Сегодня последний тред из мифов в ООП #oopmyths Поговорим о том, что обычно считают ООП кодом и что влияет на его структуру больше всего. Какие вещи в ООП универсальны сквозь большинство языков. Включайтесь)
Ну и традиционно вопрос. Может ли код быть одновременно объектно-ориентирован и функционален?
Несмотря на любую теорию, на практике, многие программисты если не видят в коде конструкций вида something.do(data), то они не считают код объектно ориентированным. Проверял это много раз. Все это сопровождается философией в стиле "это поведение", а иначе нет.
Начинаем третий про наследование и отношения. Во второй части был опрос про отношения, на который правильно ответило только 29 процентов! И кажется что не все поняли первый тред. #oopmyths
Начнем как обычно с опроса. Вопрос: "Объяснять ООП надо через аналогию с реальным миром". Именно так делается в подавляющем большинстве источников и сервисах типа стековерфлоу.
Строго говоря, отношение частное-общее про типы, а не классы. В статье про сабтайпинг об этом написано внизу: en.wikipedia.org/wiki/Subtyping. И принцип лисков тоже не про классы. Наследование классов это всего лишь способ убрать дублирование кода. Один из худших способов.