Но реально бесит эта ситуация. 70% собеседований одинаковые. Любого дурака можно научить типовым задачам, алгоритмам и структурам данных и он сможет проходить интервью на уровень Senior Developer.
Какое эта сраная сортировка имеет отношение к моему умению быстро писать качественный код? Чем они думают, эти интервьюеры?
Доля правды в этом есть, но эти знания нужны просто, как база, а так, интервьюеры сами придумывают задачи, их основная цель — понять как думает кандидат и, что более важно, как быстро он думает. Сейчас ситуация такая, что уволить с работы очень трудно, нужно «придумывать» веские причины, поэтому интервьюеры/рекрутеры стараются как можно больше «убедить» себя, что кандидат хороший и нужный. Отсюда мораль, если вы профессионально пишете код, достаточно хорошо владеете базовыми/фундаментальными знаниями, то у вас проблем не будет.
P.S. Как однажды сказал мне мой интервьюер компании, в которой сейчас работаю я — "есть люди, которые прекрасно владеют математикой, фундаментальными знаниями, алгоритмы и т.п., они могут с легкостью доказать сложную теорему, решать сложные задачи, но нам нужны практические люди, люди, которые имеют «ньюх», которые могут в уме компилировать код, при этом учуяв ошибки, люди, которые смогут работать. Практики, а не теоретики".
Да нужны практики но таких людей
а) легко научить (и их много)
б) такие люди нужны но в унылых маленьких компаниях
А люди которые умеют думать и имеют глубокие познания в алгоритмах
а) Их мало, и они ценятся на вес золота (а соответственно получают на порядки больше)
б) их просто научить правильно делать то что требуется компании
И да, знаие какого либо фреймворка перестанет быть нужным через 2-3 года.
Ну «фреймворки» тоже разные. Например возмем api/структуры/устройство ОС (чем не фреймворк), будь то windows или mac, там крайне медленно что-то меняется и в основном только дополняется. Меня до сих пор знакомые бывает используют как справочник по windows (эдакий интерактивный учебник по «windows internals»), хотя я уже ну примерно 6 лет под нее не пишу и забыл просто невероятное количество материала пересев за мак. И да, чтобы подобный обьем знаний впихнуть в себя, нужно пожалуй даже больше, чем 2-3 года.
У вас идёт интересный цикл, спорный, но тем и интересный. И, наверное, нет «серебряной пули» для всех случаев. Т.к. в каждой отрасли программирования есть свои ньюансы и свои требования к конкретной функциональной обязанности в данный момент.
Я на протяжении 8 лет, занимаясь отбором сотрудников, процедуру оценки кандидата делил на 2 этапа:
— очень короткая беседа-знакомство с просьбой рассказать про свои труды и минимум технических вопросов, цель которых прощупать кандидата — а знает ли он вообще что-то в требуемой области (примеры вопросов — для Java-разработчика — «Что такое JAVA_HOME и CLASSPATH?», для PHP — «где искать сообщения об ошибках?», для DBA — «для чего применяются транзакиции?») — т.е. что-то очень элементарное, что позволяет отсечь тех, кто просто обозначил в резюме список аббревиатур. И самое забавное, что на каждом наборе встречался минимум 1 такой кандидат.
— на следующем этапе кандидату предлагается провести в коллективе 2-3 дня и столько времени, сколько возможно — например по 2 часа в день или вообще 1 полноценный день — кто как может. На этом этапе кандидату дается рабочее место и некая реальная задача по его профилю. На задаче есть предварительная оценка времени командой (обычно 2-3 часа). Ну а дальше спрашиваем понравилось ли кандидату у нас и если понравилось, то оцениваем код и фактическое время выполнения задач.
Посадить за машину и дать небольшую задачу. Сразу будет виден и ход мысли, и стиль кодирования, и скорость.
Только задачу практическую, а не алгоритм сортировки. Кстати, тестовые задания мне неплохие попадались, но их присылали по почте, а уж после приглашали на беседу. Тоже хороший подход, но скорость не оценить, да и помочь кандидату кто-нибудь может.
Как правильно сказал интервьюер Dehumanizerа в каменте выше — для обычной программерской работы нужен практический человек. Который умеет писать код, который этого кода написал уже туеву хучу, видит заранее возможные места ошибок, знает свой язык/фреймворк как пять пальцев.
Объясню свою позицию, почему у меня большие сомнения, что можно оценить работу программиста (по критериям быстро/качественно), посадив его на два-три часа за незнакомый компьютер.
Программист хорошо работает в комфортной и привычной обстановке. Когда его IDE настроена под него, когда в наушниках играет любимая музыка и когда за спиной не сидит кто-то, который смотрит на каждый набранный символ.
Со-беседование — это всегда диалог, вопросы/ответы, анализ его знаний и коммуникабельности (ему же потом в коллективе работать!). Никаким наблюдением за процессом кодирования этого не заменить.
Понимаю. Следует учесть, что для небольших коллективов обеспечить программисту комфортную среду разработки — сложно, не всегда возможно, особенно если задача требует диалога/итерационности/quick-check… Такой метод позволяет оценить способность работы в сложных условиях.
В любом случае, я не отдаю предпочтение какому-либо способу, а применяю множество из них, меня так научили.
Собеседование должно иметь за цель поверхностный отбор необходимых кадров. Уже в самом рабочем процессе человек показывает, какими качествами обладает.
В случае полного непрофессионализма и зазубренных ответов — в течение месяца всё становится очевидным. Хотя бывают исключения.
Лучше бы давали кусок говнокода (если ООП — то ООП-говнокода), и просили его отрефакторить, а еще лучше — найти ошибку или внести улучшение. Останутся только, кто не прошел хорошую школу.
Bucket sort может использоваться для равномерно распределенных по ОДЗ данных, и максимальное время ее работы — все те же nlog(n). Сортировать по возрастам надо подсчетом.
П. С. А будет третья часть? Где секция про рандомизацию? Как перемешать массив за один проход и все такое?
Третья часть статьи будет посвящена языкам программирования, и планируется написать еще несколько частей, рассматривающих более сложные собеседования, скажем, на должность сениора. Если есть какие-то предложения, буду только рад.
Максимальное время работы Bucket sort не О(nlog(n)), а всетаки — О(n). Пруф-линк 1.Пруф-линк 2.
Сортировать по возрастам используя блочную сортировку не является ошибкой, представьте «блоки» маленькими (по году каждый).
Под сортировкой по возрастам я понимал сортировку с точностью до года, тем более вы упомянули про «маленький интервал значений», который в случае сортировки с точности до дня не такой уж маленький. Если «эффективность прежде всего», то большой массив надо сортировать стд:: сортом и не морочить голову :)
Я люблю на собеседованиях спрашивать недостатки технологий, которыми владеет соискатель.
Т.е. приходит соискатель, говорит, что знает технологию или язык «Х». Я не спрашиваю достоинства, они есть в книжках, их все знают. Я сразу спрашиваю, что в технологии «Х» плохо или не нравится соискателю. Удивительно, но большинство соискателей испытывают затруднения с этим вопросом. А ведь профессионал в технологии «Х» рано или поздно находит в ней недостатки. Это кстати справедливо для любого «Х».
вторую статью же уже халва идет, причем неудачно реализованная
ну где и кто ищет n-ое число фибоначчи за линию (второй вариант)/квадрат(первый вариант), когда его можно найти за логарифм?
Я одно понять не могу.
Любой человек с опытом успешно проходил десятки точно таких же стереотипных собеседований, и отвечал там на точно такие же стереотипные вопросы.
Вы действительно думаете, что сможете заметить что-то такое, что пропустили десятки кадровиков до вас?
Вопросы у вас банальные — сортировка, Фибоначчи, битовые операции… Все это разжевано и реализовано в базовых библиотеках 30 лет назад. Сейчас это делается не самописной процедурой, а готовой функцией. Вы бы еще умение пользоваться логарифмической линейкой проверяли.
Сейчас актуально ООП, знание основных принципов построения масштабируемой системы при помощи готовой платформы/фреймворка, правила оформления кода, принципы отладки, рефакторинга и оптимизации. Это нужно всегда и должно быть в голове по умолчанию.
1. Это будет рассмотрено в следующих частях.
2. Готовую функцию могут вызвать все, но не многие могут объяснить как она работает и тем более как ее реализовать.
3. Знание фреймворков может стать не актуальной через некоторое время, лучше быть готовым изучать новые фреймворки, понимая, что там творится под капотом.
4. В статье я не говорю что-то новое, я просто предоставляю руководство(скромное) для людей интересующихся, а проблемы «тупых» интервью пусть решат сами конторы.
Скромное руководство по прохождению интервью: часть 2