Идеальное резюме для разработчика

Я написал статью с советами по резюме для разработчиков на украинском и русском языке. Чтобы вас заинтересовать, там про то, что: ваши увлечения и хобби это лишнее; опыт в прошлом на позиции СТО скорее навредит; не надо писать сколько вы работаете с технологией в годах, и уж тем более выставлять оценки своим знаниями по какой-то шкале.

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

Руководство по работе со мной

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

Ранняя обратная связь. Я ценю раннюю обратную связь и поэтому стремлюсь найти баланс между «зарыться» в проблему и попросить помощи.

Практики. Я не внедряю такие практики как дедлайны, GitFlow, 1-to-1, Agile, Scrum, Kanban, KPI, OKR по всем канонам и правилам. Потому что я понимаю, что не бывает так, что какая-то методология подходит большинству компаний и команд в индустрии. Я разбиваю практику на составляющие, анализирую и пытаюсь понять какую пользу из этого можно извлечь.

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

Не пофигизм. Мне никогда не все равно, я не пройду мимо, если увижу, что что-то не работает либо делается неправильно, либо мое мнение принесет пользу в принятии решения. Обратная сторона: я могу быть «не в тему» (у продукта другие приоритеты) либо кого-то ненароком оскорбить.

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

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

Рефлексия. Я не люблю людей, которые не анализируют свое поведение и принятые решения. Остановившись в развитии, они забирают время и силы не только у себя, но и у других людей. Мне тяжело с ними работать и я могу чувствовать себя демотивированным (когда всем вокруг все равно, твоя работа превращается в борьбу с ветряными мельницами).

Я думаю, составлять такие списки полезно: можно лучше понять самого себя, подготовиться к вопросам про сильные и слабые стороны на собеседованиях, чтобы ответить искренне. Вот примеры других людей, там больше информации, чем у меня, и все разбито на категории: product manager, developer advocate, director of engineering. А здесь примеры вопросов, которые можно себе задать, и ответов на них при составлении таких списков.

Почему кодинг-интервью еще хуже, чем вы думали

Кодинг-интервью — это когда вы решаете задачи на знание алгоритмов и структур данных. В Google это может быть серия из 3-4 интервью по 45 минут, где на каждом из них надо решить 2 задачи. И там настолько строго, что если из двух задач решено ноль, вы провалили весь процесс интервью. И к тому же, вы не можете запускать свой код, и должны проверять логику и тестировать в уме. Там еще проводят интервью на системный дизайн и на поведенческие вопросы, но не об этом речь.

Чтобы подготовиться к кодинг-интервью, нужно:
— Решить ±300 задач (1, 2, 3, 4), из которых ±200 средней сложности, каждая занимает 20-60 минут.
— Выделить на это 2-3 часа каждый день, и целый день в субботу, выпивая кофе или алкоголь, жертвуя сном.
— Уволиться с работы, и не отдыхать, а решать задачи.

Почему кодинг-интервью это плохо:
— Только 1% разработчиков будет решать такие задачи в 1% продуктов. Сами задачи, в свою очередь, будут коррелировать с 1% тех задач, которые они решили в прошлом. Но такие задачи, конечно, есть. Например, приложение по доставке еды — там надо находить ближайшего курьера или ресторан. Но даже если такая задача и будет решаться, то вряд ли самописным алгоритмом, скорее всего каким-нибудь PostGIS. То, что спрашивают на собеседованиях, не относится к будущей работе.
— А как же разработка игр, где важен оптимальный код, там то уж точно надо — спросите вы. Rockstar тоже проводит кодинг-интервью, но им почему-то это не помогло с GTA — отвечу я. И это мало на что повлияло, деньги в Steam за игру уже заплатили. Даже там, где эти знания необходимы, их не применяют, несмотря на сотни решенных задач.
— Компании теряют талантливых разработчиков, которые не знают алгоритмы и структуры данных. Max Hovell'a, создателя Homebrew и PromiseKit, не взяли в Google потому, что он не умеет вращать бинарные деревья. Daniel Buchmueller оказался «недостаточно сeньор» для Netflix, который до этого работал 4 года в Microsoft и 8 лет был фаундером в компании, а потом сделал Amazon Prime Air. Ну, возьми и сделай отдельный процесс для разработчиков, которые уже доказали, что они классные инженеры. Да, чтобы можно было за заслуги и достижения попасть в компанию без кодинг-интервью. Так компания дала бы мотивацию разработчикам делать продукты, которые приносят реальную пользу другим людям. И, следовательно, это сделало бы инженеров, компании, индустрию и мир лучше, чем кодинг-интервью не занимается.

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

Но в той же Украине большинство компаний на рынке работают как аутсорс и аутстафф, где нет кодинг-интервью. В то же время рынок делят и небольшие продуктовые компании с крутыми продуктами типа ЛУН и Grammarly, где кодинг-интервью проводят. То есть, для таких компаний остается меньшинство разработчиков на рынке. Из них потом остается еще меньше, потому что зная алгоритмы и структуры данных, они с большей вероятностью захотят работать в FAANG, а не на локальную компанию. Кодинг-интервью работает для небольших компаний?

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

В сумме кодинг-интервью — это необратимый урон по индустрии и культ процессов вместо результата.

Часто менять работу

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

Лично я не против частой смены работы, но в индустрии такие люди, которые относятся к этому предвзято, есть: рекрутеры, HR-менеджеры, другие разработчики, руководители команд и компаний. И хорошо, если о причинах частой смены работы спросят на интервью, там можно объясниться и это никак не повлияет на карьеру. Но есть вероятность, что не спросят — посмотрят резюме, подумают про себя «бегунок», и выбросят в урну. Потому что для них это признак конфликтности и нестабильности.

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

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

Если вы попали в такую ситуацию, совет — вам обязательно нужно дотянуть свое пребывание в компании до 1 года. 1 год — это оптимальный срок работы в индустрии в одной компании, чтобы вас не считали «бегунком». Таким образом, вы ошиблись с компанией один раз, протянули год, ошиблись еще раз, протянули год, потом сделали хороший выбор и проработали 3 года — резюме в порядке. Пример плохого резюме — полгода, полгода, год, год, полгода, полтора года. Согласитесь, первое резюме чисто визуально выглядит лучше, даже если у разработчика из второго резюме больше достижений.

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

Лайфхаки:
— Для LinkedIn. Если вы пришли на работу 30 апреля, а ушли 1 марта, указав в LinkedIn начало работы — апрель, а конец — март, то фактически проработав 10 месяцев, на LindekIn у вас будет один год (так работает сайт). Эти два месяца могут помочь вам либо скорее покинуть компанию и взять пару месяцев на отдых, либо сразу найти новую работу и посмотреть как там работается. Для консистентности, в резюме вы указываете те же даты, что и на LinkedIn.
— Для резюме. Объединяйте опыт в нескольких компаний на старте карьеры в одну строчку. Например, Software Engineer at Ciklum and Epam • April 2017 — April 2018 (как пример, мое резюме). Это поможет сконцентрировать внимание читателя резюме на ваших достижениях, а не на годах. В LinkedIn так делать не нужно, там указывайте полную информацию.

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

Развитие вместо процессов и ритуалов

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

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

Каждые две недели проводим ретроспективы и 1-to-1. Если мы хотим знать, что мы сделали плохо и/или хорошо, есть ли блокеры, недопонимания, личные проблемы, лучше сделать постоянный канал связи куда можно сообщить (написать, позвонить, подойти лично) в любой момент (желательно, сразу), чтобы нужные люди отреагировали как можно быстрее.

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

Внедряем команды тестировщиков. Вместо того чтобы выработать персональную ответственность за разработанную фичу, мы нанимаем команды тестировщиков. Разработчики перестают думать о качестве решений, теперь достаточно поменять статус задачи в Jira с «In Progress» на «Ready to Test» и сойдет.

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

Нереальные примеры

Представьте, что вы никогда не работали в FoodTech, пришли в новую компанию. Она разрабатывает административную панель, в которой можно вести учет расходов ресторана. Вам выдают доступ на тестовый стенд, вы заходите, и на каждой странице в каждом поле видите «test», «test111», «hello1234567». Если на странице ресторана поле называется «name» — вы поняли из контекста, что это его название. А что значит поле «name» на странице «menu dish attribute»? А это добавка (toppings) к блюду! Если бы там было написано «Моцарелла», а название блюда «Пицца», то вопросов бы не возникало вообще.

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

func join(string string: String, toString stringTwo: String) -> String {
    return string + stringTwo
}

join(string: "foo", toString: "bar")

Но ничего не понятно, если бы «toString» назывался «stringTwo», как и в случае со «string», ничего бы не измелилось. Б-г с ним, со StackOverflow, поищем какой-то туториал. Там дают следующий пример:

func logMessage(message message: String, withPrefix prefix: String) {
    print("\(prefix)-\(message)")
}

logMessage(message: "message", withPrefix: "prefix")

Опять не понятно, чем в этом примере «withPrefix prefix» лучше «prefix prefix»? Ничем. А приведи хороший пример, и читатель сразу поймет насколько это крутой инструмент для построения читабельных и понятных интерфейсов.

func transferMoney(from sender: User, to receiver: User, money: Money) -> Void {
    sender.balance -= money.amount
    receiver.balance += money.amount
}

transferMoney(from: sender, to: receiver, money: money)

И такое встречается везде: документация, тестовые базы данных, фикстуры, StackOverflow, туториалы, гайды, тесты в веб-фреймфорке Django, где непонятно, что третий аргумент это пароль, не открыв сигнатуру метода. Используйте реальные и релевантные примеры в ваших проектах. Заботьтесь о других людях, так вы лучше погрузите человека в контекст и он быстрее и качественнее решит свою проблему.

Из головы в документацию

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

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

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

Ничего не должно оставаться в головах разработчиков.

Идеальная вакансия для разработчика

Выступил на конференции для рекрутеров и HR-специалистов, где рассказал о плохих и хороших вакансиях. Говорил про то, что недостаточно указать стек технологий, что для успешной вакансии нужна корпоративная и техническая культура, что широкий диапазон заработной вилки скорее вредит компании, чем наоборот и много чего другого. В конце также ответил на вопросы слушателей.

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

Ссылка на видео — https://www.youtube.com/watch?v=OaS6vOAh6Vs. Там есть тайм-коды и вы сможете переключиться между частями выступления. Это мой YouTube-канал, я его недавно создал и немного оформил, так что подписывайтесь — есть идеи насчет видеоконтента в будущем.

Собрал 8-битный компьютер

Два месяца назад писал, что хочу собрать свой компьютер с целью понять как он работает не только в теории, но и на практике. У меня это получилось и это было круто! Я сделал небольшое видео для вас, в котором демонстрирую результат – запускаю программу для последовательности Фибоначчи на собранном компьютере.

Ссылка на видео — https://www.youtube.com/watch?v=9BbM1_VXrsU. Рекомендую смотреть на x1.5.

Проект. По моим подсчетам, я потратил где-то 120-140 часов.

Основные трудности:
— Перемычки (проводки, соединяющие разные отверстия макетных плат, и соответственно, входы и выходы чипов). Их нужно вручную отмерять, обрезать, загибать. Они разного размера, и их сотни. Если перемычки длинные, они становятся «непослушными», приходится дополнительно крепить к другим перемычкам.
— Все, с чем ты работаешь — физические вещи. Перемычки выпадают из отверстий, «ножки» чипов ломаются, сами чипы попадаются бракованными. У тебя нет компилятора, который скажет, что ты сделал не так. Поэтому если у меня что-то не работало, поиск проблемы превращался в путешествие и перепроверку всего.
— Электроника. Знания о напряжении, токе, сопротивлении, устройстве резисторов и транзисторов — все это училось в школе и университете и давно забылось без практики. Приходилось учить заново базовую информацию, чтобы понять как работает (либо почему не работает) та или иная часть логики в компьютере на физическом уровне.
— Брак. Чипы сгорали (буквально разогревались до такой степени, что обжигали мне пальци), работали странно или вовсе не работали. Поэтому мне пришлось делать заказ бракованных чипов отдельно c Jameco (американский дистрибьютор электронных компонентов) и в таком количестве, чтобы покрыть еще один возможный брак.

Несколько раз за весь проект ловил себя на мысли, что если сейчас что-то не заработает, у меня просто нет знаний сделать так, чтобы заработало, и я не смогу закончить проект – это очень демотивирует. Помог subreddit от Ben Eater'a, это что-то вроде отдельного форума на Reddit, — где энтузиасты занимаются электроникой и делают похожие проекты. Сложность проекта ставит высокие требования к вопросам: чтобы тебя поняли, надо все детально расписать, приложить фото и видео проблемы. Был удивлен «здоровьем» сообщества, все настроены позитивно и без агрессии помогают с банальными вопросами.

На удивление, непосредственно логика компонентов компьютера (счетчик команд, оперативная память, тактовый процессор, АЛУ, и прочее) — самое простое в понимании. Но сложное в осознании — ты, вроде, понял как это работает, но рассказать об этом трудно. Я связываю это с тем, что понять природу физического мира, систем исчисления в принципе не просто.

Видео. Не ставьте высоких требований к видео, моей целью не было детально рассказать или научить как работает компьютер. Я всего лишь хотел дать немного больше контекста тому, что я сделал. Поэтому там есть и «бэ-мэ», и запинания, и куча склеек, и голова в кадре. Я вообще был в шоке, насколько это трудно без готового сценария и сюжета рассказать о чем либо без запинок — я перезаписывал части видео по 10 раз. Особенно трудно рассказывать «на лету» на русском языке о том, что ты учишь и применяешь только на английском — хочется сказать и «профилировать», и «экзекьютбл», и «запринтовать».

Дальше на очереди видеокарта и процессор 6502. В будущем хочу сделать проект по типу построить свой интернет с нуля — не знаю на сколько это реально, не нашел, чтобы кто-то подобное сделал.

Инициализация памяти в 8-битном компьютере

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

Здорово еще то, что для этого я использовал знания, которые получил во время основного проекта.

Arduino (на GIF-ке слева внизу возле питания) — это готовая плата со своим процессором и оперативной памятью, небольшой компьютер. У него есть входы и выходы, к которым можно подключать разные датчики или перемычки (проводки) — на них можно передавать напряжение либо считывать его. У Arduino есть USB-интерфейс, через который можно прошивать его. Прошивка — это логика того как будут вести себя входы и выходы, написанная на языке программирования Arduino C, упрощенном С++.

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

Чуть больше информации про проект можно посмотреть в репозитории на GitHub.

Продвижение проектов

Один из подписчиков прорекламировал репозиторий из поста выше на Hacker News. В течение 4 дней на страницу проекта на GitHub перешло 4 тысячи уникальных пользователей (скриншот снизу). Это первый раз, когда мои проекты рекламирую не я сам, а кто-то другой — я был приятно удивлен. В 2018 году я рекламировал свою библиотеку для входа на сайт через Телеграм на Habr. Тогда на страницу проекта на GitHub пришло 2 тысячи уникальных пользователей, и даже сейчас в статистике посещений я вижу 50 уникальных пользователей за последние 2 недели.

Хочу поделиться ресурсами, которыми я пользуюсь или пользовался, когда хочу сделать маркетинг своему проекту:

1) Пишу статьи на Habr на русском (пример) и Medium английском (пример).
2) Сабмичу на Hacker News (пример).
3) Сабмичу на Reddit в SubReddit по языку программирования или просто по своим проектам (пример).
4) Нахожу тематические дайджесты для языков программирования или инструментов (пример).
5) Делаю пулл реквест в тематические репозитории на GitHub (пример).
6) Пишу в тематические группы ВКонтакте (например, если я писал библиотеку на Python, я искал группы по разработке на Python и писал туда пост).
7) Пишу в LinkedIn (пример).

Заказал раму для компьютера

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

Также слева сделан вырез под провод питания. Задумка в том, чтобы включать вилку в розетку и компьютер начинал работать.

Обошлось в ~$25, весит относительно тяжело — килограмма 2-3.

Статья про 8-битный компьютер

Написал статью про компьютер на Habr. Прошелся по каждому компоненту, рассказал детально про устройство, логику и взаимодействие с другими компонентами. Постарался, где тяжело что-то объяснить текстом, создать понятные абстракции для читателя, чтобы не потерять его интерес. Цель статьи — рассказать как работает компьютер и заинтересовать людей электроникой.

Принял участие в войс-чате на тему «Кто такой Senior?» на DOU

Время от времени DOU (dou.ua) организовывает войс-чаты в своем Телеграм-канале на различные темы. Участие принимают приглашенные гости из разных компаний, которые обсуждают заранее 5-6 заготовленных тем. После подключаются слушатели и задают вопросы спикерам.

В этот раз вместе с разработчиками из Netflix, Google, SoftServe и video intelligence обсуждали сеньйорность: кто такой, как им стать, расти в одной компании или чаще их менять, какие различия в работе на этой должности в аутсорсе, продукте и FAANG-компаниях.

Тайм-коды к записи здесь.

Аудіозапис войс-чату «Хто такий Senior?» від 11.08.2021

Спікери:
🗣 Микита Проценко, Senior Software Engineer в Netflix
🗣 Володя Штеньович, Senior Software Engineer в Google
🗣 Дмитро Стрілецький, Senior Software Engineer в Rocket
🗣 Андрій Губський, Software Architect в video intelligence
🗣 Олексій Голубєв, Senior Software Developer в SoftServe

Матеріали, що згадувалися під час чату:

«Хочу стать сеньором». Ошибки и заблуждения специалистов

Почему нет смысла готовиться к собеседованию