Техническое собеседование - важный этап приема на рабочий проект. Мы поговорили с коллегами с рынка (как работающими в нашей компании, так и нет) и обсудили их последний опыт техсобесов, а также важный на наш взгляд вопрос - нужно ли к ним готовиться заранее.
Спойлер - готовиться нужно. Все это делают по-своему, но мы наметили несколько общих подходов.
Техническое собеседование глазами кандидата
По факту техническое собеседование представляет собой срез знаний по последним технологиям. Проблема в том, что даже обладая опытом в ИТ в 10 или 20 лет, без подготовки такие знания из головы не достанешь.
Скорость обновления технологий в ИТ очень высокая. Если ты не меняешь работу каждые полгода, а трудишься спокойно на одном проекте, фокусируешься только на нем, ты в любом случае немного скатываешься в легаси. Это не критично, пока с последнего обновления библиотек и версий прошло не так много времени. Но года за четыре стек обновляется полностью. И получается, что при обсуждении этого нового стека разницы между человеком с опытом 4 года и его коллегой с опытом 8 лет уже не будет (за исключением знаний в каких-то классических областях).
Чтобы оставаться актуальным, необходимо заниматься самообразованием - постоянно освежать свои знания. Но в фоне с основным проектом как правило этого никто не делает. Многие и смысла в этом не видят. Сегодня технология на хайпе, но к тому моменту, когда ты выйдешь на рынок труда, она может благополучно исчезнуть. Зачем же тратить время на то, чтобы во внерабочее время ковыряться с ней без конкретной цели? Плюс некоторые знания - в части подходов и паттернов - можно получить только на практике в компании. Работа над некоммерческим пет-проектом здесь не поможет, потому что там далеко не всегда используются те же подходы, что и в коммерческой разработке (это, кстати, беда всех самоучек - они уходят в практики, которые не совпадают с мейнстримом).
И даже более острая проблема заключается в том, что на техническом собеседовании на самом деле спрашивают не то, с чем предстоит работать в рамках этого нового стека. Зачастую интервьюеры фокусируются на сугубо теоретических вещах, с которыми в реальной работе ты не сталкивался и вряд ли встретишься на проекте. Максимум - покажут кусок кода и попросят его усовершенствовать.
Как отметил один из спикеров, примерно 95% рабочих ситуаций укладывается в 5% опыта. Но спрашивать именно об оставшихся 5% ситуаций - это своего рода традиция. И особенно абстрактными вопросами грешат крупные компании - они очень любят спросить базу по теории или погонять по алгоритмам, которые скорее всего не пригодятся. Отличный пример от другого спикера - асинхронность в JavaScript. Как он отметил, знание о том, что есть так называемый event loop или отдельная очередь микрозадач, за 10 лет работы не пригодилось ни разу, зато на собеседованиях все это вспоминают часто. Спикер вспомнил, что из последних десяти собеседований хорошие вопросы именно о том, с чем предстоит работать, встречались только на двух или трех.
Считается, что все это база. Но тот же коллега привел аналогию с реальным миром: “Это как у строителя, который работает перфоратором, спрашивать, медная или стальная катушка используется внутри инструмента, а не то, какие бывают буры и под какие стены они используются. Но я же собеседуюсь не на специалиста по починке перфораторов, а на того, кто с его помощью будет квартиру отделывать. Поэтому выбор вопросов получается довольно странный”.
Почему вопросы именно такие, в целом понятно. В рамках собеседования представители компании пытаются понять, какого уровня кандидат перед ними - стоит ли платить ему столько, сколько он запрашивает. И крупным компаниям здесь сложнее, потому что у них часто одна вакансия висит на несколько отделов и собеседуют человека одновременно во все, т.е. задать вопросы по конкретному проекту не получается. А при этом оценить, как человек мыслит и подходит к решению задач, надо. И на это у них всего 10-15 вопросов.
Раз мир “охоты за головами” устроен именно так, кандидату остается готовиться к техническим собеседованиям.
Как именно готовиться?
Подход к подготовке - штука индивидуальная. Здесь вы найдете мнения четырех опытных специалистов, которые поделились своими практиками. Для тех, кто не хочет вчитываться, в самом конце подготовили краткое резюме.
Лид во фронтенде, ментор
Раз собеседования - самостоятельная задача, то и готовиться к ней надо отдельно, не смешивая это с рабочим проектом.
Можно пойти и посмотреть в интернете статьи вроде “30 вопросов по JavaScript”. По моему опыту в них действительно встречаются вопросы, которые задают на технических собеседованиях. Но пересечение не 100% - где-то есть устаревшие версии, где-то надуманные, поэтому полностью доверять таким спискам я бы не стал.
Сама подготовка - это чтение теории и решение задач, т.е. книги, статьи, задачи и онлайн-тесты на каком-нибудь javascript.ru, решение алгоритмов на codewars и т.п. Если мы говорим про фронтенд, надо посмотреть в первую очередь JS и основной фреймворк (react, vue, angular), при необходимости - освежить знания по вёрстке, да и в целом понять свои слабые места и закрыть их. Я рекомендую в качестве источника знаний видеозаписи прохождения реальных собеседований на YouTube, особенно если указана компания и чем она занимается (какой использует стек).
Можно также поработать с ментором. Сейчас есть масса сервисов для поиска тех, кто предоставляет услугу MOK-собеседования, т.е. проводит пробное интервью, спрашивая то же, что и в реальных компаниях. Самое ценное в таком опыте - развернутая обратная связь по итогам. Компании не всегда раскрывают, почему берут одних, но отказывают другим. А ментор может подсказать, какие темы кандидат знает недостаточно хорошо и помочь подтянуть. Минус этого только в том, что за услуги ментора придется заплатить какие-то деньги.
Ну и еще один подход к подготовке к техническим собеседованиям - это просто постоянно их проходить. Многие шутят, что есть отдельная “собеседовательная мышца”, которую надо накачать. В реальной жизни она редко используется. Ты ее немного подкачиваешь, но не развиваешь по-настоящему, пока не ищешь работу. Чтобы ее развить, надо ходить на собеседования, выписывать для себя вопросы, которые показались сложными, пытаться запрашивать фидбек (хотя обычно и сам понимаешь, на что ты не ответил или ответил хуже, чем хотелось бы). Моя рекомендация - ходить по собеседованиям хотя бы раз в месяц, чтобы быть в курсе. В качестве побочного эффекта ты можешь случайно найти более интересную работу.
А еще я не стал бы пренебрегать моральной подготовкой. Здесь все очень индивидуально. Кому-то помогает спорт, кому-то просмотр чужих собеседований. важно понимать, как повысить свою уверенность, и пользоваться этим.
Я вижу, что для многих пройти собеседование, особенно на свою первую работу, - это проблема, поэтому сейчас запустил наставничество - веду группу ребят, которые обладают определенными знаниями во фронтенде, хотят хорошо пройти собеседование и устроиться на свой первый интересный проект. Также провожу индивидуальные консультации по карьере и развитию.
Александр
15+ лет в IT
Карьерный путь: сисадмин - backend - аналитик - руководитель проекта - фронт - frontend lead
прошел более 100 собеседований и в несколько раз больше провел сам в качестве руководителя
200+ учеников по программированию
https://t.me/sanya_ob_it
Лид в мобильной разработке
За свою жизнь я прошел достаточно много технических собеседований и считаю, что к ним нужно готовиться, чтобы компенсировать постоянно увеличивающееся отставание от технологий. На это нужно выделить время. Кому-то достаточно нескольких дней, а кому-то лучше начать за пару недель.
Обычно в рамках подготовки я смотрю самый последний стек и прогугливаю его в поисках свежих статей и практик. Как правило, ссылки ведут на Хабр, где все довольно подробно расписано. Но лучшая подготовка - ходить по собеседованиям. Когда ты уже в процессе смены работы, мотивация выше - вступаешь в борьбу тогда, когда начинается драка, а не заранее.
Технология проведения технического этапа - достаточно специфическая. Во многих компаниях принято жестить, поэтому попасть к конкретному работодателю как правило не удается, да и нет смысла. Везде примерно одинаковый стек. И вполне нормальная практика - завалить первые несколько интервью, выяснить, что сейчас интересует нанимающих, подготовиться и хорошо пройти следующее собеседование. Своеобразная реализация алгоритма разборчивой невесты.
В принципе, все эти подходы к техническим интервью описаны в интернете. Есть практики от компаний и даже открытые записи собеседований.
Не жалейте времени на подготовку. Результат не заставит себя долго ждать.
Артур
Большой опыт мобильной разработки на разных проектах со сложной архитектурой и бизнес-логикой в разных ролях от рядового разработчика до технического лидера. В Андроид разработке более 8 лет
Старший разработчик Android
Честно говоря, в последние годы мой подход к подготовке изменился. Сейчас я стараюсь изучать новый материал вне зависимости от подготовки к собеседованиям, потому что это же как перед экзаменом в студенчестве - если ты весь семестр ничего не делал, накануне не вызубришь. Может быть тебе повезет и спросят то, что ты успел прочитать, а может и нет. Гораздо лучше все усваивается, если делать это постепенно.
Стараюсь следить за официальными блогами Google, Android и т.п. Вышло обновление библиотеки или заметил новый тренд (например, все переходят из классического XML в Compose), отправляешься читать.
В основном я перечитываю официальную документацию на Google Developers. Это первоисточник, а книги и статьи - уже переизложение того же материала другими специалистами, куда вполне может закрасться какая-то ошибка (или материал просто неправильно донесут). Ну и я к этому просто привык. Когда я заканчивал институт в 2005 году, книг по нужной тематике либо не было, либо они были для меня, как студента, дороговаты. А документация всегда была в бесплатном доступе. Так что книги я всегда оставляю на втором плане, если только это не материалы от создателей технологии (так это было, например с Kotlin in action).
Но даже в таком режиме готовиться к техническому этапу надо. Как правило, компании скидывают примерный набор вопросов, чтобы ты знал, в каком направлении смотреть. Немного освежить воспоминания можно и за день. В плане кода могу пробежаться по одному из своих проектов и вспомнить, например корутины. А когда ты долго не проходишь собеседования по данному стеку, придется потратить больше времени. В целом пары недель достаточно, даже если ты меняешь фокус с одного направления на другое или пытаешься устроиться в Яндекс с его фокусом на алгоритмах. Я в свое время так и переходил из бэкенда в Android.
Юрий
11 лет опыт коммерческой разработки Андроид, старший разработчик
Старший разработчик Android
По моему опыту собеседования либо проходят по заготовленным спискам вопросов, либо в разговоре о текущем проекте. На мой взгляд, второй вариант лучше, поскольку у тебя здесь есть свежие воспоминания в голове, ты можешь рассказать какие-то нюансы. Вспомнить, как решал проблемы, а не просто односложно ответить на вопрос. Тут будет диалог. И людям, которые собеседуют, обычно тоже интересно - это же реальный, а не выдуманный кейс. К сожалению, так бывает далеко не всегда.
Я обязательно готовлюсь. Стараюсь раз в полгода - год ходить на какое-нибудь реальное собеседование, чтобы держать себя в форме. Собираясь на такое собеседование, ты примерно представляешь, что читать и зачем. Все это обретает смысл. Иначе мотивации нет, а воспоминания без использования на практике впоследствии окажутся бесполезны.
Собеседование дает встряску и новые знания - может быть там спросят о том, о чем ты раньше даже не думал. Отмечаю для себя вопросы, на которые не ответил или ответил плохо. А если так не получается, смотрю видео с собеседованиями - их сейчас очень много. При просмотре ставлю на паузу и сам отвечаю на те же вопросы. Если не знаю ответ, читаю документацию.
Никита
Более 6 лет опыта коммерческой разработки Андроид, Старший разработчик
Подводя итоги
Вопросы на технических собеседованиях часто выходят за рамки практик, используемых на реальных проектах.
Готовиться надо, потому что даже если с момента смены работы прошло всего полгода, технологии уже ушли немного вперед.
Нужно представлять, к чему готовиться: некоторые компании высылают заранее темы или списки вопросов. Можно подробнее расспросить рекрутера вакансии, что планируется на технической встрече.
Чтобы определить вектор подготовки, стоит посмотреть свежие записи собеседований, сходить на реальное интервью, понимая, что скорее всего оно будет завалено.
Подготовку может быть психологически комфортнее обсудить с ментором.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.
Комментарии (21)
trabl
22.11.2023 02:07+1Из своего опыта, готовиться к собеседованию нужно, хотя бы внимательно ознакомиться с вакансией и компанией. Далее всё индивидуально, кто-то может быть уверен в себе на все 100, и ему необходимо лишь восполнить какие-то небольшие пробелы, а кому-то действительно понадобится как минимум пару дней. Не знаю как у разрабов, но у тех же DevOps 70% вопросов практически всегда одинаковые, поэтому при поиске работы чем чаще ходишь на собеседования, тем больше откладывается в голове. Самое печальное, что даже на сегодняшний день у многих компаний собеседование до сих пор проводят как экзамен.
gun_dose
22.11.2023 02:07+2Вот мой чеклист с учётом того, что большинство собеседований сейчас проходят удалённо:
Выбрать или подготовить место, где удобно сидеть, и на фоне нет ничего стрёмного. Блюрить или заменять фон нежелательно, т.к. многие ценят открытость.
Надеть нормальную майку или рубашку. Тут вроде всё понятно.
Обязательно (!!!) надеть штаны! Хоть их и не видно, но в процессе собеседования может произойти ситуация, когда придётся срочно встать из-за стола, например, кот что-нибудь учудит или какой-то другой форс-мажор. Кстати, по-моему, тут на Хабре кто-то писал, что его на собеседовании попросили встать.
Привести себя в порядок: причесаться, если есть волосы, достать из бороды остатки недавнего приёма пищи, если есть борода, и т. д.
Предупредить окружающих, чтобы не отвлекали.
Nialpe
22.11.2023 02:07со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из jira" или "у меня nda". в таких случаях уже переходим на разбор моих кейсов - это обычно ревью заготовленного кода или архитектуры - из текущего проекта с долей упрощения, разумеется. да, я готовлюсь к собеседованию, и кейсы мне дает реальная практика с проектов. надо просто оправданий лени не искать. и зачастую очень любопытные и непринуждённые беседы выходят.
zergon321
22.11.2023 02:07+3Без подготовки в IT теперь не пройти ни одно собеседование. Да и с подготовкой тоже. Меня однажды спросили, какую ассемблерную инструкцию сгенерирует компилятор Go для инкремента. Жабьескриптерам дают выражение с нагромождением скобок и требуют предсказать результат, попутно объяснив его. А чтобы его объяснить, надо знать такие кишки интерпретатора, что упасть не встать. Какой человек, если у него здорова психика, будет засорять себе мозг всем этим хламом?
Hivemaster
Готовиться к собеседованиям - это всё равно, что принимать антибиотики перед анализами. Если единственная задача как угодно попасть хоть куда-то, то смысл в подготовке есть, но в норме собеседование - это не экзамен, а подбор сотрудника с подходящими навыками с одной стороны и подбор компании с подходящими задачами с другой.
Может быть на фронте и в мобильной разработке, а вообще всё самое важное в ИТ придумали лет 50 назад. На бэкенде только какие-нибудь дурачки, у которых лучше не работать, будут спрашивать мелкие нюансы последней версии модного фреймворка.
Смотрим предыдущий пункт. Самые жирные деньги в нормальной разработке приносят фундаментальные знания, которые были 50 лет назад и будут ещё через 50 лет.
Мир нужно менять к лучшему, а не подыгрывать плохим практикам. Сейчас рынок кандидата, что даёт нам возможность диктовать условия проведения собеседований.
MinimumLaw
Лучше и не скажешь. При чем даже в этом случае что грамотный диагност, что толковый представитель работодателя враз раскусит примененную хитрость и это будет скорее очень жирным минусом в лучшем случае. В худшем поломает тот самый SoftSkill, который "быть, а не казаться"
В общем это тоже правильно. Но, как всегда есть нюансы...
К счастью мир IT довольно большой. Там найдется место и готовящимся к техническим собеседованиям любителям самых хайповых технологий, уходящих работать в откровенно "пузырные" темы, и серьезным математикам-фундаменталистам, и людям с инженерным подходом, производящим то, что реально продается. Главное для себя определиться кто ж ты таков на самом деле.
Не знаю. Мне не дает. Да я и сам не беру. Более того, уже сколько лет наблюдаю - как только двухуровневое собеседование (HR, затем техника) так совершенно без шансов. А когда люди, с которыми работал, приводят непосредственно к руководителю и разговор с ним - оффер в кармане. Правда тут приходится думать что с ним делать - ибо в большинстве случаев меняешь шило на мыло. Условия везде примерно одинаковые, а бросать свои многолетние проекты и доказывать в новом месте что ты не верблюд, и в состоянии заниматься разработкой, а не просто затыкать дыры - ну то еще удовольствие.
Ну и вопрос денег... Они там, где хайп и очередной пузырь. Где реальное дело деньги всегда с оборота. Не то, чтоб их не было, но их всегда кратно меньше. За то не надо раз в три года работу менять. Эта история, как правило, на долго.
Batalmv
Смысл есть, так как собеседование не идеально. И даже близко не идельно. Вот если вас сразу на испытательный берут, где вы уж точно себя покажете - тогда да, тут не подготовишься. Собеседование - это все таки экзамен, где себя надо показать здесь и сейчас. И глупо будет, если окажется что ты его завалил, если забыл банальную вещь. Причем ее можно знать, пользоваться, но даже банально забыть, а как оно называется :)
Как минимум, стоит изучить компанию, хоть приблизительно. Также требования к вакансии. Там много подсказок, на что стоит обратить внимание. Просто опять же, простой тест.
Я работодатель, опубликовал описание вакансии. Приходит кандидат и оказывается он его не смотрел. Вопрос - а почему тогда он будет более внимательно читать тех. задание, описание таски в Jira и т.д.? Не, может связи и нет, но вероятность наличия пренебрежительного отношения к входящей инфе стала выше, что не играет на руку кандидату
Я тоже как бы пионерский галстук носит, и начинал с паскалей, С и 286. Но не совсем. Хотим мы или нет, но вот банальный ORM. Я бы не сказал, что в эпоху двух-слойных приложений такая концепция была реально массовой, хотя допускаю, что можно найти что вот мистер "Х" ее применил.
Ну и если от человека ожидается, что он будет выдавать продукцию, желательно знание того, что использует команда. Либо явно будет видно, что кандидат реально прошареный тип и освоит очень быстро
Это не означает, что можно на собеседовании класть ноги на стол. Да, вас хантят, меня хантят. Но не факт, что возьмут. Потому что хантят многих, и вот именно туда, куда бы стоило попасть - могут и не взять
gun_dose
Ничего зазорного нет в том, чтобы что-то не помнить. В далёком 2016 году, я будучи инженером-системотехником, самостоятельно выучил основы веб-разработки и решил "войти в IT". В одной из контор меня попросили написать алгоритм пузырьковой сортировки, а я не знал как. Я так и сказал "вы же видите в резюме, что я по образованию инженер по приборостроению и мне такие штуки в универе не рассказывали, а то, что рассказывали в школе, я забыл. Но если мне надо будет отсортировать массив, то я знаю, что в php есть целая куча функций для сортировки по значению, по ключу, по пользовательской функции, всё это с сохранением ключей или без сохранения. Но я даже не помню названия всех этих функций, потому что когда будет нужно, я открою документацию на php.net и посмотрю там в разделе о массивах, какая функция сортировки подойдёт мне." В итоге получил оффер. Но я не пошёл туда работать, потому что кроме этого у меня было ещё три других оффера, и я пошёл туда, где больше понравилось. Кстати, ни к одному из собеседований я не готовился.
Весьма удручает тот факт, что приходится давать такие советы. Я всегда изучал всю доступную информацию о компании, прежде чем откликаться на вакансию. И никогда не откликался на то, что мне не подходит или не нравится. Я думал, что это нечто само собой разумеющееся, и что у всех так. Но увы, реальность показывает, что люди сейчас кликают на всё подряд, не глядя. Иначе откуда эти истории, как джун сделал более 1000 откликов впустую. Я не верю, что в природе существует такое количество вакансий, подходящих для одного человека.
event1
Экзамен, да. Для нанимателя. Если он меня не возьмёт из-за того, что я забыл как что-то называется, ну он сам себе плохо и сделал.
Batalmv
Боюсь не стоит так высоко о себе думать :)
Krushiler
Нанимателям? Возможно. Как минимум тем, которые хантят. Контора, в которую все хотят попасть хантить не будет.
Batalmv
Ну оно ж не совсем так работает.
Допустим крутая контора "Х" открыла вакансию для хорошего спеца и ждет :) Мы ж не хантим. Что дальше?
Нежданчик первый. Все заняты. Дело в том, что люди в целом трудоустроены. Даже если взять страну в целом, то процент безработицы обычно 5-10%. Но это в целом. Хорошие спецы обычно показывают куда лучший результат. Поэтому сразу оказывается, что из 100 кандидатов, которые бы точно подошли, без работы сидит 2, и то - это не точно. Понятно, что среди 98 работающих еще есть пара-тройка, которым не очень на их рабочем месте и они тоже ищут, куда б свалить. Итого потенциальный улов на 3-5 на 100. Но они еще должны увидеть эту вакансию, они им должна подойти ... вообщем статистика пришла и почти победила с первого захода
Нежданчик второй. Все хотят попасть. Поэтому присылать свои резюме будут все, кто увидел вакансию. И тут компания "Х" получит условно еще 100 резюме на одного спеца, который ей бы подошел. Так как по резюме не сразу видно, подходит кандидат или нет - надо либо собеседовать, либо еще как-то фильтровать.
В общем получается, что при наличии потенциальный 100 кандидатов, который можно переманить, компания старательно перелопачивает тонные "пустой" породы в поисках своей крупинки золота. Не самое отпимальное решение :)
Поэтому что делается. Ищутся спецы по "прямым" каналам, и не важно, они ищут работу или нет. Найденым спецам прямо предлагается вакансия. Кто-то откажется, кто-то нет. Но легко поверить, что те же 3-5 кандидатов найдуться. пусть даже два.
Такая стратегия выгодно отличатся от первой, так как ищется та крупинка золота, которая окажется доступной.
Но вот фишин, и есть условно два кандидата. И из надо сравнить методом собеседования.
И тут рынок сразу переворачивается и становится рынком работодателя. И чтобы не вышло, что взяли когото другого - лучше подготовиться
iboltaev
Как раз отсеивают других дурачков, которые, не разобравшись, грохнут сервер, допустят утечку сокетов или вообще дедлок, или еще круче, начнут постранично отдавать то, что можно отдать потоком
Консенсус меньше 30 лет назад придумали, асинхронный ввод/вывод в линуксе 20 лет назад появился, rcu в ядре столько же, докер и контейнеры ок 10 лет назад, map/reduce лет 15, сейчас тот же flink года по-моему 4 назад появился и предлагает потоковую обработку больших данных и концепцию dynamic table
Короче, на технологиях 50 летней давности вы не выедете, если только не писали на cobol все эти 50 лет
nick0x01
map и foldl были уже реализованы в Haskell версии 1.0 - 1990 год. В lisp/scheme, я думаю, были и раньше.
nick0x01
Не про то подумал, блин, это про модель MapReduce было...
event1
Тётя вика указывает 78-ой, как формальный год рождения византийских генералов.
речь была про самое важное. Алгоритмы, подходы, парадигмы. Асинхронный ввод/вывод, да ещё и именно в Линуксе трудно отнести к этой категории.
Та же тётя Вика относит день рождения LXC к 2008-му году. По важности — там же где aio
В целом я скорее согласен с вами по поводу важности данной технологии для индустрии. Однако, именно её новаторство спорно. Реализация облаков — намного больший прорыв на мой взгляд. Однако, для разработчиков от этого не очень много поменялось, по-моему.
вы путаете концепции и фреймворки. Изучение нового фреймворка занимает две недели, если вы знакомы с концепциями на которых он основан. Переезд с С на Хаскель может вообще не получится.
iboltaev
я вообще Paxos имел в виду, год публикации 1998, отсюда есть и пошли распределенные системы, всякие там bigtable, hdfs, hbase... Византийские генералы, ну не знаю, давайте еще обедающих философов вспомним, довольно отвлеченная задача
вообще, асинхронный ввод/вывод - это и подход, и немного парадигма даже. Было: апач с его process/thread-per-connection, стало - Nginx с его C10K
Докер дал дешевую виртуализацию, а также подход к решению проблемы dependency hell, в общем.
фреймворк иногда бывает реализацией концепции
я переезжал с C++ на Scala с ФП) 8 лет, полет нормальный
event1
The Paxos protocol was first submitted in 1989. Придумал его, кстати, тот же Лесли Лампорт, который предложил решение вышеупомянутой проблемы генералов за 10 лет до того.
вы молодец.
n43jl
Расскажите это людям, которые годами готовятся к собеседованиям в FAANG и в итоге это даёт свои плоды.