Продолжаем говорить о технических собеседованиях (если вы не читали — просмотрите предыдущие статьи из цикла — о собеседованиях с HR и технических). В этот раз будет больше субъективного опыта, минимум советов, а также немножко про тестовые задания и теоретические вопросы. Поехали.
Disclaimer: автор — не турборазработчик, а обычная веб-макака без претензий. Поэтому приведенные задания и решения могут вызвать у вас улыбку, баттхерт и желание указать автору на его некомпетентность. С нетерпением жду вас в комментариях! :)
В прошлой части я описывал, что делал аж два тестовых задания: первое на DevOps Engineer, второе — на Ruby Developer. Расскажу, что же было дальше.
Продолжим тему тестовых заданий из предыдущей части и рассмотрим задачи на кодинг на собеседованиях.
Задачи могут быть нескольких типов: реализовать алгоритм, написать решение на псевдокоде, что-нибудь отрефакторить и так далее. Наши инженеры больше всего любят алгоритмические задачи.
Много людей, в том числе и я, считают, что эти задачи показывают лишь умение кандидата решать именно такие задачи, и совсем не показывают, как он будет справляться с реальными рабочими заданиями, которые, как правило, более высокоуровневые. Почему же их до сих пор дают? Я думаю, причина простая: интервьюеры просто не способны придумать что-то лучшее. А раз не можем придумать ничего лучше — давайте возьмем старые добрые инверсии строк, сортировки, балансировки деревьев и прочее.
В качестве инструментов, которые используются для решения, лучше всего подойдет редактор кода + repl + возможность коллаборации. Из всех вариантов, которые есть на рынке, мне больше всего нравится CoderPad. Создается комната, куда подключаетесь вы и интервьюеры, можно вместе редактировать, выполнять код и смотреть на результаты выполнения. Очень удобно. Если нет денег на кодерпад, то в бой идет repl.it и шаринг экрана — в принципе то же самое, только без возможности коллаборации.
Upd: пока переводилась статья, repl.it добавили Multiplayer Mode, который позволяет неограниченному количеству участников одновременно работать с кодом. Совершенно бесплатно! CoderPad уже не нужен, ура!
Какую ошибку допустил я — сразу бросился писать код, не уточнив три раза, правильно ли я понял условие. Если вам будут давать такие задачи на собеседованиях, тосразу отключайтесь от чата и найдите себе более интересное занятие уточните несколько раз, правильно ли вы поняли условие, напишите в редакторе тест и получите у интервьюера подтверждение, что все корректно.
К сожалению, из всех собеседований, такие задачи были у меня только на трех, поэтому выборка маленькая. Возможно, есть еще какие-то более хитрые тесты/задания, но я на них не попадал.
Это моя любимая часть. Все любят спрашивать теорию, давайте немного пройдемся по этому.
Почему-то так получилось, что больше всего теорию меня спрашивали на позициях Ruby Engineer. Я знал её хуже всего, поэтому постоянно заваливал собеседования и выглядел джуном, пока не понял, что дальше так не годится продолжать. Я сел и прочитал учебник по языку, который позволил мне выступать значительно качественнее и без нытья «Ребята, зачем вы меня об этом спрашиваете? Я хороший разработчик, какая разница, какой порядок поиска метода у объекта? Кому это нужно?».
Итак, мне отказали, потому что я не знал основ языка (Ruby). Ок, едем дальше.
После двух провалов я понял что так быть не должно и нужно почитать теорию. Если её спрашивают — нужно знать. Никто не хочет верить в то, что я хороший парень просто так и давать нормальные задачи, поэтому я сел, прочитал учебник, и…
Какой вывод можно сделать из этих трех собеседований? Между ними прошло несколько дней. За это время я не сделал новый проект, не получил новых знаний или новый опыт, не стал более лучшим разработчиком, нежели был. Я каким был, таким и остался! Знание теории на практике мне не добавило абсолютно ничего (извините за каламбур). Просто, вместо того, чтобы заблаговременно прочитать Cracking Ruby Interview, я решил наступить на все грабли сам. Думаю, еще два-три таких собеседованиях и моя «сеньорность» не будет вызывать ни у кого сомнений, не смотря на то, что на самом деле я какой макакой был, такой и остался :)
Еще несколько историй и с чистой теорией будем завязывать.
Про SOLID спросили, кажется, всего два раза: один раз на Ruby-позицию, второй раз — на Java. Про DRY не спрашивали :)
Поэтому, каким бы бессмысленным это не было, но советую вам:
Пока что все, опять много текста, надеюсь вам было интересно. В следующей части будем говорить о вопросах по поводу прошлого опыта, вопросах о системном дизайне, вопросах «на подумать и порассуждать» и других вещах, которые уже больше похожи на правильное техническое собеседование.
Не забывайте подписываться на мой телеграм канал (я там пишу текста поменьше, но такие же интересные), заходите почитать бложек, и до следующей статьи!
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).После этого я переосмыслил свое отношение к таким задачам. Обычно для меня никогда не было проблемой закодить что-то под присмотром, но тут сработало несколько факторов: моя заявка на серьезную позицию, недостаточное понимание базовых конструкций языка (хотя они мне никогда не были нужны, а если бы и были, то загуглить решение можно за 5 секунд) и эффект наблюдателя. Конечно, я читал, что множество людей не могут решать задачи, когда на них смотрят, но мне всегда казалось, что это какое оправдание собственной неуверенности и некомпетентности, пока я сам не попал на этих суровых ребят с each_slice.
Сам метод я написал более-менее быстро, но он не работал, и я никак не мог понять, почему. Я начал немного паниковать, удалил все и написал заново, но мой код снова не работал как нужно.
«Не пошло», — подумал я и сказал своим собеседникам: «Парни, знаете, я вот хорошо умею в веб-макакинг и делаю проекты, но с вашими дурацкими задачами у меня что-то не получается. Я понимаю, что это простая задача и человек с 10-ю годами опыта просто обязан её быстро сделать. Так что давайте я не буду вас больше задерживать, и мы разойдемся». Парни согласились, на том и расстались.
У меня серьезно бомбануло, потому что я не привык так просто проигрывать. Чтобы хоть как-то выйти в экзистенциальный плюс, я написал рекрутеру, что сломался на задаче, которая не имеет отношения к реальной работе. Потом успокоился, сел, быстро протестировал как работают индексы в циклах. Понял, что я совершил джуниорскую ошибку, переделал индекс и получил готовое решение. Фактически, ошибка у меня была в одной строке. Я сказал об этом HR и предложил ей передать ссылку на решение парням, если им интересно, потому что я все-таки решил задачу. Но она ответила: «Вы не прошли дальше, потому что не решили задачу,прощайте». Я еще немножко поныл ей про сломанные процессы собеседований, чтобы как-то себя оправдать и мы расстались.
Еще у меня было собеседование на позицию Java Developer. В этот раз оно проходило в несколько другом формате. Мы связались по Zoom и интервьюер говрит: «Скажи свой e-mail, я тебе вышлю задачу, почитаешь, скажешь, все ли понятно. У тебя будет два часа, я буду на мьюте и не буду смотреть, что ты там делаешь (экран не шарим). Через два часа выходим на связь, шаришь экран и смотрим, что ты там сделал. Пользоваться можно чем угодно». Я почитал условия задачи, проговорил еще раз её с интервьюером, отключил видео (потому что кодирование потока кушает CPU) и замьютился. Открыл IDE и начал работу.Чем было хорошо это задание?
Задание было связано с I/O — нужно было сделать API для записи данных в файл на диске, так, чтобы все было thread safe и быстро, и еще написать юнит-тесты, которые бы проверяли это (в т.ч. потокобезопасность). Давно не работал с concurrency и I/O, поэтому пришлось быстро пробежаться по докам и вспомнить что к чему. Я написал решение в лоб, проверил что оно потокобезопасно и так далее. На все про все у меня ушло примерно полтора часа. Я пинганул своего интервьюера, сказал что я уже готов, но осталось только мелочи отполировать, будем смотреть? На это он ответил: «Давай еще полчасика посиди и доделай все, что не доделал». Ок, я сел и довел до ума все мелочи и шерховатости, дописал джавадоки, еще раз прочитал все что мог про I/O и подумал, какие могут быть недостатки у моего решения.
Через полчаса мы вышли на связь, я расшарил экран, показал код, запустил тесты и так далее. Следующие полчаса мы говорили строго о решении задачи и возможных вариантах его модификации при изменении тех или иных условий. Хочу обратить внимание на то, что на предыдущих собеседованиях (да и на последующих тоже) никто задачами не готовил базу для разговора, она всегда была просто каким-то абстрактным куском, который давал на выходе 0/1 и мы переходили к следующему вопросу. А тут задание было достаточно простым, чтобы его можно было сделать за пару часов, но в то же время достаточно основательным, чтобы можно было добавить условий и обсудить с кандидатом, как бы он дорабатывал решение.
Мне это собеседование очень понравилось. Я смог показать что не только fizz buzz умею решать, но и что-то понимаю в архитектурах. Интервьюер убедился, что перед ним сидит не джун, а специалист, который что-то отстреливает в своей работе. Это было лучшее техническое интервью из всех, которые у меня были. Думаю, вы уже догадались, что интервьюер был не из наших :) Добавлю так же, что я успешно его прошел, потом еще два этапа и в итоге получил оффер. Но это уже другая история.
- Приближенность к реальной работе, к тому, чем занимаются в той компании.
- Ограничение по времени.
- Отсутствие наблюдения.
- Возможность пользоваться чем угодно а не проверка памяти.
- Создание базиса для дальнейшего разговора.
- Проверка умения канидата кодить, пользоваться IDE и думать в целом.
К сожалению, из всех собеседований, такие задачи были у меня только на трех, поэтому выборка маленькая. Возможно, есть еще какие-то более хитрые тесты/задания, но я на них не попадал.
Типичные недостатки задач на собеседованиях
- Задание никак не касается реальной работы. Меня это раздражает больше всего. Дают решать алгоритмы, хотя на самом деле круды клепают. Давайте релевантную задачу, сделаю вам круд! Зачем вам человек, который умеет подстроки в строках искать?
- Организационно — часто отсутствует нормальный инструмент для решения. Один раз мне показывали код в google docs, один раз я шарил экран в repl.it, один раз был CoderPad.
- Задача не создает контекст для дальнейшего разговора — это следствие первого пункта. Зачем давать задачу если потом не будем её обсуждать?
- Не все люди могут справиться с заданием под присмотром. Соответственно, хороший кандидат может отсеяться еще на этом этапе.
Теоретические вопросы
Это моя любимая часть. Все любят спрашивать теорию, давайте немного пройдемся по этому.
Почему-то так получилось, что больше всего теорию меня спрашивали на позициях Ruby Engineer. Я знал её хуже всего, поэтому постоянно заваливал собеседования и выглядел джуном, пока не понял, что дальше так не годится продолжать. Я сел и прочитал учебник по языку, который позволил мне выступать значительно качественнее и без нытья «Ребята, зачем вы меня об этом спрашиваете? Я хороший разработчик, какая разница, какой порядок поиска метода у объекта? Кому это нужно?».
Первое собеседование, которое я проходил на позицию Ruby Developer, было как раз тем, где нужно было делать тестовое задание, однако, как оказалось, оно никого не интересовало. Тимлид, который должен был со мной общаться, не пришел (в пробке стоял или что-то такое), поэтому мне выдали другого. После знакомства он говорит: «У меня есть правило — я все собеседования провожу на английском, поэтому переходим на английский». И тут мои уши скручиваются в графеновую нанотрубку, потому что у интервьюера очень сильный акцент. Это меня несколько выбило из колеи (мне очень тяжело общаться с соотечественниками на английском).
Дальше пошли вопросы: что такое модуль, что такое блок, что такое yield, — и я начал фейлить. Вместо определения «как в учебнике», я начал лепетать: «Ну, не знаю точного определения, но, наверное, это вот такая штука, я её применял вот так». Интервьюер был недоволен, я это начал чувствовать и тогда подумал что все, приехали.
Дальше были вопросы о конкретных методах, а именно: «Как называется метод, который фильтрует все нилы в коллекции?». Тут я уже включил тролля и ответил: «Если вы проверяете мою память на знание этих методов, то я не могу вам ничего рассказать о том, чего не использовал недавно. Я пишу на многих языках и платформах и не помню всех методов SDK». Интервьюера это не удовлетворило, и следующим вопросом было что-то вроде: «Что такое Enumerable? Назовите, какие там есть методы и кто его экстендит». «Дядя, ты шо, не понял?», — подумал я про себя, но вслух сказал: «Не знаю точно, думаю, что какие-то методы типа map/reduce/slice и тд». Ему это тоже не подошло.
Дальше он задал мне стандартный вопрос о том, куда в MVC засовывать логику. Я ответил что в модели, а если в модели не влазит, то в какие-то другие классы. Оказалось, что верным ответом были так называемые Service Objects (неужели эта дрянь и сюда добралась?). Я что-то буркнул в ответ, типа, ну можно и так называть, но мне это не нравится.
Дальше он спросил дефолтный вопрос про SQL, на который я уже смог грамотно ответить, потом спросил про RSpec, который я не использовал, вот и все. По Rails (а у них как раз были рельсы) я не получил ни одного вопроса. Так же, ни одного вопроса я не получил и о своем предыдущем опыте.
После этого он спросил у меня, что я думаю о daily стендапах. Тут я уже решил не давать социально ожидаемых ответов (сгорел сарай — гори и хата!), а сразу сказал что это напрасная трата времени и практикуется в командах, где менеджер не может обеспечить прозрачность и удобство отчетности по прогрессу. И еще добавил что Scrum — это фигня на постном масле, и никто у нас нормально по скраму не работает, а все только делают вид. Очевидно, что я тут еще нахватал минусов.
Дальше он предложил задать вопросы ему (видимо из вежливости), и я, на свою голову, спросил про процесс, архитектуру и так далее. То, что я услышал, мне не понравилось, потому что они много занимались велосипедостроением для типовых задач. Я хотел дать понять парню что я не просто разработчик, а умею чуть больше, но все было напрасным, и вскоре он сказал что ему пора на митинг и отчалил.
На следующий день мне написала рекрутер и сообщила об отказе. «И слава Богу», — подумал я, но все-таки немножко подгорело. У меня создалось впечатление, что интервьюер с самого начала имел какие-то предубеждения, не знаю. Кстати, это была та самая контора, которая тянула месяц от первого контакта до технического собеседования.
Итак, мне отказали, потому что я не знал основ языка (Ruby). Ок, едем дальше.
Еще одно собеседование на Ruby Debeloper, уже двое собеседующих. Хорошо что хоть говорят один на русском, второй — на украинском, поэтому не пришлось ломать себе мозг. К моему удивлению, начинается та же история: что такое модули, что такое блоки. Я тогда еще не прочитал учебник, поэтому снова плавал в ответах. Дальше спросили о видах ассоциаций в Rails. «Наконец-то хоть что-то», — подумал я, и назвал три вида по памяти. Интервьюерам это не понравилось (потому что их было больше), как и то, что я сказал: «За остальными я лезу в доку». Дальше они дали мне то задание, которое я описал выше — про each_slice. После этого, как вам уже известно, я предложил закругляться. Один из интервьюеров напоследок решил попытать счастья: «У меня тогда последний вопрос, вы когда-то писали Rack middleware?». Не знаю, что он хотел услышать. Я сказал что не писал, но знаю, что это такое (типа фильтров в Java Servlets, или middleware в каком-нибудь Laravel/Express), и могу быстро разобраться при необходимости. И снова их это не устроило, поэтому наш разговор закончился.Опять, никого не интересовал ни мой опыт, ни мои знания в построении решений или в смежных сферах. Я не осуждаю тех парней. Может им действительно нужны программисты, которые прямо сейчас знают, как нужно писать rack middleware, однако думаю, что на самом деле они просто не умеют проводить собеседования.
После двух провалов я понял что так быть не должно и нужно почитать теорию. Если её спрашивают — нужно знать. Никто не хочет верить в то, что я хороший парень просто так и давать нормальные задачи, поэтому я сел, прочитал учебник, и…
Третье интервью на Ruby Developer. Тимлид снова в отпуске, поэтому со мной говорил простой разработчик. Те же самые вопросы про модули и блоки, но я уже был во всеоружии, поэтому даю корректные ответы. Интервьюер идет дальше и спрашивает у меня что такое Proc, но и тут я даю верный ответ, хотя никогда не пользовался этим :) Тогда он решает пустить в ход тяжелую артиллерию и задает вопрос: «Назовите порядок поиска метода для вызова, если у нас есть класс, он экстендится от другого, а еще есть модуль и еще что-то там». Тут я уже не знал 100% верного ответа, поэтому попробовал как-то логически предположить, какая цепочка должна быть. Угадал половину.
Дальше был еще вопрос вроде такого: «каким образом работает require». У этих ребят уже был не Rails а Grape, поэтому, наверное, для них это было актуальным. Я опять ответил «сходу не знаю, но наверное вот так и вот так». Кажется, не угадал. Дальше были какие-то вопросы-паззлеры, типа «вот кусочек кода, что он выведет?». Потом немного поговорили про ActiveRecord — тут уже я почти на все ответил верно, потому что имел с ним хороший опыт.
Потом он начинает меня спрашивать про concurrency (тут мне стало смешно). Я не знаю точно, какая модель concurrency в Ruby — так я ему и отвечал. Добавил что знаю о примитивах синхронизации, атомиках, мьютексах и прочем. Пытался намекнуть, что ваше конкарренси в MRI — тухлая рыба в сравнении с JVM и щас я вам тут расскажу про модели памяти, разницу между volatile и synchronized и буду цитировать Шипилёва, но интервьюеру это не зашло. Корме того, он признался, что в проекте они (не может быть!) concurrency не используют. Кто бы мог подумать? Зачем тогда спрашивать?
Дальше ведущий решил покрасоваться и спросил, знаю ли я что-то про SOLID. Я сказал что точную расшифровку забыл, смысл всего примерно переводится как «Нормально делай — нормально будет», а все функции по написанию солидного кода я зааутсорсил рубокопу. Интервьюер со мной не согласился, и конструктивного диалога у нас не получилось. Это был единственный раз, когда меня спросили про баззворды. После этого мы уже больше говорили о каких-то архитектурных решениях, подходах и прочем. В итоге меня пропустили дальше, а в конце я получил оффер с пометкой «не знает основ языка». Но об этом позже.
Какой вывод можно сделать из этих трех собеседований? Между ними прошло несколько дней. За это время я не сделал новый проект, не получил новых знаний или новый опыт, не стал более лучшим разработчиком, нежели был. Я каким был, таким и остался! Знание теории на практике мне не добавило абсолютно ничего (извините за каламбур). Просто, вместо того, чтобы заблаговременно прочитать Cracking Ruby Interview, я решил наступить на все грабли сам. Думаю, еще два-три таких собеседованиях и моя «сеньорность» не будет вызывать ни у кого сомнений, не смотря на то, что на самом деле я какой макакой был, такой и остался :)
Еще несколько историй и с чистой теорией будем завязывать.
Было у меня собеседование на Fullstack Java Developer. Меня предупредили что оно будет состоять из двух частей — бекенд и фронтенд. Последний я знаю не очень хорошо и сообщил об этом рекрутеру, но они решили идти дальше. Ок, связываюсь с парнями, начинаем с Java.Хотя эти люди тоже пытались вытащить из меня какие-то чисто теоретические вопросы, но сам фронтендер признал, что таких практических задач они не имеют. Фронт на jQuery, и нужно уметь в него. Я сказал что умею и проблем нет :)
Честно говоря, вопросы были ни теоретическими, ни практическими, а какой-то нудной тягмотиной. Думаю, что человек, который со мной разговаривал, сам толком не знал, что ж такого спросить. Тем не менее, как многажды стрелянный воробей, я отвечал как нужно.
Перешли к фронту. На том конце сидел уже чисто фронтендер. Начал меня спрашивать про прошлый опыт, а потом перешел к паззлерам, типа, что будет если undefined сравнить с null, как работают области видимости и var. Еще несколько дефолтных вопросов по JS и снова перешел к WAT-вопросам. Я сразу сказал: «Слушайте, я с вашим WAT никогда в жизни не имел дела. Если очень нужно будет, я погуглю, но я считаю что эти знания некуда применять, кроме как посмеяться с пацанами на митапчиках». Интервьюер со мной согласился, но все равно продолжил задавать паззл-вопросы. В итоге он посоветовал мне прочитать книгу «JavaScript: The Good Parts», после чего я еще поговорил с менеджером и на том разошлись.
Мне быстро сообщили, что я подхожу, и будут назначать собеседование с заказчиком. Через некоторое время опять вышли на связь и сказали что заказчика не устраивают мои знания фронтенда (?) и поэтому он не хочет иметь со мной дела, но они (аутстаф контора, которая мою голову перепродавала) будут пытаться его переубедить, потому что по их мнению все ок. После этого никто мне уже не писал. Наверное, не переубедили :)
И еще было у меня собеседование на DevOps Engineer, где я делал тестовое. Перешли к разговору и тут интервьюер спрашивает: «А что такое маска подсети?». Тут-то я и посыпался :) Сказал что это количество циферок, которые обозначают адрес подсети, а все остальное — это диапазон. Но что с этим делать уже не помню, давно не настраивал сетей. Хорошо, что интервьюер оказался адекватным, подвел меня к правильному ответу и не обращал внимания на то, что на такой простой вопрос я не смог сразу дать верный ответ. Дальше собеседование проходило уже без теоретических вопросов. Стоит ли упоминать что собеседующий снова был из другой страны (хотя и с советским бэкграундом)?Меня удивило что перестали вообще спрашивать про шаблоны проектирования (кроме того случая про MVC). Всего (ха-ха) 5-10 лет тому назад буквально на каждом собеседовании проверяли знание паттернов. Я еще с того времени почти все их (из GoF) знаю на память и еще и могу реализовать на бумажке. Но в этом году среди всех собеседований я не получил ни одного вопроса по шаблонам. Ruby-разработчиков, наверное еще можно понять, — они, наверное, про них ничего и не знают (у них есть MVC и ActiveRecord и этого достаточно). Но отсутствие таких вопросов на Java-собеседованиях меня очень удивило.
Про SOLID спросили, кажется, всего два раза: один раз на Ruby-позицию, второй раз — на Java. Про DRY не спрашивали :)
Какие можно сделать из этого всего выводы?
- Теорию до сих пор любят спрашивать, особенно наши с вами соотечественники.
- Знание теории не гарантирует знание практики, поэтому к теории любят добавлять задачи.
- Умение ответить на вопросы или решить задачу не гарантирует, что человек умеет программировать.
- Незнание теории или фейл с решениями задачи не означают, что перед вами плохой разработчик.
Поэтому, каким бы бессмысленным это не было, но советую вам:
- Перед собеседованиями изучить типовые наборы вопросов по вашему языку/платформе и хорошенько их заучить. Знать неоднозначные вопросы, ответы на которые просто так не выведешь. Один из моих любимых таких вопросов: «Какой есть недостаток в использовании прокси-AOP по сравнению с AspectJ в Spring?» :) Это нужно, чтобы легко проходить собеседования с интервьюерами, у которых не хватает фантазии на нормальные вопросы.
- Порешать типовые алгоритмические задачки на LeetCode и подобных ресурсах, чтобы быть к ним готовым.
Пока что все, опять много текста, надеюсь вам было интересно. В следующей части будем говорить о вопросах по поводу прошлого опыта, вопросах о системном дизайне, вопросах «на подумать и порассуждать» и других вещах, которые уже больше похожи на правильное техническое собеседование.
Не забывайте подписываться на мой телеграм канал (я там пишу текста поменьше, но такие же интересные), заходите почитать бложек, и до следующей статьи!
Denis631
Я не знаю почему в ваших глазах, заданные вопросы про:
вы видите как теоретические. По мне так это очень даже практические вопросы. Вещи которыми пользуешься каждый день.
Более теоретические (в моем понимании) это:
и так далее
Вы тем самым показали, что не владеете инструментарием и скорее всего (из-за не знание основ) гавнокодите.
r0zh0k Автор
Я тем самым вообще ничего не показал, потому что на следующем собесе на эти вопросы ответил и в итоге получил оффер (правда не на 5к как рассчитывал а всего лишь на 4.5к :)))
crmMaster
4.5k гривен? Вас даже переоценили, с вашими то глубокими знаниями в руби. Видимо кадровый голод настолько сильный, что уже берут всех, кто хоть немного шарит в программировании и хочет программировать на руби.
А еще вы очень хорошо показали в статье что навык проходить собесы приходит с опытом :)
r0zh0k Автор
Беларусских рублей )))
Timpo
У вас проблемы с логикой
Во-первых если тест имеет вероятность ложноположительного результата выше нуля, это еще не значит что тест плохой.
Во-вторых между собеседованиями вы провели обучение и закрыли какие-то пробелы в знаниях, а значит стали лучше, то есть вы не такой же как были на первом собесе.
Все потому и проводят по-разному интервью, что нет единого лучшего способа их проводить. Все методы имеют недостатки, их конечно можно на этом основании критиковать, но проводить то как-то надо) Вы наверно и сами согласитесь, что кандидат ответивший на 5 теоретических вопросов правильно, при прочих равных (или неизвестных) лучше кандидата который на них не ответил.
Wesha
Писал и пишу на Ruby с 2006 года, за всё время использовал эту фичу 3 раза. ЧЯДНТ?
Denis631
У меня для вас плохие новости
Lalartu
Не знаю насчет С#, но в Python и Scala yield — это разные вещи, я б не стал их сравнивать.
tyler_derden
Вот конкретно такие вопросы — бессмысленные. Если кто-то зазубрит названия всех методов, это вовсе не будет значить, что он знает язык и хорошо кодит. Достаточно общего представления о возможностях (что так или примерно так можно, дальше уточнить в документации). На вскидку названия этого метода не припомню, но это ничуть не помешало использовать его не так давно.
mclander
Зависит от того, кто что использует.
Меня в JS бесит reduce-мания. Я на практике использовал reduce пару раз, поскольку не считаю, что reduce даёт читаемый код (часто проще обойтись map).
Но если я приду в контору у которой всё на reduce, то ессно буду выглядить бледно, потому что хоть знаю как работает reduce, но он у меня «не наработан».
Та же беда с SQL. Я не люблю joinы с использованием join, предпочитая джойниться в where. Для ребят у которых join на джойне, будет важно понимаю ли я чем отличается righ outer join от left inner. А я ведь с ходу не скажу ничего. Поскольку привык реализовывать это через exists и *= (в оракле).
Другое дело, что перестроится, что на reduce, что на join мне пробела особых на будет, но вот верит ли в это интервьюер? )))
r0zh0k Автор
Я тоже, только в MySQL такой фокус не пройдет )))
mayorovp
Вот только условие в where может заменить лишь внутренне соединение (inner join) или внешнее, но только с проверкой ключа на is null. Все остальные варианты соединений на условие в where не способны заменяться в принципе. По крайней мере, за пределами Oracle. Кстати, left inner join не бывает.
mclander
Правда? Приведите пример, пожалуйста.
Я лет 10 занимался проектированием и программированием БД. И всегда хватало обычного where. Вложенные запросы с exists и in как правило решают проблему.
Все современные БД, умеют оптимизировать запросы с exists/in равно как и join'ы поэтому всё дело вкуса (и соглашения в текущей команде), имхо
mayorovp
Вот, держите:
dss_kalika
Вы это… полегче с ними ))
На самом деле важное, я бы сказал в следующем:
Мне, просто, всегда казалось что именно в этом основной смысл «join», а не в фильтрации )
mclander
Единственная разница в том, что у в выборке не будет кучи пустых полей из bar. Для того, чтобы её получить надо более сильное колдунство
mayorovp
Ваш запрос вернет только те записи из foo, для которых не существует записей из bar — а надо-то все. Причём вместе с данными из bar!
mclander
Да, согласен. Перепутал join'ы, почему-то мне outer почудился, о чем ссно писал выше (что не готов с листа читать / писать join синтаксис)
Для выборки всего действительно «старый синтаксис» не подойдёт либо нужно будет делать извращения с union или агрегацией
mayorovp
outer вам не почудился, полное название left join — left outer join
mclander
Ок. Вы меня победили )))
Я же говорю, что join'ы это не моё. И время, чтобы в них въехать. И наша дискуссия это подтверждает. Практически уверен, что вы бы не взяли меня на работу.
Потому, что после того, как я так показательно сел в лужу, спрашивать, что собственно я делал такими кривыми руками, какие задачи решал, какие объёмы баз данных и насколько сложная там структура — смысла нет.
PS. На пред-предыдущеё работе за 5 лет работы с Oracle использовал =* (left join) два раза, на 40К+ строк PL/SQL. Но возможно мои задачи можно было решать и без него, где-то left join может осознанно и аргументированно использоваться очень активно
mayorovp
Конечно же смысла нет, если вы знаете только Oracle, а в вакансии требуются MSSQL или Postgres...
mclander
Ну был небольшой опыт)
sved
Не все, у Оракл перформанс часто проседает. Кроме того с джойнам проще писать базонезависимый код, там где это важно.
zagayevskiy
map и reduce это же принципиально разные инструменты, как это вы одним обходитесь?
mclander
Я использую lodash — там много инструментов)
Я про то, что часто достаточно использовать map или for in/of, а не гордится, что любую проблему можно, а поэтому нужно решать с помощью reduce
zagayevskiy
Я, видимо, чего-то не понимаю. Допустим, вам надо просуммировать числа в массиве. Логично использовать reduce. Допустим, вам надо возвести числа в в массиве в квадрат. Логично использовать map. Допустим, вам надо возвести числа в квадрат, а затем — просуммировать. Логично использовать map+reduce.
Тут нечем гордиться, это просто инструменты одного уровня. И точно так же глупо говорить
AnutaU
map можно выразить через reduce. Но «обойтись map» действительно проще. В таком случае нет противоречия ?\_(?)_/?
mclander
С точки зрения скорости использовать reduce выгоднее. Но если у меня нет потребностей скрупулезно экономить ресурсы, то я напишу
Для меня это гораздо лучше читается, чем
Потому что в первом случае мы делаем две атомарные операции: (1) суммируем массив (2) квадратов исходного массива
В данном конкретном случае сложность чтения невысокая, но если нам надо например просуммировать квадраты всех чисел от двух и больше
Да оба примера выглядят грязно. Можно использовать chain запись — она тут читается идеально
Но, в плане улучшения читаемости кода, у нас есть возможность раскрыть часть функционального выражения через временную переменную (которую V8 на легко заоптимизирует)
В reduce раскрытие кода хуже читается, потому на русском языке проще сказать — как написано выше: фильтруем всё что меньше 2, остальное возводим в квадрат и суммируем
Так же у нас есть возможность использовать for
PS. Написал lodash во всех случаях для простоты сравнения
PPS. Вообще меня в reduce бесит то, что инициализация — последний параметр. По мне было бы не в пример удобнее, если поменять инициализацию и функцию.
PPPS. Возможно я говорю глупо, но мне кажется, что я имею право на свою точку зрения? )
zagayevskiy
Вы, конечно, нормально упоролись, но сумма — это был просто пример. Я не пишу на js, я вообще про концепции говорил. Если у вас есть sum и reduce, и надо суммировать числа, то надо использовать sum. Только не надо при этом утверждать, что проще обходиться map.
Druu
Если нужна производительность, то можно трансдьюсеры юзать. Будет в один проход и читабельно.
mayorovp
Тут мне на днях кто-то на Хабре заявлял, что reduceRight допустимо использовать в качестве аналога forEach когда нужно обойти массив в обратном направлении…
Вот так и обходятся.
Viacheslav01
Не факт, что оптимизатор SQL переварит это и выдаст правильный план исполнения.
Maksclub
Мой поиск работы длился 3 с половиной месяца, месяц удаленно по скайпу из НСК, и два с половиной уж в МСК. Язык PHP — почти все собеседования по паттернам и SOLID.
Так вот, одно из удаленных собеседований было на джуниора (почти остальные на мидла или что-то между джуном и мидлом), и мне задали вопрос по SOLID, погоняли по каждому принципу, привел даже примеры, погоняли по MySQL (тоже всегда гоняют пыхеров), по NoSQL сразу сказал, что вообще не работал ни с чем, в т.ч. с Эластиком и прочим...
Дали задание
В режиме шаринга экрана написать простой код с внедрением зависимости, походу дела усложнив до реализации простого контейнера зависимостей… в ближайший понедельник мне заявили в сообщении, что я слабый джуниор и не возьмут меня. Было странное ощущение недоумения, тк более-менее есть адекватное понимание, кто и что должен знать :)
Хотя конечно на мидловых собеседованиях меня в лужу садили несколько раз так, что в затылке биение сердца чувствовал :)
ledocool
В php вообще, судя по всему, творится ад и хаос.
Wesha
Это стандартная фича языка ;)
r0zh0k Автор
Ну почему, мне, например, Laravel вполне даже приятен. Если приучить себя к особенностям синтаксиса PHP то становится почти как Rails.
mclander
Вы сделали мой день ;)
Интересно многие ли PHP команды это употребляют? Хотя, PHP как раз такой язык, что требует беспощадного насаждения культуры разработки.
andreyons
Многие просто спрашивают на собеседовании, просто чтобы было что спросить.
На практике мало кто действительно использует и заморачивается. Иногда даже думают, что используют, но на самом деле — нет.
VolCh
Думаю, сильно зависит от фреймворка.
Maksclub
Много, в топовых проектах много где Симфони (аналог Spring из языка Java)
github.com/symfony/symfony
Mail.ru (Delivery), Rambler, Lamoda, Forbes, Conde Nast, Skyeng… используют точно Симфони
И тысячи проектов пользуют похожие фреймворки, у некоторых есть огромнейшие минусы/плюсы, есть монолитные проекты, но во всех больших преоктах, сами понимаете, встает вопрос рефакторинга, поддержки и переиспользования кода… на что приходит нам на помощь неожиданно ООП.
Понимаю, для некоторых программистов очень удивительно слышать SOLID и PHP, недавно столкнулся с тимлидом на Java с 7 летним опытом, он очень был удивлен :):) просто про PHP он знал примерно то, о чем все обсуждают в ВК :)
VolCh
«в ВК» — в компании при разработке одноименного сайта? :)
Maksclub
Как понимаю, там не сильно прижился ООП с их изобретением
habr.com/ru/company/vk/blog/442284/#comment_19828486
habr.com/ru/company/vk/blog/442284/#comment_19826400
UnclShura
Я конечно ничего не понимаю в Java и Ruby, но по вопросам можно примерно представить уровень. Ну так вот не взяли вас в большинстве случаев совершенно правильно. Если вы не знаете синтаксиса языка, то зачем вы на те позиции шли? Можно не знать методов и библиотек, но синтаксис — святое.
Задачки на переворот строки дают чтобы не тратить время на совсем не программистов (вы не поверите сколько народу так отсеялось).
И ещё. Вы не прошли самый начальный уровень. Дальше были-бы вопросы сложнее. Потом ещё сложнее. И т.д. И так до предела возможностей или ваших или интервьювера. Это надо чтобы определить ваш уровень с одной стороны и предложить лучше позицию если случайно overqualified человек пришёл.
r0zh0k Автор
Все верно, два раза не взяли, на третий раз взяли хотя я-до и я-после ничем не отличались по уровню. Между собесами прошло несколько дней. О чем это говорит? О том, что вопросы, которые мне задавали, совершенно ничего не показывают.
По фану ))) А еще на RoR я сделал несколько довольно серьезных коммерческих проектов и заработал прилично денег, поэтому уверен в своих способностях решать задачи бизнеса.
Понятие «говнокод» универсально для всех языков, я могу сходу определить что код плохой, будь он написан на Java/Ruby/Python/JS и так далее.
dim2r
Оно самое! Сейчас почему-то спрашивают какую-то хрень. По умным вопросам кажется, что проект будет гениальным, а потом окунают в махровый легаси уровня ПТУ.
zirix
Наличие успешных проектов ничего не говорит о компетентности.
У меня в портфолию есть пара проектов на PHP, которые принесли мне миллионы. При этом мои знания PHP уровня джуниора, я даже синтаксис могу не весь знать.
Stas911
Нефига себе — поделитесь историй успеха?
Anton23
А еще он знает лично Илона Маска, помогал Лари Пейджу, и владеет солидным куском акций Apple и Amazon.
П-з-ть — не мешки ворочить!
zirix
Особо рассказывать нечего, несколько проектов связанных с эл коммерцией в т.ч. обменники коинов и прочей эл валюты.
PHP выбрал т.к. недостаточно хорошо знал Java EE / Spring.
dim2r
Ну почему? Практический опыт о многом говорит.
К сожалению на интервью зачастую делают упор на незнание. А незнать можно боооольшое количество вещей. Начиная от сигнатуры метода и кончая какой-нибудь пятой нормальной формой. Обычно сам спрашивающий никогда не использовал эти знания на практике. Но если есть эквивалентные знания, то надо делать упор на них. Я например не знаю что такое «мок», но на самом деле это элеметарная вещь, которую просто хитро назвали. А тем временем спрашивающий наслаждается тайной властью.
rotarepo
Насчёт успешных проектов — как ни странно, это во многом так. Когда фрилансил, периодически приходилось что-то приделывать к коммерческим веб-приложениям (партнёрки, cms, и т.п.) — успешно продающимся на международном уровне. Код, как правило — тихий ужас. В мало-мальски крупной энтерпрайз-конторе такого бы не написали.
dim2r
В больших конторах тоже бедлам. Я сейчас работаю в проекте со 150 программистами. Такого кода насмотрелся, от самого умного до самого тупого.
DarthVictor
Вы бы не подготовились за несколько дней, если бы не
Даже за месяц не факт, что подготовились бы.
Так что вполне возможно, что показывают. Да, вполне возможно, что на первых двух из трех ваших собеседованиях были ложно отрицательные результаты и Вы бы подошли на эти вакансии. Но вы же не знаете, какой в этих компаниях поток кандидатов. Может им не страшно не взять хорошего, но страшно взять плохого.
VolCh
1) есть позиции, где умение программировать в целом важнее знания нюансов синтаксиса, а, тем более, сигнатур методов
2) в редко используемом (лично) языке трудно понять что в синтаксисе мастхэв, а что нюанс, который реально используется в паре низкоуровневых библиотек и введённый в язык их авторами. Кроме как сходить на собеседование других способов особо нет понять.
yoshka
Насчет «синтаксис — святое» не соглашусь. Если пишешь проект на нескольких языках разом, в моем случае Ruby, JS и Kotlin, то легко перепутать и написать метод или конструкцию не того языка сдуру. Да, перед собеседованием не грех и повторить азы, чтоб не смущать собеседущего. Но так вот радикально, не помнишь синтаксис — вон из сеньоров, это напрасно.
springme
Знакомые ощущения, после собеседований уровня «переверни-ка мне дерево» и чем X структура отличается от У (при условии, что У нигде на практике не используется) и резюмирования «у вас пробелы в базовых знаниях», наступает некоторая апатия, даже объяснять интервьюерам/рекрутерам ничего не хочется.
Тут важно понимать, что есть много вещей, которые вы знаете, но не знает тот (собеседующий), кто знает, то, что вы не знаете/путаетесь.
r0zh0k Автор
Я рассуждаю так — если работа вам нужна, то нужно просто выучить все эти алгоритмы и уметь решать их с закрытыми глазами. Было много историй о собесах в FAANGи где люди месяцами сидели учили Cracking Coding Interview и LeetCode чтобы пройти собесы. Если рынок требует — значит надо соответствовать. Иначе снижается количество мест, куда можно попасть, зачем себя ограничивать в потенциальных возможностях. Если бы на собесах требовали писать о себе эссе на 10 страниц — пришлось бы писать, что поделать.
Я ходил на собесы по фану, поэтому не готовился ваще и поставил себе челлендж получить максимум офферов на $5k, на любые позиции, на любые технологии, отвечал на все запросы рекрутеров. Конечно, если бы я более серьезно подошел к делу, то результат был бы лучше, но и времени мне пришлось бы потратить больше (учитывая что новая работа мне ваще-т не нужна была). Я бы конечно хотел повторить этот опыт, только уже не для локальных аутсорс конторок, а FAANG, но как только представлю, сколько времени нужно будет потратить на подготовку, чтобы получть хоть один оффер из 10 попыток, всякое желание отпадает. Тем более что работать там я все равно не хочу.
411
Вы, конечно, правильные минусы выделили у собеседований, но если бы вы вместе со своим резюме скинули бы мне ещё и эту статью, то я бы вас к себе не взял. И даже не стал бы интервью проводить. Не из-за пробелов в знаниях, а именно из-за вашего отношения. Вы знали, на какую позицию идёте, при этом даже не удосужились подтянуть свои знания.
«Смогу выучить за пару месяцев» и подобные вещи — аргумент, но вот контр-аргументом будет то, что перед собеседованиями у вас было время это выучить, но вместо этого вы решили выехать на опыте, а потом уже как-нибудь доучить. Ведь далеко не все вопросы были ненужными и многие были достаточно фундаментальными по языку.
А уж имея такие пробелы и надеясь выехать на опыте, вдвойне удивительно, что вы даже не пытались сами показать то, что вы умеете, вместо этого в статье только и слышно, что не те вопросы вам задавали.
Просто с таким отношением есть высокая вероятность, что ваши интересы будут перпендикулярны интересам проекта и в долгосрочной перспективе не факт, что ваш вклад вообще будет со знаком плюс. И страдать от этого всего будет не только сама компания, но и люди, с которыми вам придётся работать.
r0zh0k Автор
Я ходил на собесы по фану, и чтобы статьи потом написать (зацените предыдущие две).
Ну че, на третий раз подтянул и оффер получил. Ez.
Отличные вопросы мне задавали на позицию java техлида (я об этом написал), так шо нет, таки были хорошие собеседующие. Ruby ребята чот не порадовали, не барское это дело, на вопросы о синтаксисе отвечать, ну и ладно.
Это уже менеджерское дело выяснять ))) Но любой человек при желании может давать социально приемлемые ответы и эту линию обороны тоже на изичах проскочить.
Вот я собеседовался на позицию Group Manager и там меня раскусили и не дали оффер )
VolCh
Это если предполагать, что человек в активном поиске на конкретный стэк. А если просто откликается на прямые предложения или всё равно какой стэк, то подготовить теорию по всем возможным проблематично.
dreamseeker92
можно увидеть решение задачки each_slice по первому собеседованию? и что там с индексами в итераторах — где прочитать про это?
r0zh0k Автор
Собес был еще в октябре (полгода назад), кодерпад я потерял, да и код там тривиальный.
Не знаю, наверное в учебнике ))) Я просто запустил код в repl и протестировал как он работает. Что-то вроде
Выведет не 0, 2, 4 а 1, 2, 3, 4, 5
Школьный вопрос какой-то на самом деле )))
kzhyg
Зачем менять переменную цикла D:
r0zh0k Автор
Чтобы подвинуть «окно» итерации для each_slice. Надо было через while делать но я затупил, вот и все.
dimka11
Это не переменная цикла, а item в массиве.
И вроде в большинстве языков с for each его модифицировать нельзя.
P.S.: На ruby никогда не писал.
Жалко, что C — style for не существует во многих языках. Приходится разбираться, как выполнять элементарные операции, типа получить текущий индекс или перезаписать элемент массива.
yefrem
за пару лет разработки на Ruby как-то и не вспомню, когда приходилось использовать for и приходилось ли вообще. А уже переменную менять…
r0zh0k Автор
Да наверное и реализацию each_slice или другого тривиального метода тоже нечасто нужно делать )))
Anarchist
Тут дело даже не в мутабельности. :)
zuko3d
Собеседования «на доске» очень полезны. Лично я, когда провожу собеседования, обязательно даю задачу, которую надо написать «без гугла». Желательно — на листке бумаги. Потому что когда человек пишет рукой на листке бумаги — у него нет возможности что-то легко поправить, где-то вставить строчку кода. Большинство это понимают сразу и сначала планируют решение, а потом уже его пишут. Я таким образом проверяю не способность кандидата (например) развернуть список, а оцениваю опыт написания кода в целом. Опытный разраб для простых задач сразу знает, сколько ему нужно переменных, какие циклы будут и т.п. — у него во время написания кода уже в голове цельная картинка и он её просто переносит на бумагу. А вот джун такой картинки не имеет — он по ходу додумывает решение, где-то что-то подправляет. Иногда джун даже не может удержать всё решение в голове (а это крайне важное умение для того, чтобы писать код без багов — иначе всегда будут пропущенные корнер-кейсы). К слову, для решения задач на бумаге я никогда не даю что-то «головоломистое» — только базовые вещи, чтобы senior писал «от руки» решение за пару минут.
Matisumi
Представляю сколько толковых кандидатов вы из-за этого потеряли!
zuko3d
Если честно, не очень понимаю — каким образом? Это не риторический вопрос, мне действительно интересно мнение.
На мой взгляд — толковый кандидат легко напишет на бумаге нужный код. Или я что-то упускаю?
r0zh0k Автор
Я лично знаю жестких типов (отличных разработчиков), которые после предложения написать код на бумажке просто встанут и уйдут :)
senya_z
и это кстати очень хорошо. они и свое время таким образом сэкономят, и время команды интервьюеров. еще лучше было бы, если бы эти мега-парни еще у рекрутера догадались спросить о формате интервью и вообще не приходили бы.
michael_vostrikov
Почему бы не написать об этом в вакансии и сэкономить время всем сторонам, включая рекрутера?
zuko3d
Это говорит об их невоспитанности, а не о профессионализме. Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?
Насколько я понимаю, этим жёстким типам никогда не хотелось попасть в такие организации, как Microsoft, Google, Яндекс и т.п. (если речь идёт про SWE).
r0zh0k Автор
Ваще-т да, у нас как-то уже давно такое не практикуют. Да и все собесы почти проходят по скайпу, там есть repl.it/coderpad/шаринг экрана
Да, у нас в Украине тухло с этими конторами ((( Только тупой аутсорс, только галеры.
Druu
Просить писать программу на листочке — это хамство. В том, чтобы встать и уйти, если тебе нахамили — ничего невоспитанного нет.
zuko3d
И много ли вы раз так вставали и уходили с интервью в мировых организациях?
senya_z
чтобы встать и уйти с интервью «в мировых организациях», как вы их назвали, надо, чтобы на это интервью сначала позвали.
zuko3d
Ровно об этом я и подумал, но решил не писать, т.к. прозвучало бы слишком резко, а я и так вон уже минусов нахватал =)
А так — да, судя по всему многие «комментаторы» не дотягивают по уровню, оттого и не понимают, зачем всё это нужно.
Druu
А какая разница, мировая или не мировая? Если тебя оскорбляет представитель мировой компании — то он типа "право имеет" или как?
senya_z
в чем оскорбление заключается? в том, что они хотят какие-то вещи проверить перед приемом на работу? есть стандартный процесс собеседования в эти «мировые» компании, который всех там работающих не оскорбляет, а вас почему-то оскорбляет.
Druu
Человек пришел устраиваться программистом, а ему предлагают заниматься цирковыми номерами.
Но ведь в этом стандартном процессе никаких задач на листочках нет.
senya_z
что значит нет? почитайте, как устроено интервью в топ 5 мировых софтверных компаний. не на листочке, а на доске. но суть та же. в последнее время некоторые по желанию стали давать компьютер, где писать надо в ноутпэде (если повезет, с подсветкой синтаксиса).
Perlovich
Если есть возражения против такой формы собеседования, вежливо скажите об этом интервьюверу. Вставать в позу или обижаться — это не серьезно и просто не профессионально. Более непрофессионально, чем попросить написать программу на листочке.
Так одному кандидату не понравилось, что попросили написать SQL запрос на листочке — он «встал и ушел». Второму не понравилось, что спросили теорию, он встал и ушел. Третьему не понравилось, что спросили, чем не нравится текущее место работы — он встал и ушел.
Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».
fukkit
Что же он, по-вашему, должен делать, если настолько не нравится? Сидеть там до пенсии, которой не будет, или умных жизни учить?
VolCh
Есть мнение, что лучше сначала говорить, что не нравится, а уходить только когда ожидаемой реакции нет за разумное время.
Nikobraz
И вы остались без работников.
MamOn
Слышал такое мнение: Если человек хорошо пишет на листочке, то это либо студент, либо профессиональный ходок по собеседованиям.
zuko3d
Со студентами-олимпиадниками есть отдельная проблема: они очень хорошо пишут код на листочке, решают алгоритмические задачки на раз и вообще влёт проходят типичные «гугл-фейсбук-эппл»-собеседования. Для таких товарищей есть секции по архитектуре и проектированию. Жаль, не во всех организациях при приёме эти секции проводят (я не про отдельную встречу на час-два, а хотя бы рассуждения минут на 15).
Ну и студентов настолько больше, чем молодых senior-разрабов, что обычно если видишь молодого парня, бодро пишущего код от руки, то вывод (изредка неверный) сам напрашивается, это да.
senya_z
мы недавно взяли такого олимпиадника. причем, не просто олимпиадника, а тренера одной из азиатских олимпийских команд. но взяли на entry-level позицию. и вроде как и с настоящей работой справляется. секции на дизайн и архитектуру проводят в зависимости от уровня, на который кандидата рассматривают. чем выше уровень, тем больше внимания этому уделяется. на начальные позиции легко можно пройти, просто умея решать задачи.
Lissov
Вопрос в том, что ожидается увидеть. Если готовое рабочее решение — то да, именно так. А если базу, от которой можно потом говорить, дорисовывать и так далее, то уже не важно что написано на листочке вначале, важно куда это всё придёт.
zuko3d
Ожидается увидеть то, как человек подходит к написанию кода. Ни разу ещё не было такого, чтобы опытный разработчик после прослушивания задачи сразу начал её писать. Обычно идёт несколько вопросов, размышление/обсуждение, строится решение, продумываются корнер-кейсы и после этого быстро пишется код на бумаге. У джунов (и некоторых мидлов) обычно происходит иначе.
Ketovdk
на самом деле часто встречается такое, что у людей совсем без знания алгоритмов на ровном месте появляется лишняя квадратная асимптотика, которая всплывает только ближе к проду. Плюс людям без знания алгоритмов сильно сложнее объяснить в чем именно тут проблема. Даже в примере, который привел автор, он решил задачу какими-то вложенными циклами (уже скорее всего квадрат), хотя она решается одним проходом со словарем всех встреченных значений и их индексов
JustDont
Без озвучивания ограничений ваше «даже» абсолютно бессмысленно. Вы экономите циклы, расходуя память — что, очевидно, возможно только тогда, когда у вас есть память, которую можно потратить.
Ketovdk
в задачах конечно можно давать ограничения, но в том и дело, что в реальной жизни эти ограничения часто обнаруживаются поздно (конечно хорошо, когда программист знает ограничения предметной области и они не собираются меняться) и нужно сразу писать более менее оптимально (в разумных пределах и не особо ухудшая код). Ну и да, экономим циклы, расходуя память, но
1) память также расходуется линейно, а не квадратично
2) в подавляющем большинстве случаев, память дешевле вычислительной мощности и легче масштабируется
Lissov
Нет, словарь всех встреченных индексов занимает примерно столько же, сколько строка с промежуточным найденным значением у автора.
И память можно оценить — сколько там символов в юникоде? Случай, когда сотни килобайт нет но есть секунды а то и минуты на исполнение, ИМХО, не совсем типичен.
nick_gabpe
Толковый разработчик в спокойном состоянии может писать хороший код. Во время интервью большинство людей испытывают стресс, то есть уже не так продуктивны как могли бы быть. Помимо этого сам ход интервью может выбить из колеи. Да и в отличии от IDE на бумаге вставлять.
Очень сложно писать код без привычных инструментов, с сильным стрессом, без права на ошибку. Хороший девелопер может не написать код, а может и написать. Разве нужна эта лотерея? Давать для вайт боард кодинг можно лишь простейшие задачи(fuzz bizz, проверка строки на палиндром) для проверки, а умеет ли кандидат вообще писать код, в принципе?
zuko3d
Дак если бы был способ надёжно, без лотереи, узнать уровень кандидата — все бы им пользовались.
Согласен, именно о таких задачах я и писал. У меня личный критерий отсечения «сложных» задачи — попросить коллегу-мидла на обеденном перерыве накатать решение. В спокойных условиях, за чашечкой чая. Если за 10 минут не вышло — задача плохая, т.к. при стрессе вперемешку с обсуждениями и мыслями вслух, кандидат будет писать её минут 40.
Matisumi
Такой способ есть — поговорить про прошлый опыт, про то, какие задачи решал, чем пользовался и так далее. Если со слов опыт релевантный — брать на испытательный. Это лучший вариант узнать, подходит ли тебе кандидат. Другое дело, что далеко не все конторы до этого додумались, более того — это лишняя нагрузка на отдел кадров, но имхо это лучше, чем набрать черти кого по задачам на листочке, а потом думать что с ними вообще делать.
VolCh
Вообще программиста берут на работу не разговаривать, а программы писать. :) Поговорить — это софт-скилл, важный но недостаточный.
Matisumi
То есть вы правда считаете, что программист с большей вероятностью напишет код на листочке под прессингом интервьюеров, чем расскажет о том, чем занимался на прошлой работе? Рассказать про опыт — это не софт-скилл даже близко.
VolCh
Я считаю, что способность написать код на листочке под прессингом интервьюеров больше коррелирует со способностью писать код в IDE под прессингом начальства/команды/сроков и т. п., чем способность рассказать о своём (предположительно, но не факт) опыте под тем же прессингом.
Это навык самопрезентации — главный, пожалуй, из софт-скиллов на собеседованиях, аттестациях и прочих разговорах об условиях сотрудничества. Сильно вам поможет «Чем занимался? Задачи делал. Какие? Разные. На каком стеке? В резюме написано. Что сложного было? Ну за неделю до годового релиза пришли новые требования, из-за которых пришлось неделю по 16 часов всё переписывать»
Matisumi
Ох, да ну вы серьезно? Часто над вами стоит ваш начальник и менеджер и смотрит что вы там делаете, когда вы пишете код? Если да, и вы все еще работаете в этом месте — то это какая-то ваша личная профдеформация, так быть не должно.
VolCh
Прессинг не только в виде пристального взгляда может быть.
Matisumi
Может быть, а может и не быть. Взгляда, или не взгляда. А на «бумажном» интервью он будет точно, и это точно будет взгляд. Чуете разницу?
Человек может не уметь хорошо работать в стрессе, это нормальная ситуация. А вот если в компании столько этих стрессовых ситуаций, что нужно проверять работоспособность кандидата в стрессе — это вот уже как раз совсем не нормально.
VolCh
Ну пару раз мне давали занятия на бумаге, оставив одного и объяснив правила типа «названия функций/методов не бойся написать неправильно, если уж совсем не помнишь, то просто дай название, синтаксис тоже поскольку постольку, считай вообще что псевдокод пишешь». Так что тоже может быть, а может не быть.
JustDont
Уточняем по одной (наиболее запомнившейся) задаче, и поехали дальше вглубь до примененных решений, а там и до уровня кода можно в отдельных местах копнуть? Не?
Про жизненные случаи и то, как писался или не писался код — кандидат и сам очень даже расскажет, если его немного «разговорить» перед этим.
Или у вас вызывает сопротивление то, что в этом случае вы остаётесь без бинарного результата (написал код на бумажке / не написал)? Так вы не экзаменатором должны работать, а собеседующим. Экзаменаторство прокатит в школе и в ВУЗе (и по этим же причинам оно более-менее сгодится для джунов без опыта).
senya_z
вы остаетесь вообще без понимания того, как кандидат подходит к написанию кода — все в кучу или разбито на функции, использует ли синхронизационный примитив или влепит спин-лок, как и в каком порядке подойдет к решению составляющих частей (начнет ли с самых важных кусков, обозначив утилити-функции только названиями или станет ковыряться в малозначащих вещах), как он подойдет к поиску ошибок, которые с большой вероятностью будут в коде. результат далеко не бинарный, результат дает множество данных о способностях кандидата.
VolCh
Код или схема на бумажке для меня как раз предмет обсуждений (с обеих сторон баррикад), а не бинарный результат.
zuko3d
Когда у вас поток по 2-3 кандидата в неделю, то оказывается, что дело не в «конторы не додумались». В крупных организациях на 1000+ разрабов поток бывает и по 10 кандидатов в неделю.
rotarepo
Меня бы это сбило с толку хотя бы потому, что у меня жуткий почерк и я со школы ничего не пишу от руки. Это примерно как выполнить задание, стоя на голове.
zuko3d
Почерк практически у всех плохой — это норма. Если что-то написано непонятно — интервьюер уточнит (а что ему ещё остаётся).
Интересное сравнение, надо бы запомнить.
fukkit
Не писал кода на бумажке лет эдак 20 и не планирую начинать.
Последний раз это был ассемблер для ZX Spectrum. Там это было оправдано необходимостью получения на той же бумажке соответствующего списка машинных кодов для прямого вбивания в память в отсутствии подходящих высокоуровневых инструментов.
Было бы здорово, если бы Вы включали Ваши предпочтения по вайтбордингу и бумажкам в описание вакансии. Сэкономили бы кучу времени себе и таким противникам извращений как я.
zuko3d
В описании вакансии этому не место, но рекрутер всегда предупреждает потенциальных кандидатов об этом.
Kwent
Как раз таки место, просто вы понимаете, что после этого к вам никто не придет на чудесное собеседование, поэтому и тяните до последнего. Если бы это было круто и правильно — об этом говорили бы сразу, но вы прекрасно понимаете, что с этим «что-то не так».
zuko3d
В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.
Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов, если «никто не хочет на такие собеседования ходить»? Может проблема в ваших представлениях о том, что должен уметь скилловый разраб?
Вы намеренно проигнорировали слова о том, что рекрутер всегда предупреждает человека?
Kwent
А процесс найма это тоже «о компании».
Собеседовался в гугл и яндекс — писал код клавиатурой. Большие компании инертны и дольше переходят на нормальные способы. Ваше «думание перед тем как написать на листочке» от создателей «писать реферат от руки чтобы запомнилось» — это пережиток прошлого, в этом нет ни романтики, ни смысла. Гипербола — заставляйте писать код на бересте — там цена ошибки выше.
Я был бы рад, если бы информация о процессе собеседования была в вакансии, это просто личная хотелка, посыл был совсем не в этом предложении.
senya_z
«писать на листочке» — это обобщающее определение, означающее, что IDE использовать не дадут. это может быть доска, листочек, простенький текстовый редактор. гугл дает на выбор редактор с подсветкой синтаксиса (без возможности запустить код) или доску. многие дают сейчас такой выбор. некоторые уже даже позволяют запускать IDE (но не из top 10 компаний), хотя все еще есть места, где предпочитают маркер и доску.
Kwent
zuko3d:
Так в том-то и дело, что человек не про обобщение говорит, а про прям листочек, именно к этому притензия.
zuko3d
Пока что я увидел фразу «пережиток прошлого» и ни одного конструктивного аргумента против. О том, что нет смысла — я уже написал, какой в этом смысл и эта практика даёт плоды.
Буду рад прочитать конструктивные аргументы против такого подхода.
michael_vostrikov
Одно другому не мешает же, просто одна дополнительная строчка. Про тестовые задания в вакансии часто пишут, а это процесс найма. Вакансия сама по себе часть процесса найма.
Durimar123
А вы программист?
Если нет то, то я поясню как сейчас пишется программа.
В IDE начинаешь писать «for» затем выбираешь из списка подсказки оператор/функцию/переменную…
затем IDE за тебя добавляет нужные скобки, кавычки, точки и т.д.
Откуда у программиста детальное знание синтаксиса? а главное зачем оно ему? Интервью проходить?
У сеньеров в голове 10-20 языков, причем многие похожи.
Лично я не помню синтаксис создания классов и даже енумов. И не парюсь по этому поводу — это меньше 1% кода? причем стандартного и ошибиться там нельзя — IDE подскажет. Так зачем мне это помнить?
>то крайне важное умение для того, чтобы писать код без багов
Может для уровня джюниор?
На уровне сеньера баги совсем совсем другие:
Не верно продумал архитектуру базовых классов, из-за этого при сотом изменении ТЗ приходится делать костыли.
Не так срабатывает удаление объектов, так как по мере разработки сильно поменялась их передача и создание. А «умные» подсказки про shared_ptr вызывают улыбку.
И т.д.
zuko3d
Да, программист. Опыт более 10 лет, успел поработать в нескольких крупных (5000+) айтишных организациях, сейчас я Senior SWE в одной из них.
Вы же каждый (рабочий) день код пишете — как иначе?
На кой чёрт нужно в одном проекте 10 языков? Это же зоопарк технологий, который нереально поддерживать. На своём опыте в успешных проектах видел не болоее трёх языков одновременно. При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.
И правда — зачем?.. Я, кажется, писал о том, что придираться к запятым и потерянным скобкам — глупость, мы таким не занимаемся.
Согласен, что баги другие. Но как, по-вашему, человек продумает архитектуру сложного объекта, если он даже не может в голове удержать простую программу? Или вы считаете, что каким-то волшебным образом можно решать сложные задачи не умея решать простые?
r0zh0k Автор
У меня прямо щас проект где ехал микросервис через лямбду и там используется Java, Python, Node.js, горы скриптов на баше и немного Ruby, на фронте реакт. Я коммичу во все места )))
И есть еще один где PHP, Java, Ruby, лямбды на node.js и работа с OpenCV на питоне. Тоже коммичу во все )))
zuko3d
Ваш проект приносит много денег? Стабильно ли он работает, легко ли проходят релизы? И при этом он уже много лет на рынке?
Кажется, на большинство вопросов ответ будет «нет».
r0zh0k Автор
достаточно, чтобы спонсировать дальнейшую разработку
конечно
ваще изи, вы наверное не слышали про такую штуку как CI/CD, да?)))
define много? Три года — много или мало?
Когда кажется, сами знаете, что надо делать. Не стоит натягивать привычную вам картину на весь остальной мир.
То, что вы не работали с чем-то, или не видели чего-то, не значит, что другие не работают с этим или не делают. Если вы не видели больше 3х экосистем в рамках одного проекта — это значит лишь то, что вы просто не принимали участия в таких проектах, но не значит что таких проектов нет вообще, или они какие-то плохие.
VolCh
> На кой чёрт нужно в одном проекте 10 языков?
У многих нет одного-единственного проекта на всю жизнь.
> При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.
Если SQL, HTML и CSS считать за языки, то и 6+ на одного может легко набраться на одном проекте.
r0zh0k Автор
Кстати да! А еще есть серверный js и клиентский ))) Тогда у меня легко десяточка будет )))
VolCh
Или клиентский ts и серверный js :)
Lissov
А на JavaScript IDE напишет for..in или for..of? :)
Вообще я с Вами в целом согласен, просто забавно. Тут скорее не очень удачное решение, сделать два очень похожих иногда разных варианта цикла.
rotarepo
Детальное знание синтаксиса нужно хотя бы для того, чтобы быстро и полностью понимать чужой код.
viirtus
В целом, имел похожее представление о подобных задачах. Но недавно был на собеседовании в одну компанию, которая любит 4 часа писать код на доске и бумаге, и как-то резко поменял своё отношение к таким собеседованиям.
Из четырёх людей трое докапывались чуть ли не до запятой. Из часа, выделенного на общение с каждым, минут 35-40 я тупо писал и правил код без IDE, подсветки синтаксиса и даже возможности запустить творение.
Задачи, может быть, и интересный способ оценки, но в варианте «объяснить решение на пальцах». Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда. А написание кода на бумаге тупо тратит время и повышает градус неадекватности.
zuko3d
Тоже встречался с таким (в качестве кандидата). В таких историях есть сильные косяки от интервьюеров:
Я и мои коллеги-интервьюеры никогда не считаем это проблемой, т.к. ясное дело, что если человек пропустил точку-с-запятой в конце строки, то это либо от концентрации на самой задаче, либо от волнения. И то, и другое — вполне ожидаемо на собеседовании, так что лично я просто указываю кандидату, мол «запятую потеряли» — и даже не успеваю сказать где именно, а человек уже исправил. Если же интервьюер просто говорил «у вас программа работает некорректно» и ждёт исправления запятой — это косяк скорее интервьюера, нежели кандидата, т.к. таким образом ничего полезного не выясняется, а время (и нервы) тратятся.
Это вообще треш. Если решение занимает несколько листов А4 (ну или несколько исписанных досок) — это крайне плохая задача для собеседования. Вариант, что «кандидат настолько плох, что не догадался до короткого решения» я откидываю, т.к. головоломки с коротким и элегантным решением ничего полезного не проверяют. У задачи должно быть изначально видно либо короткое, либо эффективное решение.
А вот тут я не согласен. На личном очень неприятном опыте убедился, что есть люди, которые могут объяснить решение, но не способны написать рабочий код. То баги сажают, то не компилируется под какие-то платформы, то просто пишут код, который делает совсем другое. Давно (ещё когда не было опыта собеседования) по ошибке брал таких людей (мол, главное чтоб соображал, а код написать кто угодно сможет) и для организации это выходило очень дорого.
r0zh0k Автор
Ну вот вы не считаете, а у большинства собеседуемых впечатление об упражнениях с бумажкой может быть именно таким, потому что им на пути всегда попадались «неправильные» собеседующие, а «правильных» днем с огнем не сыщешь. Поэтому у людей и горит от кода на бумажке.
senya_z
в моей практике тоже не встречалось случаев, когда придирались к запятым. при этом я сам прошел десятки интервью и гораздо больше их провел. мы даем на выбор — писать или на доске, или на компьютере (не в IDE, но в редакторе с подсветкой синтаксиса). и примерно половина кандидатов-таки выбирает доску.
почти в половине случаев люди, которые очень хорошо рассказывают про решение, не могли его вменяемо написать.
VolCh
А на что ещё указываете? Синтаксис, названия классов, функций/методов и т. п.? В общем указываете, что код просто не запустится нормально не из-за алгоритмических ошибок?
zagayevskiy
Я не указываю, вообще пофиг. Лишь бы алгоритм был правильный.
Sabubu
Не понимаю, зачем бахвалиться незнанием основ языка? Я не специалист в Руби, но знать, как работает вызов метода, конечно надо. Как вы иначе поймете, что в каком случае вызывается?
Что касается "service objects", опять же странно недоумение автора. как можно не понимать таких элементарных вещей? Модель в RoR это обычно объект, соответствующий строчке в БД. Но часто нам нужно писать код, не работающий с БД вообще (условно, рассылающий письма, работающий с API итд), или код, работающий с несколькими разными моделями. Куда еще его помещать? В контроллер, может быть?
Статический анализатор не обнаружит нарушение принципов SOLID.
То есть автор каким-то образом ранее прошел собеседование, пролез без особых знаний, ничего нового не приобрел за время работы и винит в этом других.
Другой пример: если человек не понимает, например, как работает ActiveRecord и связи, то он может написать неэффективный код, слишком медленно работающий или создающий нагрузку на БД, с грубыми ошибками именно из-за незнания.
Наконец, про то, что вопросы не совпадают с тем, что приходится делать на работе. Чтобы давать "реальные" задачи, вас надо ознакомить с кодом проекта. Но он является коммерческой тайной, плюс вы вряд ли захотите тратить на это несколько дней, плюс у нас может не быть хорошей документации (так как ваши коллеги аналогично вам думают, что их код настолько гениален, что не требует пояснений). И сами рабочие задачи тоже могут быть длительными по времени, никто не захочет их решать. И более того, умение решать рабочие задачи мы увидим на испытательном сроке. Потому на собеседовании мы просто пытаемся из пришедших кандидатов отобрать самых ярких, с самым широким кругозором или хотя бы превышающих определенную планку.
И кстати, у многих кандидатов, даже с большим опытом, есть серьезные пробелы в знаниях. Банально: один толком не разбирается в нормализации или индексах в БД, другой не может описать примеры популярных уязвимостей в веб-приложениях, третий не понимает HTTP, и почти каждый 9 из 10 не пишет комментарии. Как вас вообще допускают код писать, ау?
Будь моя воля — я бы всех "вкатывальщиков" выкатил обратно — учить основы. Водителя не пускают на дорогу без сдачи экзамена по правилам безопасного вождения. Почему программистов без знания правил безопасного написания кода надо допускать на рабочее место? По-вашему, старший разработчик должен за вами бегать, перечитывать код и исправлять ошибки?
(если вы читаете эти строки, попробуйте мысленно без запинки и "ну… это когда..." рассказать про 5 самых популярных уязвимостей и объяснить механизм их возникновения. Если не можете — вы не годны)
r0zh0k Автор
Разжигать в комментариях! ))) Реакция публики очевидна — «ах как он посмел не знать синтаксиса, анафема!» и ожидаема. Статья получает больше просмотров, больше дискуссии, всем профит!
Кроме того, заметьте, что в итоге я всем советую заучить теорию и типовые вопросы чтобы не попадать в такие ситуации как я. Однако это не отменяет моего мнения что знание теории по большому счету ничего не значит.
Ерунду написали :D И я никого не обвиняю.
Я имел ввиду не концепцию а название. Концепцию я использую (хотя может быть и не совсем в таком виде каким ее видят авторы, когда модель остается вообще чистой, как в стандартных Java Spring/Hibernate приложухах), понятное дело, а то что оно так называется — не знал.
Лол зачем? Это нужно раз в год, когда ты достаточно неаккуратен для того, чтобы назвать метод в классе словом send и потом удивляться, почему у тебя мистические баги вылазят.
Знать нужно не порядок вызова методов, а, например, порядок срабатывания хуков ActiveRecord, или хотя бы просто иметь представление о том, что это такое.
Все верно, вот это — пример хорошего вопроса и постоянно возникающей рабочей ситуации. Но почему-то никто меня про это не спрашивал ))) А могли бы спросить, например чем отличается joins от includes, когда что использовать, как делать вложенные includes, как правильно писать валидации, что такое скоупы и так далее. Но чот никто не хотел (((
Негоден для чего? Для вашей работы? Ну ок, пойду на соседнюю улицу оффера получать, там такой ерундой как секурити не заморачиваются ))) Годность или негодность определяет строго рынок а не комментаторы. Если рынку не нужны разрабы со знаниями тонкостей работы GC — никто не будет заморачиваться чтобы это учить просто так.
Sabubu
Вот, кстати, мне еще и показалось, что у вас требования по з/п высокие. Вы, как я понимаю, живете в Украине и там, может быть, другая экономическая ситуация, но у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов. За 2500-3000, если подольше поискать, как мне кажется, вполне можно найти специалиста, который хорошо знает и теорию и перечисленные выше в моем комментарии вопросы. Непонятно, зачем ему предлагать 5 000 :) Мы же не в Калифорнии, у нас тут минимальная зарплата вообще 11500 рублей (ок, в Москве побольше — 19 000). На 5 000 долларов, мне кажется, это должен быть уникум из команды Вконтакте или крутой специалист из Яндекса со знанием всего, что можно. Разве я не прав?
Ну и, конечно, хочется подбирать людей не с тягой к деньгам, а тягой к знаниям и любовью к решению сложных задач.
Вот еще ниже спрашивают про комментарии. Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги? Или вы об этом не задумывались? Не приспособлены к работе в команде?
Ну это же какие-то очевидные вещи, которые наверно описаны в мануале по фреймворку. На 5 000 наверно нужны навыки получше, чем умение пересказывать мануал.
Ну вот мы еще и выяснили, что вас не беспокоит качество получающегося продукта.
senya_z
Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается. Теория эта вдребезги разбивается о реальную жизнь, однако многие в нее все же верят.
pesh1983
Есть не менее замечательная теория о том, что комментарии — всемогущее средство, если код непонятен. Увы, по опыту, это только теория. Комментарии обычно живут в отрыве от кода и при его изменении их часто просто забывают поправить. В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным. Хорошо написанный код и правда не нуждается в комментариях. На моей практике было очень мало реальных случаев, когда без комментариев прям совсем не обойтись. А если хочется написать комментарий к коду, который непонятен, то тут 2 варианта. Первый — код просто нуждается в рефакторинге и тут комментарий, ИТ как мёртвому припарка. Второй — сложная бизнес-логика, которую иначе не описать, кроме как снабдив сопровождающими описаниями. Заметьте, я сейчас не про докстринги, описывающие сигнатуры методов, а именно про комментарии в непонятном коде.
senya_z
простой код, как правило, в комментариях не нуждается. а вот сложный код — как раз наоборот. как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто. иначе может быть очень дорого чинить инцидент в проде, потому что кто-то улучшил какой-то кусок. кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии. но не пользоваться каким-то инструментом с объяснением «мы все равно им пользуемся неправильно» мне кажется странным.
pesh1983
> а вот сложный код — как раз наоборот.
Я об этом и написал, это как раз 1 случай, когда код нуждается в рефакторинге.
> как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто.
Такие случаи конечно имеют место быть и там комментарии необходимы. Но если ваш код сплошь и рядом состоит из таких кусков кода, то это либо какой-то специфический проект, в котором иначе никак, и без комментариев вообще непонятно, как оно работает, либо вы реально что-то делаете не так, если ваш код сплошь настолько сложный, что без комментариев в нем не разобраться.
> кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии.
Кодбейз гугла разрабатывается уже не первый десяток лет, разрабатывают его инженеры с разным уровнем опыта и скорее всего там достаточно легаси, закладок на обратную совместимость, нестандартную оптимизацию и прочее. Никто не спорит, что если такие вещи явно не описать комментариями, то там все легко сломать.
Но мы ж про простой код говорим) И про среднестатистические проекты, где таких мест, как правило, не очень много. Я хочу быть понятым правильно, я не против комментариев там, где без них реально не обойтись. Я против комментариев, которые представляются, как возможность описать код, который нужно переписать. Если код нельзя переписать, конечно пишите комментарий. Но, повторюсь, в моей практике таких случаев было не так уж и много, хотя они и были.
michael_vostrikov
Вот ни разу не было, чтобы устаревший комментарий оказался вредным. А вот когда он помогал разобраться в текущем коде, было.
pesh1983
Не видел, значит не бывает?) Ну а у меня было) Ну и опять же, это ни о чем не говорит. На моём опыте так же было, что раз можно написать комментарии к каждому блоку, чё не запихнуть все эти блоки в одну большую функцию. Зато всё ясно и понятно, да и в одни месте. Так что в некоторых случаях вместо декомпозиции и рефакторинга предпочитают комментарии
michael_vostrikov
Да нет, это скорее о вероятностях)
Wesha
Есть красивая теория, что код описывает, что надо делать, а комментарии — почему это надо делать.
Например:
JustDont
На мой взгляд куда страннее собеседовать человека на позицию из окрестности 5000 баксов, и при этом спрашивать у него синтаксис языка или тривиальные алгоритмические задачки. Но вот почему-то спрашивают.
senya_z
а что, по-вашему, у него надо спрашивать? просто поговорить о высоких материях? а если он 10К попросит? а если 20К? Вообще без собеседования брать? Высокая зарплата не должна освобождать от требования уметь и понимать то, что умеет и понимает типичный мидл. Высокая позиция предполагает, что в дополнение ко всему тому у вас еще и отличное понимание архитектуры, организации процессов и еще чего-то там есть.
r0zh0k Автор
Давать норм тестовое задание (на час-два, а не на два дня), вопросы по дизайну, по архитектуре, про общение в команде, про взаимодействие с бизнесом.
И у меня действительно спрашивали эти вопросы, но на позиции java-техлида или архитекта. Руби парни не спрашивали, хотя запросы по зп были одинаковыми и там и там.
euroUK
Судя по вашим ответам тут, спрашивать вас по архитектуре и дизайну достаточно бесполезно, ибо если вы не удосужились ответить на простейшие вещи, то уж и на более глубокие вряд ли сможете. И да, я ознакомился с вашим профилем в Линкедине. Но ваши слова здесь и стиль общения сведетельствуют скорее о том, что в Линкедине — пурга.
На самом деле, я диву даюсь, насколько перегрета отрасль, что готовы предлагать зарплаты по 5к любым синьорам с 2мя годами опыта работы. (Если что, это не конкретно к вам относится)
JustDont
Именно. Только не «просто» поговорить, а предметно. Что решалось, как решалось, проблемы какие были, и так далее. Естественно, собеседовать должен человек с соответствующей квалификацией, чтоб можно было распознать чистую пургу.
Нет, ни в коем случае. Просто это требование не будет основополагающим. При прочих равных (которые в случае сеньоров скорее всего не возникнут, но вот в теории) конечно же лучше взять того, кто на уровне мидла шибче. Но если собеседовать только по уровню мидла, то — … собственно, кого нанимаем-то? Мидла на 5К?
senya_z
про «только» разговора не было. был о том, что надо, чтобы и высокие материи знал, и руками работать мог. если он все это делал настолько давно, что теперь может только о высоких материях, то он для нас сильно неидеален.
JustDont
Ага. И собеседовали про работу руками, оставляя высокие материи где-то на закуску. Опять же, вопрос о том, кого нанимаем: того, кто за 5К будет в первую очередь руками работать? Или нет?
senya_z
почему на закуску? архитектурные интервью так же важны как и интервью на кодинг. на них надо выделять отдельные секции, где эти навыки и оценивать. человек высокого уровня будет скорее всего заниматься больше не ручным трудом, но он должен быть способен помочь застрявшему мидлу, к примеру, если понадобится. а как он это будет делать, если он ничего этого не может?
пару месяцев назад я интервьюировался на позиции, эквивалентные гугловому Staff Engineer в несколько других компаний. и решать алгоритмические задачи (где на доске, где на компьютере) приходилось везде. так же приходилось решать high scale system design задачи, проходить behavioral секции и много чего еще. но при этом никому почему-то был не нужен человек, который может говорить о высоких материях, и при этом не может решить алгоритмическую задачу (при условии, что он претендует на техническую позицию, а не позицию менеджера людей).
wataru
К сожалению, есть полно кандидатов, вообще не дотягивающих по квалификации, но отправляющих CV, хорошенько преукрашенное, везде куда могут, на авось.
Поэтому имеет смысл спрашивать и про синтаксис. Правда, лучше, чтобы это был телефонный скриннинг выполняемый не специалистом с простыми впросами и ответами на бумажке.
r0zh0k Автор
Это не у меня высокие, это у вас — низкие )))
Может в РФ это и так, но у нас 5k — это норм зарплата для норм спеца. Не каждый конечно такие деньги получает, но это и незаоблачные или недосягаемые вещи, в чем я убедился на собственном опыте. В итоге я получил несколько офферов на эти деньги без особых трудностей (наверное мог даже больше просить), ну вот кроме разве что позиции руби разраба где мне дали только 4.5 потому что я «плохо синтаксис знал». Ах да, 5k это на руки, после вычета налогов. Про зарплаты я писал у себя в телеге — вот можете почитать — https://t.me/full_of_hatred/19
И нет, я не вру и не хвастаюсь.
Яндекс платит ниже рынка, это известно даже мне.
И да, Вастрик например писал что в МСК можно косить примерно такое же бабло без особых напрягов.
Можете еще первую статью перечитать, там написано кто я ваще такой и какой у меня бэкграунд, может со стороны показаться что я какой-то вайтишник-понторез, но это не так. Можете вот еще линкедин посмотреть — https://www.linkedin.com/in/rozhok/
Не очень понял кому вообще вопрос, у меня в секции про тестовое задание написано что я писал джавадоки.
Но ведь надо же знать про их существование, нет? Как по мне, это такая же важная штука как и eager/includes/join. Впрочем кому я вру, у меня на трех или четырех рейлс проектах не написано ни одной валидации — не нужно было )))
А мы выяснили что у вас отсутствует детектор сарказма/юмора.
andvary
> у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов
Насколько я понимаю, украинские (и белорусские) зп действительно в разы выше российских сейчас, и происходит это из-за разного уровня налогов.
r0zh0k Автор
Я бы сказал из-за экспортоориентированности украинских и беларусских компаний. Налоги тут второстепенный вопрос (хотя и их мы платим намного меньше).
В Украине почти нет компаний, которые работают на внутренний рынок, в отличие от РФ, где есть яндексы, вк, мейл.ру, одноклассники и прочие ребята, которые, естественно, получают выручку в рублях.
А у нас все получают выручку в твердых долларах и евро, поэтому когда курс обвалился то российские программисты стали получать меньше денег в долларах, а украинские/беларусские — остались на месте.
Вот и вся арифметика.
andvary
Курс рубля все-таки не в два раза обвалился. И потом, в России немало «экспортирующих» компаний тоже — тот же Luxoft или как он там.
А зарплаты все равно в два раза меньше.
r0zh0k Автор
Как это не в два? В РФ был по 30 стал по 60.
В Украине был по 8 стал по 27.
Да, но все равно на рынке сложилась ситуация когда крупные игроки фиксируют зарплаты в рублях. У нас (в Украине) такого никогда не было. Люди просто не пойдут работать в компанию, где фиксируют зп в гривнах.
Я че-то в этом вообще не уверен. Особенно в МСК — там точно зп сравнимы с киевскими. В общем хотите косить бабло и не платить сотни денег за аренду однушки в ново-медведково — приезжайте к нам )))
andvary
Это очень интересный момент, потому что в России тоже так было, в 90х повсеместно, и потом сохранялось даже какое-то время в 2000х. А потом прошло, интересно почему. Я помню, как одна моя подработка, стабильно платившая мне долларами в конверте, в 2009 году вдруг заявила, что теперь рубли и баста, а то их всех посадят. Рубли предлагались все в том же конверте.
Нам тогда пришлось расстаться, потому что мы не договорились.
DarthVictor
Сениорская зарплата в Москве — 200-300т.р. или от 3-4.5 тыс долларов на руки чистыми. При лобовом сравнении по ХХ разница у Москвы и Киева процентов 15%, где вы там в два раза нашли, я не знаю.
andvary
Спасибо за цифры! Я давно живу во Франции и, может быть, неправильно сужу со стороны.
Мои впечатления основаны вот на этой статистике moikrug, согласно которой зп больше 220тр (=3300 долларов) имеют меньше 3%. А медиана так и вовсе 90тр (=1300 долларов).
А вот статистика по Украине, которая дает 2000 долларов как медиану зп разработчика и суммы порядка 4000 долларов как медиану зп сеньора.
У меня сложилось впечатление, что в среднем зп в два раза выше.
Вы сразу стали обсуждать сеньоров, но по вашим цифрам и по статистике moikrug получается, что вы сразу отбросили 97% и обсуждаете оставшиеся 3%.
Что вы думаете насчет зарплат в среднем?
Zuy
Комментарии? Их что прямо на собеседовании надо писать на доске или бумажке?
В реальных проектах лучше бы код писали понятный без комментариев, а то я видел устаревших комментариев больше чем реально полезных.
r0zh0k Автор
Самый главный коммент )))
senya_z
нет ни одного надежного способа достоверно определить, будет ли кандидат хорошим работником или нет. умение решать задачи на алгоритмы на доске показывает хотя бы то, что кандидат способен за разумное время разобрать эти алгоритмы и набить руку на решение таких задач. то есть он обучаем, мотивирован, и в целом соображает. на интервью на синиор инженера ожидать, что на интервью придется писать только круды, немного странно.
r0zh0k Автор
Есть — это совместная работа в течение короткого периода времени (день-два парного программирования). Но такое не все могут позволить, а галерам/большим конторам это просто не нужно, потому что у них потоковая работа и цена ошибки (найма плохого человека) довольно низкая.
Таким образом, например, на работу берет такая контора как Basecamp (это кстати они придумали Rails).
Я ожидал какие-то вопросы по дизайну и архитектуре, но их получил только на Java собесах. Ruby ребята спрашивали дичь для джунов.
senya_z
пара дней совместной работы тоже никакой гарантии не дает. вы, похоже, путаете «будет» и «может быть». кандидат вполне может оказаться хорошим разработчиком, способным быть хорошим работником, однако это не значит, что он таковым будет. через пару дней вашего короткого периода и получения офера все может и закончиться. способа определить, будет он хорошим работником или нет, не существует.
ну и по поводу подхода в целом: для какого-нибудь условного джуниора пару дней наблюдения за тем, как он пишет круды (или, как говорят в гуглах, двигает протобафы), может и подойдет. а вот у синиоров на такое обычно времени нет. а если вдруг есть, то ему на эти два дня надо вполне себе широкий спектр интересных задач найти (при этом таких, чтобы их еще и закончить можно было), чтобы можно было какие-то выводы сделать.
самый надежный на сегодняшний день индикатор — это личная рекомендация от людей, мнению которых доверяешь, и у которых есть личный опыт работы с человеком. это тоже не 100% гарантия, но уже сильно ближе. жаль только, что крайне редко такой индикатор доступен.
Lissov
Есть несколько причин давать алгоритмические задачи на собеседовании:
1. Они короткие.
2. Они интересны кандидатам.
3. Это Common Sense, применимый к любой технологии. И без привязки к технологии, просто проверка что у человека мозги на месте.
4. Они позволяют увидеть, как человек пишет код. на абстрактной задаче, реальный код.
5. Показывают подход к решеню проблем.
И не особо в пользу задач, но как факт многие так делают:
6. они позволяют формально отранжировать кандидатов и выбрать одного. То есть задачу «обоснованно самого полезного из [имеющихся кандидатов]» сводят к «обоснованно одного из».
Во многом Ваша статья сводится к тому, что многие не умеют собеседовать. Прекрасный пример тут:
То есть интервьюер изначально не видит смысла в том методе собеседования, который он применяет. Тут проблема именно в этом, а не в задачах.
За 15 лет работы у меня не было ни одного проекта, где не было алгоритмических задач. Даже в самом «кровавом энтерпрайзе». Просто иногда эти задачи замечаю только тогда, когда в коде вместо понятных 3 строчек написано непонятных 50. Ведь иногда действительно важно вовремя подумать про время исполнения.
Задача с многопоточным API для записи данных в файл на диске — это отличная задача. Но не факт, что в той фирме таки такое пишут каждый день. Или хоть раз.
По теории — во-первых я тоже заметил, что западноевропейские фирмы уделяют этому куда меньше внимания, чем в России и Украине. Не знаю почему.
Во-вторых, иногда это просто попытки свести кандидатов к каким-то сравнимым метрикам.
Ну и главное из моего опыта — процесс очень по-разному выглядит со стороны собеседующего и собеседуемого. И, конечно, с обеих сторон бывают ошибки.
r0zh0k Автор
А у меня за 12 не было ни одного, где они бы были, кроме проекта, где вовсю использовались деревья и графы. Но даже там базовые вещи вроде траверса-вставки-балансировки и тд писались один раз и потом реюзались всеми годами.
Lissov
Вообще говоря в любом куске кода есть какой-то алгоритм :)
Понятно, что чистое первозданное «отбалансировать дерево» встречается редко. Скорее бывает что-то вроде «убрать перекрывающиеся интервалы из списка», что совсем не похоже на известные алгоритмы, но при этом к ним сводится. Человек, который об алгоритмах не думает, выдаёт код «в лоб», который 2 минуты из базы данные выгребает. Или пишет 200 строк кода вместо 10.
wataru
Вбейте в поиске "сотрудник Гугла, фото", смотрите на здоровье. :)
В гугле, яндексе и других крупных международных компаниях очень часто дают задачи и на динамическое программирование. Хотя чаще встречаются просто на знание структур данных.
Штука с динамическим программированием, что ты не знаешь, когда оно понадобится. И если разработчик его не знает, он(а) будет писать какой-нибудь полный перебор и даже не задумается, что задачу можно решить лучше. Да, есть области, где это крайне маловероятно — какие-нибудь embedded разработчики, где тупо нет памяти и регистров, чтобы что-то нетривиальное сделать, или рисовальщики формочек например, где все задачи тривиальны по своей сути. Если же в продукте есть хоть какая-то обработка данных, ДП может когда-нибудь да вылезти.
Читаемость кода и лучшие практики можно натренировать у почти любого программиста за пару месяцев код-ревью (а в перечисленных фирмах ревью есть всегда). Динамическое программирование же — понять суждено не всем.
Так что, если есть поток кандидатов, то нанимающий может позволить себе отсеивать тех. кто не знает ДП, например. Не потому, что это абсолютно необходимое знание — нет, но потому что это хороший бонус.
Как уже написали выше, все собеседования — это нелепая попытка измерить за n минут то, что можно хотя бы примерно оценить только за несколько месяцев работы. Но нанимать всех на испытательный срок в, скажем, 6 месяцев физически невозможно.
senya_z
ДП на интервью — это в последнее время редкость. в гугле уже не рекомендуют давать задачи на ДП, хотя изредка их все же можно встретить. это раньше давали достаточно часто. в других местах тоже не так чтобы часто попадалось. три месяца назад я сходил на интервью в пяток компаний — в среднем по 6 секций в каждой — и из всех этих 30 секций ДП было только на одной, и то — это была запасная задача, потому что решение основной я знал, и интервьюеру пришлось что-то еще срочно выдумывать.
r0zh0k Автор
Ахаха, вся суть этих задач ))) У меня тоже был такой случай, но очень давно, в начале десятых годов, там тоже так оказалось что ребята дали мне задачу типа почему люки круглые а я сразу и ответил. Тогда такие вопросы были в моде )))
r0zh0k Автор
Я имел ввиду наши реалии. Ну нет у наших аутсорсеров и аутстафферов реально сложных задач требующих вот этого всего. Все проекты — веб-формошлепство, кровавый ентерпрайз и прочая дичь, требующая умения не решать алгоритмические задачи, а выдавать нужный бизнесу код с приемлемой скоростью и приемлемым качеством.
Но если вдруг есть — то я только за. Главное предупредите, что у вас хардкорные разработки и надо шарить деревья, сортировки тима и быстро подстроки искать. Тогда я подготовлюсь, приду, и буду потеть над этими задачами понимая, зачем я это делаю. А не просто дать задачу потому что все дают а потом посадить меня круды делать.
Про FAANG и так все понятно — сотни постов и тысячи комментов в западной блогосфере написаны на тему сломанности их техинтервью, но ситуацию это не меняет. Что забавно, они тоже пишут что даже там в работе эти алгоритмы реально не нужны.
senya_z
нужны они в FAANG. не каждый день, но достаточно часто. какой-нибудь reservoir sampling, к примеру, мне пригодился для шардинга ки-спэйса для распределенной обработки не так давно. задачи на многопоточность — так вообще каждодневно нужны. изредка что-то из графов пригождается. ну и в целом — даже если в большинстве случаев это будет двиганье протобафов, иногда будет появляться что-то, где желательно уметь рассмотреть возможность оптимизации (иногда на порядки). а без знания того, что какой-то алгоритм или структура существует и каким-то образом может быть применен(а), шанс на то, что эта оптимизация произойдет, достаточно низкий.
Lissov
Добавлю к этому, что понимание алгоритмов обычно говорит о любознательности и эрудиции, и коррелирует с умением эффективно работать.
da-nie
Если вас интересует любознательность и эрудиция, то вы можете поговорить далеко не только об алгоритмах. :) Скажем, спросить, знает ли собеседник, как работает магнетрон, сможет ли он объяснить эффект Доплера, рассказать, как работает лазер, объяснить угол Брюстера и что такое поляризация ЭМ волны вообще, что такое дифференциальный и инструментальный усилители, гиратор и для чего все они нужны, объяснить, что такое устойчивость следящей системы и как её определить, ну и какие типы регуляторов знает собеседуемый, а вот уже потом, вернувшись к ПО, можно попросить рассказать о построении софтверных 3D движков (соответствующая статья про движок уровня Wolf 3D тут недавно была очень востребована, что говорит о слабом освещении этой темы для большого количества разработчиков).
Вот только после таких диалогов может вдруг оказаться, что при наличии данного вида любознательности и эрудиции (если собеседник смог ответить на вопросы), собеседник не вспомнит алгоритм Дейкстры и балансировку дерева. Потому что либо не знал, либо не использовал. Ну так это лечится открыванием книжки/статей. В конце-концов, над алгоритмами люди их придумавшие думали совсем не один день.
А причина всего этого одна — область знаний огромна. Просто огромна. И вместить её всю человеку невозможно. И совсем не обязательно, это должны быть стандартные алгоритмы. :)
P.S. Когда нам читали численные методы, там были круги Гершгорина (я давно забыл, что это и для чего применялись — 18 лет прошло). Они тоже были в одном алгоритме про вычисление чего-то. Но я очень сомневаюсь, что много кто про этого Гершгорина слышал, кроме специфических математиков. И таких малоизвестных алгоритмов тьма.
Lissov
Если Вы идёте работать в институт физики, то я сложно представляю себе кандидата, не знающего про эффект Доплера.
А вот если Вы хотите быть программистом, то ту маленькую часть области знаний, которая относится к программированию, желательно немного знать. И да, я не говорю об алгоритмах как о заученных решениях конкретных задач. Скорее об алгоритмизации в принципе, об умении придумать и написать какой-то алгоритм в принципе. И знание какиех-то основных принципов.
То же динамическое программирование, это не какой-то конкретный алгоритм, а мкорее принцип, хотя бы о том, что вложенные циклы работают медленно, и их можно иногда заменить затратами памяти.
Если конкретнее, я никогда не спрашиваю на собеседовании алгоритм Дейкстры. Не вижу смысла заучивать алгоритмы по абстрактным названиям (да и сам только что подсмотрел в Вики, хоть и писал его много раз). А вполне могу дать простую задачу, и посмотрю что:
а) кандидат в принципе решит её хоть как нибудь. ну ведь очевидно, что задача решаема.
б) кандидат понимает, что его решение неоптимально, и может подумать в сторону оптимизации. Да хотя бы просто задумывается о сложности и прожорливости.
в) кандидат догадывается, что могут сушествовать готовые решения, и примерно понимает где их искать.
da-nie
А совершенно напрасно. Если у вас есть знакомые физики, попробуйте поспрашивать их по учебнику для 1-2 курса вузов. Найдёте великое множество пробелов, непонимания и ошибочных суждений. Даже у докторов наук и академиков РАН. Потому что можно хорошо и досконально знать только крохотную область. А всё вместе в голову просто не влезет из-за моря нюансов.
Но мы ведь говорили про эрудицию и любознательность, как общее мерило кандидата. Смотрите, какой охват вопросов — от математики к физике и электронике и потом к ПО. Можно ещё и школьную химию вспомнить: скажем, не скажет ли кандидат, что такое электроотрицательность, валентность, степень окисления, стехиометрические и нестехиометрические соединения. Не знает ли он, почему при понижении температуры реакции обычно замедляются и не назовёт ли с объяснением работы пример реакции, которая ускоряется при охлаждении? Помнит ли что такое белки, жиры и углеводы? Можно физхимию вспомнить: что такое энергия Гиббса и энтропия и энтальпия, например. Ну и диаграмму плавкости пусть объяснит — где там эвтектика и перитектика, а так же ликвидус и солидус. Ну и так далее. Много чего можно вспомнить, коль интересны эрудиция и любознательность кандидата. А то всё компьютер, да компьютер… На нём свет клином не сошёлся. Кстати, можно предложить построить на бумажке простейший процессор (это если кандидат вспомнит синтез автоматов) — но это уже особый навык.
Разумеется. Вот только это может занять массу времени и не гарантирует результата. Вот, скажем, я только через 15 лет понял, как сделать при выводе 3D экранный портал. До этого просто не сообразил. Бывает. А так, массу хитрых алгоритмов хорошо придумывают математики — у них мышление в этом плане удачнее идёт.
Вот вы тот же алгоритм Дейкстры смогли бы вывести, не зная его вообще? Вряд ли. Значит, вперёд выходит память (как и везде, кстати). Но сейчас память можно заменить поиском в соответствующей литературе. Так все специальности делают! Только программистам, почему-то, нельзя.
Весь вопрос в том, что не все задачи следует оптимизировать хитрыми способами. Может оказаться, что это на самом деле не нужно — вызывается очень-очень редко и вполне можно немножко подождать.
Lissov
Ещё раз, про эрудицию и любознательность — я говорил про IT, а не вообще во всём. И вроде как повторил в своём ответе ещё раз. Зачем опять писать про физику?
И да, из личного опыта, обычно те, кому интересно как работает процессор и как найти путь в графе, пишут код куда лучше, чем те кому это не интересно.
wataru
Нужны. В дополнение к словам senya_z, я cам писал ДП в пакетизации видео данных с разбиениями. И всякие задачи с собеседований, типа максимума в двигающемся окне, тоже приходилось писать. Линейная регрессия, еще, например. Т.е. даже математика бывает нужна, хотя какзалось бы, проект — фактически обертка над видео кодеком, даже не сам кодек.
Да, они нужны не 95% и даже не 10% времени. Но когда они нужны — они реально нужны. Что, в этом случае — иметь в комманде отдельного алгоритмиста-гуру? Во первых, проблема в том, что не имея знаний в алгоритмах, программист даже не будет подозревать, что этот кусок вместо 100 строк рекурсивного мессива полного перебора можно заменить на 20 строк с двумя вложенными циклами и коротким комментарием. Во вторых, простой, вроде бы код, никто кроме этого гуру понимать не будет.
Wesha
"Не оставалось", говорите? Challenge accepted. Вопросы, их есть у меня.
Lissov
Зачастую интервьюер действительно хочет посмотреть, какие вопросы задаст кандидат.
senya_z
да. практически всегда хочет. часто задача формулируется так, чтобы кандидату надо было задавать вопросы, чтобы прийти к решению. вопросы, ход мыслей, процесс решения и общий подход к проблеме часто важнее правильного результата.
Stas911
Я хоть и не программирую на работе каждый день, но тоже начал в последнее время разбираться с алгоритмами (с универа многое заржавело уже, а многого у нас и не преподавали). А то конторы повадились их давать даже на инженерные позиции, не связанные с разработкой кода непосредственно.
asd111
Service Objects это очень удобно. Так у нас получаются тонкие модели, тонкие контроллеры и толстые сервисы, в которые уходит вся логика получения и обработки данных.
Service objects не усложняют архитектуру и позволяют разгрузить модели и контроллеры.
igorp1024
Тег "цiкавi дослiди" — это пять! :)
А что до
это весьма сложно звучащая вещь, но она очень просто проявляется в виде граблей в
повседневной жизниобыденных задачах.r0zh0k Автор
Если не знаешь этого то можно легко полдня-денёк на дебаг потратить — лично такое наблюдал.
CrzyDocTI
DevOps без знания IP это сильно=)
r0zh0k Автор
Ага ))) Что интересно — в итоге оффер таки сделали )))
Nalivai
Ну к слову сказать, чтобы девопсить, знать что такое маска подсети не обязательно, действительно.
r0zh0k Автор
Ну такое на самом деле, не уверен что это будет хороший девопс учитывая например что в любом мало-мальски большом проекте который хостится в облаке есть публичные и приватные подсети, разнесенные по AZ.
Я-то знал что такое маска подсети (и вообще что такое подсети), но не смог внятно дать определение.
RomanMen23
Интересно, что уже довольно большой стек статей про то как везде всё плохо с собеседованиями. Причем в каждой упор на недостатки, а не способы их устранения. Увидим тут когда-нибудь ли мы квинтэссенцию идеального собеседования, хоть сколько нибудь приближенной к реальности?
SvyatoslavS
У меня про паттерны спрашивают постоянно, даже те, кто, по моим ощущениям, сам не очень понимает (тут хватает упоминания аббревиатур без расшифровки :)). Правда, я претендовал на миддла, возможно, собеседующие считают, что senior по умолчанию обязан знать основы проектирования.
da-nie
Кстати, как вы это решали? Есть какой-то быстрый алгоритм типа подобного?
r0zh0k Автор
В лоб конечно же — иду по строке, сохраняю в буфере текущую подстроку, проверяю, есть ли там уже такой символ, если нет — добавляю его в буфер и двигаюсь дальше по строке, если есть — проверяю длиннее ли эта подстрока текущего максимума и при необходимости заменяю его, и иду дальше начиная с того места, на котором закончил, как-то так.
По этому решению интервьюер не смог меня ничего спросить, так как его вопросы были заточены именно под длину подстроки, её действительно можно решить проще и быстрее.
По моему решению он вроде как согласился что особо тут ничего не соптимизируешь. Да и не стояло у нас такой задачи.
Я предварительно не готовился и не знал, есть ли быстрые решения. Да и сейчас мне это не особо интересно — хотя наверняка что-то можно придумать.
wataru
Можно тут поподробнее немного? У вас то же, что я описал в этом комментарии, или нет?
А как длину можно найти проще и быстрее, чем саму подстроку?
Lissov
Если я правильно понял, то нет — использовался буфер, который надо проходить заново каждый раз для «проверяю, есть ли там уже такой символ». Именно здесь напрашивается оптимизация вроде хешсета (или как в Вашем решении, с массивом ещё лучше).
В данном случае скорее всего интервьюеру не только сказали дать такую задачу (в чём он явно признался), но и рассказали как свести к вопросу о хешсете, потому что сам он не понимает. Иначе бы он понял, что тут можно прийти ровно к тем же вопросам.
На один шаг проще и быстрее, потому что надо сделать то же самое, но не копировать строку. Насколько я понимаю, самый эффективный вариант найти подстроку это найти сначала длину (плюс место), а потом взять там подстроку.
wataru
Нет, тут никакие z-функции или префикс функции не помогут. Нужен только массив на 256 элементов/хешмап для обобщенных символов.
Не самое лучшее, но умнее наивного за куб, решение за квадрат примерно такое: Для каждого возможного начала подстроки, жадно удленняем ее, пока не встретим символ, который уже видели. Для отслеживания этого просто считаем в массиве/хешмапе сколько каждых символов уже видели. Когда патаемся добавить новый символ, если уже такой видели — останавливаемся.
Быстрое решение за линию почти такое же. Только не начинаем для каждого начала подстроки считать символы заново. Вместо этого продолжаем с последнего символа для предыдущего начала. Ведь эта новая, на один символ короче строка точно иммет уникальные символы.
Можно заменить counts на bool, вместо счетчиков.
mayorovp
wataru
Это субъективная оценка. Ваше решение на 1 строчку длиннее, например, но, по хорошему, я бы тоже должен был сохранить static_cast(end). Какое из двух проще — не очевидно. Мое логически выводится из наивного за кадрат, и поэтому я предпочитаю его.
Я бы сказал, что это 2 одинаково простых решения с разными подходами =)
da-nie
del. Понял, в чём моя ошибка. Символ с beg выводить не нужно.
(Ну и size_t беззнаковый, его на long надо заменить, раз у вас -1 используется. )
mayorovp
А, ну да. Только тогда уж на какой-нибудь ptrdiff_t или intptr_t…
Там, кстати, ещё и со знаковым char будут проблемы.
da-nie
Отличный вариант, но тут есть проблема — а вдруг предполагается строка абстрактная. И возможно, скажем, utf-16 или даже utf-32. Но это надо отдельно оговаривать, наверное.
wataru
Я этот вариант описал сразу за указанной цитатой: "хешмап для обобщенных символов."
Lissov
И можно закапываться дальше в собеседование с вопросами «что лучше». Ведь в некоторых случаях массив всё равно лучше.
abar
Статью обсуждать не буду, меня заинтересовал вот этот момент:
Кто как прокомментирует такое решение:
?
r0zh0k Автор
А звездочки зачем? ))) Причем тут split?
И найти надо не длину последовательности, а саму последовательность.
abar
Звёздочки — потому что неверно задание понял, решил что искать надо последовательность определенных, а не уникальных символов. Тогда, конечно, решение неверное, хорошо ещё что я потратил на него меньше минуты.
artX89
Сейчас пилю проект где серверная часть на Python (flask, asyncio, sqlalchemy, jinja2), база на PostgreSQL, для кеширования и как брокер сообщений Redis, клиентская браузерная часть html5, CSS3, JavaScript (vue), клиентская мобильная часть Kotlin (rxjava, retrofit), используется паттерн MVVM. Все это взаимодействует через API (json-rpc) и WebSocket, периодически данные выгружаются из 1С (используя HTTP-сервисы 1с). Все это располагается на Linux VDS сервере (Nginx). Кроме этого всего, за годы программирования было изучено огромное количество других языков таких как C#, C++, PHP и т.д. НО! Как только я начитаю читать такие статьи, я понимаю, что меня не взяли бы даже на позицию джуниора. Хорошо грузчикам: не пьет – принят :)
dididididi
И еще проблемы такие детские типа один метод, плоховато работает)) Когда у тебя сто тыщ строк кода написаны через жопу и работают вкривь и вкось, чуть что тронешь все разваливается, то починить один метод, который неээфективно сумму скобок считает — да это в радость))))
JSocket
А как же вывод, что нытиков никто не любит?
puyol_dev2
Выскажусь на тему собеседований — ещё до собеседования интересуйтесь, каким образом компания ищет человека: берет сразу, как найдёт нужного, или выбирает. Это крайне важно для понимания дальнейшей работы в этой компании. Компания, которая выбирает из кандидатов, точно не знает, кто ей нужен и берет людей по принципу «нравится». В такой компании и команде каши не сваришь. Не тратьте свое время на собеседования с ними
VolCh
Выбирают обычно компании, у которых одна негорящая вакансия и большой поток формально подходящих кандидатов. И «нравится» не последнюю роль играет — совместная работа, как минимум, негативных эмоций не должна приносить.
SbWereWolf
Смысл проходить интервью с «тупыми» вопросами? мне не интересно работать с людьми которые ни чего интересного спросить не могут. Всегда плыву на вопросах по теории и по практике :) потому что тоже писал на тысяче и одном языке, и что там где как ни когда не помню, гугл всегда поможет.
Когда сам провожу собеседования, то просто смотрю на код тестового и мы обсуждаем его, считаю этого достаточно.
r0zh0k Автор
Кто ж знает наперед что они «тупые»? Все это выясняется уже когда поздно…
SbWereWolf
я к тому что бы не парить себе мозг штудированием ответов на стандартные вопросы, и на самом собеседовании не обломаться сказать «я не в курсе но я умею читать доки и меня не забанили в гугле»
r0zh0k Автор
Я так говорил, но это не прокатывало. Особенно смешно было с тем самым методом compact, который фильтрует нилы в коллекции.
SbWereWolf
главное не расстраиваться. у меня было овер дофига собеседований гдеменя из-за подобных вещей не брали, но я ни окгда об этом не жалел
senya_z
когда на большую часть вопросов кандидат отвечает «меня не забанили в гугле», то шансов мало. когда он знает, в какую сторону копать, но не помнит каких-то деталей, то ответ про гугл принимается. например, решает задачу поиска пути конем на шахматной доске через BFS, при этом говорит, что она может быть улучшена через A*, но он не помнит, как это сделать — в реальной жизни нагуглил бы за 5 минут.
Lunmijo
У меня в универе преподавательница на первом курсе вынуждала писать код на С++ на бумажке. И ладно бы простые циклы/условия/переменные в стеке.
Едва ли не на уровне битовых операций писать заставляла.
На втором поменялся преподаватель — зная, что лабу я сдаю на Java (RESTful микросервис с каким-либо фронтом, «абы было, на красоту мне все равно»), несколько человек пишут на Django, ещё несколько вообще десктопное приложение на C# и WPF пишут, все ещё требовал учить на экзамен какие-то базовые приколы С++ типа зачем обнулять указатели, что такое битовые поля, специфика наследования в С++ (это джависту, питонщикам и дотнетовцам!).
Завалился я на вопросе «в чем отличие struct от class», потому что в моём любимом языке нет нет таких заморочек, а к экзамену я такого вопроса не готовил :))
Многопоточности к слову не было, её тихо отрицали, как явление :(
Это я к чему. Всё эти собеседования бесконечно близки к экзаменам в универе — без бумажки сходу назвать какие-то методы, которые гуглятся в две секунды (один клик в официальную документацию — профит). Я проходил два собеседования по JS на должность «ближе к джуну, но вообще ищем миддла», на одном из них мне показали реальный код ошибки в консоли Хрома, на другом — я решал алгоритмическую задачу в духе «перевернуть массив с повторяющимися элементами».
Если первое — вполне себе вменяемо, потому что с консолью фронтэндщику нужно каждый день работать, то второе просто ??? А зачем мне вообще переворачивать массивы руками? Если я буду писать на Python, я сделаю [::-1], на JS — myArray.reverse() и ничего не потеряю в скорости работы + я не думаю, что писать велосипеды на реальной работе — гуд.
На собеседовании по QA мне дали несложную логическую задачку, посмотреть на ход мышления. И мне это понравилось больше, чем извращаться с алгоритмами, 99% из которых реализованы в стандартных библиотеках, а 1% мне понадобится писать на должности сеньйора, до которого ещё дожить нужно.
P.S.
Собеседования проходил давно, алгоритмические задачи люблю, но не считаю, что умение построить красно-чёрное дерево/написать свою реализаю хэш-мапы/реализовать свой класс динамического массива — задача, которую будешь делать в реальной жизни каждый день.
Lissov
И это ИМХО отличный правильный ответ.
После которого неплохо бы написать хоть какой-то алгоритм именно для «посмотреть на ход мышления». На таком примитивном примере видно, насколько человек дружит с математикой и логикой. Хотя бы то немногое, что можно проверить на собеседовании.
da-nie
У меня на первом курсе пришёл дядя с кафедры высшей математики и изнасиловал нас Derive, Mathlab и численными методами. :) Что характерно, он всё доказывал, но часто ошибался и доказательство не получалось. «Ну исправите, там очевидно», говорил он. :) Как бы не так.