Comments 431
У меня были друзья-разработчики, они работали джунами и использовали какую-то бездушную хрень вроде C# или Java. И я хорошо чувствовал — я уже разбираюсь в своей технологии намного лучше, чем они в своих.
Чувства тебя обманывали, Антон)
Да
У тебя есть доступ в приватный репо. Твой выход
Значит, мне придется это выложить в опенсорс, оформив, как полагается в npm. И все же, где мне посмотреть твой лучший код?
Я ещё не написал свой лучший код
Как и все мы… :)
Даёшь идеальный публичный FizzBazz для хайлоада с e2e тестами, dockerfile, правильной историей коммитов, TDD, DDD, SOLID, KISS, FP, MVC, CI/CD, PWA… ой, не туда меня понесло.
Есть и HelloWorld Enterprise Edition: gist.github.com/lolzballs/2152bc0f31ee0286b722
В моем 10-летнем или даже прошло-месячном коде все хуже чем в сегодняшнем. Но сегодняшний код я пишу балансируя между тем как я хочу и тем, сколько мне дают на это времени. Дали бы ∞ времени, я бы довел весь свой код до ∞ совершенства.
Вы видимо, пишите его один раз и больше не меняете. Ну и работаете наверное с этим кодом один. При долгосрочной поддержке и командной работе с кодом такоц подход допустим только на этапе PoC или прототипа.
ЗЫ что-то вспомнилось, надо где нить спросить как крутые ентерпрайз ребяты сделали бы регистронезависимый поиск по обычной html табличке, с последующим скрытием строк.
Мой лучший код — быстро, с хаками и велосипедами написанная логика системы управления станка
Работоспособность — не характеристика кода, это характеристика программы. Хороших программ с плохим кодом много.
А вылизанный, чистый хороший модуль, написанный с соблюдением всех известных мне хороших практик, пылящийся в старой репе развалившейся комманды я лучшим своим кодом не считаю.
А зря ))
Когда ваш станок отрежет оператору палец, а вас собьет Self-Driving Car написаный человеком с вашими идеалами — вот тогда и… не поговорим.
Возможно, сейчас меня занесет в полную противоположность — но будь моя воля, я бы может брал вообще всех, кто хочет работать.
Что интересно — меня по похожему принципу взяли. Я выгорел на прошлом стеке технологий, начал изучать другой, неожиданно написала HR, пригласили на собес несмотря на то что сказал что только недавно начал изучать стек нужный, на собеседовании поговорили с руководителем будущим на довольно общие темы, сейчас на испытательном с НГ. Да, риск непрохождения испытательного большой, особенно учитывая что команда мобильных разработчиков в отделе только собирается и нет какого то наставничества и введения в процессы как на прошлом месте, но пока мне все нравится, посмотрим что будет в конце испытательного.
P.S. И да, «бездушное, что-то вроде C# или Java» — ни разу не правда. Пишу на котлине и не понимаю как до этого писал на языке с динамической типизацией.
Пишу на котлине и не понимаю как до этого писал на языке с динамической типизацией.
Ха! «Пишу на языке с превосходным дизайном, отличным набором библиотек и extra-high quality toolchain-ом — и радуюсь жизни» — вот как это звучит в переводе.
Особенно нынешняя java.
А вот что особенно здорово для «вкатывающегося в jvm» — это котлиновский curated набор библиотек.
Собрано все лучшее — нет опасности что кто-то закопипастит реликтовую дрянь из года 2006-го
И да, «бездушное, что-то вроде C# или Java» — ни разу не правдапохоже, имелся в виду «кровавый энтерпрайз».
Если нет — ну тогда это простой наемник, которому все равно что делать, лишь бы $$$ платили, и тогда имеет смысл переходить к классическому собеседованию вопросы/ответы.
Важно понять, что человек делал, но техническую часть проверить тоже надо.
Я стараюсь создать доброжелательную атмосферу, подчеркиваю, что можно ошибаться, если удобно — можно рассуждать вслух, если есть варианты — обсуждаем их, какой когда лучше. Если случился затык — наводящие вопросы, не помогает — предлагаю подойти к задаче с другой стороны. Главное, что надо понять — сможет ли человек решать проблемы заказчика.
Задачи предлагаю довольно общие
- fizzbuzz — вывести в столбик числа от 1 до 100, если число делится на 3 — то вместо него fizz, если делится на 5 — то buzz, если и на 3, и на 5 — то fizzbuzz). Язык — любой, хоть псевдокод
- спроектировать БД на 3 таблицы и написать запрос к ней (если есть ошибки в SQL — неважно, лишь бы общая канва решения была понятна)
- задачка на синхронизацию потоков (для нас это актуально)
Понятно, что бывают наемники, бывают фанаты, но от хорошего Senior Developer я все же ожидаю достаточно хорошего решения по каждой из этих задач (не обязательно с первого раза и не обязательно такого же, как мое).
Есть опасность взять человека, «умеющего только проходить интервью».
Полагаю, вы можете не согласиться, но, на мой взгляд, далее по тексту пример интервью, идеально подходящего в первую очередь для "человека, умеющего проходить интервью".
Каждый* человек способен на диалог, разговоры для нас естественны, кроме того, чем дальше мы растем, тем больше учимся "читать мысли", — отвечать на вопросы, которые еще не заданы, предупреждать проблемы, которые пока не возникли. В особенности это касается человека, на плечи которого возложена ответственность. Ведь обычно, мы учимся не решать задачки, а понимать, как именно нужно решить "задачку" именно "сейчас", в определенном контексте.
Что такого в этих задачках? В чем их манящая для рекрутеров природа?
Почему опытным разработчикам так необходимо проходить простые, "общие" задачки?
Вас не заботит, насколько они просты, насколько оторваны от контекста?
На одну и ту же задачку я могу потратить вечность, минуту или долю мгновения. Что бы оценили вы? Время? Число наводящих вопросов? Эффективность решения? Универсальность? Но ведь, как бы я не размышлял, единственный способ максимально удовлетворить каждому из этих критериев — заведомо знать ответ. FizzBuzz решенный за минуту, примерно в 60 раз хуже "решенного вчера".
Что делает нас специалистами? Опыт. Знание. Успех. Ошибки.
Полагаю, некоторые из нас в конечном итоге вовсе забывают, что такое "ошибиться":
скорость и изящество; код, архитектура — ровно настолько безупречные, насколько это необходимо.
Несколько часов подготовки и вот, любая задачка окажется решена прежде, чем вы протянете карандаш. Я никогда не проваливал тесты, готовясь к ним. И никогда не осиливал, спонтанно явившись на интервью.
В какой то момент появился вопрос.
Мои работа и стремление — создавать уникальные вещи, на границах возможностей работодателя.
Ради чего мне стремиться учить то, что (на мой взгляд) способен выучить любой?
Безусловно, я не отбираю у вас право задавать задачки. Более того! Скажи вы мне:
Задачи предлагаю довольно общие
fizzbuzz — вывести в столбик числа от 1 до 100, если число делится на 3 — то вместо него fizz, если делится на 5 — то buzz, если и на 3, и на 5 — то fizzbuzz). Язык — любой, хоть псевдокод
спроектировать БД на 3 таблицы и написать запрос к ней (если есть ошибки в SQL — неважно, лишь бы общая канва решения была понятна)
задачка на синхронизацию потоков (для нас это актуально)
И, сделав ставку на то, как прекрасна ваша вакансия, вы бы увидели самого прилежного зубрилу.
Но… Так много вакансий без нудных задачек. Стоит ли тратить время зря?
А так ли их много?...
Их, в действительности, стало очень много за последний год. И справедливости ради, компании часто соглашаются отказаться от задачк, если попросить.
На днях прошел первые 2 собеседования за год.
Рапортую вам 50% вероятности
Компания А после 1.5 часа хочет алгоритмы на час + собес с руководством + неизвестно, даст ли оффер.
Компания Б согласовала собес в тот же день и после 2 часов интервью дала оффер.
Первое предложение Б на 10% хуже максимума в А., сфера деят., масштаб ~ одинаковы.
спроектировать БД на 3 таблицы и написать запрос к ней (если есть ошибки в SQL — неважно, лишь бы общая канва решения была понятна)
Классическую из задачника вроде книго/фильмотеки на умение в нормализацию, или что-то более специфичное? Напишите, пожалуйста, сформулированное задание, если не затруднит. Интересно.
Мне однажды на мою фразу, что я в айти по любви ответили с гадкой усмешкой, что ну у нас тут не любовь, а работа. Безмозглые мудаки.
А если боевой сервер «то падает, то не работает», то CTO нужно уволить к чертям.
горячо обсуждаемая статья
А не поделишься ли ссылкой, пожалуйста? Не могу найти, а почитать было бы интересно.
Халявщики конечно иногда встречаются везде. Но очевидно что в таком случае они не являются увлеченными и любящему свою работу. Просачиваются, что же поделать. Самый яркий пример у меня был: набирали продавцов в спортивный магазин в крупном ТЦ: зарплата выше рынка, работа интересная, мотивация имеется, etc. 2 из 11 оказались лодырями, что поделать. Зато получил непередаваемое удовольствие от работе с остальными: одни хорошо продавали, другие владели техническими аспектами, некоторые были харизматичны до ужаса, а другие про товар рассказывали так что я сам был готов купить, обнять и облизать. Конечно бывает и отвлекались и витали в облаках и не занимались рутиной, ничего страшного, рассказывал, объяснял, убеждал и наступало счастье. Где то правили бизнес-процессы согласно их замечаниям и опыту, учились друг у друга. Мы даже разрешали регистрировать покупки на отсутствующих в смене: клиенты частенько через длительное время и помнили кто их консультировал.
Если же с такими людьми топать ногами, требовать немедленных продаж, не слушать доводы и действовать как средний менеджер, то все может пойти очень плохо. И нужны будут жесткие бизнес процессы как у крупных сетей расчитанные на низкоквалифицированный персонал.
Вообще программисты все из себя такие плохие и требуют. Но почему то строительство здания предполагает проект, инженерные изыскания etc И если вместо сарая вдруг понадобился отель то обычно сносят сарай и строят отель. А вот программистам регулярно предлагают сделать из сарая, который стоит то чудом, построить Бурдж Халифа (как минимум).
А большинство неуспешных — начало с найма дорогих профессионалов а потомПруф.
Сколько денег выкинуто в мусор на релизе забагованных продуктов, потере критичных данных, отсутсвии резервной архитектуры и прочей экономии, несчесть. Да вон взять тот же геймдев: триллионы баксов отправились в помойку по причине релиза сырых продуктов.
Вообще апеллирование к систематической ошибке выжившего как к аргументы как раз наилучшее доказательство того, о чем я говорю)
В геймдеве я не силен — но думаю что проектов, «заваленных» из-за багов на два порядка меньше чем закрытых из-за кончившегося бюджета. Особенно в наше время сетевых игр и онлайн-установки апдейтов и патчей.
Главное доказательство этой теории — это Винда и другие продукты Майкрософт, дружно осмеиваемые «хардкор-программистами», «супер-админами», поклонниками TeX и прочими узкими меньшинствами на протяжении всего жизненного цикла. Что не помешало ей снискать колоссальный коммерческий успех и похоронить кучу конкурентов.
Это не ошибка выжившего — это поиск стратегии выживания. И из известных мне фирм вот это самое "… як-… як — и в продакшен" привело к успеху десятки, а мощное и всеобьемлющее планирование погубило сотни.
Чрезмерное затягивание действительно губиьельно. Но стратегия быстрого релиза может сработать только если вы предлагаете уникальный продукт на пустом рынке и смогли в первых версиях продемонстрировать его конкурентные преимущества.
И опять же, мы конечно можем говорить что дельфины чрезвычайно умные и всегда выносят человека к берегу, вот только у тех, кого они несли не к берегу шансов рассказать уже не будет никаких.
В геймдеве я не силен — но думаю что проектов, «заваленных» из-за багов на два порядка меньше чем закрытых из-за кончившегося бюджета
Возможно, на азиатском рынке так оно и есть. Но вот сколько я наблюдаю за рынком ММО, релизнуть сырую игру это которкий путь выкинуть много денег.
Особенно в наше время сетевых игр и онлайн-установки апдейтов и патчей.
И кому они будут нужны когда в стиме рейтинг игр будет в районе плинтуса?
Главное доказательство этой теории — это Винда и другие продукты Майкрософт
Не только их заслуга, время было такое. Сейчас иногда снести ее проще чем сражаться.
В конце концов если мы говорим о крайних случаях: ну и пусть?
Я и переделать потом могу, только деньги несите и сроки реальные ожидайте.
Даже если ваше здание убьет сотню человек?
Я вот например не согласен, я не хочу делать картонный фундамент, не хочу делать средства цензуры и слежки. Рынок большой.
Типо делать нужно все что прикажут?
Хотя лично я с идеей вашей согласен. Да, начальник может сказать: «да мне пофиг, делай на картоне», а когда здание рухнет — «ну я же не знал, ты профессионал и не должен был делать так, чтобы оно рухнуло».
Мне как-то спустя 4 года работы менеджер кинул претензию, что решение, принятое 4 года назад не подходит под новые требования, оно не может достаточно гибко настроиться в админке и нужно кусок перекодить. Говорит, мол: «хреновый из тебя архитектор, раз ты не продумал, из-за тебя теперь релиз переносим»
А четыре года назад он сказал: «Та сделай как-нибудь, нам срочно надо, потом переделаем». И четыре года оно продержалось, отлично скейлилось, но в итоге я всё-равно виноват, что плохо закодил и плохой из меня архитектор.
Он, конечно, потом признал, что был неправ, но тут сильно яркие разбежности — много лет прошло, а изменения вносились за дни, а не месяцы. Но это мне явно показало, что даже если начальник говорит: «та это полная хрень, ответственность на мне, мы никогда не будем использовать это на продакшене, так что сделай костылем и очень срочно», то надо слышать: «это крайне важная фича, ответственность полностью на тебе, мы её будем использовать на продакшене и тыкать тебя носом в каждую недоработку»
«это крайне важная фича, ответственность полностью на тебе, мы её будем использовать на продакшене и тыкать тебя носом в каждую недоработку»
Все именно так. Еще смешнее все выглядит когда решения связаны с инфраструктурой. Одной компании предлагал для повышения эффективности внедрить ip-телефонию все дела. Не хотели нивкакую, потом внедряли очень срочно потому что «эффективность же». А на мои указания «ты не достаточно сильно настаивал, надо было донести».
Думаю, что проблема в слишком агрессивном уходе в крайности.
Разве? А повальное нежелание разбираться в вопросах/нести ответственность/принимать решения не есть крайность?
Кроме того, «я выполнял приказы» — самая частая фраза на нюрнбергском процессе. Посему я буду думать своей головой и жить так, как верю.
Жизненно-критическое ПО проверяется и перепроверяется по 10 раз.
А причем тут жизненно важное? Я например не буду ни писать ни внедрять системы слежки и иже с ними.
а заказчик всё равно хочет по-своему
Есть еще третий вариант: нет, будет вот так, или увольняйте.
С одной стороны выглядит не очень красиво, но мода на
ну я же не знал, ты профессионал и не должен был делать так
прямо захватывает умы сотен. Причем встречается в разных сферах/городах/etc. Без проблем, я готов брать на себя ответственность, но тогда будет по-моему.
зы
Я вас не минусил
Да я переживу, просто любопытно стало прям.
Приходилось руководить разными. Понятие "своего дела" любимого — у каждого свое, к сожалению часто отличающееся от того, что приносит фирме деньги.
Вот, из последнего — очень толковый алгоритмист работал лишнюю неделю над повышением точности алгоритма и не соглашался релизить "сырую" версию. Он достиг действительно выдающихся результатов — но в самом продукте такая точность не нужна и даже сбивает с толку. Теперь обьясните, где фирма должна найти деньги чтобы оплатить ему эту неделю.
А ты точно "руководитель"?
Пока больше похоже, что хвост вилял собакой
Но если поставить иначе то вот потому, волт для этого и вот такой эффект.
Так что ошибаются не только менеджеры ;)
Исключительно они. Виноват всегда и во всем руководитель.
В любом случае если ваши планы на сотрудника не сошлись с действительностью то косяк исключительно ваш.
Вечер, дождь. У камина сидит пожилой джентльмен. Распахивается дверь и вбегает дворецкий:
— Сэр! Спасайтесь! Темза вышла из берегов! Через пять минут вода
хлынет сюда!
— Выйдите и зайдите снова.
Дворецкий выходит и снова забегает:
— Сэр, Темза уже вот-вот будет здесь, спасайтесь!
— Бэрримор, выйдите и доложите, как подобает настоящему английскому дворецкому!
Не спеша открывается дверь, потоком воды вносит дворецкого:
— К Вам Темза, Сэр!
многолетним опытом участия в олимпиадахэто сразу такой красный флажочек, который просто кричит ОСТОРОЖНО — «минное поле», не вступи во что-то плохое))
А что не так с олимпиадниками?
«Олимпиадники» не думают ни про поддерживаемость и читаемость своего кода, ни про интеграцию в комманду, ни про сроки и трудозатраты, ни про опасность велосипедостроения,
Качество кода фиксится за пару месяцев, если используется код-ревью.
Интеграция в команду — это от человека зависит. Например, самые престижные олимпиады — командные, так что кто-кто, а олимпиадники должны уметь работать в команде.
Сроки, приорететы и велосипедостроение — это больше зависит от менеджера и лечится тоже весьма просто, парой внушений.
Например, тот же гугл в интервью своих явно заточен именно на олимпиадников. Костяк команды вконтакта был сплошные олимпиадники.
Если бы перечисленные вами проблемы действительно были системными, у кучи больших компаний были бы огромные проблемы.
И да, мы говорим не про людей, которые «лечатся парой внушений», мы говорим про людей обычных, у которых есть свой подход, свой опыт и свои практики.
технологии фанатом которых собеседуемый является.
уж лучше простой наёмник чем фанатик
Реально прямо влюблённых в программирование — десятки процентов, точно меньше половины. Из них ещё какая-то доля тех, кто настолько его, программирование, любит, что без устали строит велосипеды и занимается прочим ftwjavascript вместо решения непосредственно бизнес-задач.
Почему бы отказывать в нормальном собеседовании большей части? Вам же нужен сотрудник для работы, а не для интересных разговоров
Это стиль статей такой или автор создал второй аккаунт?
Изначальное приглашение fillpackart от arttom, намекало на виртуальность аккаунта, то что теперь там стоит приглашение от НЛО, намекает еще больше. А стиль изложения своих мыслей от rcanedu в этом посту, очень похож на стиль fillpackart, прям идентичным мне показался.
Есть одно правило: чтобы хорошо писать, надо много читать. Безусловно нужен определенный талант, чтобы овладеть искусством письма, но это доступно каждому. Про психологию и риторику написано очень многое, это не тайные знания. Может этим обусловлены похожие стили, потому что авторам понятно как они будут работать, а может виртуальностью авторов. Согласно Байесовскому мышлению, можно предположить различные гипотизы для выяснения вероятности виртуальности авторов, например: какие-то детали в именах, в никах, в закладках, в КДПВ и прочих вещах, в которых смогли наследить авторы, но для меня это не очень важно. Мне просто видится намеренная игра с читателями, а если говорить в духе времени, то троллинг читателя и бездушие авторов. И по моему, вся суть заключается в привлечении аудитории. При этом я могу ошибаться.
Но главное не в этом, а в принципе — «потребление или созидание».
«Потребитель» ищет идеально готового спеца, а «созидатель» ищет того, кого сможет обучить, если вдруг тот чего-то не знает. Если нужно по-быстрому закончить проект и разбежаться, то «потребительство» оправдано. А если предстоит работать месте в одной команде несколько лет, то подход совсем другой.
Джуны? Наставничество? Пффф…
Только уверенные, опытные, отлично владеющие нужными технологиями парни. Хорошо-бы уже команда, но мечтать не вредно. HR-ы — вперед, нужно сто резюме, выгребите hh и прочие площадки. Тим-лид — ты следующие три дня только собеседуешь, прости брат, ты эти три дня как на конвейере, извини за цинизм, но из тех что ты просмотришь ты должен взять а) лучших по компетенциям б) тех с кем точно сработаешься сам и другие сотрудники.
Парни, вперед, just do it.
За последние полгода при смерти оказалось два крупных системных интегратора, один на полторы тысячи численного состава, другой на пятьсот. И там и там были десятки джунов, наставничество и все такое. Еще пара интеграторов такого же уровня тоже чувствуют себя ой как непросто.
Долгосрочная перспектива это в сбер, газпром, я там не работал, только слухами питаюсь, но говорят, что там что джун, что сеньор, вообще могут и не работать, главное в офис являться и на совещания ходить.
около 100 человек, из которых программистов около трети.
А чем компания зарабатывала? Вы P&L видели?
Можно сидеть на одном-двух крупных заказчиков и пуле их проектов и чувствовать себя отлично.
Например так жил полтора десятка лет Active CIS, а потом, в декабре взял и выгнал на улицу тысячу человек.
Кейс: вы берете джуна на вырост, на 50К, следующие полгода он как пылесос собирает со всех до кого может дотянуться знания, опыт, наработки. Это период адаптации, человек учится, его вовлеченность, а точнее та добавленная стоимость, которую он создает, колеблется около нуля. А через полгода он просит 100К, или заявление на стол. Ваши действия?
В условиях крупного города, где десятки, сотни компаний работают в том же стеке, я раз за разом сталкивался именно с той моделью которую описал выше.
Компенсируется как ни смешно прозвучит — хорошим коллективом и интересными задачами.А как же печеньки?
И вы спрашиваете что не так? ВСЁ.
Шанс из джуна вырастить звезду есть, но я даже обсчитывать вероятность этого не хочу, просто у нас нет денег чтобы эксперементировать.
Я говорю про производство, где звезды не нужны. Где от зари и до заката надо фигачить вполне тривиальные задачи. Вот в этой ситуации джуны ну совсем с экономикой не вяжутся.
Во всех остальных случаях, платить 50 специалисту который стоит 100 нельзя.
Полностью согласен. Именно поэтому наверху постулирую, что лучше сразу взять спеца за 100, он уже все что нужно умеет и стоит ровно столько на сколько умеет.
Ваша компания работает, а компания вашего оппонента выигрывает тендеры.
Но есть и другой вид бизнеса — взять потребности заказчика и их реализовать. Выбирая вендора, технологию, архитектуру в зависимости от потребностей заказчика, а не особенности конкретного продукта.
Тендер — это нечто обидное? Да, мы работаем на внешнем рынке, да мы вынуждены мониторить площадки, где публикуется информация о заказах, конкурсах, тендерах, аукционах. Мы именно таким образом работаем, в этой модели что-то не так?
Это как у Пушкина: орлу и ворону не сойтись во вкусовых предпочтениях.
UPD.
Стоит уточнить термин «работает»: я так понимаю, проблема в нем.
Компания вашего оппонента решает задачи, как я понял, своими силами. У нее есть штат специалистов, приспособленных для решения таких задач. Они и работают.
У вашей, опять же насколько я понял, есть штат специалистов, приспособленных под решение задачи выиграть тендер и организовать решение содержащихся в нем задач. Собственно же решение задач осуществляется силами приглашенных специалистов. В этом смысле «работают», решают задачи именно они.
В общем случае это не хорошо и не плохо, посредник — занятие необходимое в большинстве сценариев, известных нашей цивилизации. А детали могут различаться настолько, что опять-таки никакую оценку им давать без знаний конкретики попросту некорректно.
Наверное, такой ответ будет более правилен, чем предыдущая сокращенная версия.
Ваша компания работает, а компания вашего оппонента выигрывает тендеры.
Противопоставление выделенного болдом подразумевает, что компания которая выигрывает — не работает?
UPD: Увидел ваш update уже после того как написал свой комментарий.
Поэтому срочный договор, или ГПХ.
![image](https://habrastorage.org/getpro/habr/comment_images/827/b46/79e/827b4679ea85dff5470dd0da77ca8fce.jpg)
Я то же с опытом понял, что если у человека есть желание работать и учиться то это гораздо важнее чем его текущие знания. Все таки в мире больше умных людей и практически любого при желание и возможности можно научить чему угодно. А слова "… учить людей интереснее, чем их фильтровать." вообще можно отлить в золоте!
Это история взросления, зарабатывания уверенности в себе и самоуважения. +100.
— А покажешь? Может хоть пойму, чем так людям нравятся эти мерзкие руби.
— после чего у автора якобы начинали раскрепощаться кандидаты…
Не представляю себе кандидата, который после такого начал бы раскрепощаться, для меня подобное заявление поставило бы жирную точку в дальнейшем общении. Я тоже считаю руби мерзкими, как и любимый джс автора, и пхп с виндой и много чего еще, но заявлять такое на собеседовании… Надо быть совсем уж упоротым «интровертом».
Взросления?
Именно. Вы примеряете этот диалог на себя в позиции собеседуемого в типичной ролевой игре, описанной в начале статьи. Это когда собеседующий — "строгий профессор", а вы "студент-раздолбай" на зачёте, потеете в ожидании каверзных вопросов с целью завалить.
Автор же ищет пути этой ситуации избежать и беседовать с кандидатом на равных, как человек с человеком. Может, не идеально ищет, но сам факт.
«Мерзкий?! Показать тебе, почему ты не прав?! Ну держись, сам напросился!»
del, ошибся веткой.
У компании есть реальные задачи и перед вами сидит человек. Нужно изучать человека и пытаться трезво и четко представить как это будет когда он начнет решать эти задачи. Как только представили, думаем годится ли это или есть шансы что придет кто-то получше. Все остальные способы оценки кандидатов — лютая лотерея.
![image](https://habrastorage.org/getpro/habr/comment_images/46f/039/724/46f039724bffc31ca64e78268bc09d65.png)
Всегда напрягало, что не мог поделиться с коллегами статьями с хабра на русском :)
Кстати, код в этом твите очень странный. Используется
return array.map
и, казалось бы, функция должна вернуть вменяемый массив с результатом проверки каждой строки, но на практике функция, которая передана в мап — грязная процедура, которая что-то там пишет в глобальные переменные, возвращает undefined и как результат — вся функция возвращает массив undefined. Нафига? Если уж есть надобность релизовать через изменение глобальных переменных — пиши через for-of, зачем вводить в заблуждение используя мап?И вот ты, с хорошим настроением, зайдешь сделать код-ревью. Увидишь такое и, с впечатлением, что человеку абсолютно наплевать на проект и на команду ты прокомментируешь, что этот код неудачный.
А эта обиженка побежит в твиттер и напишет прикольненькое сообщение о том, как его лид-мудак в плохом настроении несправедливо покритиковал его прекрасный функциональный код.
— Языки программирования делятся на процедурные/обьектные и функциональные
— Процессоры делятся на «классические», SIMD (GPU/DLA) и встраиваемые
Единственные профессиональные критерии — насколько человек понимает, как то что он делал ранее (или говорит что делал) ложится на эту классификацию и как абстракции принятые в использованной системе программирования соотносятся с более низкоуровневыми абстракциями (файлы, потоки, сетевые соединения и так далее).
И если человек понимает что и как заставляет мигать светодиод на Ардуино — он начнет писать для STM или чего-то подобного уже к обеду первого дня. А если обьяснение — «ну, я там нашел библиотеку и оно вот», то все плохо.
Нужно понимать, что срок жизни отличного программиста на рынке труда это считанные месяцы за 10-20 лет. Есть у меня знакомый А, он может за 2-3 недели изучить распределённую систему (ядро биржи, ~100KLOC), в которой куча многопоточности, сложная логика и нет документации и начать решать любые задачи с отличной скоростью и качеством, не задавая даже вопросов авторам кода. Есть знакомый Б, который после года работы с этой же системой не может выйти за пределы одного, небольшого модуля. Резюме знакомого А никогда даже не было опубликовано, нашёл работу студентом, а после сам выбирал работодателя. Знакомый Б всегда открыт к предложениям и его легко найти и на hh и в LinkedIn. Аналогичная история у всех, без исключения, моих знакомых уровня А. Их просто нет на рынке труда и они там никогда не появятся.
Может кто-то наблюдает другую картину?
Вы всех под одну гребенку как-то. Знакомому А повезло студентом выбрать адекватную контору, которая платит деньги и даёт интересные задачи. А некоторым приходится учиться на горьком опыте и составлять резюме.
Просто кто-то учится всю жизнь, без перерывов, а кто-то просто фигачит не вдаваясь в подробности, лишь бы работало. За 10-15 лет разница между ними становится настолько огромной, что вторым первые кажутся уже даже не людьми, а магами, которые волшебным образом решают проблемы.
Я провел их около сотни, и за все время взял может человек четырех.
Из этой строки понимаю, что компании просто не нужны были новые сотрудники: HR проводили бурную имитацию деятельности, автор тоже, практически с нулевым выхлопом, всех всё устраивало и было даже причиной для гордости. Бывает.
Так что насчет надежности данного метода есть обоснованные сомнения.
У меня свои, личные счёты есть к подобным собеседующим. Традиционно, считается, что лучше всего быстро предложить "Пусть не лучшее, но точно рабочее решение и работать над его улучшением, чем сразу пытаться решать задачу оптимально и не добраться даже до половины." — я традиционно так и поступал.
А потом мне попался собеседующий, который вообще не слушал мои пояснения, а просто пырился в служебный ноут, выдал только что-то типа "Квадрат, давайте другой вариант" и дальше пырится в свой ноут.
Я сижу и думаю "Ну да, я же, блин, сразу сказал, что решение за квадрат будет и почему я его беру..."
И позже, уже после собеседования — "Что это вообще было? Профдеформация олимпиадников, для которых если решение не оптимальное, то это и вовсе не решение? Так он, вроде, не похож был на недавнего студента, а такие вредные привычки довольно быстро проходят."
Сам пришел к тем же выводам. Максимальный дефицит находится не в области глубоких знаний, а в области личностных характеристик.
Собеседование это оценка потенциала и скорости его реализации в вашей среде. Уровень формальных знаний, это оценка умения проходить интервью и текущей стоимости, но с формальными знаниями очень легко ошибиться попав чуть мимо кандидата.
По этому на собеседовании нужно проверить базис, способность рассуждать и искать ответы и подходит ли кандидат вашей команде, а вы ему. Не правильные ответы кандидата в данном случае даже более ценны, они позволяют выстроить дискуссию и посмотреть куда она кандидата выведет.
Я вот в своё время просто смотрел «наш» ли это человек. В том смысле, что когда общаешься сначала в университете, а потом на работе с программистами, то уже знаешь «какие они». Я, конечно, задавал вопросы и даже задачки на сортировку, но это был просто повод для общения. Да, тут конечно, некая эмпатия и нюх нужны.
P.S. А вот в соседнем департменте набирали так: берём всех, после испытательного увольняем лишних. Считалось, это эффективно, но я от такого отказался, когда мне пытались этот подход навязать. Потому что я — сначала человек, а потом уже программист, и только потом начальник.
Я вот в своё время просто смотрел «наш» ли это человек
А что это значит? Можете развернуть?
В результате сложилось некое ощущение «своего» — это программист вроде меня или круче. Просто надо поговорить с человеком, обсудить его или наши задачи и это ощущение «своего» будет или расти, или убывать.
Если в итоге «свой» — можно брать. Понятно, если мы пишем на java, а он на ней 10 лет молотил до этого, то это будет попадание — такой человек сразу здорово двинет дела вперёд. А если мало опыта или нужного нам опыта — предложить начальную позицию, со временем вырастет, освоит, в отделе должен быть механизм передачи экспертизы новичкам.
Вообще не пойму проблемы, когда везде стоит испытательный срок. Я обычно из 20 собеседований беру 15 человек, ошибусь, может, раз-два. Хотя теперь уже нет, на опыте усвоил еще пару моментов, но делиться не буду ими — не политкорректно они звучат.
Вообще не пойму проблемы, когда везде стоит испытательный срок.
Отсеивать на испытательном сроке дороже чем на собеседовании.
Я часто встречал неприятные сюрпризы, когда вроде человек говорит гладко, а простую задачу решить не может.
В указанном примере собеседования человека с двухлетним опытом в Ruby:
— Вижу у тебя в резюме есть Ruby. Я пытался писать на рубях когда-то, но меня стало тошнить.
— Не знаю, мне нравилось.
— Ну вообще, мне тогда его особо негде было применять. Может я что-то не рассмотрел.
— У меня была пара приложений, там он подходил.
— А покажешь? Может хоть пойму, чем так людям нравятся эти мерзкие руби.
Я что-то неправильно понял, или вы сходу указываете человеку, что он потратил два года своей жизни на какую-то мерзость и какашку?
С друзьями можно разговор и так начать, но с незнакомым кандидатом, мне кажется, лучше начать с:
— Я вижу у вас есть 2-летний опыт работы с рельсами, расскажите, пожалуйста, что вы делали, и почему выбрали именно эту технологию?
—…
— А почему решили всё же перейти на JS?
Он говорит о "личном" отношении, и скорее всего, в такой интонации, что становится предельно ясно, что это не настолько серьёзно, как вам показалось. Разговор достаточно вежлив, и немного провоцирует в позитивном смысле. Не вижу смысла оскорбляться на ровном месте.
Я пробовал Ruby, но мне не зашло, а почему Вы выбрали его? Какие проекты реализовывали?
Без употребления слов «тошнить» и «мерзкие». Как-то они далековаты от профессионализма, не находите?
Ну и зачем на собеседовании (тем более в чужой отдел) выражать свою личную позицию, мы же оцениваем навыки соискателя и презентуем компанию, а не ведём разговор за пивом с другом? Зачем делать провокации мне тоже не понятно, тем более, что автор сам признаётся, что ему было сложно проходить собеседования из-за стресса, зачем провоцировать кого-то, ведь это может усилить их стресс, «я страдал, они тоже должны»?
P.S. Никто и не думал оскорбляться, просто решил уточнить этот момент.
Ну и лучше на собеседование выявить, что при унизительных мнениях о Руби кандидат плакать начинает или драться, чем перед дедлайном :)
В обычной ситуации, если начать с таких провокационных и даже немного унизительных вопросов, то скорее всего кандидат серьёзно усомнится в профессионализме команды и задумается насчёт атмосферы в ней и своём желании работать в таких условиях.
В том-то и смысл — если в команде реально используют унизительные эпитеты для технологий и т. п., то брать в неё надо человека, которые если не разделяет таких взглядов, то толерантен к ним :)
В целом нужна, особенно если позиция программиста предполагает общение с бизнесом.
Ну по моему личному опыту
А вот что нужно, так это умение подбирать слова и вести диалог так, чтобы потенциальных оскорблений там было по-минимуму, а информации по-максимуму.
Можно, конечно, сказать человеку, что он дебил, и его код — говно, но лучше сказать, что вот здесь есть линейный алгоритм, вместо его NP, и отшутиться, что ваши пользователи не хотят идти заваривать чай, после каждого клика, ещё и смайлик в конце сообщения поставить, чтобы уж точно не обидеть никого. :)
Вам же ещё работать вместе, да и цель не доказать свою крутость, а крутой продукт выкатить.
Ну а уже по ответам и соответствию заявленного опыта и роли действительности можно принимать решения, подходит кандидат в проект или нет. Но опять же, не каждый кандидат со 100% правильных ответов должен проходить и не каждый кандидат с заметной долей ошибок или незнания должен отсекаться.
Ну… Ладно. Просто интересно, как и почему вы стали собеседующим? Кем вы были в тот момент в компании?
Автор признает проблему и вроде как даже пытается исправиться но то, что он написал в конце показывает, что нет, нефига, нельзя его допускать до работы с людьми — пусть и дальше ковыряет свой джаваскрипт, возможно он хороший специалист, возможно он может проектировать хорошие системы и его надо просто вернуть на эту работу с повышением зарплаты (чтоб не обиделся), но для работы с людьми (тимлид/собеседования) он просто не годится.
Мой первый собес в Германии как был как раз с таким вот человеком (привет Personio). Я поначалу даже свою самооценку уронил. Вроде ж Европа. Вроде же культур-мультур и толерантность. А тут мне: There're 3 errors, show me them. А на деле практически все "ошибки" были либо незнакомыми человеку понятиями, либо вкусовщиной, либо просто незнанием матчасти.
Сейчас собираюсь менять работу и получил очень хороший оффер на сеньора (сейчас я миддл), при этом мне не задали ни одного сложного вопроса по нюансам. И собеседования были очень комфортными, в формате диалога, а не вопрос-ответ.
Один раз я прошел в компании всю техническую часть, и мне тимлид сказал, что тестовое задание я выполнил лучше остальных кандидатов. После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
Надо было не много думать, а много радоваться, что не вышли на работу в компанию, которая устраивает такие «culture interview».
Как бы вы изменили мир, обладая неограниченными возможностями?
Варианты «вернулся бы назад во времени, чтобы не проходить это интервью» и «уменьшил количество тестов, выглядящих бесполезными» были правильными или нет?
JavaScript implicit conversion Expert.
Просто интересно, как и почему вы стали собеседующим? Кем вы были в тот момент в компании?хмм… я на 5м курсе (в армии не служил) стал сходить на собеседования вместе с моим ПМом — она задавала общие вопросы, а я — технические.
А что именно вас удивляет? Человек собеседует себе будущих коллег, так что какие могут быть еще варианты?
И вовсе не из за каких-то эфемерных регалий. На собеседовании не надо оценивать умение сортировать массивы, надо понять, насколько человек знаком с основными технологиями проекта и рабочими инструментами, понимать направление развития, понимать в какой области навыков команду надо усилить и на какую можно не обращать внимания.
Удивляет меня то, что человек с двумя годами опыта в компании является одним из таких людей. Это возможно, но выглядит крайне странно.
Проводить техническое собеседование должен кто-то из технических специалистов высокого уровня.ну, вот он и был тем специалистом высокого уровня.
Про себя — на тот момент, мы только-только внедрили одну систему со своим внутренним языком и ИДЕ (язык похож на питон и яву). Так что никого более продвинутого по ней не было во всей компании (хотя там были огого спецы по С++, Ява ЕЕ и т.д.)
Но, впрочем воля ваша. Я сплю крепко даже если в интернете кто-то не прав.
Поэтому у меня свое когнитивное искажение в работе и на собеседованиях: я больше всего ценю скорость и гибкость мышления.
2. Время все-таки важно. Да, есть те кто и за десять лет остался джуном, но есть определенный опыт, который нельзя просто выучить, как нельзя научится водить профессонально машину только уча теорию и за десяток уроков в автошколе — тоже. Я бы сказал, что нужно 3-5 лет, чтобы стать действительно опытным разработчиком,
3. Во многих фирмах уровень старшего разработчика дают тем кто даже не стал уверенным джуном, поэтому часто сеньоры весьма дутые,
Научитесь читать внимательно. Сейчас автору 24, два года назад он проводил собеседования. 24 — 2 = 22. Вряд ли он в армии программировал, да и первый курс этому не особо способствует.
Определённо есть выдающиеся разработчики и в 18 лет, но никак не могу понять, почему вот уже шесть человек на серьёзных щах пытаются доказывать что это норма.
Как результат — по собеседованиям ходят в основном джуны, либо люди лишенные всякой тяги к саморазвитию и расширению кругозора. Поэтому они никому особо и не нужны.
И вполне может оказаться что 100 интервью были проведены с такими же людьми как (похоже и сам) автор.
И да, знание одного лишь JavaScript еще не делает вас программистом.
Знание любого из языков программирования не делает вас программистом.
Стоит признать, что сейчас все нормальные кандидаты (миддлы за вменяемые деньги, например) высосаны с рынка известными всем авитами, смузи банками и прочими популярными компаниями.
Как результат — по собеседованиям ходят в основном джуны...
Никто не мешает перетягивать людей из других компаний, но вообще опытные программисты тоже ходят на собеседования, возможно, тут дело не в них, а в вашей вакансии?
«Senior frontend developer» с кратким опытом по технологиям: JS: 1 год, React: 4 месяца, Ruby (on Rails): 2 года".
Я программист, осознавший едва,
Всю суть программистских контор.
Я мидл опять в свои двадцать два,
А в двадцать один был сеньор.
(с) graninas
Вообще это прекрасный результат — «мудрость приходит с годами, но иногда годы приходят в одиночестве». Тут человеку повезло, да. Отличный возраст, впереди много лет для работы и творчества.
- Это совсем «немного» спорно.
- Даже если мозг перестаёт «улучшаться», не перестают оттачиваться профессиональные навыки.
Так что 25 это не вершина, это самое начало профессионального пути.
Профессиональные навыки будут совершенствоваться всю профессиональную жизнь.
На 5 знает бог, на 4 знаю я, а кандидат максимум на 3. Конкретно этот на 2 — он даже не знает «Почему NaN имеет тип числа»
Серебряной пули найма не существует. Решение о найме в любом случае принимает тот кто будет платить нанятому. Когда бизнес хочет делегировать вопрос найма, он ищет конкретного человека, а не случайного сеньора. И если такой человек окажется сеньором, то фраза "«Сеньоры» не должны принимать решение… " дает противоречие.
На 5 знает бог, на 4 знаю я, а кандидат максимум на 3. Конкретно этот на 2 — он даже не знает
Хорошо хоть без сексизма. А то мне девушка рассказывала про одного козла, который всем девушкам ставил исключительно тройки, а всем парнями ставил исключительно четвёрки, без каких-либо исключений, и вне зависимости от реальных знаний.
Я думаю, имелось ввиду, что человек заваливал кандидатов на тех интервью, а hr не могут брать кандидата, если он не прошел тех интервью. По сути, он принял решение о найме
Хорошо если кандидату подробно рассказывают что Вы делаете, какие проблемы решаете — тогда у него, по крайней мере, есть возможность самому понять какие его навыки могут вам пригодиться и самому про них рассказать.
DHH (David Heinemeier Hansson, creator of the super popular Ruby on Rails framework) once said: “I would fail to write bubble sort on a whiteboard”. (https://flaviocopes.com/interview-questions)
одним из важнейших критериев — сможет ли новый человек в команде принести в нее что-то новое
Мой опыт шепчет мне на ухо, что такое очень-очень-очень редко бывает. Я встречал исключительно противоположное: к примеру, есть тимлид который ничего нового слышать не хочет и вообще хоть как-то менять процессы. Он самый умный, самый главный и так далее.
То есть, работников набирают для выполнения чьих-то задач, реализации чьих-то идей. Практически никогда не слушая "нового" мнения.
На одном из первых моих собеседований меня так затерзали вопросами, что в конце я очень расстроенный не смог написать простейший код. Сказалось полное отсутствие опыта с моей стороны. Собеседование это часто большой стресс для человека и он может забыть даже простейшие вещи.
Мне очень не нравится когда задают каверзные вопросы на нюансы языка, которые практически никак не применимы в работе. Если я знаю ответ, то это значит, что я просто прочитал статью, где это упоминается. Да, если я это знаю, то это небольшой плюс, но если я не знаю ответа, то это ещё ничего не значит. Этими вопросами можно завалить любого, но чего этим добьётся интервьюер?
Помнится было дело, мне вообще дали бумажку с напечатанными терминами и спросили что я из них знаю. Вот тут меня знатно припекло и я от волнения забыла вообще всё, как на каком-нибудь экзамене в институте. Потом, конечно, эта самая бумажка пригодилась, чтобы других интервьюеров пугать.
И как-то не докажешь никому, что работать хочешь и любишь, и учишься быстро, и готов впитывать как губка 24/7, и что никто из ранее нанимавших не пожалел. Точнее, это обычно никого не интересует.
работать хочешь и любишь, и учишься быстро, и готов впитывать как губка 24/7, и что никто из ранее нанимавших не пожалел. Точнее, это обычно никого не интересует.э! Обычно — это «много», но не «все поголовно».
Вот когда я собеседовал лет 10 тому назад, то мы смотрели как раз на характеристики «учится быстро» — я до сих пор вспоминаю, как мы смогли нанять к себе в отдел одну девушку с радиофиза (хотя потом она все равно ушла от нас в РубиГерлз :) ), так она тогда вообще не умела программировать, зато алгоритмы схватывала — токо в путь. Эх!
Там были общие теоретические понятия, которые в этой области используются не часто. Если знания не системные, а прикладные, то тут подобный подход ничего не покажет. Кроме того, спустя пару дней я уже и эти понятия заботала, и могла бы рассказать лучше, но явно не на собесе сразу.
Лично я апологет ситуативного подхода, когда смотрят как человек мыслит, есть ли логика, понятие о необходимости предусмотреть косяки и т.д., а спрашивать теорию я бы не стала. Но никому не навязываю
Решающими ответы не должны быть в общем случае, но «будет большим плюсом» вполне.
И вообще совет: не относитесь к собеседованию как к экзамену, даже если ему явно стараются придать такую форму.
Еще подумал, что возможно HR-у хорошо бы собирать у кандидатов фидбек по результатом собеседования, чтобы понимать, что им понравилось, что не понравилось в процессе. А то недавно ходил на собеседование, так один из интервьюеров уткнулся в телефон, и пока я отвечал на вопросы в тесте, он глядя в телефон смеялся, периодически переводя на меня взгляд. Возможно смеялся с мемасов, но, блин, это же жутко неприятно. Спасибо второму интервьюеру, с которым мы вполне хорошо общались в этот момент. Мне кажется, что если бы был фидбек, то человеку хотя бы поведение скорректировали. А так он и будет возможно продолжать такой фигнёй страдать.
Так что согласен и про «завалить» и про «становимся теми, от кого настрадались».
Хорошо, если с опытом начинают глаза открываться, как у автора.
Я связываю это с тем, что почти любая технология стала гораздо доступней, чем 5-10 лет назад. Отдельные технологии оформились во фреймворки, в которых пару строк кода и готово, по другим написали более удачные книги. Третьи технологии перешли на другой стэк, более понятный людями и намного легче осваиваемый.
Потому в современном собеседовании не особо важны знания тех или иных узких мест. Просто кандидат должен быть адекватным и стремиться к развитию. А уж как определить, обладает ли кандидат этими чертами, совсем другая история.
Я тоже провёл сотни собеседований и брал действительно примерно 4-х из сотни.
И один раз я поддался напору кандидата, который не прошел собеседование, но был очень активен, присылал попытки разбора заданий.
В итоге те 4, которые прошли собеседования — прекрасные специалисты, я просто счастлив, что позвал их.
И ещё я мучаюсь с тем «активным», потому что он работает в разы медленнее, косячит в разы больше, и вся его активность куда-то пропала после найма.
Поэтому, лучше я откажу хорошему кандидату — он с лёгкостью устроится в другую контору, чем возьму фигового и не буду знать, что с ним делать.
Ну и образование образованию — рознь. Кто-то MIT заканчивает, а кто-то филиал не очень хорошего университета в русской глубинке. Равнять двух этих людей по навыкам после получения образования никак нельзя.
Кругозор с вышкой колосален
Ага, особенно у ребят, которые раз в семестр конверт заносят в деканат, а потом приходят за дипломом.
У меня однокурсники катались на машинах за несколько миллионов рублей. Были даже люди с ягуарами (машина, не животное).
Кругозор с вышкой колосален
Судя по написанию последнего слова, с кругозором вышла заминочка. :D
А реально лично я за 5 лет учёбы изучил всего 1 полезный предмет (сети ЭВМ) и 2 интересных (теория автоматов и электроника). Лучше бы я 3 учебника за 3 для прочитал и пошёл сразу же работать.
Мне тоже приходится искать и собеседовать специалистов. У нас небольшая ИТ компания и основная потребность в сотрудниках технической поддержки и системных администраторах. Учитывая, что у нас нет отдельного HR, да и знаний о том, как нанимать людей у меня не было, я сразу начал применять беседу как способ узнать о человеке (возможно, тут сыграла моя лень, мне было лениво составлять универсальный список вопросов для теста), о его способах мыслить и о том, насколько он хорошо разбирается в тех технологиях, которые описаны у него в резюме.
И вот, компании уже 5 лет, и я ни разу не пожалел о том, что именно так нанимал людей.
З.Ы. поделился своей историей в комментах, возможно, для кого-то она станет дополнительным стимулом изменить свои подходы к найму людей.
Я пытался писать на рубях когда-то, но меня стало тошнить.
использовали бездушное, что-то вроде C# или Java
Подпись:
Senior Frontend Developer
Вы уверены, что вы сениор? Просто сениор подразумевает некоторую ментальную зрелость. Даже в качестве провокации такие вещи сениору не придут в голову в принципе.
Хотя в нашем мире девальвированных погон…
берем центральный элемент, все элементы, которые меньше — заносим в массив А, все элементы, которые больше в массив Б, а потом делаем
qsort(A) + base + qsort(B)
В отличии от пузырька, который описать сложнее, как мне кажется.
Квиксорт описать словами просто, но в процедуре разбиения можно столько косяков допустить, если в самом массиве свопами делать, без дополнительной памяти. Если ни разу в жизни квиксорт не писали, за 30 минут на интервью шансов практически нет написать.
А пузырек на таком же уровне тоже просто описывается. Пока массив не отсортирован проходимся по нему и меняем местами подряд идущие элементы, если они в не правильном порядке стоят.
Квиксорт описать словами просто, но в процедуре разбиения можно столько косяков допустить, если в самом массиве
Пацаны квиксортят списки, так что там в две строки :)
Квиксорт описать словами просто, но в процедуре разбиения можно столько косяков допустить, если в самом массиве свопами делать, без дополнительной памятиЕсли бы описания на словах не хватило бы и надо было реально писать — я бы подугарел и написал бы этот алгоритм в ФП стиле:
const lt = target => item => item < target;
const gte = target => item => item >= target;
const qsort = array => {
if (!array || !array.length) return [];
const first = array[0];
const rest = array.slice(1);
return qsort(rest.filter(lt(first)))
.concat([ first ])
.concat(qsort(rest.filter(gte(first))));
}
И вы потеряли основное требование отсортировать на месте.
Или у вас тут не массив а списки в итоге используются (я не уверен, что это за ЯП и как там работает filter()). Это другая задача — опять же, тут понятие сортровки на месте уже нет. И для списков вместо QuickSort тогда уж надо MergeSort использовать.
Я вот глянул на вики — там в примерах реализации тоже нету сортировки на месте.
Это ведь больше на теоретическое понимание вопрос, а не «написать алгоритм мечты на коленке в переговорке». Это уже какая-то олимпиадная задача, а не собеседование начинается и я бы с такими идеями предложил бы собеседнику идти именно туда — на олимпиаду, искать людей, которые на это заточены.
Ну «сортировка на месте» — это новое требование.
Я с этого требования и начал (https://habr.com/ru/post/440930/?reply_to=19787094#comment_19786904):
Квиксорт описать словами просто, но в процедуре разбиения можно столько косяков допустить, если в самом массиве свопами делать, без дополнительной памяти
Дальше,
Я вот глянул на вики — там в примерах реализации тоже нету сортировки на месте.
Да, на русской вики криво написано, но там есть фраза "На практике она не используется, а служит лишь в образовательных целях, так как использует дополнительную память, чего можно избежать". А еще, если знать теорию, то можно понять, что сортировка " с помощью прямого обмена" (как несколько раз в русской вики квиксорт называют) — это именно сортировка на месте.
В англйской же, сразу во втором абзаце: Quicksort can operate in-place on an array, requiring small additional amounts of memory to perform the sorting.
Квиксорт описать словами просто, но в процедуре разбиения можно столько косяков допустить, если в самом массиве свопами делать, без дополнительной памятиВы сказали, что можно допустить ошибки, если делать без дополнительной памяти. Но я делал с дополнительной памятью и избежал ошибок.
Вы нигде не говорили, что это требование. Вы сказали, что если соискатель по какой-то причине решит пойти сложным путем — он может наделать ошибок.
В англйской же, сразу во втором абзаце:Вы не там акцент сделали. Правильно — так:
Quicksort can operate in-place on an array, requiring small additional amounts of memory to perform the sorting.
Это нужно, чтобы понять, знает ли человек, чем отличается O(n2) от O(nlogn), сможет ли на практике показать, в каком месте nlogn может превратиться в n2 и почему это плохо. И так далее.
Вы не там акцент сделали. Правильно — так:
Quicksort can operate in-place on an array, requiring small additional amounts of memory to perform the sorting.
А где в этой фразе с русской вики надо акцент, по Вашему, поставить?
На практике она не используется, а служит лишь в образовательных целях, так как использует дополнительную память, чего можно избежать
Если кого-то на интервью и спросят QuickSort написать (что довольно плохой вопрос для интервью, как я и пытался указать), то точно попросят версию без дополнительной памяти, т.к. это основное приемущество квиксорта, перед тем же mergeSort или radix sort. Если бы не это, квиксорт, с его квадратичным худшим случаем, никто бы никогда и не использовал.
А ваше решение только показывает, что вы описание алгоритма знаете, но совершенно не понимаете какие у него плюсы и минусы.
А ваше решение только показывает, что вы описание алгоритма знаете, но совершенно не понимаете какие у него плюсы и минусы.Мое решение показывает, что я не заморачиваюсь на собеседованиях ненужными вещами, я не зря изначально указал:
надо было реально писать — я бы подугарел и написал бы этот алгоритм в ФП стиле:
Формально задача «написать quicksort» выполнена (там, кстати, совершенно рабочий код). То, что он не соответствует каким-то вашим внутренним требованиям и вас это праведно возмущает — лишь указывает на то, что вы из тех интервьюеров, которых так не любят на собеседовании — ответы должны быть строго такие, какие они хотят, и не дай бог ты решил проявить изобретательность. Я бы с таким лидом работать не захотел.
А реализация merge sort для собеседования — это более сложная задача.
А ваше решение только показывает, что вы описание алгоритма знаете, но совершенно не понимаете какие у него плюсы и минусы.А ваш вывод показывает, что вы неправильно воспринимаете цель собеседования. Цель собеседования — это не посамоутверждаться за счет придираний к кандидату.
Формально задача «написать quicksort» выполнена
Да, да, да. А потом некоторые для конкатенации строк используют алгоритм маляра Шлемиля. Ну и что, что у пользователей без проца i100500 на 5Ггц и 64 потока и 128Гб оперативки сайты по пол минуты грузятся. Зато, как Вы выразились "Совершенно рабочий код и формально задача выполнена". И в справке про strcat написано, что оно за линию работает, все оптимально же!
И я с самого начала требование о сортировке "на месте" привел. Потому что, еще раз, квиксорт без этого требования — плохой, не нужный алгоритм.
ответы должны быть строго такие, какие они хотят, и не дай бог ты решил проявить изобретательность
Если вас спрашивают, подсчитайте 2+2, то да, нужен строго ответ, какой они хотят. Тут уж никуда не деться.
Но в этом вопросе я бы порадовался за ваш хороший (серъезно) код и напомнил бы вам, что мне хочется сортировку на месте. Может у меня много данных и мало памяти. Тут меня устроил бы и другой ответ вида "я не помню, как делать квик сорт на месте но знаю другую сортировку, которая это делает" или какой-нибудь убедительный аргумент, почему "требование сортировки на месте бессмысленное, если много данных, надо параллелить". Честно, я бы порадовался вашей изобретательности. Тут бы мы могли обсудить, а какие другие сортировки кандидат знает, в каких условиях бы их применял и т.д. Просто выяснить, вызубрили ли Вы реализацию квиксорта — это как раз про ваших нелюбимых интервьюверов. Мне важно, что человек понимает что, зачем и где использовать.
Но это глубоко гипотетическая ситуация, ибо я никогда не спрашиваю реализацию стандартных алгоритмов или структур данных. Мне интересно, может ли кандидат выбрать подходящие для задачи алгоритмы и структуры данных.
Цель собеседования — это не посамоутверждаться за счет придираний к кандидату.
Да — цель понять что кандидат знает и умеет (в случае интернов еще и какой у кандидата потенциал).
Ну и что, что у пользователей без проца i100500 на 5Ггц и 64 потока и 128Гб оперативки сайты по пол минуты грузятся.Ну вообще, мой подход хотя и использует дополнительную память, но обладает чистотой (что, иногда, нужнее), а сложность алгоритма у него корректная — nlogn, так что мне непонятно, зачем тут i100500.
И я с самого начала требование о сортировке «на месте» привел.Нет, вы сказали, что если кандидат начнет реализовывать с сортировкой на месте, то он может наделать ошибок. Почитайте внимательнее свои слова. Может вы и подразумевали что-то другое, но написали ведь именно это.
или какой-нибудь убедительный аргумент, почему «требование сортировки на месте бессмысленное, если много данных, надо параллелить».Да потому что я могу взять готовую реализацию алгоритма сортировки, а этот пример написал просто, чтобы показать понимание того, как они работают.
а сложность алгоритма у него корректная — nlogn, так что мне непонятно, зачем тут i100500.
Не верно. Ваша реализация, например, на отсортированном массиве будет работать за O(n^2). Не лучше пузырька, только памяти в 2 раза больше надо.
Нет, вы сказали, что если кандидат начнет реализовывать с сортировкой на месте, то он может наделать ошибок.
Да, наверно я плохо выразился. Просто, по указаным выше причинам, вообще не вижу смысла спрашивать квиксорт без этого требования.
Ваша реализация, например, на отсортированном массиве будет работать за O(n^2).Тут согласен. Но взять другой опорный элемент не проблема. К примеру, так:
const key = Math.floor(array.length / 2)
const first = array[key];
const rest = array.slice(0, key)
.concat(array.slice(key + 1));
Тут, правда, уже устойчивость пострадала.
вообще не вижу смысла спрашивать квиксорт без этого требования.Ну дело ж не в самом квиксорте, это просто тема для разговора.
Тут согласен. Но взять другой опорный элемент не проблема. К примеру, так:
И ваша реализация опять будет работать за n^2, если вдруг меньший или больший элемент довольно часто окажется посередине списка.
Тут, правда, уже устойчивость пострадала.
Ее, кстати, и в первом вашем примере не было.
Ну дело ж не в самом квиксорте, это просто тема для разговора.
И в этом разговоре мы бы неминуемо пришли бы к тому, что худший случай у квиксорта O(n^2) всегда. Почему же его вообще тогда используют вместо того же Merge Sort, у которого этой проблемы нет?
И ваша реализация опять будет работать за n^2, если вдруг меньший или больший элемент довольно часто окажется посередине списка.Во-первых, нет. Оно будет работать за n^2, если меньший или больший элемент на каждом шаге будет оказываться в центре, а не только на первом шаге.
И ну да, у Квиксорта ведь есть худший квадратичный случай. Просто плохо, когда худший случай срабатывает на отсортированном массиве — это частый кейс, когда стараемся сортировать уже отсортированный массив.
Ее, кстати, и в первом вашем примере не было.В первом есть.
Почему же его вообще тогда используют вместо того же Merge SortА почему используют пузырьковую сортировку? Если я не ошибаюсь, в одном из современных браузеров на малом количестве элементов (что-то вроде до 8) досортировывается пузырьком (или вставками?), тупо потому что меньше константа.
К примеру на собеседовании Merge Sort не спрашивается, потому что это сложный алгоритм — его не так просто описать на пальцах или накидать в псевдокоде на доске.
Во-первых, нет. Оно будет работать за n^2, если меньший или больший элемент на каждом шаге будет оказываться в центре, а не только на первом шаге.
Поэтому я и написал "довольно часто окажется". По моему, понятно, что не только про первый шаг разговор.
В первом есть.
Да, я был не прав.
А почему используют пузырьковую сортировку? Если я не ошибаюсь, в одном из современных браузеров на малом количестве элементов (что-то вроде до 8) досортировывается пузырьком, тупо потому что меньше константа.
Потому что при маленьком n, O(n^2) может быть быстрее O(n log n). Тут можно спросить, как кандидат понимает O().
К примеру на собеседовании Merge Sort не спрашивается, потому что это сложный алгоритм — его не так просто описать на пальцах или накидать в псевдокоде на доске.
И мы вернулись к моему первому коментарию! Квиксорт не спрашивают обынчо, потому что единственную приличную его реализацию писать сложно — много где можно накосячить.
А объяснить как работает merge sort нисколько не сложнее. псевдо код чуть-чуть сложнее вашей реализации квиксорта. Но, в отличии от, применимый на практике.
Я на вашем языке не пишу, поэтому могут быть ошибки. Считайте, что это псевдокод.
const mergeSort = array => {
if (!array) return [];
if (array.length <= 1) return array;
const half_len = Math.floor(array.length / 2)
const first = mergeSort(array.slice(0, half_len));
const second = mergeSort(array.slice(half_len+1));
ans = [];
i = 0;
j = 0;
while (true) {
if (i == first.length && j == second.lengh) {
break;
}
if (i < first.length && (j == second.length || first[i] <= second[j])) {
ans.concat([first[i]]);
i++;
} else {
ans.concat([second[j]]);
j++;
}
}
return ans;
}
Для пущей производительности, надо ans зарезервировать и вместо concat класть в нужное место. Еще стоит от slice избавится и передавать массив по ссылке и начало/конец сортируемой области. Небольшое усложнение. Еще можно разбить основной if на 3 и отдельно копировать конец одной пловины, если вторая кончилась, но это на сложность алгоритма не влияет.
Нет. См. ниже.
> Почему же его вообще тогда используют вместо того же Merge Sort, у которого этой проблемы нет?
Потому что:
1. Если применить какую-то из техник поиска оптимального разделяющего элемента (например, «медиана медиан» известна с 1973-го года и даёт тоже O(n log n) на всё применение), то можно жёстко гарантировать оптимальное время, хоть и с повышенным коэффициентом.
Это часто забывают, когда рассказывают про «худший случай — O(n^2)». К сожалению, миф про неизбежность O(n^2) «в худшем случае» остался с 60-х годов, несмотря на научный прогресс.
2. Если сделать выбор разделяющего элемента случайным, то вероятность попасть на O(n^2) стремится к нулю при росте n. Это сильно дешевле медианы медиан, и почти всегда можно считать результат не хуже.
3. Если применять heapsort или другое с гарантированным O(n log n) в проблемных случаях, то в целом всё равно время будет оптимальным по асимптоте и хорошим по коэффициенту (в 2-3 раза лучше heapsort).
Последний вариант применён, например, в GCC STL: выбор медианы для разделяющего элемента, heapsort при истечении бюджета рекурсии (ну и insertion sort на мелких отрезках). И там явно не худший вариант:) мой самопальный для сравнения оказался ровно в 2 раза медленнее.
Этот алгоритм для поиска медианы на практике не используют.
Он, хоть и линейный, но константа там такая, что ее на логарифм хватит и еще на квадрат чуть-чуть останется.
Этот алгоритм, наверно, был бы любимым примером всяких ненавистников и презирателей О-большое и другой мутной математики в программировании, если бы они про него знали.
В остальном я с вами согласен, квадратичный случай для квиксорта на практике не проблема совсем и с ним можно бороться. Но это нисколько не отменяет основной мысли моих постов: Квиксорт хорош для сортировки массивов на месте. Настолько хорош, что используют именно его, даже если надо при этом накручивать сортировки хипсортом по достижении определенной глубины рекурсии или использовать рандом, оставляя хоть мизерный, но шанс повиснуть.
Но все эти приемущества квиксорта отсутсвуют при сортировке списков, что тут и пытались делать. Отсаются только недостатки. Поэтому вот такая реализация квиксорта, хоть и короче применяемой на практике — она плохая. Если вас попросят на интервью отсортировать списки — не надо писать квиксорт. Если вас попросят написать именно квиксорт, то не надо сортирвать списки (добавлю, что это плохой вопрос, если вас спросили именно про квиксорт — вам попался плохой интервьювер).
Про списки — тут не было однозначного обсуждения в сторону списков (наоборот, субтред начался с того, что при наличии массива делать quicksort на списках в ФП стиле как-то вредно), поэтому я в эту сторону и не смотрел. Для связных списков, да, больше смотрят в сторону слияний (ну или переделывают их таки в массив и сортируют уже массив, это уже где как удобнее). Тут ещё зависит от возможностей доступного ФП. В LISP образца Common LISP есть куча хаков по перестройке списков на месте, с ними сильно дешевле обрабатывать уже частично сортированные списки, рвать/сшивать их без выделения памяти на промежуточные представления, и всё такое. Где-нибудь в Erlang этого нет, и там другие подходы.
> Этот алгоритм, наверно, был бы любимым примером всяких ненавистников и презирателей О-большое и другой мутной математики в программировании, если бы они про него знали.
:))
> Если вас попросят написать именно квиксорт, то не надо сортирвать списки (добавлю, что это плохой вопрос, если вас спросили именно про квиксорт — вам попался плохой интервьювер).
Ну, пока таких не попадалось. Наверно, всё впереди :)
Про списки — тут не было однозначного обсуждения в сторону списков (наоборот, субтред начался с того, что при наличии массива делать quicksort на списках в ФП стиле как-то вредно)
Тред начался с того, что тут привели простую и изящную реализацию квиксорта, которая сортирует списки. Я весь тред пытаюсь доказать, что она плохая.
Тут, правда, уже устойчивость пострадала.Кстати, вот устойчивый вариант:
const lt = target => item => item < target;
const gte = target => item => item >= target;
const eq = target => item => item == target;
const qsort = array => {
if (!array) return [];
if (array.length <= 1) return array;
const ind = Math.floor(array.length / 2);
const key = array[ ind ];
return [].concat(
qsort(array.filter(lt(key))),
array.filter(eq(key)) ,
qsort(array.filter(gte(key))
);
}
Только надо gt вместо gte сделать, а то у Вас равные опорному элементы 2 раза продублируются.
Но, все-равно, это бесполезное упражнение. Квиксорт не используют для иммутабельных контейнеров, потому что есть более быстрые и практичные алгоритмы. Единственная ниша для квиксорта — сортировка массива на месте.
const lt = target => item => item < target;
const gt = target => item => item > target;
const eq = target => item => item == target;
const qsort = array => {
if (!array) return [];
if (array.length <= 1) return array;
const ind = Math.floor(array.length / 2);
const key = array[ ind ];
return [].concat(
qsort(array.filter(lt(key))),
array.filter(eq(key)) ,
qsort(array.filter(gt(key)))
);
}
Она решаема, но я бы дважды подумал прежде чем решать чтобы то ни было через поиск гамильтонова пути :-)
А теперь докажите, что эта процедура завершится.
Количество инверсий в массиве после каждого свопа уменьшается на 1. Количество инверсий изначально — конечно (меньше n^2). В итоге будет выполнено только конечное количество свопов.
Кстати, интересно, может ли достаточно умный компилятор свернуть каноничный ФП-недоквиксорт в инплейс-сортировку. Линейные типы там какие-нибудь, хз.
Никак, только если конкретно этот случай разработчики компилятора не захардкодили.
Не надо хардкодить сортировку, достаточно выразительных систем типов, как всегда.
Вообще не в этом проблема. Ладно, даже если компилятор поймет, что вместе вызываются filter(gt), filter(lt) и filter(eq), и больше нигде не используется исходный массив, он не может заменить это на процедуру разбиения, потому что она не стабильная, а фильтры эти — стабильны. Другого метода получить меньше, равно, больше в массиве на месте — нет (пока не придумали, по крайней мере).
Но до этой фундаментальной проблемы, надо еще как-то понять, что эти несколько вызовов filter, можно сделать вместе. Иначе нельзя выкинуть первый и переиспользовать исходный массив, ведь этот же самый массив используется во втором фильтре. Т.е. нужно именно что захардкодить этот конкретный случай.
Мы на старой работе собирали вопросы с собеседований, и часто спрашивают очень странные вещи, которые никак к реальной работе не относятся.
Seriously, синдром инженера — это ужасная вещь. Educated fools.
Многие айтишники мечтают построить новый дивный мир, управляемый такими же айтишниками. Но мне кажется, это будет ад а не рай.
«Моя точка зрения самая верная», уверенность в понимании всего в мире, «если я чего-то не хочу значит это не надо никому », проблемы с эмпатией, да много чего еще. Прямо золотой набор предпосылок тирании и антиутопии.
Хосе Ортега-и-Гассет, если быть точным. В кратце: частично он говорил, что чем больше человек образован в своей специализации, тем меньше он понимает принципы функционирования общества, перестает с ними считаться и начинает судить обо всем на свете с помощью своей специализации. Тут чуть подробнее, если вдруг стало интересно.
Возможно, сейчас меня занесет в полную противоположность — но будь моя воля, я бы может брал вообще всех, кто хочет работать.Еще к этому стоит добавить адекватность.
Собеседование с вопросами, про какие-то лютые тонкости — поршлый век. Доступность информации на порядок выше и на первый план выходит способность идентифицировать и решать проблемы оптимальным способом. Эксперты нужны, но каждый разработчик не должен быть экспертом.
При собеседовании меня скорее интересует путь решения проблемы, а не конечный вариант. Условия могут измениться, требований, технологии. Сегодня ты пишешь на C#, завтра надо написать под iOS или Android. И вопрос не в том, что знаешь или нет, а за сколько узнаешь.
Или взять любой проект, хорошего кода видел мало, зато тех, кого нанимали знали и про GC и про таблицу виртуальных методов и т.д. Что толку с того, что человек досканально знает как процессор параллелит на конвеере инструкции, если ему наплевать на успешность проекта. Знание технических тонкостей не делает проект успешным, проект успешен тогда, когда люди стремятся идентифицировать узкое место и его улучшить и именно таким способом получаешь знание и опыт по месту.
А теоретическое запоминание материала напоминает плюшкина, который собирает все, а применяет лишь небольшую долю, КПД такого работника не высоко, потому, что он получает информацию, которая не решает его проблему.
you ARE arrogant and stupid
С уважением ваш grammar nazi
С уважением, Ваш grammar nazi
В — большая, когда речь идет об уважительном отношении, а не множественном числе. И очень круто смотриться с запятой.
Я специально оставил там мягкий знак, чтобы Вы могли мне отомстить и не считали себя должником.
В — большая, когда речь идет об уважительном отношении, а не множественном числе. И очень круто смотриться с запятой.
век живи — век учись.
Ну а по поводу запятой, гуглил, кто-то пишет, что писать надо, а кто-то нет.
В русской грамматике правила постановки запятой после фразы «с уважением» и подписью автора письма не ставилась.
Сейчас сложилась традиция, что после «с уважением» запятая ставится обязательно, потому что при чтении на месте запятой интонационно просится пауза.
1. Есть прямоугольник со одной стороной 9 и суммой трех других 37. Вычислите площадь.
2. Вы продали за месяц 5 станков по 1500 долларов каждый, и потратили на зарплату 1800 долларов, что составило 80% от ваших общих затрат. Какую прибыль вы получили?
3. Есть три коробки с фруктами — в одной яблоки, в другой апельсины в третьих смесь тех и других. На каждой коробке есть маркировка, и известно, что они все неверны. Как достать один фрукт из одной коробки и правильно надписать все три?
4. Напишите FizzBuzz, язык не важен.
5. Дано две простейшие SQL таблицы, напишите запрос на подсчет количества (требовалось SELECT name,COUNT(blah) AS cnt FROM tbl GROUP BY name)
6. Единственный вопрос именно на PHP — есть ассоциативный массив, прогоняем его через ksort(), потом через implode(). Что на выходе?
Написал, отдал, ушел. Вчера позвонили и пригласили на интервью, сказали, что самое сложное я уже прошел. Жена долго ржала и спрашивала, точно ли позиция Senior Dev — не знаю, но вилка зарплат вроде подходит. Завтра интервью, беспокоюсь, что еще спросят.
Либо банально переоценивают свои навыки, часто бывает рисовал пару лет простейшие html страницы с минимумом php на первой работе, получал вместо повышений звания мидла и синьора, а потом приходит на собеседование, уверенный, что он крут и все может, а там не может написать ничего внятного.
Впрочем все три первых задачи достаточно элементарные
Вроде да, но бывают нюансы. Если вас собеседуют на не родном языке, то 3 задача может дать жару. Говорю как человек с довольно слабым английским (Middle Intermediate), который недавно проходил много технических интервью.
А дело всё в том, что обычно требуют при этом "мыслить вслух". И я вот на себе проверил, что мыслить вслух что-то мутное (перебирать все варианты яблок\коробок\следствий) и при этом мыслить продуктивно очень сложно. Большая часть мозга вынужденно занимается построением внятных формулировок. На задачу почти ничего не остаётся. Такое чувство… отупения наступает.
Я бы столкнувшись с этой яблочно-апельсиновой задачей приуныл. Хотя с другой точки зрения, можно везде хитрить. Скажем — попросить время на подумать. И дать сразу готовый ответ.
Приходит человек, у него в резюме написано: имею опыт создания Highload-проектов.
У него лид спрашивает:
— В каких Highload проектах принимали участие?
— Ни в каких не принимал!
— А зачем в резюме написали?
— Все пишут — вот и я написал!
Или так:
— Расскажите, что вы знаете о Design Patterns (обычно я такие вопросы не задаю, но тут попалось на глаза)
— Эмс, ничего не знаю, а что это?
— Ну вот же, у вас третим пунктов знаний в вашем же резюме
— А, ну я просто на русском писал и переводчиком переводил, потому не знаю такого термина
— Ну хорошо, тогда что такое «Паттерны проектирования»?
— Эмс, не знаю
— Ну Сигнлтон, к примеру
— А, ну да, Сингтон
— Еще какие?
— Нуууууу…
— Фабрика?
— Да, Фабрика, знаю такое
— Ну хорошо, расскажите о Фабрике
— Ну фабрика — это… фабрика… Она создает… Ну вот, короче.
Блин, да если бы он этого не написал — я бы в жизни такого вопроса не задал! Не понимаю — неужели так сложно перед собеседованием хотя бы СВОЕ СОБСТВЕННОЕ резюме прочитать? Такое впечатление, что им просто друг клевое резюме написал.
При собеседовании на позицию геймдев не могут своими словами рассказать, как бы они написали игру Орел-Решка. Ну то есть вопрос без подвоха. Две кнопки — орел, решка, угадал-неугадал. Затык в том, что человек просто не умеет пользоваться функцией Math.random для того, чтобы с вероятностью в 50% вывести текст «орел» и с вероятностью в 50% вывести текст «решка».
Более сложные вещи типа: «Возьмите из колоды в 36 карт 6 случайных» — это у нас была самая сложная задача. Когда люди не знают как я решить — я обычно подсказываю, спрашиваю, играли ли они в Дурака и как давали людям 6 случайных карт.
Была тут как-то статья, где объяснялся этот эффект: чем меньше человек знает и умеет, тем больше он ходит по собеседованиям.
Расскажите как там процесс построен? :)
Не удалось с ними пообщаться как-то до сих пор.
Интересен опыт про собеседования больше.
По опыту работу я краем уха слышал, но как по мне всё сильно зависит от проекта и людей настраивающих процессы.
У нас (мы разрабатывали игру на JS и Canvas — острие web-технологий на тот момент, куча багрепортов в браузеры, никакой инфы в интернете) HR встречала человека, общалась 5 минут о чем-то, пока придет тех специалист. Лично я был лидом клиентской команды и всегда собеседовал сам. Давал несколько относительно простых. По JS это было на знание прототипов вроде такой:
function MyClass (name) {
this.options.name = name;
}
MyClass.prototype.options = {
name: 'default'
};
var foo = new MyClass('foo');
var bar = new MyClass('bar');
console.log( foo.options.name, bar.options.name );
Спрашивал, что будет, почему, как сделать, чтобы результат был более ожидаем, если человек шарит — мог повести разговор в то, как это реализовано в новом на тот момент ES6, TypeScript, всяких фреймворках. Если же не шарит — говорил, что выведет, спрашивал, почему может быть такой результат
Следующая задача — это понимание замыканий:
<button>Zero</button>
<button>One</button>
<button>Two</button>
<button>Three</button>
<button>Four</button>
var buttons = document.querySelectorAll('button');
for (var i = 0; i < buttons.length; i++) {
buttons[i].onclick = function () {
console.log(i);
}
}
Вопрос — что выведет при клике на любой элемент, почему? Как исправить неожиданное поведение?
Самый правильный ответ — IIFE (название не обязательно, достаточно описать общий принцип).
Потом спрашивал, какие нестандартные способы могут назвать люди. Самый популярный правильный ответ — dataset.
Из менее популярных — forEach, with, let, bind (короткий и длинный варианты). Но это уже так — на совсем увлеченность
Эти две задачи показывали, что человек реально имеет базовый опыт работы с JS, умеет распознавать типичные сложные паттерны. Часто с протипами люди не работали вообще (а они у нас часто встречались), но это не так критично, если по остальным пунктам человек хороший.
А вот если не может ответить про проблемы с замыканием — тревожный звоночек, все JS-специалисты не раз сталкиваются с этим шаблоном и это свидетельствует или о вранье в резюме или о слабом опыте (да, есть 5 лет опыта, но только подключение одинаковых плагинов на JQuery, без глубины). У нас же было тьма очень сложного кода, игра в паблике, на которую мы постоянно заливаем обновления и было лучше не нанять хорошего специалиста, который боится общаться с людьми, чем нанять плохого специалиста и потом на боевом сервере получить тьму багов потому что он не смог распознать замыкание.
Code Review у нас было (при чем довольно строгое — минимум два аппрува от других членов команды для мерджа), но все-равно лишней головной боли не хотелось — и так есть над чем страдать.
Потом задача про игру орел-решка. Потом поспрашивал по резюме, выбирая интересные моменты, пообщался на отвлеченные темы, про будущее технологий, про архитектуру, поотвечал на вопросы.
Если человек недостаточно силен — обычно сразу указывал на то, что нужно подтянуть, какую литературу почитать и говорил, что жду через год на новом собеседовании.
Потом шел за HR (а у нас почти со всеми ими были дружеские отношения, лично я считал, что они у нас хорошие), рассказывал в двух словах:
— Кандидат не очень, максимум слабый мид, сказал, что подтянуть
— Кандидат хороший, можно брать
— У кандидата слабый язык, но хорошая верстка — можно посоветовать в веб-команду (тогда с веб могли пригласить на собеседование их спеца)
Потом HR приходила, общалась, провожала или предлагала деньги.
Обычно все собеседования заканчивались за один день и максимум 2 часа.
Хотя был случай, но я уже слабо помню точно, что сильного кандидата, которого я советовал для найма очень долго протянули и он был очень оскорблен и ругался. Там что-то вроде: «человек, который ответственный за бюджет и должен поставить свою подпись — уехал в отпуск, а его зам попал в больницу со сломанной ногой». Короче, бред какой-то и мы все были очень недовольные, но такой случай только один помню.
Но, опять же, все очень сильно зависит от офиса, HR и от команды. Это я про киевский офис рассказывал.
Самый правильный ответ — IIFE (название не обязательно, достаточно описать общий принцип).
Зачем, можно же var на let поменять
Самый правильный ответ — IIFE (название не обязательно, достаточно описать общий принцип).Это правда самый правильной вариант? А что будет если в цикле использвть let вместо var?
for (let i = 0; i < buttons.length; i++) {
PS чукча писатель
Это правда самый правильной вариант? А что будет если в цикле использвть let вместо var?На Senior сейчас бы спросил — знает ли кандидат как реализуется let при транспиляции в ES5 — всё-равно разговор пришел бы к IIFE или аналогам и выяснению причин, почему так происходит
variable == null
, но это очень специфическое знание. И вот человек может иметь такие специфические мнения и разговор уйдет в холивар по мелочам.Потому я предпочитаю задавать технические темы, в которых невозможно холиварить. «Какой будет результат и почему» — тут нечего холивариать. «Как это можно исправить» — тоже не холивар.
У меня совершенно не конвеерный подход — я стараюсь нащупать глубину знаний каждого кандидата. Но не хочу базироваться на потенциально холиварных засадах
На Senior сейчас бы спросил — знает ли кандидат как реализуется let при транспиляции
Думаю, ренеймингом ;)
Типа да :)
Меняется на var и меняется имя переменной в случае конфликта имени с именем переменной из внешнего скопа — почти во всех кейзах этого достаточно.
В случае for — не достаточно, но это особенность именно for. То есть, говорить тут надо о транспиляции for (и то только в случае захвата счетчика замыканием), а не о транспиляции let :)
с-но:
https://babeljs.io/repl/#?babili=false&browsers=IE%20%3E%3D%2011&build=&builtIns=false&spec=false&loose=false&code_lz=Q&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env&prettier=false&targets=&version=7.3.3
Правда, программист, который специально игнорирует контекст, чтобы придраться.
Тем более, если он при этом ошибается. Это особенность как раз let, а не for. Зависит, конечно, от версии
![](https://habrastorage.org/webt/pb/vr/gl/pbvrglmrxsdeuohq-hpunkkyy1i.png)
Правда, тот сайт, который дали вы — транспилирует с багами. Вот пруф. Такой код:
let x = () => {};
{
let x = () => {};
setTimeout(function () {
console.log(x.name);
}, 100);
}
Он оттранспилирует в ошибочный:
"use strict";
var x = function x() {};
{
var _x = function _x() {};
setTimeout(function () {
console.log(_x.name);
}, 100);
}
Который выведет в консоль неправильное значение.
Программист, который не умеет в контекст меня бы смутил.
Так а при чем тут контекст, если вопрос не о том?
Тем более, если он при этом ошибается. Это особенность как раз let, а не for.
Нет, именно for. В вашем примере точно так же все решается ренеймингом и никакого IIFE не требуется. IIFE нужна только в отдельных редких случаях — как вот в случае for, например. Ну и не обязательно IIFE, кстати, вынести эту ф-ю никто не мешает.
Правда, тот сайт, который дали вы — транспилирует с багами. Вот пруф.
Это не баг, т.к. стандарт не фиксирует жестко формат имени ф-и. С-но, транспилятор имеет право его поменять.
Так а при чем тут контекст, если вопрос не о том?Контекст в бытовом смысле, не в девелоперском. В том слове я имел ввиду «контекст общения».
Нет, именно forНет, именно let. Просто for — самый яркий пример, когда проявляется то, что переменные, объявленные через let находятся в разных лексических окружениях. Самый простой способ симмитировать поведение let в старых браузерах (создание своего собственного лексического окруження для переменной) — это использование IIFE (на самом деле with, но он уже deprecated). Еще раз — это особенность именно let/const, а for — это яркий пример, когда это особенность проявляется.
Это не баг, т.к. стандарт не фиксирует жестко формат имени ф-и. С-но, транспилятор имеет право его поменять.Если я правильно разобрался, то в стандарте описывается присваивание имени в пункте 12.14.4.1.e.iii.
Даже если нет, то я ожидаю, что транспилер сделает код, который будет работать так же, как не-оттранспилированный работает в современных браузерах.
Ну такое себе… сомнительное.
Не отображает прикладного применения. Видно кто составлял физ.мат окончил, а с фантазией всё посредственно.
Хотя перечитал ещё раз, про физ.мат эт я погорячился, местами задачки за школьный курс.
1. Сложите строку виду «00 0 0 00 0» в число, где первая группа нолей — флаг (00 = 1, 0 = 0), следующая за ней — маркеры, которые надо заменить на 1/0, и загнать в строку, повторить до конца. Результирующую бинарную строку вывести в десятичном виде. Решений множество, битовые смещения мне показались наиболее простыми.
2. Нарисуйте в HTML/CSS/JS три прямоугольника в определенном порядке, скройте любой/все по клику, потом заставьте любой по клику переехать в начало.
Всё. А потом он сказал, что у соискателя после найма будет много разнообразных задач — включая, например, собирание осколков распределенной InnoDB базы после крэша и поддержку распределенной инфраструктуры сайтов на LAMP. Который час сижу и думаю, как это соотносится. Есть подозрение, что на данный момент им нужна хоть одна прямая пара рук, торчащих из некоего кентавра из сениора и сисадмина, но тогда надо другие вопросы задавать и другие деньги платить.
P.S. Интервью было на позицию с потолком зарплаты около в 120к в год. Хьюстон. Кстати, HR подтвердила, что ситуация на рынке труда аховая, адекватных PHP-разработчиков между мало и нет совсем, опытных — в принципе нет. Мои 19 лет опыта вызвали там легкий шок… если я правильно понял, сениором считается любой с 7 годами и более.
Говорит, людей с опытом на PHP более 2 лет на рынке практически нет.
Это из-за чего с-но? Вдруг случилась какая-то болезнь которая выкосила всех тех людей, кто писал на пыхе ~5 лет назад?
Еще вижу кучу людей, всерьез спрашивающих меня — слушай, а в разработке же много платят, да — так я счас пойду за 3 месяца изучу что там надо, буду кнопки давить, комп все сам сделает, и мне тут же дадут 100+, это же так работает? При этом нет ни огня в глазах про собственно разработку, ни даже отдаленного понимания, зачем им это, кроме денег. Как результат, имеем вакуум в области настоящих, любящих свое дело профессионалов, тем более с опытом.
Проблема в том, что потребности в таком количестве JS-ников на рынке, собственно, нетСудя по раздутым зп и количеству вакансий — JSников категорический дефицит. Жаль, что нормальных Геймдев вакансий очень мало.
Опять же, в пятницу на собеседовании интервьюер спросил, почему у меня опыт в основном с MySQL, а не Mongo и другие более современные вещи. Рассказал — use case у меня другие были, итп, объяснил в деталях, насколько позволяли NDA. Он еще немного приподнял брови, когда выяснилось, что я в курсе разницы между MariaDB и MySQL. А потом он мимолетно признался, что многие, кого он собеседовал (на сениора, на секундочку), даже не в курсе разницы между RDBMS и NoSQL движками — оно как-то само работает у них через любимый %framework% (ну или не работает), и используется, потому что модно. Иногда приходится взрослым людям после 5 лет в профессии объяснять, зачем нужен статический анализ кода, что такое отладка, и что она дает по сравнению с printf(), как пользоваться отладочными прокси… Я знаю людей, у которых упавший на 3 месяца (!) из-за конфликта портов xdebug (отладчик для PHP, если вы не по этой теме) не стал препятствием для работы на уровне архитектуры немаленького такого приложения. Я не знаю как так можно жить… и так много с чем.
да хоть SQL надо хотя бы на базовом уровне пониматьНе обязательно, сейчас большинство JSников-серверщиков его совершенно не знает и пользуется NoSQL базами.
На рынке же полно джунов… на собеседовании хотят зарплату сениора
Такое во все времена на любом языке. К примеру, в 2012-м наблюдали такое в Java
своих прошлых коллег 1сников с радостьюНу так то коллеги, которых взяли на работу. Просто не берите на работу людей, с которыми нет про что поговорить
–А как же! У нас же служит.
–Да кем? Что он делает?
–А как же. Инспектором у нас в уездном училище. Где я директором состою. Дока.
–Это он-то дока?
–Он. Вы бы посмотрели, как он на экзаменах учеников спрашивает. Любо-дорого посмот-реть. Уж его не надуешь, не проведешь за нос. Ён, как говорится, достанет. Посмотрели бы вы, ка-ким он орлом на экзамене…
–Много бы я дал, чтобы посмотреть!–вырвалось у меня.
–В самом деле хотите? Это можно устроить. Завтра у нас как раз экзамены –приходите. По-сторонним, правда, нельзя, но мы вас за какого-нибудь почетного попечителя выдадим. Вы же, кстати, и пишете –вам любопытно будет… Среди учеников такие типы встречаются… Умора! Смотрите, только нас не опишите! Хе-хе! Вот вам и адресок. Право, приезжайте завтра. Мы глас-ности не боимся.
II
За длинным столом, покрытым синим сукном, сидело пятеро. Посредине любезный старик с белой звездой, а справа от него торжественный, свеже-накрахмаленный Бельмесов, Иван Демьяныч. Я вскользь осмотрел остальных и скромно уселся на стул.
Солнце бегало золотыми зайчиками по столу, по потолку и по круглым стриженым головенкам учеников. В открытое окно заглядывали темно-зеленые ветки старых деревьев и приветливо, одобрительно кивали детям: «Ничего, мол. Все на свете перемелется — мука будет. Бодритесь, детки...»
— Кувшинников, Иван, — сказал Бельмесов. — А подойти к нам сюда, Иван Кувшинников… Вот так. Сколько будет пятью-шесть, Кувшинников, а?
— Тридцать.
— Правильно, молодец. Ну, а сколько будет, если помножить пять деревьев на шесть лошадей?
Мучительная складка перерезала загорелый лоб Кувшинникова Ивана.
— Пять деревьев на шесть лошадей? Тоже тридцать.
— Правильно. Но тридцать — чего?
Молчал Кувшинников.
— Ну, чего же — тридцать? Тридцать деревьев или тридцать лошадей?
У Кувшинникова зашевелились губы, волосы на голове и даже уши тихо затрепетали.
— Тридцать… лошадей.
— А куда же девались деревья? — иронически прищурился Бельмесов. — Нехорошо, тезка, нехорошо… Было всего шесть лошадей, было пять деревьев и вдруг — на тебе! — тридцать лошадей и ни одного дерева… Куда же ты их дел?! С кашей съел или лодку себе из них сделал?
Кто-то на задней парте печально хихикнул. В смехе слышалось тоскливое предчувствие собственной гибели.
Ободренный успехом своей остроты, Иван Демьяныч продолжал:
— Или ты думаешь, что из пяти деревьев выйдут четыре лошади? Ну, хорошо: я тебе дам одно дерево — сделай ты мне из него четыре лошади. Тебе это, очевидно, легко, Кувшинников, Иван, а? Что ж ты молчишь. Иван, а? Печально, печально. Плохо твое дело, Иван. Ступай, брат!
— Я знаю, — тоскливо промямлил Кувшинников. — Я учил.
— Верю, милый. Учил, но как? Плохо учил. Бесмысленно. Без рассуждения. Садись, брат, Иван. Кулебякин, Илья! Ну… ты нам скажешь, что такое дробь?
— Дробью называется часть какого-нибудь числа.
— Да? Ты так думаешь? Ну, а если я набью ружье дробью, это будет часть какого числа?
— То дробь не такая, — улыбнулся бледными губами Кулебякин. — То другая.
— Откуда же ты знаешь, о какой дроби я тебя спросил? Может быть, я тебя о ружейной дроби? Вот если бы ты был, Кулебякин, умнее, ты бы спросил: о какой дроби я хочу знать: о простой или арифметической?.. И на мой утвердительный ответ, что — о последней — ты должен был ответить: «арифметической дробью называется — и так далее»… Ну, теперь скажи ты нам, какие бывают дроби?
— Простые бывают дроби, — вздохнул обескураженный Кулебякин, — а также десятичные.
— А еще? Какая еще бывает дробь, а? Ну, скажи-ка?
— Больше нет, — развел руками Кулебякин, будто искренно сожалея, что не может удовлетворить еще какой-нибудь дробью ненасытного экзаменатора.
— Да? Больше нет? А вот если человек танцует и ногами дробь выделывает, это как же? По-твоему, не дробь? Видишь ли что, мой милый… Ты, может быть, и знаешь арифметику, но русского языка — нашего великого, разнообразного и могучего языка — ты не знаешь. И это нам всем печально. Ступай, брат Кулебякин, и на свободе кое о чем подумай, брат Кулебякин. Лысенко! Вот, ты, Лысенко! Кондратий, скажешь нам, что тебе известно о цепном правиле? Ты знаешь цепное правило?
— Знаю.
— Очень хорошо-с. Ну а цепное исключение тебе известно?
Лысенко метнул в сторону товарищей испуганным глазом и, повесив голову, умолк.
— Ну что же ты, Лысенко? Ведь говорят же: нет правила без исключений. Ну, вот ты мне и ответь: есть в цепном правиле цепное исключение?
Стараясь не шуметь, я отодвинул стул, тихонько встал и, сделав общий поклон, направился к выходу.
Любезный директор с белой звездой тоже встал, догнал в передней и сказал, подмигивая на экзаменационную комнату:
— Ну, как?.. Не говорил ли я, что дока. Так и хапает, так и режет. Орел! Да только, жалко, не жилец он у нас… Переводят с повышением в Харьков. А жалко… Я уж не знаю, что мы без него и делать будем?.. Без орла-то!
Про личный опыт:
1) С точки зрения соискателя. Самые качественные и интересные интервью те, где тебе предлагают что-то спроектировать на ходу или обсудить, как должно работать в идеале. Какое-то решение живой бизнес-задачи с помощью твоего стека. Естественно, подходит только для миддлов-сеньоров, джунов таки стоит гонять по азбучной теории.
Самые некачественные интервью — там, где спрашивают точное знание встроенных методов или алгоритмы решения отвлечённых задач. Каждый раз выходишь: а что это было и зачем?
2) С точки зрения нанимателя. Хорошие интервью получаются, когда сам наниматель понимает, под что он берёт работника, может рассказать, в каких конкретно процессах ему придётся участвовать, какую пользу он принесёт. В больших компаниях с этим проблемы, да.
Плохие интервью получаются, когда руководство решило просто расширить штат, потому что не очень сбываются его ожидания по скорости решения тасков. Короче, когда у собеседующего нет внутренней уверенности в нужности сотрудника
Профессионал часто оказывается с трудных характером, склочный, амбициозный, будет вечно шантажировать уходом, тянуть лямку на себя, спорить, что его решение самое лучше, что это он тут все сделал, а чем вы занимались? Будет подставлять коллег, не будет командной работы и духа, будет неуступчив. Т.к. он профессионал он моментально напишет код, и остальные 7 часов будет почивать на лаврах ничего не делая, жалуясь, что задача написана криво, что пусть тестируют тестировщики. Не будет делиться знаниями и опытом. Не будет мыслить в интересах команды и клиента, а только в своих.
Из-за этого я первую очередь смотрю на личностные качества человека, на его характер, soft skills вобщем
Согласен с автором, что можно брать почти любого, кто правда хочет развиваться и обладает нормальный характером
Ответ berez похож опять же на спор что я описывал выше. Нет никакого согласия, понимания и поиска консенсуса, бессмысленный спор
Это хорошо, что вы упомянули про заграницу. Там действительно работают по-другому. Но дело тут не только в менталитете (в конце концов, там и наши эмигранты работают в больших количествах — и ничего, менталитет не мешает). Мне кажется, дело скорее в отношениях между работодателем и работником.
Вот как я это себе представляю (для сферы IT):
В Европе работодатель хорошо защищен социально, но при этом понимает, что социалка зависит и от его активности тоже. Отсюда — крепкие профсоюзы, а работодатели идут на компромиссы.
В Америке с работником «договариваются» зарплатой. Работник хорошо впахивает потому, что деньги нужны, работодатель хорошо платит потому, что иначе хорошие работники разбегутся.
У нас, к сожалению, социальной защищенности нет. Т.е. каждый работник по сути сам за себя. Но и с зарплатами не фонтан — ибо конкуренции не так уж и много. Вот и получается с одной стороны — имитация рабочего энтузиазма, а с другой — имитация заботы о работнике и «коллективные ценности».
Профессионал часто оказывается с трудных характером, склочный,
Это можно определить на собеседовании, разве нет?
амбициозный,
А это вот вообще ни разу не недостаток. Да, есть проекты (всякий maintenance), где амбициозность не нужна, а нужны другие качества. Но вот для стартапов амбициозность очень даже неплоха.
Задача рекрутера и собеседующих — определить, подходит ли данный конкретный человек к вашему конкретному проекту. В том числе психологически.
Не за что, ваш К.О.
будет вечно шантажировать уходом,
Если ваш проект не подходит для «звезд» — возможно и будет. С другой стороны, если гражданин в проекте прижился и «расцвел», то он один в случае чего сможет вытянуть на себе весь проект.
тянуть лямку на себя, спорить, что его решение самое лучше, что это он тут все сделал, а чем вы занимались?
Это вы описываете какого-то молодого да раннего звездуна, как мне кажется.
Я с трудом представляю себе опытного специалиста, который вдруг ни с того ни с сего вот так вот «зазвездился». Опытного — значит, поработавшего в разных проектах и разных коллективах. Такие люди, как правило, трезво понимают свою роль в коллективной разработке.
Будет подставлять коллег, не будет командной работы и духа, будет неуступчив.
Другими словами, bad team player & trouble maker.
Опять же, даже такому гражданину иногда находится применение — например, некая узкая зона ответственности, где он может в одиночку творить что ему заблагорассудится. Узкая — чтобы в случае чего эффект автобуса был не слишком большим. :)
Т.к. он профессионал он моментально напишет код, и остальные 7 часов будет почивать на лаврах ничего не делая, жалуясь, что задача написана криво, что пусть тестируют тестировщики.
По поводу «моментально напишет код» вспомнилась коронная фраза одного бывшего коллеги: «как мы все знаем, хороший программист работает от силы пару часов в день. Но это не повод уходить с работы в 12». :)
Не будет делиться знаниями и опытом.
Значит, менторство — не его. Ну и что? Кому-то ведь нужно и просто работать.
Не будет мыслить в интересах команды и клиента, а только в своих.
Опять же, зависит от проекта. Иногда клиентов-то и нет еще (я имею в виду всяческое RnD).
А для воспитания очень уж самовлюбленных граждан, бывает, применяют штрафы. Как регулярная мера они, конечно, сильно портят атмосферу в коллективе, но как разовая мера — очень даже помогают отдельным личностям приобщиться к проблемам клиентов на собственной шкуре. Ну и — если вдруг гражданин решит уволиться — туда ему и дорога, не так ли? :)
Я провел сто собеседований, отказал сотне людей — и только потом научился собеседовать