Senior Engineer в поисках работы. О задачах на технических собеседованиях и теоретических вопросах

Автор оригинала: Włodzimierz Rożkow
  • Перевод
Продолжаем говорить о технических собеседованиях (если вы не читали — просмотрите предыдущие статьи из цикла — о собеседованиях с 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 и думать в целом.

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

Типичные недостатки задач на собеседованиях


  1. Задание никак не касается реальной работы. Меня это раздражает больше всего. Дают решать алгоритмы, хотя на самом деле круды клепают. Давайте релевантную задачу, сделаю вам круд! Зачем вам человек, который умеет подстроки в строках искать?
  2. Организационно — часто отсутствует нормальный инструмент для решения. Один раз мне показывали код в google docs, один раз я шарил экран в repl.it, один раз был CoderPad.
  3. Задача не создает контекст для дальнейшего разговора — это следствие первого пункта. Зачем давать задачу если потом не будем её обсуждать?
  4. Не все люди могут справиться с заданием под присмотром. Соответственно, хороший кандидат может отсеяться еще на этом этапе.

Теоретические вопросы


Это моя любимая часть. Все любят спрашивать теорию, давайте немного пройдемся по этому.

Почему-то так получилось, что больше всего теорию меня спрашивали на позициях 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 не спрашивали :)

Какие можно сделать из этого всего выводы?


  1. Теорию до сих пор любят спрашивать, особенно наши с вами соотечественники.
  2. Знание теории не гарантирует знание практики, поэтому к теории любят добавлять задачи.
  3. Умение ответить на вопросы или решить задачу не гарантирует, что человек умеет программировать.
  4. Незнание теории или фейл с решениями задачи не означают, что перед вами плохой разработчик.

Поэтому, каким бы бессмысленным это не было, но советую вам:

  • Перед собеседованиями изучить типовые наборы вопросов по вашему языку/платформе и хорошенько их заучить. Знать неоднозначные вопросы, ответы на которые просто так не выведешь. Один из моих любимых таких вопросов: «Какой есть недостаток в использовании прокси-AOP по сравнению с AspectJ в Spring?» :) Это нужно, чтобы легко проходить собеседования с интервьюерами, у которых не хватает фантазии на нормальные вопросы.
  • Порешать типовые алгоритмические задачки на LeetCode и подобных ресурсах, чтобы быть к ним готовым.

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

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

Комментарии 302

    +5
    Я не знаю почему в ваших глазах, заданные вопросы про:
    • yield
    • Как называется метод, который фильтрует все нилы в коллекции?
    • Что такое Enumerable? Назовите, какие там есть методы и кто его экстендит

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

    Более теоретические (в моем понимании) это:
    • Чем отличается interface от mixin'а
    • Что такое функтор

    и так далее

    Вы тем самым показали, что не владеете инструментарием и скорее всего (из-за не знание основ) гавнокодите.
      +3
      Вы тем самым показали

      Я тем самым вообще ничего не показал, потому что на следующем собесе на эти вопросы ответил и в итоге получил оффер (правда не на 5к как рассчитывал а всего лишь на 4.5к :)))
        –6
        4.5k гривен? Вас даже переоценили, с вашими то глубокими знаниями в руби. Видимо кадровый голод настолько сильный, что уже берут всех, кто хоть немного шарит в программировании и хочет программировать на руби.

        А еще вы очень хорошо показали в статье что навык проходить собесы приходит с опытом :)
          +3
          гривен

          Беларусских рублей )))
          +1
          У вас проблемы с логикой
          Во-первых если тест имеет вероятность ложноположительного результата выше нуля, это еще не значит что тест плохой.
          Во-вторых между собеседованиями вы провели обучение и закрыли какие-то пробелы в знаниях, а значит стали лучше, то есть вы не такой же как были на первом собесе.

          Все потому и проводят по-разному интервью, что нет единого лучшего способа их проводить. Все методы имеют недостатки, их конечно можно на этом основании критиковать, но проводить то как-то надо) Вы наверно и сами согласитесь, что кандидат ответивший на 5 теоретических вопросов правильно, при прочих равных (или неизвестных) лучше кандидата который на них не ответил.
          +2
          yield

          Писал и пишу на Ruby с 2006 года, за всё время использовал эту фичу 3 раза. ЧЯДНТ?

            +3
            У меня для вас плохие новости
            Spoiler header
            шутка :)


            Ну по мне так, yield стал очень популярным. Концепт, который существует в других языках, как Python, C#, Scalа. И во всех этих языках это довольно популярная фича.
              +2

              Не знаю насчет С#, но в Python и Scala yield — это разные вещи, я б не стал их сравнивать.

            +2
            Как называется метод, который фильтрует все нилы в коллекции?

            Вот конкретно такие вопросы — бессмысленные. Если кто-то зазубрит названия всех методов, это вовсе не будет значить, что он знает язык и хорошо кодит. Достаточно общего представления о возможностях (что так или примерно так можно, дальше уточнить в документации). На вскидку названия этого метода не припомню, но это ничуть не помешало использовать его не так давно.
              0
              Зависит от того, кто что использует.

              Меня в JS бесит reduce-мания. Я на практике использовал reduce пару раз, поскольку не считаю, что reduce даёт читаемый код (часто проще обойтись map).

              Но если я приду в контору у которой всё на reduce, то ессно буду выглядить бледно, потому что хоть знаю как работает reduce, но он у меня «не наработан».

              Та же беда с SQL. Я не люблю joinы с использованием join, предпочитая джойниться в where. Для ребят у которых join на джойне, будет важно понимаю ли я чем отличается righ outer join от left inner. А я ведь с ходу не скажу ничего. Поскольку привык реализовывать это через exists и *= (в оракле).

              Другое дело, что перестроится, что на reduce, что на join мне пробела особых на будет, но вот верит ли в это интервьюер? )))
                +1
                . Я не люблю joinы с использованием join, предпочитая джойниться в where.

                Я тоже, только в MySQL такой фокус не пройдет )))
                  +2
                  Вот только условие в where может заменить лишь внутренне соединение (inner join) или внешнее, но только с проверкой ключа на is null. Все остальные варианты соединений на условие в where не способны заменяться в принципе. По крайней мере, за пределами Oracle. Кстати, left inner join не бывает.
                    –1
                    Правда? Приведите пример, пожалуйста.

                    Я лет 10 занимался проектированием и программированием БД. И всегда хватало обычного where. Вложенные запросы с exists и in как правило решают проблему.

                    Все современные БД, умеют оптимизировать запросы с exists/in равно как и join'ы поэтому всё дело вкуса (и соглашения в текущей команде), имхо
                      +1

                      Вот, держите:


                      select *
                      from foo
                      left join bar on foo.id = bar.fooid
                        +1
                        Вы это… полегче с ними ))

                        На самом деле важное, я бы сказал в следующем:

                        SELECT 
                             f.SomeField
                            ,b.SomeOtherField
                        FROM foo as f
                        join bar as b on b.fooid = f.id


                        Мне, просто, всегда казалось что именно в этом основной смысл «join», а не в фильтрации )
                          –3
                          select *
                          from foo
                          where not exists (select 1
                          from bar where foo.id = bar.fooid)


                          Единственная разница в том, что у в выборке не будет кучи пустых полей из bar. Для того, чтобы её получить надо более сильное колдунство

                            +2

                            Ваш запрос вернет только те записи из foo, для которых не существует записей из bar — а надо-то все. Причём вместе с данными из bar!

                              –3
                              Да, согласен. Перепутал join'ы, почему-то мне outer почудился, о чем ссно писал выше (что не готов с листа читать / писать join синтаксис)

                              Для выборки всего действительно «старый синтаксис» не подойдёт либо нужно будет делать извращения с union или агрегацией
                                +1
                                outer вам не почудился, полное название left join — left outer join
                                  0
                                  Ок. Вы меня победили )))

                                  Я же говорю, что join'ы это не моё. И время, чтобы в них въехать. И наша дискуссия это подтверждает. Практически уверен, что вы бы не взяли меня на работу.

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

                                  PS. На пред-предыдущеё работе за 5 лет работы с Oracle использовал =* (left join) два раза, на 40К+ строк PL/SQL. Но возможно мои задачи можно было решать и без него, где-то left join может осознанно и аргументированно использоваться очень активно
                                    0
                                    Потому, что после того, как я так показательно сел в лужу, спрашивать, что собственно я делал такими кривыми руками, какие задачи решал, какие объёмы баз данных и насколько сложная там структура — смысла нет.

                                    Конечно же смысла нет, если вы знаете только Oracle, а в вакансии требуются MSSQL или Postgres...

                                      0
                                      Ну был небольшой опыт)
                            0
                            select *
                            from foo, bar
                            where foo.id = bar.fooid(+)
                              0
                              Я же писал: за пределами Оракла
                            0
                            Не все, у Оракл перформанс часто проседает. Кроме того с джойнам проще писать базонезависимый код, там где это важно.
                          +1
                          map и reduce это же принципиально разные инструменты, как это вы одним обходитесь?
                            0
                            Я использую lodash — там много инструментов)

                            Я про то, что часто достаточно использовать map или for in/of, а не гордится, что любую проблему можно, а поэтому нужно решать с помощью reduce
                              0
                              Я, видимо, чего-то не понимаю. Допустим, вам надо просуммировать числа в массиве. Логично использовать reduce. Допустим, вам надо возвести числа в в массиве в квадрат. Логично использовать map. Допустим, вам надо возвести числа в квадрат, а затем — просуммировать. Логично использовать map+reduce.
                              Тут нечем гордиться, это просто инструменты одного уровня. И точно так же глупо говорить
                              не считаю, что reduce даёт читаемый код (часто проще обойтись map).
                                +1
                                map можно выразить через reduce. Но «обойтись map» действительно проще. В таком случае нет противоречия ¯\_(ツ)_/¯
                                  +1
                                  С точки зрения скорости использовать reduce выгоднее. Но если у меня нет потребностей скрупулезно экономить ресурсы, то я напишу

                                  mySum  = _.sum(_.map(arr, x => x *x ))
                                  

                                  Для меня это гораздо лучше читается, чем

                                  mySum = _.reduce(arr, (sum, x) => sum + x * x, 0)


                                  Потому что в первом случае мы делаем две атомарные операции: (1) суммируем массив (2) квадратов исходного массива

                                  В данном конкретном случае сложность чтения невысокая, но если нам надо например просуммировать квадраты всех чисел от двух и больше

                                  _.sum(_.map(_.filter(arr, (x) => x >= 2 ), x => x * x))
                                  // vs
                                  _.reduce(arr, (sum, x) => sum + (x >= 2 ? x * x : 0) , 0)


                                  Да оба примера выглядят грязно. Можно использовать chain запись — она тут читается идеально
                                  
                                  _(arr)
                                    .filter(x => x >= 2)
                                    .map(x=> x * x)
                                    .sum()


                                  Но, в плане улучшения читаемости кода, у нас есть возможность раскрыть часть функционального выражения через временную переменную (которую V8 на легко заоптимизирует)

                                  
                                  const filtered = _.filter(arr, x=x => 2)
                                  _.sum(_.map(filtered, x => x * x))


                                  В reduce раскрытие кода хуже читается, потому на русском языке проще сказать — как написано выше: фильтруем всё что меньше 2, остальное возводим в квадрат и суммируем

                                  _.reduce(arr, (sum, x) => {
                                     if (x >= 2) return sum + x*x;
                                     return sum
                                  }, 0)


                                  Так же у нас есть возможность использовать for

                                  
                                  let sum = 0
                                  for (const x of arr){
                                    if (x >=2) { sum += x *x }
                                  }
                                  


                                  PS. Написал lodash во всех случаях для простоты сравнения

                                  PPS. Вообще меня в reduce бесит то, что инициализация — последний параметр. По мне было бы не в пример удобнее, если поменять инициализацию и функцию.

                                  PPPS. Возможно я говорю глупо, но мне кажется, что я имею право на свою точку зрения? )
                                    +1
                                    Вы, конечно, нормально упоролись, но сумма — это был просто пример. Я не пишу на js, я вообще про концепции говорил. Если у вас есть sum и reduce, и надо суммировать числа, то надо использовать sum. Только не надо при этом утверждать, что проще обходиться map.
                                      0

                                      Если нужна производительность, то можно трансдьюсеры юзать. Будет в один проход и читабельно.

                                  +2
                                  Тут мне на днях кто-то на Хабре заявлял, что reduceRight допустимо использовать в качестве аналога forEach когда нужно обойти массив в обратном направлении…

                                  Вот так и обходятся.
                                  +1
                                  Не факт, что оптимизатор SQL переварит это и выдаст правильный план исполнения.
                              +3
                              Но в этом году среди всех собеседований я не получил ни одного вопроса по шаблонам. Ruby-разработчиков, наверное еще можно понять, — они, наверное, про них ничего и не знают

                              Мой поиск работы длился 3 с половиной месяца, месяц удаленно по скайпу из НСК, и два с половиной уж в МСК. Язык PHP — почти все собеседования по паттернам и SOLID.

                              Так вот, одно из удаленных собеседований было на джуниора (почти остальные на мидла или что-то между джуном и мидлом), и мне задали вопрос по SOLID, погоняли по каждому принципу, привел даже примеры, погоняли по MySQL (тоже всегда гоняют пыхеров), по NoSQL сразу сказал, что вообще не работал ни с чем, в т.ч. с Эластиком и прочим...


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

                              Хотя конечно на мидловых собеседованиях меня в лужу садили несколько раз так, что в затылке биение сердца чувствовал :)
                                +3
                                В php вообще, судя по всему, творится ад и хаос.
                                  +4
                                  Это стандартная фича языка ;)
                                    0
                                    Ну почему, мне, например, Laravel вполне даже приятен. Если приучить себя к особенностям синтаксиса PHP то становится почти как Rails.
                                      0
                                      Вообще ща пишу на yii2. Как понимаю, что-то родственное laravell. Но пыхе ща не хватает жесткой статической типизации — оттуда ад и хаос.
                                        0
                                        Зачем вам принципиально статическая нужна?
                                    +1
                                    Вы сделали мой день ;)

                                    Язык PHP — почти все собеседования по паттернам и SOLID


                                    Интересно многие ли PHP команды это употребляют? Хотя, PHP как раз такой язык, что требует беспощадного насаждения культуры разработки.
                                      0
                                      Многие просто спрашивают на собеседовании, просто чтобы было что спросить.
                                      На практике мало кто действительно использует и заморачивается. Иногда даже думают, что используют, но на самом деле — нет.
                                        0
                                        Думаю, сильно зависит от фреймворка.
                                          0
                                          Много, в топовых проектах много где Симфони (аналог Spring из языка Java)
                                          github.com/symfony/symfony

                                          Mail.ru (Delivery), Rambler, Lamoda, Forbes, Conde Nast, Skyeng… используют точно Симфони
                                          И тысячи проектов пользуют похожие фреймворки, у некоторых есть огромнейшие минусы/плюсы, есть монолитные проекты, но во всех больших преоктах, сами понимаете, встает вопрос рефакторинга, поддержки и переиспользования кода… на что приходит нам на помощь неожиданно ООП.

                                          Понимаю, для некоторых программистов очень удивительно слышать SOLID и PHP, недавно столкнулся с тимлидом на Java с 7 летним опытом, он очень был удивлен :):) просто про PHP он знал примерно то, о чем все обсуждают в ВК :)
                                      +5
                                      Я конечно ничего не понимаю в Java и Ruby, но по вопросам можно примерно представить уровень. Ну так вот не взяли вас в большинстве случаев совершенно правильно. Если вы не знаете синтаксиса языка, то зачем вы на те позиции шли? Можно не знать методов и библиотек, но синтаксис — святое.

                                      Задачки на переворот строки дают чтобы не тратить время на совсем не программистов (вы не поверите сколько народу так отсеялось).

                                      И ещё. Вы не прошли самый начальный уровень. Дальше были-бы вопросы сложнее. Потом ещё сложнее. И т.д. И так до предела возможностей или ваших или интервьювера. Это надо чтобы определить ваш уровень с одной стороны и предложить лучше позицию если случайно overqualified человек пришёл.
                                        +8
                                        Ну так вот не взяли вас в большинстве случаев совершенно правильно.

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

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

                                        Понятие «говнокод» универсально для всех языков, я могу сходу определить что код плохой, будь он написан на Java/Ruby/Python/JS и так далее.
                                          +7
                                          делал несколько довольно серьезных коммерческих проектов


                                          Оно самое! Сейчас почему-то спрашивают какую-то хрень. По умным вопросам кажется, что проект будет гениальным, а потом окунают в махровый легаси уровня ПТУ.
                                            –1
                                            А еще на RoR я сделал несколько довольно серьезных коммерческих проектов и заработал прилично денег, поэтому уверен в своих способностях решать задачи бизнеса.

                                            Наличие успешных проектов ничего не говорит о компетентности.

                                            У меня в портфолию есть пара проектов на PHP, которые принесли мне миллионы. При этом мои знания PHP уровня джуниора, я даже синтаксис могу не весь знать.
                                              +7
                                              Нефига себе — поделитесь историй успеха?
                                                +2
                                                А еще он знает лично Илона Маска, помогал Лари Пейджу, и владеет солидным куском акций Apple и Amazon.

                                                П-з-ть — не мешки ворочить!
                                                  –1
                                                  Особо рассказывать нечего, несколько проектов связанных с эл коммерцией в т.ч. обменники коинов и прочей эл валюты.
                                                  PHP выбрал т.к. недостаточно хорошо знал Java EE / Spring.
                                                  +3
                                                  Наличие успешных проектов ничего не говорит о компетентности.


                                                  Ну почему? Практический опыт о многом говорит.

                                                  К сожалению на интервью зачастую делают упор на незнание. А незнать можно боооольшое количество вещей. Начиная от сигнатуры метода и кончая какой-нибудь пятой нормальной формой. Обычно сам спрашивающий никогда не использовал эти знания на практике. Но если есть эквивалентные знания, то надо делать упор на них. Я например не знаю что такое «мок», но на самом деле это элеметарная вещь, которую просто хитро назвали. А тем временем спрашивающий наслаждается тайной властью.
                                                    0
                                                    Насчёт успешных проектов — как ни странно, это во многом так. Когда фрилансил, периодически приходилось что-то приделывать к коммерческим веб-приложениям (партнёрки, cms, и т.п.) — успешно продающимся на международном уровне. Код, как правило — тихий ужас. В мало-мальски крупной энтерпрайз-конторе такого бы не написали.
                                                      +1
                                                      В больших конторах тоже бедлам. Я сейчас работаю в проекте со 150 программистами. Такого кода насмотрелся, от самого умного до самого тупого.
                                                  +2
                                                  Все верно, два раза не взяли, на третий раз взяли хотя я-до и я-после ничем не отличались по уровню. Между собесами прошло несколько дней. О чем это говорит? О том, что вопросы, которые мне задавали, совершенно ничего не показывают.

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

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

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

                                                    +5
                                                    Насчет «синтаксис — святое» не соглашусь. Если пишешь проект на нескольких языках разом, в моем случае Ruby, JS и Kotlin, то легко перепутать и написать метод или конструкцию не того языка сдуру. Да, перед собеседованием не грех и повторить азы, чтоб не смущать собеседущего. Но так вот радикально, не помнишь синтаксис — вон из сеньоров, это напрасно.
                                                    0
                                                    Знакомые ощущения, после собеседований уровня «переверни-ка мне дерево» и чем X структура отличается от У (при условии, что У нигде на практике не используется) и резюмирования «у вас пробелы в базовых знаниях», наступает некоторая апатия, даже объяснять интервьюерам/рекрутерам ничего не хочется.

                                                    Тут важно понимать, что есть много вещей, которые вы знаете, но не знает тот (собеседующий), кто знает, то, что вы не знаете/путаетесь.

                                                      +8
                                                      после собеседований уровня «переверни-ка мне дерево» и чем X структура отличается от У (при условии, что У нигде на практике не используется)

                                                      Я рассуждаю так — если работа вам нужна, то нужно просто выучить все эти алгоритмы и уметь решать их с закрытыми глазами. Было много историй о собесах в FAANGи где люди месяцами сидели учили Cracking Coding Interview и LeetCode чтобы пройти собесы. Если рынок требует — значит надо соответствовать. Иначе снижается количество мест, куда можно попасть, зачем себя ограничивать в потенциальных возможностях. Если бы на собесах требовали писать о себе эссе на 10 страниц — пришлось бы писать, что поделать.

                                                      Я ходил на собесы по фану, поэтому не готовился ваще и поставил себе челлендж получить максимум офферов на $5k, на любые позиции, на любые технологии, отвечал на все запросы рекрутеров. Конечно, если бы я более серьезно подошел к делу, то результат был бы лучше, но и времени мне пришлось бы потратить больше (учитывая что новая работа мне ваще-т не нужна была). Я бы конечно хотел повторить этот опыт, только уже не для локальных аутсорс конторок, а FAANG, но как только представлю, сколько времени нужно будет потратить на подготовку, чтобы получть хоть один оффер из 10 попыток, всякое желание отпадает. Тем более что работать там я все равно не хочу.
                                                      +5
                                                      Вы, конечно, правильные минусы выделили у собеседований, но если бы вы вместе со своим резюме скинули бы мне ещё и эту статью, то я бы вас к себе не взял. И даже не стал бы интервью проводить. Не из-за пробелов в знаниях, а именно из-за вашего отношения. Вы знали, на какую позицию идёте, при этом даже не удосужились подтянуть свои знания.

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

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

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

                                                        Я ходил на собесы по фану, и чтобы статьи потом написать (зацените предыдущие две).

                                                        Вы знали, на какую позицию идёте, при этом даже не удосужились подтянуть свои знания.

                                                        Ну че, на третий раз подтянул и оффер получил. Ez.

                                                        вместо этого в статье только и слышно, что не те вопросы вам задавали

                                                        Отличные вопросы мне задавали на позицию java техлида (я об этом написал), так шо нет, таки были хорошие собеседующие. Ruby ребята чот не порадовали, не барское это дело, на вопросы о синтаксисе отвечать, ну и ладно.

                                                        Просто с таким отношением есть высокая вероятность

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

                                                        Вот я собеседовался на позицию Group Manager и там меня раскусили и не дали оффер )
                                                          +3

                                                          Это если предполагать, что человек в активном поиске на конкретный стэк. А если просто откликается на прямые предложения или всё равно какой стэк, то подготовить теорию по всем возможным проблематично.

                                                          0
                                                          можно увидеть решение задачки each_slice по первому собеседованию? и что там с индексами в итераторах — где прочитать про это?
                                                            0
                                                            можно увидеть решение задачки each_slice по первому собеседованию?

                                                            Собес был еще в октябре (полгода назад), кодерпад я потерял, да и код там тривиальный.

                                                            и что там с индексами в итераторах — где прочитать про это?

                                                            Не знаю, наверное в учебнике ))) Я просто запустил код в repl и протестировал как он работает. Что-то вроде

                                                            for i in 0..5
                                                               puts "Value of local variable is #{i}"
                                                               i = i + 1
                                                            end
                                                            


                                                            Выведет не 0, 2, 4 а 1, 2, 3, 4, 5

                                                            Школьный вопрос какой-то на самом деле )))
                                                              +2
                                                              Зачем менять переменную цикла D:
                                                                0
                                                                Чтобы подвинуть «окно» итерации для each_slice. Надо было через while делать но я затупил, вот и все.
                                                                  +1

                                                                  Это не переменная цикла, а item в массиве.
                                                                  И вроде в большинстве языков с for each его модифицировать нельзя.
                                                                  P.S.: На ruby никогда не писал.
                                                                  Жалко, что C — style for не существует во многих языках. Приходится разбираться, как выполнять элементарные операции, типа получить текущий индекс или перезаписать элемент массива.

                                                                  0
                                                                  за пару лет разработки на Ruby как-то и не вспомню, когда приходилось использовать for и приходилось ли вообще. А уже переменную менять…
                                                                    0
                                                                    Да наверное и реализацию each_slice или другого тривиального метода тоже нечасто нужно делать )))
                                                                    0

                                                                    Тут дело даже не в мутабельности. :)

                                                                  –6
                                                                  Собеседования «на доске» очень полезны. Лично я, когда провожу собеседования, обязательно даю задачу, которую надо написать «без гугла». Желательно — на листке бумаги. Потому что когда человек пишет рукой на листке бумаги — у него нет возможности что-то легко поправить, где-то вставить строчку кода. Большинство это понимают сразу и сначала планируют решение, а потом уже его пишут. Я таким образом проверяю не способность кандидата (например) развернуть список, а оцениваю опыт написания кода в целом. Опытный разраб для простых задач сразу знает, сколько ему нужно переменных, какие циклы будут и т.п. — у него во время написания кода уже в голове цельная картинка и он её просто переносит на бумагу. А вот джун такой картинки не имеет — он по ходу додумывает решение, где-то что-то подправляет. Иногда джун даже не может удержать всё решение в голове (а это крайне важное умение для того, чтобы писать код без багов — иначе всегда будут пропущенные корнер-кейсы). К слову, для решения задач на бумаге я никогда не даю что-то «головоломистое» — только базовые вещи, чтобы senior писал «от руки» решение за пару минут.
                                                                    +23
                                                                    Представляю сколько толковых кандидатов вы из-за этого потеряли!
                                                                      –7
                                                                      Если честно, не очень понимаю — каким образом? Это не риторический вопрос, мне действительно интересно мнение.
                                                                      На мой взгляд — толковый кандидат легко напишет на бумаге нужный код. Или я что-то упускаю?
                                                                        +11
                                                                        Я лично знаю жестких типов (отличных разработчиков), которые после предложения написать код на бумажке просто встанут и уйдут :)
                                                                          +12
                                                                          и это кстати очень хорошо. они и свое время таким образом сэкономят, и время команды интервьюеров. еще лучше было бы, если бы эти мега-парни еще у рекрутера догадались спросить о формате интервью и вообще не приходили бы.
                                                                            +1

                                                                            Почему бы не написать об этом в вакансии и сэкономить время всем сторонам, включая рекрутера?

                                                                            –1
                                                                            Это говорит об их невоспитанности, а не о профессионализме. Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?

                                                                            Насколько я понимаю, этим жёстким типам никогда не хотелось попасть в такие организации, как Microsoft, Google, Яндекс и т.п. (если речь идёт про SWE).
                                                                              +3
                                                                              Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?

                                                                              Ваще-т да, у нас как-то уже давно такое не практикуют. Да и все собесы почти проходят по скайпу, там есть repl.it/coderpad/шаринг экрана

                                                                              Microsoft, Google, Яндекс

                                                                              Да, у нас в Украине тухло с этими конторами ((( Только тупой аутсорс, только галеры.
                                                                                +2
                                                                                Это говорит об их невоспитанности, а не о профессионализме. Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?

                                                                                Просить писать программу на листочке — это хамство. В том, чтобы встать и уйти, если тебе нахамили — ничего невоспитанного нет.

                                                                                  +1
                                                                                  И много ли вы раз так вставали и уходили с интервью в мировых организациях?
                                                                                    +1
                                                                                    чтобы встать и уйти с интервью «в мировых организациях», как вы их назвали, надо, чтобы на это интервью сначала позвали.
                                                                                      +2
                                                                                      Ровно об этом я и подумал, но решил не писать, т.к. прозвучало бы слишком резко, а я и так вон уже минусов нахватал =)
                                                                                      А так — да, судя по всему многие «комментаторы» не дотягивают по уровню, оттого и не понимают, зачем всё это нужно.
                                                                                      0

                                                                                      А какая разница, мировая или не мировая? Если тебя оскорбляет представитель мировой компании — то он типа "право имеет" или как?

                                                                                        +2
                                                                                        в чем оскорбление заключается? в том, что они хотят какие-то вещи проверить перед приемом на работу? есть стандартный процесс собеседования в эти «мировые» компании, который всех там работающих не оскорбляет, а вас почему-то оскорбляет.
                                                                                          +1
                                                                                          в чем оскорбление заключается?

                                                                                          Человек пришел устраиваться программистом, а ему предлагают заниматься цирковыми номерами.


                                                                                          есть стандартный процесс собеседования в эти «мировые» компании

                                                                                          Но ведь в этом стандартном процессе никаких задач на листочках нет.

                                                                                            +1
                                                                                            что значит нет? почитайте, как устроено интервью в топ 5 мировых софтверных компаний. не на листочке, а на доске. но суть та же. в последнее время некоторые по желанию стали давать компьютер, где писать надо в ноутпэде (если повезет, с подсветкой синтаксиса).
                                                                                      +2
                                                                                      встать и уйти


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

                                                                                      Так одному кандидату не понравилось, что попросили написать SQL запрос на листочке — он «встал и ушел». Второму не понравилось, что спросили теорию, он встал и ушел. Третьему не понравилось, что спросили, чем не нравится текущее место работы — он встал и ушел.

                                                                                      Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».
                                                                                        0
                                                                                        Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».

                                                                                        Что же он, по-вашему, должен делать, если настолько не нравится? Сидеть там до пенсии, которой не будет, или умных жизни учить?
                                                                                          +3
                                                                                          Есть мнение, что лучше сначала говорить, что не нравится, а уходить только когда ожидаемой реакции нет за разумное время.
                                                                                          0
                                                                                          И вы остались без работников.
                                                                                    +17

                                                                                    Слышал такое мнение: Если человек хорошо пишет на листочке, то это либо студент, либо профессиональный ходок по собеседованиям.

                                                                                      0
                                                                                      Со студентами-олимпиадниками есть отдельная проблема: они очень хорошо пишут код на листочке, решают алгоритмические задачки на раз и вообще влёт проходят типичные «гугл-фейсбук-эппл»-собеседования. Для таких товарищей есть секции по архитектуре и проектированию. Жаль, не во всех организациях при приёме эти секции проводят (я не про отдельную встречу на час-два, а хотя бы рассуждения минут на 15).

                                                                                      Ну и студентов настолько больше, чем молодых senior-разрабов, что обычно если видишь молодого парня, бодро пишущего код от руки, то вывод (изредка неверный) сам напрашивается, это да.
                                                                                        0
                                                                                        мы недавно взяли такого олимпиадника. причем, не просто олимпиадника, а тренера одной из азиатских олимпийских команд. но взяли на entry-level позицию. и вроде как и с настоящей работой справляется. секции на дизайн и архитектуру проводят в зависимости от уровня, на который кандидата рассматривают. чем выше уровень, тем больше внимания этому уделяется. на начальные позиции легко можно пройти, просто умея решать задачи.
                                                                                        +3
                                                                                        Вопрос в том, что ожидается увидеть. Если готовое рабочее решение — то да, именно так. А если базу, от которой можно потом говорить, дорисовывать и так далее, то уже не важно что написано на листочке вначале, важно куда это всё придёт.
                                                                                          0
                                                                                          Ожидается увидеть то, как человек подходит к написанию кода. Ни разу ещё не было такого, чтобы опытный разработчик после прослушивания задачи сразу начал её писать. Обычно идёт несколько вопросов, размышление/обсуждение, строится решение, продумываются корнер-кейсы и после этого быстро пишется код на бумаге. У джунов (и некоторых мидлов) обычно происходит иначе.
                                                                                          +2
                                                                                          на самом деле часто встречается такое, что у людей совсем без знания алгоритмов на ровном месте появляется лишняя квадратная асимптотика, которая всплывает только ближе к проду. Плюс людям без знания алгоритмов сильно сложнее объяснить в чем именно тут проблема. Даже в примере, который привел автор, он решил задачу какими-то вложенными циклами (уже скорее всего квадрат), хотя она решается одним проходом со словарем всех встреченных значений и их индексов
                                                                                            +3
                                                                                            Даже в примере, который привел автор, он решил задачу какими-то вложенными циклами (уже скорее всего квадрат), хотя она решается одним проходом со словарем всех встреченных значений и их индексов

                                                                                            Без озвучивания ограничений ваше «даже» абсолютно бессмысленно. Вы экономите циклы, расходуя память — что, очевидно, возможно только тогда, когда у вас есть память, которую можно потратить.
                                                                                              0
                                                                                              в задачах конечно можно давать ограничения, но в том и дело, что в реальной жизни эти ограничения часто обнаруживаются поздно (конечно хорошо, когда программист знает ограничения предметной области и они не собираются меняться) и нужно сразу писать более менее оптимально (в разумных пределах и не особо ухудшая код). Ну и да, экономим циклы, расходуя память, но
                                                                                              1) память также расходуется линейно, а не квадратично
                                                                                              2) в подавляющем большинстве случаев, память дешевле вычислительной мощности и легче масштабируется
                                                                                                0
                                                                                                Вы экономите циклы, расходуя память

                                                                                                Нет, словарь всех встреченных индексов занимает примерно столько же, сколько строка с промежуточным найденным значением у автора.
                                                                                                И память можно оценить — сколько там символов в юникоде? Случай, когда сотни килобайт нет но есть секунды а то и минуты на исполнение, ИМХО, не совсем типичен.
                                                                                            +8
                                                                                            Толковый разработчик в спокойном состоянии может писать хороший код. Во время интервью большинство людей испытывают стресс, то есть уже не так продуктивны как могли бы быть. Помимо этого сам ход интервью может выбить из колеи. Да и в отличии от IDE на бумаге вставлять.

                                                                                            Очень сложно писать код без привычных инструментов, с сильным стрессом, без права на ошибку. Хороший девелопер может не написать код, а может и написать. Разве нужна эта лотерея? Давать для вайт боард кодинг можно лишь простейшие задачи(fuzz bizz, проверка строки на палиндром) для проверки, а умеет ли кандидат вообще писать код, в принципе?
                                                                                              0
                                                                                              Хороший девелопер может не написать код, а может и написать. Разве нужна эта лотерея?

                                                                                              Дак если бы был способ надёжно, без лотереи, узнать уровень кандидата — все бы им пользовались.

                                                                                              Давать для вайт боард кодинг можно лишь простейшие задачи(fuzz bizz, проверка строки на палиндром) для проверки, а умеет ли кандидат вообще писать код, в принципе?

                                                                                              Согласен, именно о таких задачах я и писал. У меня личный критерий отсечения «сложных» задачи — попросить коллегу-мидла на обеденном перерыве накатать решение. В спокойных условиях, за чашечкой чая. Если за 10 минут не вышло — задача плохая, т.к. при стрессе вперемешку с обсуждениями и мыслями вслух, кандидат будет писать её минут 40.
                                                                                                0
                                                                                                Такой способ есть — поговорить про прошлый опыт, про то, какие задачи решал, чем пользовался и так далее. Если со слов опыт релевантный — брать на испытательный. Это лучший вариант узнать, подходит ли тебе кандидат. Другое дело, что далеко не все конторы до этого додумались, более того — это лишняя нагрузка на отдел кадров, но имхо это лучше, чем набрать черти кого по задачам на листочке, а потом думать что с ними вообще делать.
                                                                                                  0
                                                                                                  Вообще программиста берут на работу не разговаривать, а программы писать. :) Поговорить — это софт-скилл, важный но недостаточный.
                                                                                                    +2
                                                                                                    То есть вы правда считаете, что программист с большей вероятностью напишет код на листочке под прессингом интервьюеров, чем расскажет о том, чем занимался на прошлой работе? Рассказать про опыт — это не софт-скилл даже близко.
                                                                                                      +1
                                                                                                      Я считаю, что способность написать код на листочке под прессингом интервьюеров больше коррелирует со способностью писать код в IDE под прессингом начальства/команды/сроков и т. п., чем способность рассказать о своём (предположительно, но не факт) опыте под тем же прессингом.

                                                                                                      Это навык самопрезентации — главный, пожалуй, из софт-скиллов на собеседованиях, аттестациях и прочих разговорах об условиях сотрудничества. Сильно вам поможет «Чем занимался? Задачи делал. Какие? Разные. На каком стеке? В резюме написано. Что сложного было? Ну за неделю до годового релиза пришли новые требования, из-за которых пришлось неделю по 16 часов всё переписывать»

                                                                                                        0
                                                                                                        Ох, да ну вы серьезно? Часто над вами стоит ваш начальник и менеджер и смотрит что вы там делаете, когда вы пишете код? Если да, и вы все еще работаете в этом месте — то это какая-то ваша личная профдеформация, так быть не должно.
                                                                                                          0
                                                                                                          Прессинг не только в виде пристального взгляда может быть.
                                                                                                            0
                                                                                                            Может быть, а может и не быть. Взгляда, или не взгляда. А на «бумажном» интервью он будет точно, и это точно будет взгляд. Чуете разницу?
                                                                                                            Человек может не уметь хорошо работать в стрессе, это нормальная ситуация. А вот если в компании столько этих стрессовых ситуаций, что нужно проверять работоспособность кандидата в стрессе — это вот уже как раз совсем не нормально.
                                                                                                              0
                                                                                                              Ну пару раз мне давали занятия на бумаге, оставив одного и объяснив правила типа «названия функций/методов не бойся написать неправильно, если уж совсем не помнишь, то просто дай название, синтаксис тоже поскольку постольку, считай вообще что псевдокод пишешь». Так что тоже может быть, а может не быть.
                                                                                                          +1
                                                                                                          Сильно вам поможет «Чем занимался? Задачи делал. Какие? Разные. На каком стеке? В резюме написано. Что сложного было? Ну за неделю до годового релиза пришли новые требования, из-за которых пришлось неделю по 16 часов всё переписывать»

                                                                                                          Уточняем по одной (наиболее запомнившейся) задаче, и поехали дальше вглубь до примененных решений, а там и до уровня кода можно в отдельных местах копнуть? Не?
                                                                                                          Про жизненные случаи и то, как писался или не писался код — кандидат и сам очень даже расскажет, если его немного «разговорить» перед этим.

                                                                                                          Или у вас вызывает сопротивление то, что в этом случае вы остаётесь без бинарного результата (написал код на бумажке / не написал)? Так вы не экзаменатором должны работать, а собеседующим. Экзаменаторство прокатит в школе и в ВУЗе (и по этим же причинам оно более-менее сгодится для джунов без опыта).
                                                                                                            +1
                                                                                                            вы остаетесь вообще без понимания того, как кандидат подходит к написанию кода — все в кучу или разбито на функции, использует ли синхронизационный примитив или влепит спин-лок, как и в каком порядке подойдет к решению составляющих частей (начнет ли с самых важных кусков, обозначив утилити-функции только названиями или станет ковыряться в малозначащих вещах), как он подойдет к поиску ошибок, которые с большой вероятностью будут в коде. результат далеко не бинарный, результат дает множество данных о способностях кандидата.
                                                                                                              0
                                                                                                              Код или схема на бумажке для меня как раз предмет обсуждений (с обеих сторон баррикад), а не бинарный результат.
                                                                                                        0
                                                                                                        Другое дело, что далеко не все конторы до этого додумались

                                                                                                        Когда у вас поток по 2-3 кандидата в неделю, то оказывается, что дело не в «конторы не додумались». В крупных организациях на 1000+ разрабов поток бывает и по 10 кандидатов в неделю.
                                                                                                    +4
                                                                                                    Меня бы это сбило с толку хотя бы потому, что у меня жуткий почерк и я со школы ничего не пишу от руки. Это примерно как выполнить задание, стоя на голове.
                                                                                                      0
                                                                                                      Меня бы это сбило с толку хотя бы потому, что у меня жуткий почерк и я со школы ничего не пишу от руки.

                                                                                                      Почерк практически у всех плохой — это норма. Если что-то написано непонятно — интервьюер уточнит (а что ему ещё остаётся).

                                                                                                      Это примерно как выполнить задание, стоя на голове.

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

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

                                                                                                        В описании вакансии этому не место, но рекрутер всегда предупреждает потенциальных кандидатов об этом.
                                                                                                          +4
                                                                                                          Как раз таки место, просто вы понимаете, что после этого к вам никто не придет на чудесное собеседование, поэтому и тяните до последнего. Если бы это было круто и правильно — об этом говорили бы сразу, но вы прекрасно понимаете, что с этим «что-то не так».
                                                                                                            0
                                                                                                            Как раз таки место

                                                                                                            В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.

                                                                                                            просто вы понимаете, что после этого к вам никто не придет на чудесное собеседование

                                                                                                            Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов, если «никто не хочет на такие собеседования ходить»? Может проблема в ваших представлениях о том, что должен уметь скилловый разраб?

                                                                                                            поэтому и тяните до последнего

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

                                                                                                              А процесс найма это тоже «о компании».

                                                                                                              Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов

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

                                                                                                              Вы намеренно проигнорировали слова о том, что рекрутер всегда предупреждает человека?

                                                                                                              Я был бы рад, если бы информация о процессе собеседования была в вакансии, это просто личная хотелка, посыл был совсем не в этом предложении.
                                                                                                                +2
                                                                                                                «писать на листочке» — это обобщающее определение, означающее, что IDE использовать не дадут. это может быть доска, листочек, простенький текстовый редактор. гугл дает на выбор редактор с подсветкой синтаксиса (без возможности запустить код) или доску. многие дают сейчас такой выбор. некоторые уже даже позволяют запускать IDE (но не из top 10 компаний), хотя все еще есть места, где предпочитают маркер и доску.
                                                                                                                  +1
                                                                                                                  zuko3d:
                                                                                                                  Лично я, когда провожу собеседования, обязательно даю задачу, которую надо написать «без гугла». Желательно — на листке бумаги. Потому что когда человек пишет рукой на листке бумаги — у него нет возможности что-то легко поправить, где-то вставить строчку кода.

                                                                                                                  Так в том-то и дело, что человек не про обобщение говорит, а про прям листочек, именно к этому притензия.
                                                                                                                    0
                                                                                                                    Пока что я увидел фразу «пережиток прошлого» и ни одного конструктивного аргумента против. О том, что нет смысла — я уже написал, какой в этом смысл и эта практика даёт плоды.

                                                                                                                    Буду рад прочитать конструктивные аргументы против такого подхода.
                                                                                                                      +3
                                                                                                                      Хотите конструктива, его есть у меня:
                                                                                                                      1. Например, я хочу сперва решить основную задачу, а потом сосредоточиться на деталях. Что я делаю в редакторе?
                                                                                                                      def spam():
                                                                                                                          pass
                                                                                                                      
                                                                                                                      def egg():
                                                                                                                          pass
                                                                                                                      
                                                                                                                      def solve():
                                                                                                                          ...
                                                                                                                          spam()
                                                                                                                          ...
                                                                                                                          egg()


                                                                                                                      И после того как разберусь с solve(), я вернусь к spam() и egg(). Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?

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

                                                                                                                      3. Меня на собеседованиях иногда просили модифицировать решение, добавить А или Б фичи, с листочком вы тоже лишаете себя этой возможности.

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

                                                                                                                      5. Писать код от руки непривычно, человек уже под стрессом и в неудобной обстановке, так вы еще добавляете один фактор, который мешает, не получая преимуществ кроме вымышленных «думает, перед тем как написать» (wat?).

                                                                                                                      Итого: собеседование на листочке подходит только для эгоистичных интервьюеров, которые рассматривают собеседования как проверку кандидата на прочность в экстренных условиях, в которых ему не придется работать, а не как равный диалог о будущем кандидата в компании.
                                                                                                                        +1
                                                                                                                        Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?

                                                                                                                        Писать spam и egg после solve :-)

                                                                                                                          0
                                                                                                                          Немножко демагогия, но ладно.
                                                                                                                          Во-первых, если мы про Python, то это синтаксически неправильно.
                                                                                                                          Во-вторых, во время работы над solve я хочу видеть сигнатуру методов, при этом писать их после solve я не могу, потому что не знаю какой длины будет solve.
                                                                                                                          В любом случае, посыл не про это :)
                                                                                                                            0
                                                                                                                            А почему неправильно-то?

                                                                                                                            С сигнатурой сложнее, но можно сделать так: написать заглушку, использовать её, потом зачеркнуть заглушку и написать реализацию.
                                                                                                                              0
                                                                                                                              А почему неправильно-то?

                                                                                                                              Ну потому что методы должны быть объявлены до использования, иначе «name 'egg' is not defined»

                                                                                                                              но можно сделать так

                                                                                                                              А можно взять редактор и не делать людям мозг -_-
                                                                                                                                +1

                                                                                                                                Вот только использование происходит когда основная функция выполняется, а не когда она объявляется.


                                                                                                                                Если взять вот такой код:


                                                                                                                                def foo(): #1
                                                                                                                                    bar() #4
                                                                                                                                
                                                                                                                                def bar(): #2
                                                                                                                                    pass #5
                                                                                                                                
                                                                                                                                foo() #3

                                                                                                                                То окажется, что сроки кода выполняются в порядке 1-2-3-4-5, а функция bar используется строго после своего объявления.

                                                                                                                                  –1
                                                                                                                                  Согласен, но в вашем примере будет
                                                                                                                                  def solve():
                                                                                                                                      egg()
                                                                                                                                      spam()
                                                                                                                                  
                                                                                                                                  def spam():
                                                                                                                                      pass
                                                                                                                                  def egg():
                                                                                                                                      pass

                                                                                                                                  Что работать не будет.
                                                                                                                                    +1

                                                                                                                                    Блин, ну возьмите и проверьте уже!


                                                                                                                                    Вот чем ваш пример от моего отличается? Тем, что функций две вместо одной? Или именами? Вы уверены, что это что-то меняет?

                                                                                                                                      0
                                                                                                                                      Я немного запарился, извиняйте, у вас все норм, но еще раз, я говорил совсем не про это, я говорил про удобство редактирования.
                                                                                                                                      P.S. я говорил про такой вариант.
                                                                                                                          +1
                                                                                                                          Спасибо, конструктив понравился! Если есть ещё — пишите.

                                                                                                                          И после того как разберусь с solve(), я вернусь к spam() и egg(). Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?

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

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

                                                                                                                          Хочется проверить размер этого буфера. Я почти уверен, что вы в голове не одну строчку держите, а некий блок кода. И чем больше этот блок — тем лучше. Сначала я даю задачу типа «найти максимальный элемент». Кстати, даже с этой задачей уже не все кандидаты справляются (это было для меня открытием). Ну и потом по нарастающей. Есть кандидаты, которые BFS пишут с ходу (не олимпиадники).

                                                                                                                          3. Меня на собеседованиях иногда просили модифицировать решение, добавить А или Б фичи, с листочком вы тоже лишаете себя этой возможности.

                                                                                                                          Да, согласен. За всё приходится платить =) Но, если честно, у меня обычно не возникает желание модифицировать задачу по ходу.

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

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

                                                                                                                          5. Писать код от руки непривычно, человек уже под стрессом и в неудобной обстановке, так вы еще добавляете один фактор, который мешает, не получая преимуществ кроме вымышленных «думает, перед тем как написать» (wat?).

                                                                                                                          Так, писать от руки непривычно — согласен, это действительно проблема. А какой фактор добавляю? Не понял.

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

                                                                                                                          Не-не-не, никакой проверки на прочность. Интервью это стресс в любом случае, согласен. Но при чём тут эгоизм? Обычно у меня с кандидатом равный и достаточно свободный диалог (люди порой могут посмеяться над чем-то, или порассуждать на отвлечённые темы — это расслабляет), да и почти все собеседования, в которых мне надо было писать код на бумаге/доске тоже проходили вполне комфортно и я не чувствовал, что со мной общаются «свысока».

                                                                                                                          а не как равный диалог о будущем кандидата в компании.

                                                                                                                          Всё же техническое интервью — это не диалог о будущем, а проверка знаний и калибровка уровня кандидата. Диалог о будущем — это к HR'ам.
                                                                                                                            0
                                                                                                                            Сначала хотел ответить по пунктам, но мне уже лень, извиняйте =)
                                                                                                                            Коротко:
                                                                                                                            1. Заставлять писать кандидата на листочке — неуважение к нему, я не хочу работать в компании, которая изначально меня не уважает.

                                                                                                                            2.
                                                                                                                            проверка знаний и калибровка уровня кандидата

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

                                                                                                                            3. Чем листочек лучше редактора с подсветкой? Хоть одна «конструктивная» причина?

                                                                                                                            P.S. А по поводу вашего «сужу по опыту» у вас нет бОльшей части картины мира, поэтому выводы делать не очень дальновидно. Если бы провели 10000 интервью и половина из них была с листочком, а половина нормальных и вы могли бы снять все метрики — тогда да, ваш опыт что-либо значил, а пока вы выдаете желаемое за действительное, опираясь на дисбалансные данные и личные ощущения, а тут «здравствуйте» систематической ошибке выжившего, ложной корреляции и другим классным штукам.
                                                                                                                              –1
                                                                                                                              Вот вы считаете, что неуважение, а другие не считают. И могут считать, что кандидату так должно быть проще, чем дать IDE, но тогда и требовать работающий код.
                                                                                                                                +1
                                                                                                                                Этот разговор начинает затягиваться по непонятным для меня причинам.

                                                                                                                                В основе моей позиции простейший постулат и я искренне не понимаю как можно считать по-другому:
                                                                                                                                Программист работает на клавиатуре, не на листочке, значит, и проверять его надо на клавиатуре, на привычным инструменте, а не заставлять забивать гвозди дрелью. Здесь не противопоставление листочек — IDE, здесь противопоставление ручка — клавиатура.
                                                                                                                                  0
                                                                                                                                  Смотря что проверять. Далеко не всегда целью этапа «напиши код на бумажке» является проверка способности писать код на клавиатуре. Или является, но не единственной целью.
                                                                                                                                    0
                                                                                                                                    Извините, но я не совсем понимаю, о чем вы.
                                                                                                                                      0
                                                                                                                                      Вы, похоже, исходите из предпослыки, что целью задания «напиши код на бумажке» является проверка способности работать на клавиатуре. Но это не всегда так.

                                                                                                                                      С другой стороны, по личному опыту было несколько собеседований, которые я провалили, потому что требовали писать на клавиатуре.

                                                                                                                                      Вроде норм, да? Но я это счёл тестом на стрессоустойчивость: дали ноутбук с незнакомой клавиатурой (кажется отсутствовали клавиши Ctrl и Alt), незнакомой ОС, незнакомой IDE и, как добивающий, без мыши.
                                                                                                                                        0
                                                                                                                                        Я не исхожу из этой предпосылки, я лишь говорю, что проверка программиста на клавиатуре более репрезентативна, чем на листочке.
                                                                                                                                        Собеседование на программиста не должно быть тестом на стрессоустойчивость, оно должно быть собеседованием на программиста =)
                                                                                                                                          0
                                                                                                                                          Если работа предполагает стрессы, то проверка на стрессоустойчивость должна входить в собеседование. С одной стороны. С другой, предоставить привычное окружение программисту не всегда возможно за разумное время, а в непривычном это может быть стресс посильнее «бумажки».
                                                                                                                  +2
                                                                                                                  В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.

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

                                                                                                            +4
                                                                                                            А вы программист?
                                                                                                            Если нет то, то я поясню как сейчас пишется программа.
                                                                                                            В IDE начинаешь писать «for» затем выбираешь из списка подсказки оператор/функцию/переменную…
                                                                                                            затем IDE за тебя добавляет нужные скобки, кавычки, точки и т.д.
                                                                                                            Откуда у программиста детальное знание синтаксиса? а главное зачем оно ему? Интервью проходить?

                                                                                                            У сеньеров в голове 10-20 языков, причем многие похожи.
                                                                                                            Лично я не помню синтаксис создания классов и даже енумов. И не парюсь по этому поводу — это меньше 1% кода? причем стандартного и ошибиться там нельзя — IDE подскажет. Так зачем мне это помнить?

                                                                                                            >то крайне важное умение для того, чтобы писать код без багов
                                                                                                            Может для уровня джюниор?

                                                                                                            На уровне сеньера баги совсем совсем другие:
                                                                                                            Не верно продумал архитектуру базовых классов, из-за этого при сотом изменении ТЗ приходится делать костыли.
                                                                                                            Не так срабатывает удаление объектов, так как по мере разработки сильно поменялась их передача и создание. А «умные» подсказки про shared_ptr вызывают улыбку.
                                                                                                            И т.д.
                                                                                                              +2
                                                                                                              А вы программист?

                                                                                                              Да, программист. Опыт более 10 лет, успел поработать в нескольких крупных (5000+) айтишных организациях, сейчас я Senior SWE в одной из них.

                                                                                                              Откуда у программиста детальное знание синтаксиса?

                                                                                                              Вы же каждый (рабочий) день код пишете — как иначе?

                                                                                                              У сеньеров в голове 10-20 языков, причем многие похожи.

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

                                                                                                              Так зачем мне это помнить?

                                                                                                              И правда — зачем?.. Я, кажется, писал о том, что придираться к запятым и потерянным скобкам — глупость, мы таким не занимаемся.

                                                                                                              На уровне сеньера баги совсем совсем другие:
                                                                                                              Не верно продумал архитектуру базовых классов

                                                                                                              Согласен, что баги другие. Но как, по-вашему, человек продумает архитектуру сложного объекта, если он даже не может в голове удержать простую программу? Или вы считаете, что каким-то волшебным образом можно решать сложные задачи не умея решать простые?
                                                                                                                +2
                                                                                                                На своём опыте в успешных проектах видел не болоее трёх языков одновременно. При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.

                                                                                                                У меня прямо щас проект где ехал микросервис через лямбду и там используется Java, Python, Node.js, горы скриптов на баше и немного Ruby, на фронте реакт. Я коммичу во все места )))

                                                                                                                И есть еще один где PHP, Java, Ruby, лямбды на node.js и работа с OpenCV на питоне. Тоже коммичу во все )))
                                                                                                                  –2
                                                                                                                  Ваш проект приносит много денег? Стабильно ли он работает, легко ли проходят релизы? И при этом он уже много лет на рынке?
                                                                                                                  Кажется, на большинство вопросов ответ будет «нет».
                                                                                                                    +5
                                                                                                                    Ваш проект приносит много денег?

                                                                                                                    достаточно, чтобы спонсировать дальнейшую разработку

                                                                                                                    Стабильно ли он работает

                                                                                                                    конечно

                                                                                                                    легко ли проходят релизы

                                                                                                                    ваще изи, вы наверное не слышали про такую штуку как CI/CD, да?)))

                                                                                                                    И при этом он уже много лет на рынке?

                                                                                                                    define много? Три года — много или мало?

                                                                                                                    Кажется, на большинство вопросов ответ будет «нет».

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

                                                                                                                    То, что вы не работали с чем-то, или не видели чего-то, не значит, что другие не работают с этим или не делают. Если вы не видели больше 3х экосистем в рамках одного проекта — это значит лишь то, что вы просто не принимали участия в таких проектах, но не значит что таких проектов нет вообще, или они какие-то плохие.
                                                                                                                  +2
                                                                                                                  > На кой чёрт нужно в одном проекте 10 языков?

                                                                                                                  У многих нет одного-единственного проекта на всю жизнь.

                                                                                                                  > При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.

                                                                                                                  Если SQL, HTML и CSS считать за языки, то и 6+ на одного может легко набраться на одном проекте.
                                                                                                                    +1
                                                                                                                    Если SQL, HTML и CSS считать за языки, то и 6+ на одного может легко набраться на одном проекте.

                                                                                                                    Кстати да! А еще есть серверный js и клиентский ))) Тогда у меня легко десяточка будет )))
                                                                                                                      +2
                                                                                                                      Или клиентский ts и серверный js :)
                                                                                                                  0
                                                                                                                  В IDE начинаешь писать «for» затем выбираешь из списка подсказки оператор/функцию/переменную…

                                                                                                                  А на JavaScript IDE напишет for..in или for..of? :)
                                                                                                                  Вообще я с Вами в целом согласен, просто забавно. Тут скорее не очень удачное решение, сделать два очень похожих иногда разных варианта цикла.
                                                                                                                    0
                                                                                                                    Детальное знание синтаксиса нужно хотя бы для того, чтобы быстро и полностью понимать чужой код.
                                                                                                                      +2

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


                                                                                                                      Нет, серьезно, вы правда считаете, что никто не сможет понять, что означает "x = a + b", если в языке, которым он обычно пользуется, в конце надо ставить точку с запятой? Или что "fun powerOf(number: Int, exponent: Int) { ... }" объявляет функцию?

                                                                                                                        0
                                                                                                                        Так кажется тем, кто привык к простым языкам, вроде Java или Python. Мне как-то на собеседовании дали несколько задач на наследование C++, и я почти все их решил неправильно. Хотя написал десятки тысяч строк объектного кода на C++. Просто не знал ряда семантических нюансов, ведь современная ANSI спецификация C++ — это около 3000 страниц. Если бы такие конструкции попались мне в код ревью, я бы не смог его сделать как следует.
                                                                                                                          0
                                                                                                                          Мне как-то на собеседовании дали несколько задач на наследование C++

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


                                                                                                                          "Детальное знание синтаксиса нужно" и "спецификация C++ — это около 3000 страниц" это сильно разные вещи. Возможно, для код-ревью именно на C++ надо знать чуть больше синтаксиса, чем в других языках, но принципиально это ничего не меняет.

                                                                                                                          0
                                                                                                                          Предлагаю рассказать, что делает вот этот (между прочим, очень полезный и важный) класс и привести аналогичный пример из питона, джавы или что там нынче популярно:

                                                                                                                          template<typename Ret, typename ...Args>
                                                                                                                          class Function<Ret(Args...)>
                                                                                                                          {
                                                                                                                              using FunctionPointerType = Ret (*) (Storage, Args...);
                                                                                                                          public:
                                                                                                                              template<typename Callable>
                                                                                                                              Function (Callable callable) noexcept
                                                                                                                              {
                                                                                                                                  m_func_ptr = &trampoline<Callable>;
                                                                                                                                  new(reinterpret_cast<Callable *>(m_data)) Callable(callable);
                                                                                                                              }
                                                                                                                          
                                                                                                                              Ret operator() (Args ...args) const
                                                                                                                              {
                                                                                                                                  return (*m_func_ptr)(m_storage, std::forward<Args>(args)...);
                                                                                                                              }
                                                                                                                          
                                                                                                                          private:
                                                                                                                              template<typename Callable>
                                                                                                                              static Ret trampoline (Storage storage, Args ...args)
                                                                                                                              {
                                                                                                                                  Callable const *c = reinterpret_cast<Callable const *>(m_data);
                                                                                                                                  return (*c)(std::forward<Args>(args)...);
                                                                                                                              }
                                                                                                                          
                                                                                                                              FunctionPointerType m_func_ptr;
                                                                                                                              alignas(alignof(std::max_align_t)) char m_data[FunctionStorageSize];
                                                                                                                          };
                                                                                                                          


                                                                                                                          В этих 30 строках кода используется сразу несколько редких фич языка, и без них этот код не стал бы рабочим и полезным.
                                                                                                                            +3

                                                                                                                            Некая обертка для вызова функций. Желательно конечно пример использования посмотреть, в реальном коде это можно сделать.


                                                                                                                            ... означает список аргументов неопределеной длины, это понятно даже по названию типа.
                                                                                                                            new(m_data) видимо присваивание, раз выполняется в конструкторе.
                                                                                                                            alignas() скорее всего связано с платформозависимым выравниванием данных.
                                                                                                                            std::forward() видимо какая-то оптимизация, связанная с особенностями C++, это уже не синтаксис, а стандартная библиотека.


                                                                                                                            Чтобы просто понять, что делает код, достаточно базовых знаний синтаксиса C++ — указатели, шаблоны.
                                                                                                                            Для более детального понимания, например с целью изменить код чтобы он работал по-другому, надо поискать описание конструкций ..., reinterpret_cast, new(), std::forward(). Также надо знать про UB и как их избегать, это тоже уже не совсем синтаксис.
                                                                                                                            Конечно, джуниора на этот код нельзя ставить без присмотра, но разобраться и использовать, и даже изменить чтобы работало хотя бы в debug-режиме он сможет. Остальное подскажут на код-ревью, он запомнит, и в следующий раз сразу так будет делать.


                                                                                                                            Не знаю, как в Java или Python, в PHP это будет примерно так:


                                                                                                                            $func = [$this, 'someMethod'];
                                                                                                                            $args = [1, 2, 3, 4];
                                                                                                                            call_user_func_array($func, $args);
                                                                                                                          +1
                                                                                                                          Проблема понимания чужого кода находится на уровень выше чем синтаксис.
                                                                                                                          А для того что бы понимать, что это строка объявление класса или енума, Детальное знание синтаксиса ненужно.
                                                                                                                      +3
                                                                                                                      В целом, имел похожее представление о подобных задачах. Но недавно был на собеседовании в одну компанию, которая любит 4 часа писать код на доске и бумаге, и как-то резко поменял своё отношение к таким собеседованиям.
                                                                                                                      Из четырёх людей трое докапывались чуть ли не до запятой. Из часа, выделенного на общение с каждым, минут 35-40 я тупо писал и правил код без IDE, подсветки синтаксиса и даже возможности запустить творение.
                                                                                                                      Задачи, может быть, и интересный способ оценки, но в варианте «объяснить решение на пальцах». Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда. А написание кода на бумаге тупо тратит время и повышает градус неадекватности.
                                                                                                                        +4
                                                                                                                        Тоже встречался с таким (в качестве кандидата). В таких историях есть сильные косяки от интервьюеров:

                                                                                                                        Из четырёх людей трое докапывались чуть ли не до запятой

                                                                                                                        Я и мои коллеги-интервьюеры никогда не считаем это проблемой, т.к. ясное дело, что если человек пропустил точку-с-запятой в конце строки, то это либо от концентрации на самой задаче, либо от волнения. И то, и другое — вполне ожидаемо на собеседовании, так что лично я просто указываю кандидату, мол «запятую потеряли» — и даже не успеваю сказать где именно, а человек уже исправил. Если же интервьюер просто говорил «у вас программа работает некорректно» и ждёт исправления запятой — это косяк скорее интервьюера, нежели кандидата, т.к. таким образом ничего полезного не выясняется, а время (и нервы) тратятся.

                                                                                                                        минут 35-40 я тупо писал и правил код

                                                                                                                        Это вообще треш. Если решение занимает несколько листов А4 (ну или несколько исписанных досок) — это крайне плохая задача для собеседования. Вариант, что «кандидат настолько плох, что не догадался до короткого решения» я откидываю, т.к. головоломки с коротким и элегантным решением ничего полезного не проверяют. У задачи должно быть изначально видно либо короткое, либо эффективное решение.

                                                                                                                        Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда.

                                                                                                                        А вот тут я не согласен. На личном очень неприятном опыте убедился, что есть люди, которые могут объяснить решение, но не способны написать рабочий код. То баги сажают, то не компилируется под какие-то платформы, то просто пишут код, который делает совсем другое. Давно (ещё когда не было опыта собеседования) по ошибке брал таких людей (мол, главное чтоб соображал, а код написать кто угодно сможет) и для организации это выходило очень дорого.
                                                                                                                          +2
                                                                                                                          Я и мои коллеги-интервьюеры никогда не считаем это проблемой

                                                                                                                          Ну вот вы не считаете, а у большинства собеседуемых впечатление об упражнениях с бумажкой может быть именно таким, потому что им на пути всегда попадались «неправильные» собеседующие, а «правильных» днем с огнем не сыщешь. Поэтому у людей и горит от кода на бумажке.
                                                                                                                            0
                                                                                                                            в моей практике тоже не встречалось случаев, когда придирались к запятым. при этом я сам прошел десятки интервью и гораздо больше их провел. мы даем на выбор — писать или на доске, или на компьютере (не в IDE, но в редакторе с подсветкой синтаксиса). и примерно половина кандидатов-таки выбирает доску.

                                                                                                                            Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда

                                                                                                                            почти в половине случаев люди, которые очень хорошо рассказывают про решение, не могли его вменяемо написать.
                                                                                                                              0
                                                                                                                              А на что ещё указываете? Синтаксис, названия классов, функций/методов и т. п.? В общем указываете, что код просто не запустится нормально не из-за алгоритмических ошибок?
                                                                                                                                0
                                                                                                                                Я не указываю, вообще пофиг. Лишь бы алгоритм был правильный.
                                                                                                                        +10

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


                                                                                                                        Что касается "service objects", опять же странно недоумение автора. как можно не понимать таких элементарных вещей? Модель в RoR это обычно объект, соответствующий строчке в БД. Но часто нам нужно писать код, не работающий с БД вообще (условно, рассылающий письма, работающий с API итд), или код, работающий с несколькими разными моделями. Куда еще его помещать? В контроллер, может быть?


                                                                                                                        Статический анализатор не обнаружит нарушение принципов SOLID.


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


                                                                                                                        Другой пример: если человек не понимает, например, как работает ActiveRecord и связи, то он может написать неэффективный код, слишком медленно работающий или создающий нагрузку на БД, с грубыми ошибками именно из-за незнания.


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


                                                                                                                        И кстати, у многих кандидатов, даже с большим опытом, есть серьезные пробелы в знаниях. Банально: один толком не разбирается в нормализации или индексах в БД, другой не может описать примеры популярных уязвимостей в веб-приложениях, третий не понимает HTTP, и почти каждый 9 из 10 не пишет комментарии. Как вас вообще допускают код писать, ау?


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


                                                                                                                        (если вы читаете эти строки, попробуйте мысленно без запинки и "ну… это когда..." рассказать про 5 самых популярных уязвимостей и объяснить механизм их возникновения. Если не можете — вы не годны)

                                                                                                                          +3
                                                                                                                          зачем бахвалиться незнанием основ языка

                                                                                                                          Разжигать в комментариях! ))) Реакция публики очевидна — «ах как он посмел не знать синтаксиса, анафема!» и ожидаема. Статья получает больше просмотров, больше дискуссии, всем профит!

                                                                                                                          Кроме того, заметьте, что в итоге я всем советую заучить теорию и типовые вопросы чтобы не попадать в такие ситуации как я. Однако это не отменяет моего мнения что знание теории по большому счету ничего не значит.

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

                                                                                                                          Ерунду написали :D И я никого не обвиняю.

                                                                                                                          Что касается «service objects», опять же странно недоумение автора. как можно не понимать таких элементарных вещей?

                                                                                                                          Я имел ввиду не концепцию а название. Концепцию я использую (хотя может быть и не совсем в таком виде каким ее видят авторы, когда модель остается вообще чистой, как в стандартных Java Spring/Hibernate приложухах), понятное дело, а то что оно так называется — не знал.

                                                                                                                          Я не специалист в Руби, но знать, как работает вызов метода, конечно надо.

                                                                                                                          Лол зачем? Это нужно раз в год, когда ты достаточно неаккуратен для того, чтобы назвать метод в классе словом send и потом удивляться, почему у тебя мистические баги вылазят.
                                                                                                                          Знать нужно не порядок вызова методов, а, например, порядок срабатывания хуков ActiveRecord, или хотя бы просто иметь представление о том, что это такое.

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

                                                                                                                          Все верно, вот это — пример хорошего вопроса и постоянно возникающей рабочей ситуации. Но почему-то никто меня про это не спрашивал ))) А могли бы спросить, например чем отличается joins от includes, когда что использовать, как делать вложенные includes, как правильно писать валидации, что такое скоупы и так далее. Но чот никто не хотел (((

                                                                                                                          Если не можете — вы не годны)

                                                                                                                          Негоден для чего? Для вашей работы? Ну ок, пойду на соседнюю улицу оффера получать, там такой ерундой как секурити не заморачиваются ))) Годность или негодность определяет строго рынок а не комментаторы. Если рынку не нужны разрабы со знаниями тонкостей работы GC — никто не будет заморачиваться чтобы это учить просто так.
                                                                                                                            +3

                                                                                                                            Вот, кстати, мне еще и показалось, что у вас требования по з/п высокие. Вы, как я понимаю, живете в Украине и там, может быть, другая экономическая ситуация, но у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов. За 2500-3000, если подольше поискать, как мне кажется, вполне можно найти специалиста, который хорошо знает и теорию и перечисленные выше в моем комментарии вопросы. Непонятно, зачем ему предлагать 5 000 :) Мы же не в Калифорнии, у нас тут минимальная зарплата вообще 11500 рублей (ок, в Москве побольше — 19 000). На 5 000 долларов, мне кажется, это должен быть уникум из команды Вконтакте или крутой специалист из Яндекса со знанием всего, что можно. Разве я не прав?


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


                                                                                                                            Вот еще ниже спрашивают про комментарии. Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги? Или вы об этом не задумывались? Не приспособлены к работе в команде?


                                                                                                                            как правильно писать валидации, что такое скоупы

                                                                                                                            Ну это же какие-то очевидные вещи, которые наверно описаны в мануале по фреймворку. На 5 000 наверно нужны навыки получше, чем умение пересказывать мануал.


                                                                                                                            Ну ок, пойду на соседнюю улицу оффера получать, там такой ерундой как секурити не заморачиваются

                                                                                                                            Ну вот мы еще и выяснили, что вас не беспокоит качество получающегося продукта.

                                                                                                                              +4
                                                                                                                              Вот еще ниже спрашивают про комментарии. Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги? Или вы об этом не задумывались? Не приспособлены к работе в команде?

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

                                                                                                                                Есть не менее замечательная теория о том, что комментарии — всемогущее средство, если код непонятен. Увы, по опыту, это только теория. Комментарии обычно живут в отрыве от кода и при его изменении их часто просто забывают поправить. В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным. Хорошо написанный код и правда не нуждается в комментариях. На моей практике было очень мало реальных случаев, когда без комментариев прям совсем не обойтись. А если хочется написать комментарий к коду, который непонятен, то тут 2 варианта. Первый — код просто нуждается в рефакторинге и тут комментарий, ИТ как мёртвому припарка. Второй — сложная бизнес-логика, которую иначе не описать, кроме как снабдив сопровождающими описаниями. Заметьте, я сейчас не про докстринги, описывающие сигнатуры методов, а именно про комментарии в непонятном коде.

                                                                                                                                  +1
                                                                                                                                  простой код, как правило, в комментариях не нуждается. а вот сложный код — как раз наоборот. как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто. иначе может быть очень дорого чинить инцидент в проде, потому что кто-то улучшил какой-то кусок. кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии. но не пользоваться каким-то инструментом с объяснением «мы все равно им пользуемся неправильно» мне кажется странным.
                                                                                                                                    0
                                                                                                                                    > а вот сложный код — как раз наоборот.

                                                                                                                                    Я об этом и написал, это как раз 1 случай, когда код нуждается в рефакторинге.

                                                                                                                                    > как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто.

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

                                                                                                                                    > кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии.

                                                                                                                                    Кодбейз гугла разрабатывается уже не первый десяток лет, разрабатывают его инженеры с разным уровнем опыта и скорее всего там достаточно легаси, закладок на обратную совместимость, нестандартную оптимизацию и прочее. Никто не спорит, что если такие вещи явно не описать комментариями, то там все легко сломать.
                                                                                                                                    Но мы ж про простой код говорим) И про среднестатистические проекты, где таких мест, как правило, не очень много. Я хочу быть понятым правильно, я не против комментариев там, где без них реально не обойтись. Я против комментариев, которые представляются, как возможность описать код, который нужно переписать. Если код нельзя переписать, конечно пишите комментарий. Но, повторюсь, в моей практике таких случаев было не так уж и много, хотя они и были.
                                                                                                                                    0
                                                                                                                                    В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным.

                                                                                                                                    Вот ни разу не было, чтобы устаревший комментарий оказался вредным. А вот когда он помогал разобраться в текущем коде, было.

                                                                                                                                      0

                                                                                                                                      Не видел, значит не бывает?) Ну а у меня было) Ну и опять же, это ни о чем не говорит. На моём опыте так же было, что раз можно написать комментарии к каждому блоку, чё не запихнуть все эти блоки в одну большую функцию. Зато всё ясно и понятно, да и в одни месте. Так что в некоторых случаях вместо декомпозиции и рефакторинга предпочитают комментарии

                                                                                                                                        0
                                                                                                                                        Да нет, это скорее о вероятностях)
                                                                                                                                    +5
                                                                                                                                    Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается.

                                                                                                                                    Есть красивая теория, что код описывает, что надо делать, а комментарии — почему это надо делать.


                                                                                                                                    Например:


                                                                                                                                    def call_partner_api(params)
                                                                                                                                      # Если в API нашего партнёра передавать больше 8 знаков
                                                                                                                                      # после запятой, то у него что-то внутрях падает, поэтому
                                                                                                                                      # принудительно урежем точность.
                                                                                                                                      params[:blah] = params[:blah].round(8)
                                                                                                                                      send_request_to_api(params)
                                                                                                                                    end
                                                                                                                                    0
                                                                                                                                    у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов.

                                                                                                                                    На мой взгляд куда страннее собеседовать человека на позицию из окрестности 5000 баксов, и при этом спрашивать у него синтаксис языка или тривиальные алгоритмические задачки. Но вот почему-то спрашивают.
                                                                                                                                      +4
                                                                                                                                      а что, по-вашему, у него надо спрашивать? просто поговорить о высоких материях? а если он 10К попросит? а если 20К? Вообще без собеседования брать? Высокая зарплата не должна освобождать от требования уметь и понимать то, что умеет и понимает типичный мидл. Высокая позиция предполагает, что в дополнение ко всему тому у вас еще и отличное понимание архитектуры, организации процессов и еще чего-то там есть.
                                                                                                                                        +1
                                                                                                                                        а что, по-вашему, у него надо спрашивать?

                                                                                                                                        Давать норм тестовое задание (на час-два, а не на два дня), вопросы по дизайну, по архитектуре, про общение в команде, про взаимодействие с бизнесом.

                                                                                                                                        И у меня действительно спрашивали эти вопросы, но на позиции java-техлида или архитекта. Руби парни не спрашивали, хотя запросы по зп были одинаковыми и там и там.
                                                                                                                                          –4