Продолжаем говорить о технических собеседованиях (если вы не читали — просмотрите предыдущие статьи из цикла — о собеседованиях с HR и технических). В этот раз будет больше субъективного опыта, минимум советов, а также немножко про тестовые задания и теоретические вопросы. Поехали.
Disclaimer: автор — не турборазработчик, а обычная веб-макака без претензий. Поэтому приведенные задания и решения могут вызвать у вас улыбку, баттхерт и желание указать автору на его некомпетентность. С нетерпением жду вас в комментариях! :)
Обсуждение выполненных тестовых заданий
В прошлой части я описывал, что делал аж два тестовых задания: первое на DevOps Engineer, второе — на Ruby Developer. Расскажу, что же было дальше.
Собеседование на Ruby Developer — интервьюер даже не посмотрел на мое тестовое, не задал по нему никаких вопросов, не сделал комплимент (я выполнил задание лучше чем все предыдущие кандидаты, по крайней мере, так мне польстила рекрутер). Такое впечатление, что он про него даже не знал. Это меня немного расстроило, ведь потом меня начали спрашивать теорию, и, в итоге через теорию и отказали.
Собеседование на DevOps Engineer — интервьюер посмотрел задание, сделал комплимент (сказал что я его качественно выполнил) и задал несколько контрольных вопросов по решению: зачем тут эта строка? если заменить условие на вот такое, в каком файле нужно будет это сделать? почему тут применен именно такой подход? и так далее. Как мне передала рекрутер, некоторые кандидаты делали задачи не самостоятельно, и не могли ответить на такие вопросы. Поэтому тут я справился без проблем.
В первом случае я не спросил у собеседующего, смотрел ли он вообще мое тестовое задание и что он думает по этому поводу. А нужно было! Если у вас возникнет такая ситуация, то обязательно укажите собеседующим на это.
Задачи на собеседованиях
Продолжим тему тестовых заданий из предыдущей части и рассмотрим задачи на кодинг на собеседованиях.
Задачи могут быть нескольких типов: реализовать алгоритм, написать решение на псевдокоде, что-нибудь отрефакторить и так далее. Наши инженеры больше всего любят алгоритмические задачи.
Много людей, в том числе и я, считают, что эти задачи показывают лишь умение кандидата решать именно такие задачи, и совсем не показывают, как он будет справляться с реальными рабочими заданиями, которые, как правило, более высокоуровневые. Почему же их до сих пор дают? Я думаю, причина простая: интервьюеры просто не способны придумать что-то лучшее. А раз не можем придумать ничего лучше — давайте возьмем старые добрые инверсии строк, сортировки, балансировки деревьев и прочее.
В качестве инструментов, которые используются для решения, лучше всего подойдет редактор кода + repl + возможность коллаборации. Из всех вариантов, которые есть на рынке, мне больше всего нравится CoderPad. Создается комната, куда подключаетесь вы и интервьюеры, можно вместе редактировать, выполнять код и смотреть на результаты выполнения. Очень удобно. Если нет денег на кодерпад, то в бой идет repl.it и шаринг экрана — в принципе то же самое, только без возможности коллаборации.
Upd: пока переводилась статья, repl.it добавили Multiplayer Mode, который позволяет неограниченному количеству участников одновременно работать с кодом. Совершенно бесплатно! CoderPad уже не нужен, ура!
Было у меня собеседование в компанию на позицию Java Developer. Компания делает что-то вроде CRM и пишет кучу интеграций. Я связался с техническим специалистом по Zoom и он говорит: «Начнем с алгоритмической задачи». Я отвечаю: «Ок, задачу сделаю, но у меня вопрос: у вас в работе понадобятся эти знания, вам нужно решать похожие вещи?». На что получаю феноменальный ответ: «Мы пишем рест эндпоинты и гоняем туда-сюда json-чики, но про это же неинтересно разговаривать, поэтому давайте решать задачу». То есть, сам интервьюер сознался в своей некомпетентности. Не знаю, кто как, но я уже с этого момента понял, что там мне ловить будет нечего. Однако из спортивного интереса разговор продолжился.
Мы открыли кодерпад и перешли к задаче, условие которой мне озвучили устно: «Найти максимально длинную последовательность из уникальных символов в заданной строке». После этого интервьюер сказал, что «можно было бы дать задачу на динамическое программирование, но ограничимся более простым вариантом». Хотел бы я посмотреть на человека, который будет давать на собеседованиях задачу на динамическое программирование, серьезно.
Я повторил условия задачи интервьюеру, чтобы убедиться, правильно ли я её понял, на что получил утвердительный ответ и начал работать. Через 5 минут оказалось, что задачу я понял все-таки неправильно, потому что нужно было найти не подстроку, а её длину (это проще). Однако, я ответил «Ну раз начали, то давайте уже решать задачу со звездочкой, а не простую». Интервьюер был немножко сбит с толку, так как у него были подготовлены тесты именно для его условий, но я уже решил что заднюю не буду давать и буду пробовать делать как есть. Я спросил сколько у меня есть времени (примерно 40 минут) и начал кодить. Замечу, что, не смотря на то, что я знал, что будут давать задания, специально я не готовился.
Итак, я сразу написал тесты и начал шаманить с i, j и k индексами :) Циклами в циклах, и так далее. Уже через 15-20 минут у меня было наполовину работающее решение, но не проходили граничные кейсы, которые дал интервьюер. Еще 20 минут ушло на них, в итоге, я все-таки верно сделал задачу. Интервьюер, кажется был удовлетворен, и дальше начал спрашивать у меня о структурах данных. Оказалось, что для решения той задачи, которую он хотел давать изначально, можно было бы применить хешсет, или что-то подобное, и он ожидал именно такого решения, но я все ему сломал.
Дальше совсем немного поговорили о проекте (формы и круды). И тут он говорит: «После этого будет собеседование о системном дизайне. Вообще я не вижу смысла его проводить, потому что мы тут таким не занимаемся и знания такие нам не нужны, но порядок есть порядок, поэтому следующий этап такой». Ну вы поняли — два(!) собеседования проводятся, чтобы понять, может ли кандидат делать вещи, которые не нужны в повседневной работе в этой компании. Тут я позволил себе немного высказаться по поводу бессмысленности таких собеседований. Интервьюер со мной согласился, но снова включил делегирование ответственности и сказал: «Не я решаю, каким должен быть процесс, поэтому делаем то, что делаем». Добавлю, что второе интервью (о системном дизайне) я все-таки прошёл и было оно таким же бессмысленным, как и первое.
Какую ошибку сделал интервьюер — он не зафиксировал условия задачи в тексте. Когда я проводил такие собеседования, то я просто копипастил условия задачи в редактор кода, чтобы у кандидата не оставалось никаких вопросов.
Какую ошибку допустил я — сразу бросился писать код, не уточнив три раза, правильно ли я понял условие. Если вам будут давать такие задачи на собеседованиях, то сразу отключайтесь от чата и найдите себе более интересное занятие уточните несколько раз, правильно ли вы поняли условие, напишите в редакторе тест и получите у интервьюера подтверждение, что все корректно.
Еще было у меня собеседование на позицию Ruby Developer. После знакомства и дефолтных вопросов мне дали задание написать метод each_slice. Для тех, кто не знает — это такая штука, которая бьет массив на подмассивы заданного размера и выполняет для каждого из них блок, который мы передали в метод, или возвращает итератор по этим подмассивам. Я сел писать, и тут у меня включился тупинг. Проблема в том, что на Ruby я довольно долго и успешно занимался только веб-макакингом, и, как эталонный вайтишник, не знал некоторых базовых конструкций языка. А именно — не знал, что индекс в цикле for является иммутабельным (в отличие от, например, Java).
Сам метод я написал более-менее быстро, но он не работал, и я никак не мог понять, почему. Я начал немного паниковать, удалил все и написал заново, но мой код снова не работал как нужно.
«Не пошло», — подумал я и сказал своим собеседникам: «Парни, знаете, я вот хорошо умею в веб-макакинг и делаю проекты, но с вашими дурацкими задачами у меня что-то не получается. Я понимаю, что это простая задача и человек с 10-ю годами опыта просто обязан её быстро сделать. Так что давайте я не буду вас больше задерживать, и мы разойдемся». Парни согласились, на том и расстались.У меня серьезно бомбануло, потому что я не привык так просто проигрывать. Чтобы хоть как-то выйти в экзистенциальный плюс, я написал рекрутеру, что сломался на задаче, которая не имеет отношения к реальной работе. Потом успокоился, сел, быстро протестировал как работают индексы в циклах. Понял, что я совершил джуниорскую ошибку, переделал индекс и получил готовое решение. Фактически, ошибка у меня была в одной строке. Я сказал об этом HR и предложил ей передать ссылку на решение парням, если им интересно, потому что я все-таки решил задачу. Но она ответила: «Вы не прошли дальше, потому что не решили задачу,
прощайте». Я еще немножко поныл ей про сломанные процессы собеседований, чтобы как-то себя оправдать и мы расстались.
После этого я переосмыслил свое отношение к таким задачам. Обычно для меня никогда не было проблемой закодить что-то под присмотром, но тут сработало несколько факторов: моя заявка на серьезную позицию, недостаточное понимание базовых конструкций языка (хотя они мне никогда не были нужны, а если бы и были, то загуглить решение можно за 5 секунд) и эффект наблюдателя. Конечно, я читал, что множество людей не могут решать задачи, когда на них смотрят, но мне всегда казалось, что это какое оправдание собственной неуверенности и некомпетентности, пока я сам не попал на этих суровых ребят с each_slice.
Еще у меня было собеседование на позицию Java Developer. В этот раз оно проходило в несколько другом формате. Мы связались по Zoom и интервьюер говрит: «Скажи свой e-mail, я тебе вышлю задачу, почитаешь, скажешь, все ли понятно. У тебя будет два часа, я буду на мьюте и не буду смотреть, что ты там делаешь (экран не шарим). Через два часа выходим на связь, шаришь экран и смотрим, что ты там сделал. Пользоваться можно чем угодно». Я почитал условия задачи, проговорил еще раз её с интервьюером, отключил видео (потому что кодирование потока кушает CPU) и замьютился. Открыл IDE и начал работу.
Задание было связано с I/O — нужно было сделать API для записи данных в файл на диске, так, чтобы все было thread safe и быстро, и еще написать юнит-тесты, которые бы проверяли это (в т.ч. потокобезопасность). Давно не работал с concurrency и I/O, поэтому пришлось быстро пробежаться по докам и вспомнить что к чему. Я написал решение в лоб, проверил что оно потокобезопасно и так далее. На все про все у меня ушло примерно полтора часа. Я пинганул своего интервьюера, сказал что я уже готов, но осталось только мелочи отполировать, будем смотреть? На это он ответил: «Давай еще полчасика посиди и доделай все, что не доделал». Ок, я сел и довел до ума все мелочи и шерховатости, дописал джавадоки, еще раз прочитал все что мог про I/O и подумал, какие могут быть недостатки у моего решения.
Через полчаса мы вышли на связь, я расшарил экран, показал код, запустил тесты и так далее. Следующие полчаса мы говорили строго о решении задачи и возможных вариантах его модификации при изменении тех или иных условий. Хочу обратить внимание на то, что на предыдущих собеседованиях (да и на последующих тоже) никто задачами не готовил базу для разговора, она всегда была просто каким-то абстрактным куском, который давал на выходе 0/1 и мы переходили к следующему вопросу. А тут задание было достаточно простым, чтобы его можно было сделать за пару часов, но в то же время достаточно основательным, чтобы можно было добавить условий и обсудить с кандидатом, как бы он дорабатывал решение.
Мне это собеседование очень понравилось. Я смог показать что не только fizz buzz умею решать, но и что-то понимаю в архитектурах. Интервьюер убедился, что перед ним сидит не джун, а специалист, который что-то отстреливает в своей работе. Это было лучшее техническое интервью из всех, которые у меня были. Думаю, вы уже догадались, что интервьюер был не из наших :) Добавлю так же, что я успешно его прошел, потом еще два этапа и в итоге получил оффер. Но это уже другая история.
Чем было хорошо это задание?
- Приближенность к реальной работе, к тому, чем занимаются в той компании.
- Ограничение по времени.
- Отсутствие наблюдения.
- Возможность пользоваться чем угодно а не проверка памяти.
- Создание базиса для дальнейшего разговора.
- Проверка умения канидата кодить, пользоваться IDE и думать в целом.
К сожалению, из всех собеседований, такие задачи были у меня только на трех, поэтому выборка маленькая. Возможно, есть еще какие-то более хитрые тесты/задания, но я на них не попадал.
Типичные недостатки задач на собеседованиях
- Задание никак не касается реальной работы. Меня это раздражает больше всего. Дают решать алгоритмы, хотя на самом деле круды клепают. Давайте релевантную задачу, сделаю вам круд! Зачем вам человек, который умеет подстроки в строках искать?
- Организационно — часто отсутствует нормальный инструмент для решения. Один раз мне показывали код в google docs, один раз я шарил экран в repl.it, один раз был CoderPad.
- Задача не создает контекст для дальнейшего разговора — это следствие первого пункта. Зачем давать задачу если потом не будем её обсуждать?
- Не все люди могут справиться с заданием под присмотром. Соответственно, хороший кандидат может отсеяться еще на этом этапе.
Теоретические вопросы
Это моя любимая часть. Все любят спрашивать теорию, давайте немного пройдемся по этому.
Почему-то так получилось, что больше всего теорию меня спрашивали на позициях Ruby Engineer. Я знал её хуже всего, поэтому постоянно заваливал собеседования и выглядел джуном, пока не понял, что дальше так не годится продолжать. Я сел и прочитал учебник по языку, который позволил мне выступать значительно качественнее и без нытья «Ребята, зачем вы меня об этом спрашиваете? Я хороший разработчик, какая разница, какой порядок поиска метода у объекта? Кому это нужно?».
Первое собеседование, которое я проходил на позицию Ruby Developer, было как раз тем, где нужно было делать тестовое задание, однако, как оказалось, оно никого не интересовало. Тимлид, который должен был со мной общаться, не пришел (в пробке стоял или что-то такое), поэтому мне выдали другого. После знакомства он говорит: «У меня есть правило — я все собеседования провожу на английском, поэтому переходим на английский». И тут мои уши скручиваются в графеновую нанотрубку, потому что у интервьюера очень сильный акцент. Это меня несколько выбило из колеи (мне очень тяжело общаться с соотечественниками на английском).
Дальше пошли вопросы: что такое модуль, что такое блок, что такое yield, — и я начал фейлить. Вместо определения «как в учебнике», я начал лепетать: «Ну, не знаю точного определения, но, наверное, это вот такая штука, я её применял вот так». Интервьюер был недоволен, я это начал чувствовать и тогда подумал что все, приехали.
Дальше были вопросы о конкретных методах, а именно: «Как называется метод, который фильтрует все нилы в коллекции?». Тут я уже включил тролля и ответил: «Если вы проверяете мою память на знание этих методов, то я не могу вам ничего рассказать о том, чего не использовал недавно. Я пишу на многих языках и платформах и не помню всех методов SDK». Интервьюера это не удовлетворило, и следующим вопросом было что-то вроде: «Что такое Enumerable? Назовите, какие там есть методы и кто его экстендит». «Дядя, ты шо, не понял?», — подумал я про себя, но вслух сказал: «Не знаю точно, думаю, что какие-то методы типа map/reduce/slice и тд». Ему это тоже не подошло.
Дальше он задал мне стандартный вопрос о том, куда в MVC засовывать логику. Я ответил что в модели, а если в модели не влазит, то в какие-то другие классы. Оказалось, что верным ответом были так называемые Service Objects (неужели эта дрянь и сюда добралась?). Я что-то буркнул в ответ, типа, ну можно и так называть, но мне это не нравится.
Дальше он спросил дефолтный вопрос про SQL, на который я уже смог грамотно ответить, потом спросил про RSpec, который я не использовал, вот и все. По Rails (а у них как раз были рельсы) я не получил ни одного вопроса. Так же, ни одного вопроса я не получил и о своем предыдущем опыте.
После этого он спросил у меня, что я думаю о daily стендапах. Тут я уже решил не давать социально ожидаемых ответов (сгорел сарай — гори и хата!), а сразу сказал что это напрасная трата времени и практикуется в командах, где менеджер не может обеспечить прозрачность и удобство отчетности по прогрессу. И еще добавил что Scrum — это фигня на постном масле, и никто у нас нормально по скраму не работает, а все только делают вид. Очевидно, что я тут еще нахватал минусов.
Дальше он предложил задать вопросы ему (видимо из вежливости), и я, на свою голову, спросил про процесс, архитектуру и так далее. То, что я услышал, мне не понравилось, потому что они много занимались велосипедостроением для типовых задач. Я хотел дать понять парню что я не просто разработчик, а умею чуть больше, но все было напрасным, и вскоре он сказал что ему пора на митинг и отчалил.
На следующий день мне написала рекрутер и сообщила об отказе. «И слава Богу», — подумал я, но все-таки немножко подгорело. У меня создалось впечатление, что интервьюер с самого начала имел какие-то предубеждения, не знаю. Кстати, это была та самая контора, которая тянула месяц от первого контакта до технического собеседования.
Итак, мне отказали, потому что я не знал основ языка (Ruby). Ок, едем дальше.
Еще одно собеседование на Ruby Debeloper, уже двое собеседующих. Хорошо что хоть говорят один на русском, второй — на украинском, поэтому не пришлось ломать себе . К моему удивлению, начинается та же история: что такое модули, что такое блоки. Я тогда еще не прочитал учебник, поэтому снова плавал в ответах. Дальше спросили о видах ассоциаций в Rails. «Наконец-то хоть что-то», — подумал я, и назвал три вида по памяти. Интервьюерам это не понравилось (потому что их было больше), как и то, что я сказал: «За остальными я лезу в доку». Дальше они дали мне то задание, которое я описал выше — про each_slice. После этого, как вам уже известно, я предложил закругляться. Один из интервьюеров напоследок решил попытать счастья: «У меня тогда последний вопрос, вы когда-то писали Rack middleware?». Не знаю, что он хотел услышать. Я сказал что не писал, но знаю, что это такое (типа фильтров в Java Servlets, или middleware в каком-нибудь Laravel/Express), и могу быстро разобраться при необходимости. И снова их это не устроило, поэтому наш разговор закончился.
Опять, никого не интересовал ни мой опыт, ни мои знания в построении решений или в смежных сферах. Я не осуждаю тех парней. Может им действительно нужны программисты, которые прямо сейчас знают, как нужно писать rack middleware, однако думаю, что на самом деле они просто не умеют проводить собеседования.
После двух провалов я понял что так быть не должно и нужно почитать теорию. Если её спрашивают — нужно знать. Никто не хочет верить в то, что я хороший парень просто так и давать нормальные задачи, поэтому я сел, прочитал учебник, и…
Третье интервью на Ruby Developer. Тимлид снова в отпуске, поэтому со мной говорил простой разработчик. Те же самые вопросы про модули и блоки, но я уже был во всеоружии, поэтому даю корректные ответы. Интервьюер идет дальше и спрашивает у меня что такое Proc, но и тут я даю верный ответ, хотя никогда не пользовался этим :) Тогда он решает пустить в ход тяжелую артиллерию и задает вопрос: «Назовите порядок поиска метода для вызова, если у нас есть класс, он экстендится от другого, а еще есть модуль и еще что-то там». Тут я уже не знал 100% верного ответа, поэтому попробовал как-то логически предположить, какая цепочка должна быть. Угадал половину.
Дальше был еще вопрос вроде такого: «каким образом работает require». У этих ребят уже был не Rails а Grape, поэтому, наверное, для них это было актуальным. Я опять ответил «сходу не знаю, но наверное вот так и вот так». Кажется, не угадал. Дальше были какие-то вопросы-паззлеры, типа «вот кусочек кода, что он выведет?». Потом немного поговорили про ActiveRecord — тут уже я почти на все ответил верно, потому что имел с ним хороший опыт.
Потом он начинает меня спрашивать про concurrency (тут мне стало смешно). Я не знаю точно, какая модель concurrency в Ruby — так я ему и отвечал. Добавил что знаю о примитивах синхронизации, атомиках, мьютексах и прочем. Пытался намекнуть, что ваше конкарренси в MRI — тухлая рыба в сравнении с JVM и щас я вам тут расскажу про модели памяти, разницу между volatile и synchronized и буду цитировать Шипилёва, но интервьюеру это не зашло. Корме того, он признался, что в проекте они (не может быть!) concurrency не используют. Кто бы мог подумать? Зачем тогда спрашивать?
Дальше ведущий решил покрасоваться и спросил, знаю ли я что-то про SOLID. Я сказал что точную расшифровку забыл, смысл всего примерно переводится как «Нормально делай — нормально будет», а все функции по написанию солидного кода я зааутсорсил рубокопу. Интервьюер со мной не согласился, и конструктивного диалога у нас не получилось. Это был единственный раз, когда я меня спросили про баззворды. После этого мы уже больше говорили о каких-то архитектурных решениях, подходах и прочем. В итоге меня пропустили дальше, а в конце я получил оффер с пометкой «не знает основ языка». Но об этом позже.
Какой вывод можно сделать из этих трех собеседований? Между ними прошло несколько дней. За это время я не сделал новый проект, не получил новых знаний или новый опыт, не стал более лучшим разработчиком, нежели был. Я каким был, таким и остался! Знание теории на практике мне не добавило абсолютно ничего (извините за каламбур). Просто, вместо того, чтобы заблаговременно прочитать Cracking Ruby Interview, я решил наступить на все грабли сам. Думаю, еще два-три таких собеседованиях и моя «сеньорность» не будет вызывать ни у кого сомнений, не смотря на то, что на самом деле я какой макакой был, такой и остался :)
Еще несколько историй и с чистой теорией будем завязывать.
Было у меня собеседование на Fullstack Java Developer. Меня предупредили что оно будет состоять из двух частей — бекенд и фронтекнд. Последний я знаю не очень хорошо и сообщил об этом рекрутеру, но они решили идти дальше. Ок, связываюсь с парнями, начинаем с Java.
Честно говоря, вопросы были ни теоретическими, ни практическими, а какой-то нудной тягмотиной. Думаю, что человек, который со мной разговаривал, сам толком не знал, что ж такого спросить. Тем не менее, как многажды стрелянный воробей, я отвечал как нужно.
Перешли к фронту. На том конце сидел уже чисто фронтендер. Начал меня спрашивать про прошлый опыт, а потом перешел к паззлерам, типа, что будет если undefined сравнить с null, как работают области видимости и var. Еще несколько дефолтных вопросов по JS и снова перешел к WAT-вопросам. Я сразу сказал: «Слушайте, я с вашим WAT никогда в жизни не имел дела. Если очень нужно будет, я погуглю, но я считаю что эти знания некуда применять, кроме как посмеяться с пацанами на митапчиках». Интервьюер со мной согласился, но все равно продолжил задавать паззл-вопросы. В итоге он посоветовал мне прочитать книгу «JavaScript: The Good Parts», после чего я еще поговорил с менеджером и на том разошлись.
Мне быстро сообщили, что я подхожу, и будут назначать собеседование с заказчиком. Через некоторое время опять вышли на связь и сказали что заказчика не устраивают мои знания фронтенда (?) и поэтому он не хочет иметь со мной дела, но они (аутстаф контора, которая мою голову перепродавала) будут пытаться его переубедить, потому что по их мнению все ок. После этого никто мне уже не писал. Наверное, не переубедили :)
Хотя эти люди тоже пытались вытащить из меня какие-то чисто теоретические вопросы, но сам фронтендер признал, что таких практических задач они не имеют. Фронт на jQuery, и нужно уметь в него. Я сказал что умею и проблем нет :)
И еще было у меня собеседование на DevOps Engineer, где я делал тестовое. Перешли к разговору и тут интервьюер спрашивает: «А что такое маска подсети?». Тут-то я и посыпался :) Сказал что это количество циферок, которые обозначают адрес подсети, а все остальное — это диапазон. Но что с этим делать уже не помню, давно не настраивал сетей. Хорошо, что интервьюер оказался адекватным, подвел меня к правильному ответу и не обращал внимания на то, что на такой простой вопрос я не смог сразу дать верный ответ. Дальше собеседование проходило уже без теоретических вопросов. Стоит ли упоминать что собеседующий снова был из другой страны (хотя и с советским бэкграундом)?
Меня удивило что перестали вообще спрашивать про шаблоны проектирования (кроме того случая про MVC). Всего (ха-ха) 5-10 лет тому назад буквально на каждом собеседовании проверяли знание паттернов. Я еще с того времени почти все их (из GoF) знаю на память и еще и могу реализовать на бумажке. Но в этом году среди всех собеседований я не получил ни одного вопроса по шаблонам. Ruby-разработчиков, наверное еще можно понять, — они, наверное, про них ничего и не знают (у них есть MVC и ActiveRecord и этого достаточно). Но отсутствие таких вопросов на Java-собеседованиях меня очень удивило.
Про SOLID спросили, кажется, всего два раза: один раз на Ruby-позицию, второй раз — на Java. Про DRY не спрашивали :)
Какие можно сделать из этого всего выводы?
- Теорию до сих пор любят спрашивать, особенно наши с вами соотечественники.
- Знание теории не гарантирует знание практики, поэтому к теории любят добавлять задачи.
- Умение ответить на вопросы или решить задачу не гарантирует, что человек умеет программировать.
- Незнание теории или фейл с решениями задачи не означают, что перед вами плохой разработчик.
Поэтому, каким бы бессмысленным это не было, но советую вам:
- Перед собеседованиями изучить типовые наборы вопросов по вашему языку/платформе и хорошенько их заучить. Знать неоднозначные вопросы, ответы на которые просто так не выведешь. Один из моих любимых таких вопросов: «Какой есть недостаток в использовании прокси-AOP по сравнению с AspectJ в Spring?» :) Это нужно, чтобы легко проходить собеседования с интервьюерами, у которых не хватает фантазии на нормальные вопросы.
- Порешать типовые алгоритмические задачки на LeetCode и подобных ресурсах, чтобы быть к ним готовым.
Пока что все, опять много текста, надеюсь вам было интересно. В следующей части будем говорить о вопросах по поводу прошлого опыта, вопросах о системном дизайне, вопросах «на подумать и порассуждать» и других вещах, которые уже больше похожи на правильное техническое собеседование.
Не забывйте подписываться на мой телеграм канал (я там пишу текста поменьше, но такие же интересные), заходите почитать бложек, и до следующей статьи!
Автор: Vladimir Rozhkov
