Привет! Меня зовут Алексеев Сергей. Я разработчик и тимлид.
Учился в университете на профильной специальности. Работать начал в 2008 году: писал на плюсах в компании Webalta. Потом было много разных компаний и проектов. Разрабатывал на GO, C++, Java, Ruby, Python, PHP. От простых сайтов до искусственного интеллекта для торговых роботов.
Сейчас тружусь в российском IT гиганте. Пишу код, лидирую команду бекенд разработки.
В канале буду делиться своим опытом: в разработке, управлении командой, найме и развитии разработчиков.
Учился в университете на профильной специальности. Работать начал в 2008 году: писал на плюсах в компании Webalta. Потом было много разных компаний и проектов. Разрабатывал на GO, C++, Java, Ruby, Python, PHP. От простых сайтов до искусственного интеллекта для торговых роботов.
Сейчас тружусь в российском IT гиганте. Пишу код, лидирую команду бекенд разработки.
В канале буду делиться своим опытом: в разработке, управлении командой, найме и развитии разработчиков.
Предположим, вы решили пробежать марафон. Хорошая цель, мотивирует. И вот вы стали бегать по утрам каждый день. Прошло две недели и вот вы думаете: марафон - это как-то мелко, вон сколько людей бегает по утрам и сколько финиширует на заветной дистанции на соревнованиях. И в вашу светлую голову закладывается гениальная идея: надо пробежать триатлон!
Вот вы полезли в интернет читать success story людей, которые тренировались долго и упорно, вложили кучу денег и времени в подготовку и удачно выполнили намеченное. И тут вы думаете, а чем я хуже? Утром буду бегать, вечером на велике кататься, а в выходные поплаваю в какой-нибудь речке. Красота! И чего это они все так много времени тратят на подготовку? Лохи. Вы же самый умный.
Ах да, марафон к этому времени вы так и не пробежали. Ведь у вас новая великая цель!
Проходит еще некоторое время и вы натыкаетесь на Iron Man. И вновь блеск в глазах, колени дрожат: «Хочу!!!». И вот вы покупаете самый дорогой велик, кроссовки и прочую форму и выходите на старт, без тренировки конечно, вы же самый умный.
И что? А ничего! В спорте чудес не бывает. Тогда с какой стати такое может сработать в разработке ПО?
PS Посвящается выпускникам IT-курсов
Вот вы полезли в интернет читать success story людей, которые тренировались долго и упорно, вложили кучу денег и времени в подготовку и удачно выполнили намеченное. И тут вы думаете, а чем я хуже? Утром буду бегать, вечером на велике кататься, а в выходные поплаваю в какой-нибудь речке. Красота! И чего это они все так много времени тратят на подготовку? Лохи. Вы же самый умный.
Ах да, марафон к этому времени вы так и не пробежали. Ведь у вас новая великая цель!
Проходит еще некоторое время и вы натыкаетесь на Iron Man. И вновь блеск в глазах, колени дрожат: «Хочу!!!». И вот вы покупаете самый дорогой велик, кроссовки и прочую форму и выходите на старт, без тренировки конечно, вы же самый умный.
И что? А ничего! В спорте чудес не бывает. Тогда с какой стати такое может сработать в разработке ПО?
PS Посвящается выпускникам IT-курсов
👍2👏2
После нас хоть потоп
Под таким лозунгом пишется большая часть программного кода. Работает и ладно. При виде этого кода у другого программиста возникает желание его переписать. Тут главное не поддаться искушению, так как вряд ли у вас хорошее покрытие тестами и переписать код будет очень проблематично.
Так что же делать? Пишите понятный код, без лишней сложности, без супер алгоритмов. Соблюдайте соглашения: будь то стиль кодирования или именования файлов. Чем проще написан код, тем легче в нем разобраться. Забудьте про всевозможные трюки: они может и ускорят вашу программу на 0.001%, но сделают её поддержку неоправданно дорогой.
Под таким лозунгом пишется большая часть программного кода. Работает и ладно. При виде этого кода у другого программиста возникает желание его переписать. Тут главное не поддаться искушению, так как вряд ли у вас хорошее покрытие тестами и переписать код будет очень проблематично.
Так что же делать? Пишите понятный код, без лишней сложности, без супер алгоритмов. Соблюдайте соглашения: будь то стиль кодирования или именования файлов. Чем проще написан код, тем легче в нем разобраться. Забудьте про всевозможные трюки: они может и ускорят вашу программу на 0.001%, но сделают её поддержку неоправданно дорогой.
👍3
В постах #вопрос_на_собес буду рассказывать про вопросы, которые задаю на собеседованиях. Часто бывает, что кандидаты не понимают, почему у них спрашивают то, что кажется никак не связанным с их стеком технологий. Постараюсь раскрыть эту тему хотя бы на тех вопросах, которые сам задаю
Задача курьера
Постановка задачи
Предположим, что вы работаете backend разработчиком и продуктовый менеджер приносит вам следующую задачу.
У нас есть курьер, которому нужно развезти заказы по определённым адресам оптимальным способом. Оптимизируем мы какой-то показатель стоимости перемещения: например, расходы на бензин или время.
Как будете реализовывать такую фичу?
Почему спрашиваю?
Хочу понять, насколько кандидат может оценить применимость абстрактных алгоритмов к реальным задачам. Как реагирует на задачу, кажущуюся алгоритмически сложной.
Что ожидаю услышать?
Отлично: это похоже на известную задачу коммивояжёра, которая NP-полная. И есть библиотеки, которые решают её достаточно хорошо. Но! В нашем случае скорее всего не так много адресов, поэтому можно решить полным перебором, а там N! вариантов маршрутов.
Хорошо: это задача с графами, можно что-то придумать. Например, всегда ходить в ближайшую точку или поискать подходящий алгоритм
Удовлетворительно: а в чём проблема? просто переберём все возможные маршруты
Неуд: не знаю, как такое решать
#вопрос_на_собес
Постановка задачи
Предположим, что вы работаете backend разработчиком и продуктовый менеджер приносит вам следующую задачу.
У нас есть курьер, которому нужно развезти заказы по определённым адресам оптимальным способом. Оптимизируем мы какой-то показатель стоимости перемещения: например, расходы на бензин или время.
Как будете реализовывать такую фичу?
Почему спрашиваю?
Хочу понять, насколько кандидат может оценить применимость абстрактных алгоритмов к реальным задачам. Как реагирует на задачу, кажущуюся алгоритмически сложной.
Что ожидаю услышать?
Хорошо: это задача с графами, можно что-то придумать. Например, всегда ходить в ближайшую точку или поискать подходящий алгоритм
Удовлетворительно: а в чём проблема? просто переберём все возможные маршруты
Неуд: не знаю, как такое решать
#вопрос_на_собес
👍2
Программирование на бумаге
На собеседованиях иногда просят написать код: на бумаге, на доске, в блокноте с минимальной подсветкой. Ни о каких IDE с AI ассистентами речи не идёт. И некоторые кандидаты впадают в жёсткий ступор, некоторые прям отказываются проходить такие этапы. Причин несколько, разберём одну из них - неумение программировать без IDE.
Стремительное развитие IDE привело к тому, что программисты стали хуже программировать. То, что редактор может много чего умного сделать, очень сильно расслабляет: перестаёшь держать контекст в голове, забываешь где и какие переменные / функции определил. Структура кода становится хуже, потому что... а зачем она нужна, если IDE всё подсвечивает и перекинет в нужный участок кода, если понадобится. Страдает читаемость кода, потому что его читает не разработчик, а IDE. Привыкнув полагаться на умный редактор, возникает ситуация, что перестаёшь глубоко понимать код.
Полезная практика - периодически программировать в редакторах, в которых есть только подсветка синтаксиса. Это должно улучшить ваши навыки написания хорошего кода. Вы будете лучше его структурировать, будете думать об именованиях (вам же их в голове держать и набирать без подсказок). Вам придется думать о каждой строчке, о каждом символе. Вы станете лучше понимать синтаксис языка, логику работы программы.
Умение писать код на бумаге - это не просто причуды олдов. Это важная часть вашего профессионального развития. Это то, что выгодно отличает вас от других разработчиков. Поэтому не надо бояться выходить из зоны комфорта - больше практики и это окупится!
На собеседованиях иногда просят написать код: на бумаге, на доске, в блокноте с минимальной подсветкой. Ни о каких IDE с AI ассистентами речи не идёт. И некоторые кандидаты впадают в жёсткий ступор, некоторые прям отказываются проходить такие этапы. Причин несколько, разберём одну из них - неумение программировать без IDE.
Стремительное развитие IDE привело к тому, что программисты стали хуже программировать. То, что редактор может много чего умного сделать, очень сильно расслабляет: перестаёшь держать контекст в голове, забываешь где и какие переменные / функции определил. Структура кода становится хуже, потому что... а зачем она нужна, если IDE всё подсвечивает и перекинет в нужный участок кода, если понадобится. Страдает читаемость кода, потому что его читает не разработчик, а IDE. Привыкнув полагаться на умный редактор, возникает ситуация, что перестаёшь глубоко понимать код.
Полезная практика - периодически программировать в редакторах, в которых есть только подсветка синтаксиса. Это должно улучшить ваши навыки написания хорошего кода. Вы будете лучше его структурировать, будете думать об именованиях (вам же их в голове держать и набирать без подсказок). Вам придется думать о каждой строчке, о каждом символе. Вы станете лучше понимать синтаксис языка, логику работы программы.
Умение писать код на бумаге - это не просто причуды олдов. Это важная часть вашего профессионального развития. Это то, что выгодно отличает вас от других разработчиков. Поэтому не надо бояться выходить из зоны комфорта - больше практики и это окупится!
👍3💯1
Работающий код - это только начало
Написать код, который решает задачу, может любой программист. Накидал 100500 строк в кучу в один файл, запустил - работает. И так сойдет!
Но работающий код - это только начало. Хороший программист должен подумать о том, как этот код будет поддерживаться. Мы гораздо чаще читаем код, чем пишем. А ещё наш код будут читать другие программисты, которые могут быть менее опытными и не погруженными в контекст так хорошо, как мы.
Представьте, что вы разрабатываете сервис, который будет жить не месяц, а несколько лет. За это время много чего поменяется: технологии, нагрузки, требования, а команда разработчиков сменится несколько раз! Если ваш код будет гибким и поддерживаемым, он сможет адаптироваться к этим изменениям. Если нет, то станет техническим долгом, который проще удалить.
Мастерство программирования - это не столько умение решать задачи, сколько способность предвидеть будущее. Писать код, который работает сейчас, — это важно, но писать код, который будет легко изменить завтра, — вот цель, к которой мы должны стремиться.
Любой программист может заставить код работать именно сейчас. Однако совершенно другое дело - создать приложение, которое можно будет легко изменить. Это качество и является показателем мастерства программирования.
Сэнди Метц, Ruby, объектно-ориентированное проектирование
Написать код, который решает задачу, может любой программист. Накидал 100500 строк в кучу в один файл, запустил - работает. И так сойдет!
Но работающий код - это только начало. Хороший программист должен подумать о том, как этот код будет поддерживаться. Мы гораздо чаще читаем код, чем пишем. А ещё наш код будут читать другие программисты, которые могут быть менее опытными и не погруженными в контекст так хорошо, как мы.
Представьте, что вы разрабатываете сервис, который будет жить не месяц, а несколько лет. За это время много чего поменяется: технологии, нагрузки, требования, а команда разработчиков сменится несколько раз! Если ваш код будет гибким и поддерживаемым, он сможет адаптироваться к этим изменениям. Если нет, то станет техническим долгом, который проще удалить.
Мастерство программирования - это не столько умение решать задачи, сколько способность предвидеть будущее. Писать код, который работает сейчас, — это важно, но писать код, который будет легко изменить завтра, — вот цель, к которой мы должны стремиться.
👏1🤔1
Вопрос на собес: тормозит SQL-запрос
Постановка задачи
У вас есть SQL-запрос на чтение из базы данных и время его выполнения стало неоправданно большим. Что будете делать для его ускорения?
Почему спрашиваю?
Хочу понять, какой у кандидата опыт работы с БД, насколько хорошо он понимает устройство баз данных, способы профилирования, оптимизации и масштабирования.
Что ожидаю услышать?
Первым делом, смотрим план выполнения запроса (explain). В нём, например, будет видно, где база делает full scan.
Далее
⁃ Анализируем структуру запроса. Возможно есть подзапросы, которые не нужны. Или выполняются группировки и агрегации, результат которых не используется в бизнес логике. Или запрашиваются все данные, а используются первые N записей
⁃ Проверяем индексы. Довольно часто проблема решается добавлением правильного индекса
⁃ Смотрим на профиль нагрузки: чего больше - чтения или записи? Возможно добавлением индекса только ухудшим ситуацию
Если простые способы не помогли, то можно подумать:
⁃ о разделении запроса на несколько простых
⁃ денормализации данных
⁃ материальном представлении
⁃ масштабировании через шардирование или партиционирование
Случай из практики
Работал с одним легаси проектом на PHP. Одна из страниц веб сервиса жёстко тормозила. Выяснилось, что запрос в базу вытаскивал все данные (все, Карл!), сохранял в массив, а дальше циклом пробегался по нему и выбирал нужный кусок в соответствии с пейджингом
#вопрос_на_собес
Постановка задачи
У вас есть SQL-запрос на чтение из базы данных и время его выполнения стало неоправданно большим. Что будете делать для его ускорения?
Почему спрашиваю?
Хочу понять, какой у кандидата опыт работы с БД, насколько хорошо он понимает устройство баз данных, способы профилирования, оптимизации и масштабирования.
Что ожидаю услышать?
Далее
⁃ Анализируем структуру запроса. Возможно есть подзапросы, которые не нужны. Или выполняются группировки и агрегации, результат которых не используется в бизнес логике. Или запрашиваются все данные, а используются первые N записей
⁃ Проверяем индексы. Довольно часто проблема решается добавлением правильного индекса
⁃ Смотрим на профиль нагрузки: чего больше - чтения или записи? Возможно добавлением индекса только ухудшим ситуацию
Если простые способы не помогли, то можно подумать:
⁃ о разделении запроса на несколько простых
⁃ денормализации данных
⁃ материальном представлении
⁃ масштабировании через шардирование или партиционирование
Случай из практики
Работал с одним легаси проектом на PHP. Одна из страниц веб сервиса жёстко тормозила. Выяснилось, что запрос в базу вытаскивал все данные (все, Карл!), сохранял в массив, а дальше циклом пробегался по нему и выбирал нужный кусок в соответствии с пейджингом
#вопрос_на_собес
👍2🤯1
Совет на собес: не говорите "нет"
На любом этапе собеса не стоит говорить "нет”. Часто вижу, как кандидаты сами себе роют яму, отвечая "нет" на простые вопросы.
Основное правило: избегайте категоричного "нет". Всегда найдется способ ответить положительно и конструктивно, избежать негативной окраски.
У вас есть опыт работы с технологией X?
Напрямую с X не работал, но использовал похожие технологии Y и Z. Изучал X в пет-проектах. Учитывая мой опыт с аналогичными инструментами, уверен, что быстро освою X в боевых проектах.
Работали с большими нагрузками?
В моей практике были проекты с разной спецификой нагрузки. Например, система с небольшим общим трафиком, но большими пиками в определенные моменты. Это научило меня правильно проектировать архитектуру под конкретные задачи.
Готовы работать с legacy-кодом?
Конечно. Legacy есть в любом живом проекте, включая те, над которыми я работал. Это нормальная часть эволюции программного обеспечения. Главное – уметь грамотно его развивать и постепенно улучшать. Плох тот программист, который не хочет переписать свой код спустя некоторое время.
Помните, что собеседование - это не экзамен и допрос, а диалог. Ваша основная задача - понравиться, показать потенциал и готовность развиваться.
На любом этапе собеса не стоит говорить "нет”. Часто вижу, как кандидаты сами себе роют яму, отвечая "нет" на простые вопросы.
Основное правило: избегайте категоричного "нет". Всегда найдется способ ответить положительно и конструктивно, избежать негативной окраски.
У вас есть опыт работы с технологией X?
Напрямую с X не работал, но использовал похожие технологии Y и Z. Изучал X в пет-проектах. Учитывая мой опыт с аналогичными инструментами, уверен, что быстро освою X в боевых проектах.
Работали с большими нагрузками?
В моей практике были проекты с разной спецификой нагрузки. Например, система с небольшим общим трафиком, но большими пиками в определенные моменты. Это научило меня правильно проектировать архитектуру под конкретные задачи.
Готовы работать с legacy-кодом?
Конечно. Legacy есть в любом живом проекте, включая те, над которыми я работал. Это нормальная часть эволюции программного обеспечения. Главное – уметь грамотно его развивать и постепенно улучшать. Плох тот программист, который не хочет переписать свой код спустя некоторое время.
Помните, что собеседование - это не экзамен и допрос, а диалог. Ваша основная задача - понравиться, показать потенциал и готовность развиваться.
👍2✍1🔥1👌1
Как развивать айтишников: практический подход
Развитие разработчиков - это не просто набор активностей для галочки. Это системный процесс, который должен приносить реальную пользу и команде, и бизнесу. Существует много подходов, выделю три, которые применял на практике и уверен в результате.
1. Совместное изучение материалов
- Организуйте регулярные встречи для разбора курсов Стэнфорда, MIT или других топовых вузов (благо такого материала в свободном доступе достаточно)
- Создайте книжный клуб: выбирайте актуальные технические книги, статьи и обсуждайте по главам
Важно: не просто смотреть/читать, а именно разбирать и обсуждать, применять знания к текущим проектам.
2. Хакатоны и соревнования
- Внутренние хакатоны отлично работают для решения реальных проблем, при этом можно вообще не ограничивать стек технологий
- Участие во внешних IT соревнованиях даёт свежий взгляд и новые идеи
Главное: создать естественную мотивацию, без принуждения к участию. Можно придумать плюшки за хорошие результаты
3. Внутренние выступления
- Регулярные технические митапы, где разработчики делятся опытом
- Короткие рассказы на 5-10 минут о новых технологиях или найденных решениях (можно в рамках дейликов или других командных мероприятий)
- Разбор сложных багов или интересных кейсов
Важно: поощрять выступления джунов, это отличный способ прокачать soft skills. От синьоров просить рассказы о сложном простым языком.
Развитие команды - это марафон, а не спринт. Не стоит пытаться внедрить всё и сразу. Начните с малого, получите обратную связь, скорректируйте подход.
А какие мероприятия помогают развиваться вам или вашим коллегам? Поделитесь в комментариях
Развитие разработчиков - это не просто набор активностей для галочки. Это системный процесс, который должен приносить реальную пользу и команде, и бизнесу. Существует много подходов, выделю три, которые применял на практике и уверен в результате.
1. Совместное изучение материалов
- Организуйте регулярные встречи для разбора курсов Стэнфорда, MIT или других топовых вузов (благо такого материала в свободном доступе достаточно)
- Создайте книжный клуб: выбирайте актуальные технические книги, статьи и обсуждайте по главам
Важно: не просто смотреть/читать, а именно разбирать и обсуждать, применять знания к текущим проектам.
2. Хакатоны и соревнования
- Внутренние хакатоны отлично работают для решения реальных проблем, при этом можно вообще не ограничивать стек технологий
- Участие во внешних IT соревнованиях даёт свежий взгляд и новые идеи
Главное: создать естественную мотивацию, без принуждения к участию. Можно придумать плюшки за хорошие результаты
3. Внутренние выступления
- Регулярные технические митапы, где разработчики делятся опытом
- Короткие рассказы на 5-10 минут о новых технологиях или найденных решениях (можно в рамках дейликов или других командных мероприятий)
- Разбор сложных багов или интересных кейсов
Важно: поощрять выступления джунов, это отличный способ прокачать soft skills. От синьоров просить рассказы о сложном простым языком.
Развитие команды - это марафон, а не спринт. Не стоит пытаться внедрить всё и сразу. Начните с малого, получите обратную связь, скорректируйте подход.
А какие мероприятия помогают развиваться вам или вашим коллегам? Поделитесь в комментариях
🔥3👍2👏1
Вопрос на собес: максимальное значение int
Постановка задачи
Просим кандидата рассказать о максимальном значении целочисленного типа данных в конкретном языке программирования. Казалось бы, простой вопрос, но он раскрывает глубину понимания базовых концепций.
Почему спрашиваю?
Этот вопрос помогает выявить несколько важных аспектов:
- Понимание внутреннего устройства типов данных
- Знание ограничений языка программирования
- Умение выполнять простые математические расчёты
- Способность объяснить технические детали
Что ожидаю услышать?
Хороший ответ должен включать следующие моменты:
- Указание на то, что в разных языках это реализовано по-разному
- Для языков с фиксированным размером (C++, Java): максимальное значение для 4 байт = 2^31 - 1 ≈ 2.147 млрд
- Есть языки без ограничений (Ruby, Python)
- Объяснение, почему именно такое число: 4 байта = 32 бита, один бит под знак, остальные под значение
Вопрос со звездочкой
Как программно получить количество цифр в числе?
👍 если ответил на вопрос
Постановка задачи
Просим кандидата рассказать о максимальном значении целочисленного типа данных в конкретном языке программирования. Казалось бы, простой вопрос, но он раскрывает глубину понимания базовых концепций.
Почему спрашиваю?
Этот вопрос помогает выявить несколько важных аспектов:
- Понимание внутреннего устройства типов данных
- Знание ограничений языка программирования
- Умение выполнять простые математические расчёты
- Способность объяснить технические детали
Что ожидаю услышать?
- Указание на то, что в разных языках это реализовано по-разному
- Для языков с фиксированным размером (C++, Java): максимальное значение для 4 байт = 2^31 - 1 ≈ 2.147 млрд
- Есть языки без ограничений (Ruby, Python)
- Объяснение, почему именно такое число: 4 байта = 32 бита, один бит под знак, остальные под значение
Вопрос со звездочкой
Как программно получить количество цифр в числе?
👍 если ответил на вопрос
👍2