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