Комментарии 431
У меня были друзья-разработчики, они работали джунами и использовали какую-то бездушную хрень вроде C# или Java. И я хорошо чувствовал — я уже разбираюсь в своей технологии намного лучше, чем они в своих.
Чувства тебя обманывали, Антон)
Я же видел твой код
Звучит как долбаный вызов)
Так идти за попкорном или нет?
Видать теперь после интервью осталось немного поуспокоить эго и понять что с кодом тоже было что-то не то (просто потому что с ним вечно что-то может быть не то, а чужой код глазами самолюбования может показаться «ниже уровнем») :))) Ну и насчет бездушного C# :) rcanedu, может Вы его плохо знаете? :)
Да
Присылай свой лучший код на ревью
У тебя есть доступ в приватный репо. Твой выход
Так ведь конфликт публичный
Значит, мне придется это выложить в опенсорс, оформив, как полагается в npm. И все же, где мне посмотреть твой лучший код?
Я ещё не написал свой лучший код) Просто мой код можешь найти в этой своей приватной репе
Даёшь идеальный публичный FizzBazz для хайлоада с e2e тестами, dockerfile, правильной историей коммитов, TDD, DDD, SOLID, KISS, FP, MVC, CI/CD, PWA… ой, не туда меня понесло.
И обязательно с machine learning, AI и блокчейнами. И еще монорепо, это ведь уже снова входит в моду.
А уже есть такой: github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Есть и HelloWorld Enterprise Edition: gist.github.com/lolzballs/2152bc0f31ee0286b722
Есть и HelloWorld Enterprise Edition: gist.github.com/lolzballs/2152bc0f31ee0286b722
KISS и YAGNI лучше тогда не вспоминать а то все остальное тогда сразу в лес)
Понятно, что вы тут в шутку дуэлитесь. А все же, что значит «лучший код»? Наикрутейшая имплементация? Хитровы… хитровыкрученный алогоритм? Просто исходник «без косяков»? А что есть косяк? Необщепризнанный стиль кода? Что-то, что можно оптимизировать? Сделать более читаемым?
В моем 10-летнем или даже прошло-месячном коде все хуже чем в сегодняшнем. Но сегодняшний код я пишу балансируя между тем как я хочу и тем, сколько мне дают на это времени. Дали бы ∞ времени, я бы довел весь свой код до ∞ совершенства.
В моем 10-летнем или даже прошло-месячном коде все хуже чем в сегодняшнем. Но сегодняшний код я пишу балансируя между тем как я хочу и тем, сколько мне дают на это времени. Дали бы ∞ времени, я бы довел весь свой код до ∞ совершенства.
Мой лучший код — быстро, с хаками и велосипедами написанная логика системы управления станка. Если кто-нибудь его посмотрит, то меня не возьмут ни в одну приличную компанию, однако станок работает годами, гоня полезный продукт каждый день. А вылизанный, чистый хороший модуль, написанный с соблюдением всех известных мне хороших практик, пылящийся в старой репе развалившейся комманды я лучшим своим кодом не считаю.
Вы видимо, пишите его один раз и больше не меняете. Ну и работаете наверное с этим кодом один. При долгосрочной поддержке и командной работе с кодом такоц подход допустим только на этапе PoC или прототипа.
Если работает быстро, без сбоев, решает поставленную задачу и не предполагает расширения, то в общем и целом слегка пофигу как он написан.
ЗЫ что-то вспомнилось, надо где нить спросить как крутые ентерпрайз ребяты сделали бы регистронезависимый поиск по обычной html табличке, с последующим скрытием строк.
ЗЫ что-то вспомнилось, надо где нить спросить как крутые ентерпрайз ребяты сделали бы регистронезависимый поиск по обычной html табличке, с последующим скрытием строк.
Мой лучший код — быстро, с хаками и велосипедами написанная логика системы управления станка
Работоспособность — не характеристика кода, это характеристика программы. Хороших программ с плохим кодом много.
А вылизанный, чистый хороший модуль, написанный с соблюдением всех известных мне хороших практик, пылящийся в старой репе развалившейся комманды я лучшим своим кодом не считаю.
А зря ))
Это у вас Survival Byes, просто тех кого станком с плохим кодом убило не могут высказать радости что их плохой код работает.
Когда ваш станок отрежет оператору палец, а вас собьет Self-Driving Car написаный человеком с вашими идеалами — вот тогда и… не поговорим.
Когда ваш станок отрежет оператору палец, а вас собьет Self-Driving Car написаный человеком с вашими идеалами — вот тогда и… не поговорим.
Станок не отрежет оператору палец просто потому что области, где могут находиться режущие части станка и пальцы оператора, при включенном станке не пересекаются. Это называется «Техника безопасности».
Да не обязательно, чистота кода с его надежностью связаны не один к одному. В своем станочном коде из примера я уверен с достаточной долей уверенности, хоть он и грязный. Он там не очень поддерживаемый, да, и не очень масштабируемый, но и задачи такой нет.
Не говорите глупостей. Копипаста считается плохим кодом, но может ли он навредить? Можно вытянуть за уши что в одном месте мы что-то изменим а в другом забудем, но это уже не будет копипастой, это получится два разных куска кода. Плохой код не делает плохо, плохая программа делает плохо. Идеально написаный код с багой в логике может убить, плохо написаный код с правильной логикой будет работать хорошо.
Щас бы меня отшивал программист на джаваскрипте :) Спасибо, таких собеседований мне не нужно.
Возможно, сейчас меня занесет в полную противоположность — но будь моя воля, я бы может брал вообще всех, кто хочет работать.
Что интересно — меня по похожему принципу взяли. Я выгорел на прошлом стеке технологий, начал изучать другой, неожиданно написала HR, пригласили на собес несмотря на то что сказал что только недавно начал изучать стек нужный, на собеседовании поговорили с руководителем будущим на довольно общие темы, сейчас на испытательном с НГ. Да, риск непрохождения испытательного большой, особенно учитывая что команда мобильных разработчиков в отделе только собирается и нет какого то наставничества и введения в процессы как на прошлом месте, но пока мне все нравится, посмотрим что будет в конце испытательного.
P.S. И да, «бездушное, что-то вроде C# или Java» — ни разу не правда. Пишу на котлине и не понимаю как до этого писал на языке с динамической типизацией.
Пишу на котлине и не понимаю как до этого писал на языке с динамической типизацией.
Ха! «Пишу на языке с превосходным дизайном, отличным набором библиотек и extra-high quality toolchain-ом — и радуюсь жизни» — вот как это звучит в переводе.
Ну изначально я готовился к тому что на java писать нужно будет, то что это будет котлин — узнал почти перед выходом на работу уже.
котлин, java — все едино. На выходе получаем тот же байткод
Ну, java не так страшна, когда есть Идея )
Особенно нынешняя java.
А вот что особенно здорово для «вкатывающегося в jvm» — это котлиновский curated набор библиотек.
Собрано все лучшее — нет опасности что кто-то закопипастит реликтовую дрянь из года 2006-го
Особенно нынешняя java.
А вот что особенно здорово для «вкатывающегося в jvm» — это котлиновский curated набор библиотек.
Собрано все лучшее — нет опасности что кто-то закопипастит реликтовую дрянь из года 2006-го
Вот интересно, какой процент выгоревших перешли на котлин? Сам перешёл на него 4 месяца назад аж с делфей…
И да, «бездушное, что-то вроде C# или Java» — ни разу не правдапохоже, имелся в виду «кровавый энтерпрайз».
Мне кажется, простая беседа на профессиональные темы — самое лучшее собеседование. Если человек влюблен в программирование и информационные технологиии, то это сразу будет видно. Тут же оценивается уровень знаний — широта и глубина, подходы, темы и технологии фанатом которых собеседуемый является.
Если нет — ну тогда это простой наемник, которому все равно что делать, лишь бы $$$ платили, и тогда имеет смысл переходить к классическому собеседованию вопросы/ответы.
Если нет — ну тогда это простой наемник, которому все равно что делать, лишь бы $$$ платили, и тогда имеет смысл переходить к классическому собеседованию вопросы/ответы.
Есть опасность взять человека, «умеющего только проходить интервью».
Важно понять, что человек делал, но техническую часть проверить тоже надо.
Я стараюсь создать доброжелательную атмосферу, подчеркиваю, что можно ошибаться, если удобно — можно рассуждать вслух, если есть варианты — обсуждаем их, какой когда лучше. Если случился затык — наводящие вопросы, не помогает — предлагаю подойти к задаче с другой стороны. Главное, что надо понять — сможет ли человек решать проблемы заказчика.
Задачи предлагаю довольно общие
Понятно, что бывают наемники, бывают фанаты, но от хорошего Senior Developer я все же ожидаю достаточно хорошего решения по каждой из этих задач (не обязательно с первого раза и не обязательно такого же, как мое).
Важно понять, что человек делал, но техническую часть проверить тоже надо.
Я стараюсь создать доброжелательную атмосферу, подчеркиваю, что можно ошибаться, если удобно — можно рассуждать вслух, если есть варианты — обсуждаем их, какой когда лучше. Если случился затык — наводящие вопросы, не помогает — предлагаю подойти к задаче с другой стороны. Главное, что надо понять — сможет ли человек решать проблемы заказчика.
Задачи предлагаю довольно общие
- 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 — неважно, лишь бы общая канва решения была понятна)
задачка на синхронизацию потоков (для нас это актуально)И, сделав ставку на то, как прекрасна ваша вакансия, вы бы увидели самого прилежного зубрилу.
Но… Так много вакансий без нудных задачек. Стоит ли тратить время зря?
А так ли их много?...
Скажем так, их достаточно. Вы слышали о senior developer, который не мог бы найти работу? Ну, не с тремя годами опыта, конечно. Джунам сейчас посложнее, но вход в профессию можно сюда не считать
Их, в действительности, стало очень много за последний год. И справедливости ради, компании часто соглашаются отказаться от задачк, если попросить.
На днях прошел первые 2 собеседования за год.
Рапортую вам 50% вероятности
Компания А после 1.5 часа хочет алгоритмы на час + собес с руководством + неизвестно, даст ли оффер.
Компания Б согласовала собес в тот же день и после 2 часов интервью дала оффер.
Первое предложение Б на 10% хуже максимума в А., сфера деят., масштаб ~ одинаковы.
Приятные у вас задачки. Жаль мне так ни разу не везло.
спроектировать БД на 3 таблицы и написать запрос к ней (если есть ошибки в SQL — неважно, лишь бы общая канва решения была понятна)
Классическую из задачника вроде книго/фильмотеки на умение в нормализацию, или что-то более специфичное? Напишите, пожалуйста, сформулированное задание, если не затруднит. Интересно.
Мне однажды на мою фразу, что я в айти по любви ответили с гадкой усмешкой, что ну у нас тут не любовь, а работа. Безмозглые мудаки.
Вам, видимо, не приходилось никем руководить. И попадать в ситуацию когда что-то супер-важное для бизнеса не делается в срок или продакшен-сервер «то падает, то не работает» — а ваши подчиненные где-то патчат KDE под FreeBSD потому что это прикольно.
Вам видимо никогда не приходилось руководить людьми талантливыми и увлеченными. У них как раз не падает а работает, потому что они любят свое дело и делают его, как правило хорошо.
А если боевой сервер «то падает, то не работает», то CTO нужно уволить к чертям.
А если боевой сервер «то падает, то не работает», то CTO нужно уволить к чертям.
горячо обсуждаемая статья
А не поделишься ли ссылкой, пожалуйста? Не могу найти, а почитать было бы интересно.
Бизнес не всегда представляет что именно ему надо. Иногда менеджеру предлагают вместо фундамента здания накидать картонных коробок. И можете сколько угодно рассказывать о том что потребность бизнеса — картонный фундамент, ни один вменяемый специалист на это не пойдет. Почему вы решили что в ПО «херак, херак и в продакшен» — лучшая стратегия?
Халявщики конечно иногда встречаются везде. Но очевидно что в таком случае они не являются увлеченными и любящему свою работу. Просачиваются, что же поделать. Самый яркий пример у меня был: набирали продавцов в спортивный магазин в крупном ТЦ: зарплата выше рынка, работа интересная, мотивация имеется, etc. 2 из 11 оказались лодырями, что поделать. Зато получил непередаваемое удовольствие от работе с остальными: одни хорошо продавали, другие владели техническими аспектами, некоторые были харизматичны до ужаса, а другие про товар рассказывали так что я сам был готов купить, обнять и облизать. Конечно бывает и отвлекались и витали в облаках и не занимались рутиной, ничего страшного, рассказывал, объяснял, убеждал и наступало счастье. Где то правили бизнес-процессы согласно их замечаниям и опыту, учились друг у друга. Мы даже разрешали регистрировать покупки на отсутствующих в смене: клиенты частенько через длительное время и помнили кто их консультировал.
Если же с такими людьми топать ногами, требовать немедленных продаж, не слушать доводы и действовать как средний менеджер, то все может пойти очень плохо. И нужны будут жесткие бизнес процессы как у крупных сетей расчитанные на низкоквалифицированный персонал.
Вообще программисты все из себя такие плохие и требуют. Но почему то строительство здания предполагает проект, инженерные изыскания etc И если вместо сарая вдруг понадобился отель то обычно сносят сарай и строят отель. А вот программистам регулярно предлагают сделать из сарая, который стоит то чудом, построить Бурдж Халифа (как минимум).
Халявщики конечно иногда встречаются везде. Но очевидно что в таком случае они не являются увлеченными и любящему свою работу. Просачиваются, что же поделать. Самый яркий пример у меня был: набирали продавцов в спортивный магазин в крупном ТЦ: зарплата выше рынка, работа интересная, мотивация имеется, etc. 2 из 11 оказались лодырями, что поделать. Зато получил непередаваемое удовольствие от работе с остальными: одни хорошо продавали, другие владели техническими аспектами, некоторые были харизматичны до ужаса, а другие про товар рассказывали так что я сам был готов купить, обнять и облизать. Конечно бывает и отвлекались и витали в облаках и не занимались рутиной, ничего страшного, рассказывал, объяснял, убеждал и наступало счастье. Где то правили бизнес-процессы согласно их замечаниям и опыту, учились друг у друга. Мы даже разрешали регистрировать покупки на отсутствующих в смене: клиенты частенько через длительное время и помнили кто их консультировал.
Если же с такими людьми топать ногами, требовать немедленных продаж, не слушать доводы и действовать как средний менеджер, то все может пойти очень плохо. И нужны будут жесткие бизнес процессы как у крупных сетей расчитанные на низкоквалифицированный персонал.
Вообще программисты все из себя такие плохие и требуют. Но почему то строительство здания предполагает проект, инженерные изыскания etc И если вместо сарая вдруг понадобился отель то обычно сносят сарай и строят отель. А вот программистам регулярно предлагают сделать из сарая, который стоит то чудом, построить Бурдж Халифа (как минимум).
Вы не говорили, но «потребности бизнеса» говорят регулярно.
Это приходит с возрастом и опытом. В какой-то момент вы поймете, что деньги на зарплату тем же инженерам не растут на деревьях, а приходят от заказчиков в обмен на вполне реальные продукты или новые возможности. И что большинство успешных стартапов начинало с говнокода, вываленного в продакшен и вызвавшего первоначальное «Хочу!» у пользователей — а потом уже «причесанного» силами дорогих профессионалов. А большинство неуспешных — начало с найма дорогих профессионалов а потом… потом уже не было.
О! Аппеляция к возрасту, используется когда нету ума для адекватных аргументов.
А большинство неуспешных — начало с найма дорогих профессионалов а потомПруф.
Я прекрасно умею считать, до копейки, включая такие расходы, которые большинство себе не представляет, в том числе благодаря весьма богатому опыту. И поверьте, до найма дорогих профессионалов доживают очень немногие (а не в it дак вообще единицы).
Сколько денег выкинуто в мусор на релизе забагованных продуктов, потере критичных данных, отсутсвии резервной архитектуры и прочей экономии, несчесть. Да вон взять тот же геймдев: триллионы баксов отправились в помойку по причине релиза сырых продуктов.
Вообще апеллирование к систематической ошибке выжившего как к аргументы как раз наилучшее доказательство того, о чем я говорю)
Сколько денег выкинуто в мусор на релизе забагованных продуктов, потере критичных данных, отсутсвии резервной архитектуры и прочей экономии, несчесть. Да вон взять тот же геймдев: триллионы баксов отправились в помойку по причине релиза сырых продуктов.
Вообще апеллирование к систематической ошибке выжившего как к аргументы как раз наилучшее доказательство того, о чем я говорю)
Это не ошибка выжившего — это поиск стратегии выживания. И из известных мне фирм вот это самое "… як-… як — и в продакшен" привело к успеху десятки, а мощное и всеобьемлющее планирование погубило сотни.
В геймдеве я не силен — но думаю что проектов, «заваленных» из-за багов на два порядка меньше чем закрытых из-за кончившегося бюджета. Особенно в наше время сетевых игр и онлайн-установки апдейтов и патчей.
Главное доказательство этой теории — это Винда и другие продукты Майкрософт, дружно осмеиваемые «хардкор-программистами», «супер-админами», поклонниками TeX и прочими узкими меньшинствами на протяжении всего жизненного цикла. Что не помешало ей снискать колоссальный коммерческий успех и похоронить кучу конкурентов.
В геймдеве я не силен — но думаю что проектов, «заваленных» из-за багов на два порядка меньше чем закрытых из-за кончившегося бюджета. Особенно в наше время сетевых игр и онлайн-установки апдейтов и патчей.
Главное доказательство этой теории — это Винда и другие продукты Майкрософт, дружно осмеиваемые «хардкор-программистами», «супер-админами», поклонниками TeX и прочими узкими меньшинствами на протяжении всего жизненного цикла. Что не помешало ей снискать колоссальный коммерческий успех и похоронить кучу конкурентов.
Это не ошибка выжившего — это поиск стратегии выживания. И из известных мне фирм вот это самое "… як-… як — и в продакшен" привело к успеху десятки, а мощное и всеобьемлющее планирование погубило сотни.
Чрезмерное затягивание действительно губиьельно. Но стратегия быстрого релиза может сработать только если вы предлагаете уникальный продукт на пустом рынке и смогли в первых версиях продемонстрировать его конкурентные преимущества.
И опять же, мы конечно можем говорить что дельфины чрезвычайно умные и всегда выносят человека к берегу, вот только у тех, кого они несли не к берегу шансов рассказать уже не будет никаких.
В геймдеве я не силен — но думаю что проектов, «заваленных» из-за багов на два порядка меньше чем закрытых из-за кончившегося бюджета
Возможно, на азиатском рынке так оно и есть. Но вот сколько я наблюдаю за рынком ММО, релизнуть сырую игру это которкий путь выкинуть много денег.
Особенно в наше время сетевых игр и онлайн-установки апдейтов и патчей.
И кому они будут нужны когда в стиме рейтинг игр будет в районе плинтуса?
Главное доказательство этой теории — это Винда и другие продукты Майкрософт
Не только их заслуга, время было такое. Сейчас иногда снести ее проще чем сражаться.
В конце концов если мы говорим о крайних случаях: ну и пусть?
Я и переделать потом могу, только деньги несите и сроки реальные ожидайте.
Даже если ваше здание убьет сотню человек?
Я вот например не согласен, я не хочу делать картонный фундамент, не хочу делать средства цензуры и слежки. Рынок большой.
Я дико извиняюсь: несогласные могут пояснить свою позицию?)
Типо делать нужно все что прикажут?
Типо делать нужно все что прикажут?
Думаю, что проблема в слишком агрессивном уходе в крайности.
Хотя лично я с идеей вашей согласен. Да, начальник может сказать: «да мне пофиг, делай на картоне», а когда здание рухнет — «ну я же не знал, ты профессионал и не должен был делать так, чтобы оно рухнуло».
Мне как-то спустя 4 года работы менеджер кинул претензию, что решение, принятое 4 года назад не подходит под новые требования, оно не может достаточно гибко настроиться в админке и нужно кусок перекодить. Говорит, мол: «хреновый из тебя архитектор, раз ты не продумал, из-за тебя теперь релиз переносим»
А четыре года назад он сказал: «Та сделай как-нибудь, нам срочно надо, потом переделаем». И четыре года оно продержалось, отлично скейлилось, но в итоге я всё-равно виноват, что плохо закодил и плохой из меня архитектор.
Он, конечно, потом признал, что был неправ, но тут сильно яркие разбежности — много лет прошло, а изменения вносились за дни, а не месяцы. Но это мне явно показало, что даже если начальник говорит: «та это полная хрень, ответственность на мне, мы никогда не будем использовать это на продакшене, так что сделай костылем и очень срочно», то надо слышать: «это крайне важная фича, ответственность полностью на тебе, мы её будем использовать на продакшене и тыкать тебя носом в каждую недоработку»
Хотя лично я с идеей вашей согласен. Да, начальник может сказать: «да мне пофиг, делай на картоне», а когда здание рухнет — «ну я же не знал, ты профессионал и не должен был делать так, чтобы оно рухнуло».
Мне как-то спустя 4 года работы менеджер кинул претензию, что решение, принятое 4 года назад не подходит под новые требования, оно не может достаточно гибко настроиться в админке и нужно кусок перекодить. Говорит, мол: «хреновый из тебя архитектор, раз ты не продумал, из-за тебя теперь релиз переносим»
А четыре года назад он сказал: «Та сделай как-нибудь, нам срочно надо, потом переделаем». И четыре года оно продержалось, отлично скейлилось, но в итоге я всё-равно виноват, что плохо закодил и плохой из меня архитектор.
Он, конечно, потом признал, что был неправ, но тут сильно яркие разбежности — много лет прошло, а изменения вносились за дни, а не месяцы. Но это мне явно показало, что даже если начальник говорит: «та это полная хрень, ответственность на мне, мы никогда не будем использовать это на продакшене, так что сделай костылем и очень срочно», то надо слышать: «это крайне важная фича, ответственность полностью на тебе, мы её будем использовать на продакшене и тыкать тебя носом в каждую недоработку»
«это крайне важная фича, ответственность полностью на тебе, мы её будем использовать на продакшене и тыкать тебя носом в каждую недоработку»
Все именно так. Еще смешнее все выглядит когда решения связаны с инфраструктурой. Одной компании предлагал для повышения эффективности внедрить ip-телефонию все дела. Не хотели нивкакую, потом внедряли очень срочно потому что «эффективность же». А на мои указания «ты не достаточно сильно настаивал, надо было донести».
Думаю, что проблема в слишком агрессивном уходе в крайности.
Разве? А повальное нежелание разбираться в вопросах/нести ответственность/принимать решения не есть крайность?
Кроме того, «я выполнял приказы» — самая частая фраза на нюрнбергском процессе. Посему я буду думать своей головой и жить так, как верю.
У нас в такой ситуации веселее было. Менеджер, который дал указание «делаем как-нибудь, нам главное сейчас — проект заказчику сдать», к тому моменту, когда костыль «выстрелил» на сопровождении, работал уже на стороне заказчика…
Жизненно-критическое ПО проверяется и перепроверяется по 10 раз.
А причем тут жизненно важное? Я например не буду ни писать ни внедрять системы слежки и иже с ними.
а заказчик всё равно хочет по-своему
Есть еще третий вариант: нет, будет вот так, или увольняйте.
С одной стороны выглядит не очень красиво, но мода на
ну я же не знал, ты профессионал и не должен был делать так
прямо захватывает умы сотен. Причем встречается в разных сферах/городах/etc. Без проблем, я готов брать на себя ответственность, но тогда будет по-моему.
зы
Я вас не минусил
Да я переживу, просто любопытно стало прям.
Приходилось руководить разными. Понятие "своего дела" любимого — у каждого свое, к сожалению часто отличающееся от того, что приносит фирме деньги.
Вот, из последнего — очень толковый алгоритмист работал лишнюю неделю над повышением точности алгоритма и не соглашался релизить "сырую" версию. Он достиг действительно выдающихся результатов — но в самом продукте такая точность не нужна и даже сбивает с толку. Теперь обьясните, где фирма должна найти деньги чтобы оплатить ему эту неделю.
А ты точно "руководитель"?
Пока больше похоже, что хвост вилял собакой
Вы уже определитесь — а то одни пишут что «хвост виляет собакой», а другие — как злые менеджеры рубят их гениальные идеи
Если вы не смогли донести до подчиненного факт что оверинжениринг в данном случае не нужен, то это косяк вас в качестве менеджера. А может быть он был прав, и сырая версия действительно была бы вредна, и тогда это тоже косяк вас как менеджера. Мало того, если бы вы сказали ему в приказном порядке, не переубедив, это тоже был бы ваш косяк как менеджера, потому что он запросто мог бы быть прав.
Спасибо, я посмеялся. А подчиненному ничего обьяснять и не пришлось — всего лишь попросил ответить на выше заданный вопрос, откуда по его разумению фирма должна получить деньги на дальнейшую оплату его исследований. Честно — если бы он привел хотя бы отдаленно похожий на правду пример (вроде экономии «сотни человекочасов потом» из комментария Kwisatz) — я бы согласился просто из любви к науке. Но увы — этого не случилось. Так что ошибаются не только менеджеры ;)
Вопрос стоит очень странно. Какое ему дело где фирма деньги найдет? Проблемы индейцев… Я как CTO могу ответить на такой вопрос, а если меня спросят как рядового программера да еще в стиле «куда по его разумению фирма должна получить деньги» пожал бы плечами.
Но если поставить иначе то вот потому, волт для этого и вот такой эффект.
Исключительно они. Виноват всегда и во всем руководитель.
Но если поставить иначе то вот потому, волт для этого и вот такой эффект.
Так что ошибаются не только менеджеры ;)
Исключительно они. Виноват всегда и во всем руководитель.
Присоединяюсь к предыдущему оратору, очень велик шанс того, что вы, как менеджер, не смогли понять сути вещей, и экономия недели сейчас может вылиться в сотни человекочасов потом (сплошь и рядом в ентерпрайзе)
В любом случае если ваши планы на сотрудника не сошлись с действительностью то косяк исключительно ваш.
В любом случае если ваши планы на сотрудника не сошлись с действительностью то косяк исключительно ваш.
Я так часто что это наблюдал, что даже «я же говорил» не охота говорить, только цитирую всем анекдот.
Вечер, дождь. У камина сидит пожилой джентльмен. Распахивается дверь и вбегает дворецкий:
— Сэр! Спасайтесь! Темза вышла из берегов! Через пять минут вода
хлынет сюда!
— Выйдите и зайдите снова.
Дворецкий выходит и снова забегает:
— Сэр, Темза уже вот-вот будет здесь, спасайтесь!
— Бэрримор, выйдите и доложите, как подобает настоящему английскому дворецкому!
Не спеша открывается дверь, потоком воды вносит дворецкого:
— К Вам Темза, Сэр!
Предположу это был какой-то банк или финансовая организация?
Вот-вот, верно подмечено, наёмник (они же программисты на битриксе :) ). Выяснить типаж программиста на собеседовании — отличная идея, сразу будет понятна мотивация человека. Кроме этого выделяют rock star, как правило с хорошим математическим бекграундом или многолетним опытом участия в олимпиадах. Во, нарыл статью с хабра
Программист на Битриксе не может быть творческой и интересной личностью?)
оу, ну незнаю. для меня
многолетним опытом участия в олимпиадахэто сразу такой красный флажочек, который просто кричит ОСТОРОЖНО — «минное поле», не вступи во что-то плохое))
А что не так с олимпиадниками?
Олимпиадники затачиваются на специфические олимпиадные задачи, целью которых является не хороший програмный продукт, а элегантное изящное решение задачки в вакууме. «Олимпиадники» не думают ни про поддерживаемость и читаемость своего кода, ни про интеграцию в комманду, ни про сроки и трудозатраты, ни про опасность велосипедостроения, они думают только про то чтобы их решение было изящно, красиво и эффективно по каким-либо метрикам.
«Олимпиадники» не думают ни про поддерживаемость и читаемость своего кода, ни про интеграцию в комманду, ни про сроки и трудозатраты, ни про опасность велосипедостроения,
Качество кода фиксится за пару месяцев, если используется код-ревью.
Интеграция в команду — это от человека зависит. Например, самые престижные олимпиады — командные, так что кто-кто, а олимпиадники должны уметь работать в команде.
Сроки, приорететы и велосипедостроение — это больше зависит от менеджера и лечится тоже весьма просто, парой внушений.
Например, тот же гугл в интервью своих явно заточен именно на олимпиадников. Костяк команды вконтакта был сплошные олимпиадники.
Если бы перечисленные вами проблемы действительно были системными, у кучи больших компаний были бы огромные проблемы.
На гугл смотреть не надо, гугл может позволить себе набрать суперзвезд, собрать из них суперзведные комманды, дать им интересных задач, и ждать что из этого получится. 99% компаний не гугл, и задачи у них совсем не такие интересные, и денег на звездные комманды у них нет.
И да, мы говорим не про людей, которые «лечатся парой внушений», мы говорим про людей обычных, у которых есть свой подход, свой опыт и свои практики.
И да, мы говорим не про людей, которые «лечатся парой внушений», мы говорим про людей обычных, у которых есть свой подход, свой опыт и свои практики.
говорят, что они используют олимпиадный (не масштабируемый) подход к написанию кода, хотя я вот немного в олимпиадах участвовал и никто на меня не жаловался (хотя, может я неправильный был олимпиадник — невысоко поднимался)
Для этого суть работа должна быть похожа на «олимпиаду», тогда и «олимпийцы» будут хорошими работниками. А вот представьте, что компания саппортит чужой код, и исходный код вовсе не образец хорошего стиля. «Олимпиец» 90% в таких случаях скорее заскучает и начнет искать себе занятие поинтересней. Или станет писать код настолько вычурный, что плохо станет уже всем остальным.
технологии фанатом которых собеседуемый является.
уж лучше простой наёмник чем фанатик
Это опасная тактика.
Реально прямо влюблённых в программирование — десятки процентов, точно меньше половины. Из них ещё какая-то доля тех, кто настолько его, программирование, любит, что без устали строит велосипеды и занимается прочим ftwjavascript вместо решения непосредственно бизнес-задач.
Почему бы отказывать в нормальном собеседовании большей части? Вам же нужен сотрудник для работы, а не для интересных разговоров
Реально прямо влюблённых в программирование — десятки процентов, точно меньше половины. Из них ещё какая-то доля тех, кто настолько его, программирование, любит, что без устали строит велосипеды и занимается прочим ftwjavascript вместо решения непосредственно бизнес-задач.
Почему бы отказывать в нормальном собеседовании большей части? Вам же нужен сотрудник для работы, а не для интересных разговоров
Ожидания от работы разные бывают у разных людей. Команда обычно подбирается чтобы её руководителю было комфортно решать её силами бизнес-задачи. Если ему не комфортно ставить задачи, понимая что сделают их «отсюда и до обеда», не заботясь о красоте, эффективности кода, о техническом долге и т. п., то лучше работников, делающих задачи так, не набирать в команду.
Я так понял что это как раз тот друг которого fillpackart постоянно упоминал в своих статьях и который пишет на js/ts. Хотя может и ошибаюсь.
Вот, надо было запатентовать право использовать картинки с кодом. Ведь это же я их изобрёл.
Еще в декабре fillpackart заподозрил в том, что он профессионально занимается своим блогом. Профессиональность заключается в осознанном, намеренном создании определенного противоречивого отношения к написанному, стиль изложения тоже помогает в формировании определенных чувств.
Изначальное приглашение fillpackart от arttom, намекало на виртуальность аккаунта, то что теперь там стоит приглашение от НЛО, намекает еще больше. А стиль изложения своих мыслей от rcanedu в этом посту, очень похож на стиль fillpackart, прям идентичным мне показался.
Есть одно правило: чтобы хорошо писать, надо много читать. Безусловно нужен определенный талант, чтобы овладеть искусством письма, но это доступно каждому. Про психологию и риторику написано очень многое, это не тайные знания. Может этим обусловлены похожие стили, потому что авторам понятно как они будут работать, а может виртуальностью авторов. Согласно Байесовскому мышлению, можно предположить различные гипотизы для выяснения вероятности виртуальности авторов, например: какие-то детали в именах, в никах, в закладках, в КДПВ и прочих вещах, в которых смогли наследить авторы, но для меня это не очень важно. Мне просто видится намеренная игра с читателями, а если говорить в духе времени, то троллинг читателя и бездушие авторов. И по моему, вся суть заключается в привлечении аудитории. При этом я могу ошибаться.
Изначальное приглашение fillpackart от arttom, намекало на виртуальность аккаунта, то что теперь там стоит приглашение от НЛО, намекает еще больше. А стиль изложения своих мыслей от rcanedu в этом посту, очень похож на стиль fillpackart, прям идентичным мне показался.
Есть одно правило: чтобы хорошо писать, надо много читать. Безусловно нужен определенный талант, чтобы овладеть искусством письма, но это доступно каждому. Про психологию и риторику написано очень многое, это не тайные знания. Может этим обусловлены похожие стили, потому что авторам понятно как они будут работать, а может виртуальностью авторов. Согласно Байесовскому мышлению, можно предположить различные гипотизы для выяснения вероятности виртуальности авторов, например: какие-то детали в именах, в никах, в закладках, в КДПВ и прочих вещах, в которых смогли наследить авторы, но для меня это не очень важно. Мне просто видится намеренная игра с читателями, а если говорить в духе времени, то троллинг читателя и бездушие авторов. И по моему, вся суть заключается в привлечении аудитории. При этом я могу ошибаться.
Умение видеть людей, с которыми сможешь работать — это либо природная способность, данная от рождения, либо плод таких вот душевных метаний и интеллектуальных поисков.
Но главное не в этом, а в принципе — «потребление или созидание».
«Потребитель» ищет идеально готового спеца, а «созидатель» ищет того, кого сможет обучить, если вдруг тот чего-то не знает. Если нужно по-быстрому закончить проект и разбежаться, то «потребительство» оправдано. А если предстоит работать месте в одной команде несколько лет, то подход совсем другой.
Но главное не в этом, а в принципе — «потребление или созидание».
«Потребитель» ищет идеально готового спеца, а «созидатель» ищет того, кого сможет обучить, если вдруг тот чего-то не знает. Если нужно по-быстрому закончить проект и разбежаться, то «потребительство» оправдано. А если предстоит работать месте в одной команде несколько лет, то подход совсем другой.
Еще вчера мы не знали выиграем тендер или нет. Готовились к победе, куда без этого, но людей не нанимали. И вот сегодня узнали что победили. Архитектор на пару с тим-лидом сказали — для покрытия затребованного функционала нужно десять разработчиков вот таких компетенций. На полгода. Потом они возможно будут не нужны. А возможно и нужны. Но работу надо начать уже завтра. На край — послезавтра.
Джуны? Наставничество? Пффф…
Только уверенные, опытные, отлично владеющие нужными технологиями парни. Хорошо-бы уже команда, но мечтать не вредно. HR-ы — вперед, нужно сто резюме, выгребите hh и прочие площадки. Тим-лид — ты следующие три дня только собеседуешь, прости брат, ты эти три дня как на конвейере, извини за цинизм, но из тех что ты просмотришь ты должен взять а) лучших по компетенциям б) тех с кем точно сработаешься сам и другие сотрудники.
Парни, вперед, just do it.
Джуны? Наставничество? Пффф…
Только уверенные, опытные, отлично владеющие нужными технологиями парни. Хорошо-бы уже команда, но мечтать не вредно. HR-ы — вперед, нужно сто резюме, выгребите hh и прочие площадки. Тим-лид — ты следующие три дня только собеседуешь, прости брат, ты эти три дня как на конвейере, извини за цинизм, но из тех что ты просмотришь ты должен взять а) лучших по компетенциям б) тех с кем точно сработаешься сам и другие сотрудники.
Парни, вперед, just do it.
Просто разница между работой над краткосрочными и долгосрочными перспективами. Ну и возможно разница рынков. В провинции например люди работодателей меняют реже чем в столицах, да и людей не так много, боюсь этих 10 разработчиков из примера выбирать придется из 10-30, из которых половина джунов, а другая с других стеков резюме кинули.
Чтобы работать над долгосрочными перспективами нужно накопить жирок, который даст пережить кассовый разрыв из-за все возрастающих требований по обеспечению выполнения контрактов, который позволит пережить очередной мировой или локальный кризис, который позволит переехать из полу-подвала в офис А+, а пока — надо выживать.
За последние полгода при смерти оказалось два крупных системных интегратора, один на полторы тысячи численного состава, другой на пятьсот. И там и там были десятки джунов, наставничество и все такое. Еще пара интеграторов такого же уровня тоже чувствуют себя ой как непросто.
Долгосрочная перспектива это в сбер, газпром, я там не работал, только слухами питаюсь, но говорят, что там что джун, что сеньор, вообще могут и не работать, главное в офис являться и на совещания ходить.
За последние полгода при смерти оказалось два крупных системных интегратора, один на полторы тысячи численного состава, другой на пятьсот. И там и там были десятки джунов, наставничество и все такое. Еще пара интеграторов такого же уровня тоже чувствуют себя ой как непросто.
Долгосрочная перспектива это в сбер, газпром, я там не работал, только слухами питаюсь, но говорят, что там что джун, что сеньор, вообще могут и не работать, главное в офис являться и на совещания ходить.
На прошлом месте была не разу не крупная компания, около 100 человек, из которых программистов около трети. Основной источник кадров — стажеры после вузов без опыта, изредка программисты с опытом. Многие работают там по 5+ лет. Есть те кто уходил а потом возвращались поработав в других местах.
около 100 человек, из которых программистов около трети.
А чем компания зарабатывала? Вы P&L видели?
Можно сидеть на одном-двух крупных заказчиков и пуле их проектов и чувствовать себя отлично.
Например так жил полтора десятка лет Active CIS, а потом, в декабре взял и выгнал на улицу тысячу человек.
Два своих продукта + их внедрение на разных проектах по всему СНГ (от проектов на 100-200 часов до проектов на десятки тысяч часов), внедрение продуктов вендора. 1С франч если что.
Отличный бизнес.
Кейс: вы берете джуна на вырост, на 50К, следующие полгода он как пылесос собирает со всех до кого может дотянуться знания, опыт, наработки. Это период адаптации, человек учится, его вовлеченность, а точнее та добавленная стоимость, которую он создает, колеблется около нуля. А через полгода он просит 100К, или заявление на стол. Ваши действия?
Кейс: вы берете джуна на вырост, на 50К, следующие полгода он как пылесос собирает со всех до кого может дотянуться знания, опыт, наработки. Это период адаптации, человек учится, его вовлеченность, а точнее та добавленная стоимость, которую он создает, колеблется около нуля. А через полгода он просит 100К, или заявление на стол. Ваши действия?
Не знаю. Я таких случаев не видел, меньше 3-4 лет там никто не работает, по крайней мере я вспомнить не смог таких людей. При том что, если честно, ЗП там не сказать что высокие, и офису до элитных очень далеко. Компенсируется как ни смешно прозвучит — хорошим коллективом и интересными задачами.
Это крупный город? Я к тому, что насколько широкий рынок работодателей в этом секторе, в том городе, где работает компания?
В условиях крупного города, где десятки, сотни компаний работают в том же стеке, я раз за разом сталкивался именно с той моделью которую описал выше.
В условиях крупного города, где десятки, сотни компаний работают в том же стеке, я раз за разом сталкивался именно с той моделью которую описал выше.
Компенсируется как ни смешно прозвучит — хорошим коллективом и интересными задачами.А как же печеньки?
А что не так? Если он действительно вырос за эти полгода и может работать работу, то почему бы ему не платить?
А всё не так: НR потратил время на его поиск и собеседование, кадры потратили время на трудоустройство и адаптацию, тим-лиды и сеньоры потратили время на его обучение, компания по тратила деньги на его зарплату. Полгода чуваку платили временем (то есть деньгами по сути) и зарплатой, заплатили в общей сумме пол-ляма чистыми, а с налогами и все 750, пользы с этого джуниора за эти полгода было с гулькин нос, а теперь этот джуниор просит сотку. Офигеть, антреприза.
И вы спрашиваете что не так? ВСЁ.
И вы спрашиваете что не так? ВСЁ.
Звёзды — штучный народ, уникумы.
Шанс из джуна вырастить звезду есть, но я даже обсчитывать вероятность этого не хочу, просто у нас нет денег чтобы эксперементировать.
Я говорю про производство, где звезды не нужны. Где от зари и до заката надо фигачить вполне тривиальные задачи. Вот в этой ситуации джуны ну совсем с экономикой не вяжутся.
Шанс из джуна вырастить звезду есть, но я даже обсчитывать вероятность этого не хочу, просто у нас нет денег чтобы эксперементировать.
Я говорю про производство, где звезды не нужны. Где от зари и до заката надо фигачить вполне тривиальные задачи. Вот в этой ситуации джуны ну совсем с экономикой не вяжутся.
А вот если вы «обучаете впрок», то об этом должно быть заранее прописано в договоре, со сроками обучения, и с количеством человеконедель, которые обучаемый должен потом вам отдать в качестве платы за обучение. Во всех остальных случаях, платить 50 специалисту который стоит 100 нельзя.
Так реально после обучения он стоит 100 или нет? Если бы пришёл сразу обученный полгода назад — заплатили бы 100?
Открываю кадровое агентство, обещаю джуну золотые горы в другой компании, продаю его в другую компанию как 23-летнего синьора, получаю бонус в размере трех его месячных зарплат. Шах и мат, джуны!
А, добавлю еще, все финансовые результаты внутри компании всем открыты. И да, далеко не всегда компания прибыльна, есть убыточные проекты, есть прибыльные, но джунов и стажеров это брать почему то не мешает.
У вас разная специфика.
Ваша компания работает, а компания вашего оппонента выигрывает тендеры.
Ваша компания работает, а компания вашего оппонента выигрывает тендеры.
Согласен, можно создать продукт, а потом его продавать и внедрять на свободном рынке. Это отличный бизнес.
Но есть и другой вид бизнеса — взять потребности заказчика и их реализовать. Выбирая вендора, технологию, архитектуру в зависимости от потребностей заказчика, а не особенности конкретного продукта.
Тендер — это нечто обидное? Да, мы работаем на внешнем рынке, да мы вынуждены мониторить площадки, где публикуется информация о заказах, конкурсах, тендерах, аукционах. Мы именно таким образом работаем, в этой модели что-то не так?
Но есть и другой вид бизнеса — взять потребности заказчика и их реализовать. Выбирая вендора, технологию, архитектуру в зависимости от потребностей заказчика, а не особенности конкретного продукта.
Тендер — это нечто обидное? Да, мы работаем на внешнем рынке, да мы вынуждены мониторить площадки, где публикуется информация о заказах, конкурсах, тендерах, аукционах. Мы именно таким образом работаем, в этой модели что-то не так?
Нет, это не нечто обидное, это просто другая стратегия фуражирования. К которой неприменимы основные принципы стратегии вашего оппонента; обратное также верно.
Это как у Пушкина: орлу и ворону не сойтись во вкусовых предпочтениях.
UPD.
Стоит уточнить термин «работает»: я так понимаю, проблема в нем.
Компания вашего оппонента решает задачи, как я понял, своими силами. У нее есть штат специалистов, приспособленных для решения таких задач. Они и работают.
У вашей, опять же насколько я понял, есть штат специалистов, приспособленных под решение задачи выиграть тендер и организовать решение содержащихся в нем задач. Собственно же решение задач осуществляется силами приглашенных специалистов. В этом смысле «работают», решают задачи именно они.
В общем случае это не хорошо и не плохо, посредник — занятие необходимое в большинстве сценариев, известных нашей цивилизации. А детали могут различаться настолько, что опять-таки никакую оценку им давать без знаний конкретики попросту некорректно.
Наверное, такой ответ будет более правилен, чем предыдущая сокращенная версия.
Это как у Пушкина: орлу и ворону не сойтись во вкусовых предпочтениях.
UPD.
Стоит уточнить термин «работает»: я так понимаю, проблема в нем.
Компания вашего оппонента решает задачи, как я понял, своими силами. У нее есть штат специалистов, приспособленных для решения таких задач. Они и работают.
У вашей, опять же насколько я понял, есть штат специалистов, приспособленных под решение задачи выиграть тендер и организовать решение содержащихся в нем задач. Собственно же решение задач осуществляется силами приглашенных специалистов. В этом смысле «работают», решают задачи именно они.
В общем случае это не хорошо и не плохо, посредник — занятие необходимое в большинстве сценариев, известных нашей цивилизации. А детали могут различаться настолько, что опять-таки никакую оценку им давать без знаний конкретики попросту некорректно.
Наверное, такой ответ будет более правилен, чем предыдущая сокращенная версия.
Так, а к вам пришли, зная, что на полгода, и выходить на работу нужно вот прямо завтра?
Очень советую вам потянуть время и отвести на найм хотя бы месяц при полной загрузке. Сроки потерпят, правда.
прочитал это с его интонацией
Очень хорошая мысль "… но будь моя воля, я бы может брал вообще всех, кто хочет работать."
Я то же с опытом понял, что если у человека есть желание работать и учиться то это гораздо важнее чем его текущие знания. Все таки в мире больше умных людей и практически любого при желание и возможности можно научить чему угодно. А слова "… учить людей интереснее, чем их фильтровать." вообще можно отлить в золоте!
Я то же с опытом понял, что если у человека есть желание работать и учиться то это гораздо важнее чем его текущие знания. Все таки в мире больше умных людей и практически любого при желание и возможности можно научить чему угодно. А слова "… учить людей интереснее, чем их фильтровать." вообще можно отлить в золоте!
Это история взросления, зарабатывания уверенности в себе и самоуважения. +100.
Взросления? Но в конце мы видим:
— А покажешь? Может хоть пойму, чем так людям нравятся эти мерзкие руби.
— после чего у автора якобы начинали раскрепощаться кандидаты…
Не представляю себе кандидата, который после такого начал бы раскрепощаться, для меня подобное заявление поставило бы жирную точку в дальнейшем общении. Я тоже считаю руби мерзкими, как и любимый джс автора, и пхп с виндой и много чего еще, но заявлять такое на собеседовании… Надо быть совсем уж упоротым «интровертом».
— А покажешь? Может хоть пойму, чем так людям нравятся эти мерзкие руби.
— после чего у автора якобы начинали раскрепощаться кандидаты…
Не представляю себе кандидата, который после такого начал бы раскрепощаться, для меня подобное заявление поставило бы жирную точку в дальнейшем общении. Я тоже считаю руби мерзкими, как и любимый джс автора, и пхп с виндой и много чего еще, но заявлять такое на собеседовании… Надо быть совсем уж упоротым «интровертом».
Взросления?
Именно. Вы примеряете этот диалог на себя в позиции собеседуемого в типичной ролевой игре, описанной в начале статьи. Это когда собеседующий — "строгий профессор", а вы "студент-раздолбай" на зачёте, потеете в ожидании каверзных вопросов с целью завалить.
Автор же ищет пути этой ситуации избежать и беседовать с кандидатом на равных, как человек с человеком. Может, не идеально ищет, но сам факт.
А меня бы такая фраза наоборот раззадорила бы. Это же вызов!
«Мерзкий?! Показать тебе, почему ты не прав?! Ну держись, сам напросился!»
«Мерзкий?! Показать тебе, почему ты не прав?! Ну держись, сам напросился!»
Тоже не понял этого прикола, по моему он наоборот полностью закостенел в своём чсв и теперь унижает других зная что ему не ответят он же уже на работе это ты к нему пришёл и что то хочешь, а не наоборот.
del, ошибся веткой.
У компании есть реальные задачи и перед вами сидит человек. Нужно изучать человека и пытаться трезво и четко представить как это будет когда он начнет решать эти задачи. Как только представили, думаем годится ли это или есть шансы что придет кто-то получше. Все остальные способы оценки кандидатов — лютая лотерея.
Похоже, мое замечание похоже никому не понравилось. Суть его была в том, что автор не сосредоточен но основной цели — оценке пригодности кандидатов к работе. Это его главная ошибка. Он то ищет своих близнецов, то пытается завалить кандидата как будто это экзамен в институте, то теперь всех любит и готов всякого обучить. Т.е. автор во время собеседования сосредоточен больше на себе, своих эмоциях и на формальной проверке знаний а не на вопросе пригодности кандидата к работе.
Оффтопик: поздравляю Хабр с выходом на запад. В местной группе эта статья стала поводом жарких обсуждений:
Всегда напрягало, что не мог поделиться с коллегами статьями с хабра на русском :)
Всегда напрягало, что не мог поделиться с коллегами статьями с хабра на русском :)
На реддите эта статья нашла широкий отклик.
Не эта, а другая. Если прочитать ваше сообщение, то можно подумать, что говорят про статью выше. На самом деле на реддите другая но похожая статья от fillpackart
Кстати, код в этом твите очень странный. Используется
return array.map и, казалось бы, функция должна вернуть вменяемый массив с результатом проверки каждой строки, но на практике функция, которая передана в мап — грязная процедура, которая что-то там пишет в глобальные переменные, возвращает undefined и как результат — вся функция возвращает массив undefined. Нафига? Если уж есть надобность релизовать через изменение глобальных переменных — пиши через for-of, зачем вводить в заблуждение используя мап?И вот ты, с хорошим настроением, зайдешь сделать код-ревью. Увидишь такое и, с впечатлением, что человеку абсолютно наплевать на проект и на команду ты прокомментируешь, что этот код неудачный.
А эта обиженка побежит в твиттер и напишет прикольненькое сообщение о том, как его лид-мудак в плохом настроении несправедливо покритиковал его прекрасный функциональный код.
Я в своих интервью (а провожу их иногда и 5-6 в неделю) пользуюсь следующей классификацией:
— Языки программирования делятся на процедурные/обьектные и функциональные
— Процессоры делятся на «классические», SIMD (GPU/DLA) и встраиваемые
Единственные профессиональные критерии — насколько человек понимает, как то что он делал ранее (или говорит что делал) ложится на эту классификацию и как абстракции принятые в использованной системе программирования соотносятся с более низкоуровневыми абстракциями (файлы, потоки, сетевые соединения и так далее).
И если человек понимает что и как заставляет мигать светодиод на Ардуино — он начнет писать для STM или чего-то подобного уже к обеду первого дня. А если обьяснение — «ну, я там нашел библиотеку и оно вот», то все плохо.
— Языки программирования делятся на процедурные/обьектные и функциональные
— Процессоры делятся на «классические», SIMD (GPU/DLA) и встраиваемые
Единственные профессиональные критерии — насколько человек понимает, как то что он делал ранее (или говорит что делал) ложится на эту классификацию и как абстракции принятые в использованной системе программирования соотносятся с более низкоуровневыми абстракциями (файлы, потоки, сетевые соединения и так далее).
И если человек понимает что и как заставляет мигать светодиод на Ардуино — он начнет писать для STM или чего-то подобного уже к обеду первого дня. А если обьяснение — «ну, я там нашел библиотеку и оно вот», то все плохо.
Нужно понимать, что срок жизни отличного программиста на рынке труда это считанные месяцы за 10-20 лет. Есть у меня знакомый А, он может за 2-3 недели изучить распределённую систему (ядро биржи, ~100KLOC), в которой куча многопоточности, сложная логика и нет документации и начать решать любые задачи с отличной скоростью и качеством, не задавая даже вопросов авторам кода. Есть знакомый Б, который после года работы с этой же системой не может выйти за пределы одного, небольшого модуля. Резюме знакомого А никогда даже не было опубликовано, нашёл работу студентом, а после сам выбирал работодателя. Знакомый Б всегда открыт к предложениям и его легко найти и на hh и в LinkedIn. Аналогичная история у всех, без исключения, моих знакомых уровня А. Их просто нет на рынке труда и они там никогда не появятся.
Может кто-то наблюдает другую картину?
вы сейчас прямо как Джоэль.
Вы всех под одну гребенку как-то. Знакомому А повезло студентом выбрать адекватную контору, которая платит деньги и даёт интересные задачи. А некоторым приходится учиться на горьком опыте и составлять резюме.
По вашей логике судьбу специалиста определяет не он сам, а «адекватная контора» с «интересными задачами». Грустно это.
Просто кто-то учится всю жизнь, без перерывов, а кто-то просто фигачит не вдаваясь в подробности, лишь бы работало. За 10-15 лет разница между ними становится настолько огромной, что вторым первые кажутся уже даже не людьми, а магами, которые волшебным образом решают проблемы.
Просто кто-то учится всю жизнь, без перерывов, а кто-то просто фигачит не вдаваясь в подробности, лишь бы работало. За 10-15 лет разница между ними становится настолько огромной, что вторым первые кажутся уже даже не людьми, а магами, которые волшебным образом решают проблемы.
Но контора тоже важна, иначе не будет адекватных задач для применения полученных знаний, практики. Плюс опытные и знающие коллеги могут направить. Но да, понятно что если самому усилий не прикладывать — ничего не будет. Это я еще не вспоминаю про природные способности и условия в которых человек до работы находился, от них тоже зависит немало.
Вы сейчас описали картину, которая наблюдается на рынке труда с b2b продавцами (не важно чего). Если он хорош, компания его никогда не отпустит, а даже если по какой-то отпустит — долго он нигде висеть не будет. Таких можно найти почти исключительно через рекрутинг. На рынке же люди которые либо плохие, но готовые продавцы, либо не готовые, но их нужно будет учить и «выращивать».
Нужно срочно добавлять новый хаб «признания и раскаяния программистов», направление становится популярным. По статье:
Из этой строки понимаю, что компании просто не нужны были новые сотрудники: HR проводили бурную имитацию деятельности, автор тоже, практически с нулевым выхлопом, всех всё устраивало и было даже причиной для гордости. Бывает.
Я провел их около сотни, и за все время взял может человек четырех.
Из этой строки понимаю, что компании просто не нужны были новые сотрудники: HR проводили бурную имитацию деятельности, автор тоже, практически с нулевым выхлопом, всех всё устраивало и было даже причиной для гордости. Бывает.
The only reliable coding interview is a three month probation period. © Stevie Buckley
Лично наблюдал гражданина, который на испыталове работал вполне адекватно, а после испытательного срока резко поменял ухватки. Стал обильно говнокодить там, где не нужно, и весьма токсично реагировать на любые замечания.
Так что насчет надежности данного метода есть обоснованные сомнения.
Так что насчет надежности данного метода есть обоснованные сомнения.
Но это и не говорит о том, что обычное интервью более надежно.
Да, бывают и такие, тоже сталкивался. Но во-первых, они скорее исключение, а во-вторых, на собеседовании их тем более не вычислить, как уже заметить kshshe.
Increasing it up to six months makes it 2x more reliable right?
У меня свои, личные счёты есть к подобным собеседующим. Традиционно, считается, что лучше всего быстро предложить "Пусть не лучшее, но точно рабочее решение и работать над его улучшением, чем сразу пытаться решать задачу оптимально и не добраться даже до половины." — я традиционно так и поступал.
А потом мне попался собеседующий, который вообще не слушал мои пояснения, а просто пырился в служебный ноут, выдал только что-то типа "Квадрат, давайте другой вариант" и дальше пырится в свой ноут.
Я сижу и думаю "Ну да, я же, блин, сразу сказал, что решение за квадрат будет и почему я его беру..."
И позже, уже после собеседования — "Что это вообще было? Профдеформация олимпиадников, для которых если решение не оптимальное, то это и вовсе не решение? Так он, вроде, не похож был на недавнего студента, а такие вредные привычки довольно быстро проходят."
Сам пришел к тем же выводам. Максимальный дефицит находится не в области глубоких знаний, а в области личностных характеристик.
Собеседование это оценка потенциала и скорости его реализации в вашей среде. Уровень формальных знаний, это оценка умения проходить интервью и текущей стоимости, но с формальными знаниями очень легко ошибиться попав чуть мимо кандидата.
По этому на собеседовании нужно проверить базис, способность рассуждать и искать ответы и подходит ли кандидат вашей команде, а вы ему. Не правильные ответы кандидата в данном случае даже более ценны, они позволяют выстроить дискуссию и посмотреть куда она кандидата выведет.
Да, автор наломал дров, будь здоров.
Я вот в своё время просто смотрел «наш» ли это человек. В том смысле, что когда общаешься сначала в университете, а потом на работе с программистами, то уже знаешь «какие они». Я, конечно, задавал вопросы и даже задачки на сортировку, но это был просто повод для общения. Да, тут конечно, некая эмпатия и нюх нужны.
P.S. А вот в соседнем департменте набирали так: берём всех, после испытательного увольняем лишних. Считалось, это эффективно, но я от такого отказался, когда мне пытались этот подход навязать. Потому что я — сначала человек, а потом уже программист, и только потом начальник.
Я вот в своё время просто смотрел «наш» ли это человек. В том смысле, что когда общаешься сначала в университете, а потом на работе с программистами, то уже знаешь «какие они». Я, конечно, задавал вопросы и даже задачки на сортировку, но это был просто повод для общения. Да, тут конечно, некая эмпатия и нюх нужны.
P.S. А вот в соседнем департменте набирали так: берём всех, после испытательного увольняем лишних. Считалось, это эффективно, но я от такого отказался, когда мне пытались этот подход навязать. Потому что я — сначала человек, а потом уже программист, и только потом начальник.
Я вот в своё время просто смотрел «наш» ли это человек
А что это значит? Можете развернуть?
Ну вот я когда учился всегда примерно знал — этот перец крутой, этот вроде меня средний, а этот простофиля. Потом на работе я тоже видел много сильных и не очень программистов.
В результате сложилось некое ощущение «своего» — это программист вроде меня или круче. Просто надо поговорить с человеком, обсудить его или наши задачи и это ощущение «своего» будет или расти, или убывать.
Если в итоге «свой» — можно брать. Понятно, если мы пишем на java, а он на ней 10 лет молотил до этого, то это будет попадание — такой человек сразу здорово двинет дела вперёд. А если мало опыта или нужного нам опыта — предложить начальную позицию, со временем вырастет, освоит, в отделе должен быть механизм передачи экспертизы новичкам.
Вообще не пойму проблемы, когда везде стоит испытательный срок. Я обычно из 20 собеседований беру 15 человек, ошибусь, может, раз-два. Хотя теперь уже нет, на опыте усвоил еще пару моментов, но делиться не буду ими — не политкорректно они звучат.
В результате сложилось некое ощущение «своего» — это программист вроде меня или круче. Просто надо поговорить с человеком, обсудить его или наши задачи и это ощущение «своего» будет или расти, или убывать.
Если в итоге «свой» — можно брать. Понятно, если мы пишем на java, а он на ней 10 лет молотил до этого, то это будет попадание — такой человек сразу здорово двинет дела вперёд. А если мало опыта или нужного нам опыта — предложить начальную позицию, со временем вырастет, освоит, в отделе должен быть механизм передачи экспертизы новичкам.
Вообще не пойму проблемы, когда везде стоит испытательный срок. Я обычно из 20 собеседований беру 15 человек, ошибусь, может, раз-два. Хотя теперь уже нет, на опыте усвоил еще пару моментов, но делиться не буду ими — не политкорректно они звучат.
Вообще не пойму проблемы, когда везде стоит испытательный срок.
Отсеивать на испытательном сроке дороже чем на собеседовании.
Я часто встречал неприятные сюрпризы, когда вроде человек говорит гладко, а простую задачу решить не может.
А согласится ли на позицию новичка, человек у которого опыта много, но вам не нужного? Пару раз встречался с вакансиями типа «нужен сеньор с 5+ лет опыта веб-бэкенда, писать на Java, её знание будет плюсом», подавался (в резюме Java не упоминается), собеседовался, техническое, построенное по принципу «сначала общее, потом Java» проходил в два раза быстрее планового, потому что всё моё знание Java можно уложить в пару предложений типа «ноги из С++, компилируемый в байт-код для JVM, есть исключения, дженерики и Spring. Недавно вроде ФП немного завезли. Опыт разработки — HelloWorld году в 1995». И получал отзыв типа «отличное знание веба и бэкенда, ООП и т. п., но нулевые Java, поэтому позицию интерна предлагаем с зарплатой в 10 раз меньше чем хотите»
Не ну вообще с испытательным это 100% подход по эффективности но зп придется платить и тем кто в резюме наврал.
Статью лучше было бы назвать «Я провел сто собеседований, отказал сотне людей и до сих пор не научился собеседовать».
В указанном примере собеседования человека с двухлетним опытом в Ruby:
Я что-то неправильно понял, или вы сходу указываете человеку, что он потратил два года своей жизни на какую-то мерзость и какашку?
С друзьями можно разговор и так начать, но с незнакомым кандидатом, мне кажется, лучше начать с:
— Я вижу у вас есть 2-летний опыт работы с рельсами, расскажите, пожалуйста, что вы делали, и почему выбрали именно эту технологию?
—…
— А почему решили всё же перейти на JS?
В указанном примере собеседования человека с двухлетним опытом в Ruby:
— Вижу у тебя в резюме есть Ruby. Я пытался писать на рубях когда-то, но меня стало тошнить.
— Не знаю, мне нравилось.
— Ну вообще, мне тогда его особо негде было применять. Может я что-то не рассмотрел.
— У меня была пара приложений, там он подходил.
— А покажешь? Может хоть пойму, чем так людям нравятся эти мерзкие руби.
Я что-то неправильно понял, или вы сходу указываете человеку, что он потратил два года своей жизни на какую-то мерзость и какашку?
С друзьями можно разговор и так начать, но с незнакомым кандидатом, мне кажется, лучше начать с:
— Я вижу у вас есть 2-летний опыт работы с рельсами, расскажите, пожалуйста, что вы делали, и почему выбрали именно эту технологию?
—…
— А почему решили всё же перейти на JS?
Он говорит о "личном" отношении, и скорее всего, в такой интонации, что становится предельно ясно, что это не настолько серьёзно, как вам показалось. Разговор достаточно вежлив, и немного провоцирует в позитивном смысле. Не вижу смысла оскорбляться на ровном месте.
Сложно говорить про интонации в тексте, интонации, конечно, важны в устном разговоре, но в тексте, где мы лишены интонации, слова важнее. Те же мысли можно выразить и другими словами:
Без употребления слов «тошнить» и «мерзкие». Как-то они далековаты от профессионализма, не находите?
Ну и зачем на собеседовании (тем более в чужой отдел) выражать свою личную позицию, мы же оцениваем навыки соискателя и презентуем компанию, а не ведём разговор за пивом с другом? Зачем делать провокации мне тоже не понятно, тем более, что автор сам признаётся, что ему было сложно проходить собеседования из-за стресса, зачем провоцировать кого-то, ведь это может усилить их стресс, «я страдал, они тоже должны»?
P.S. Никто и не думал оскорбляться, просто решил уточнить этот момент.
Я пробовал Ruby, но мне не зашло, а почему Вы выбрали его? Какие проекты реализовывали?
Без употребления слов «тошнить» и «мерзкие». Как-то они далековаты от профессионализма, не находите?
Ну и зачем на собеседовании (тем более в чужой отдел) выражать свою личную позицию, мы же оцениваем навыки соискателя и презентуем компанию, а не ведём разговор за пивом с другом? Зачем делать провокации мне тоже не понятно, тем более, что автор сам признаётся, что ему было сложно проходить собеседования из-за стресса, зачем провоцировать кого-то, ведь это может усилить их стресс, «я страдал, они тоже должны»?
P.S. Никто и не думал оскорбляться, просто решил уточнить этот момент.
В некоторых рекомендация по собеседования, провокационные вопросы считаются обязательными, если позиция предполагает какую-никакую стрессоустойчивость.
Ну и лучше на собеседование выявить, что при унизительных мнениях о Руби кандидат плакать начинает или драться, чем перед дедлайном :)
Ну и лучше на собеседование выявить, что при унизительных мнениях о Руби кандидат плакать начинает или драться, чем перед дедлайном :)
Если вакансия предусматривает стрессоустойчивость, то разумеется на неё нужно проверять. И абсолютно нормально начать с места в карьер. Другое дело, что нужна ли она программистам? Если да, то скорее всего что-то не так с процессами в команде. :)
В обычной ситуации, если начать с таких провокационных и даже немного унизительных вопросов, то скорее всего кандидат серьёзно усомнится в профессионализме команды и задумается насчёт атмосферы в ней и своём желании работать в таких условиях.
В обычной ситуации, если начать с таких провокационных и даже немного унизительных вопросов, то скорее всего кандидат серьёзно усомнится в профессионализме команды и задумается насчёт атмосферы в ней и своём желании работать в таких условиях.
В целом нужна, особенно если позиция программиста предполагает общение с бизнесом.
В том-то и смысл — если в команде реально используют унизительные эпитеты для технологий и т. п., то брать в неё надо человека, которые если не разделяет таких взглядов, то толерантен к ним :)
В том-то и смысл — если в команде реально используют унизительные эпитеты для технологий и т. п., то брать в неё надо человека, которые если не разделяет таких взглядов, то толерантен к ним :)
В целом нужна, особенно если позиция программиста предполагает общение с бизнесом.
Ну по моему личному опыту
А вот что нужно, так это умение подбирать слова и вести диалог так, чтобы потенциальных оскорблений там было по-минимуму, а информации по-максимуму.
Можно, конечно, сказать человеку, что он дебил, и его код — говно, но лучше сказать, что вот здесь есть линейный алгоритм, вместо его NP, и отшутиться, что ваши пользователи не хотят идти заваривать чай, после каждого клика, ещё и смайлик в конце сообщения поставить, чтобы уж точно не обидеть никого. :)
Вам же ещё работать вместе, да и цель не доказать свою крутость, а крутой продукт выкатить.
Проводил не так много собеседований, но по большей части стараюсь пройтись по заявленному опыту в резюме и базовым вещам, необходимым на проекте, развивая всё это в диалог. Чем сеньорней кандидат, тем больше делаю упор на первое, чем на второе, ибо научить человека всегда можно, а вот насколько хорошо он учится и насколько потенциально будет справляться понять гораздо важнее. Обычно сеньор в диалогах сам способен показать свою сеньорность, а беседах с миддлами очень часть просто видишь, что человек решал какие-то проблемы, имеет какой-то опыт, но вот не сеньор он, нет в его словах, мыслях и подходах этого, как бы он правильно не отвечал на вопросы.
Ну а уже по ответам и соответствию заявленного опыта и роли действительности можно принимать решения, подходит кандидат в проект или нет. Но опять же, не каждый кандидат со 100% правильных ответов должен проходить и не каждый кандидат с заметной долей ошибок или незнания должен отсекаться.
Ну а уже по ответам и соответствию заявленного опыта и роли действительности можно принимать решения, подходит кандидат в проект или нет. Но опять же, не каждый кандидат со 100% правильных ответов должен проходить и не каждый кандидат с заметной долей ошибок или незнания должен отсекаться.
Два года назад человек собеседовал соискателей. При этом он отслужил в армии и успел поучиться в институте. Сейчас ему 24.
Ну… Ладно. Просто интересно, как и почему вы стали собеседующим? Кем вы были в тот момент в компании?
Ну… Ладно. Просто интересно, как и почему вы стали собеседующим? Кем вы были в тот момент в компании?
Может, это просто моя деформация после работы в Германии, но я считаю что тут просто факап компании, которая вообще допустила такого человека до собеседований. Молодой задр… гик, с какими-то своими тараканами в голове, какими-то идеалами и ещё не решенными комплексами — и его выставлять как (единственное?) лицо компании на собеседование. Игнорировать, что он валит всех подряд и гордится этим, зачем-то приглашать его собеседовать в другие отделы (зачем, там же работают другие люди!), после чего удивляться «чего это кадров не хватает», но не предпринимать никаких шагов для исправления ситуации. Однозначный факап руководства, желаю им теперь удачи в исправлении репутации фирмы после всех отзывов, которые им оставили те 100 человек.
Автор признает проблему и вроде как даже пытается исправиться но то, что он написал в конце показывает, что нет, нефига, нельзя его допускать до работы с людьми — пусть и дальше ковыряет свой джаваскрипт, возможно он хороший специалист, возможно он может проектировать хорошие системы и его надо просто вернуть на эту работу с повышением зарплаты (чтоб не обиделся), но для работы с людьми (тимлид/собеседования) он просто не годится.
Автор признает проблему и вроде как даже пытается исправиться но то, что он написал в конце показывает, что нет, нефига, нельзя его допускать до работы с людьми — пусть и дальше ковыряет свой джаваскрипт, возможно он хороший специалист, возможно он может проектировать хорошие системы и его надо просто вернуть на эту работу с повышением зарплаты (чтоб не обиделся), но для работы с людьми (тимлид/собеседования) он просто не годится.
Кстати, возможно, это тоже мне так подвезло, но заметил, что в Германии больше опытных работников на более ответственных должностях, да и в 30 лет поступать в магистратуру там в норме, уж не знаю, правильно это либо нет, не берусь судить.
Мой первый собес в Германии как был как раз с таким вот человеком (привет Personio). Я поначалу даже свою самооценку уронил. Вроде ж Европа. Вроде же культур-мультур и толерантность. А тут мне: There're 3 errors, show me them. А на деле практически все "ошибки" были либо незнакомыми человеку понятиями, либо вкусовщиной, либо просто незнанием матчасти.
Что значит «не годится»? Может ему надо подучиться?
Вот мне собеседования в Германии нравятся сильно больше собеседований в России. Нет ощущения, что тебя пытаются завалить, с тобой просто разговаривают о твоем опытe.
Сейчас собираюсь менять работу и получил очень хороший оффер на сеньора (сейчас я миддл), при этом мне не задали ни одного сложного вопроса по нюансам. И собеседования были очень комфортными, в формате диалога, а не вопрос-ответ.
Сейчас собираюсь менять работу и получил очень хороший оффер на сеньора (сейчас я миддл), при этом мне не задали ни одного сложного вопроса по нюансам. И собеседования были очень комфортными, в формате диалога, а не вопрос-ответ.
Вот тут субъективно я не уверен, что хуже. Когда тебе отказывают после того, как ты не решил какую-то заковыристую задачу, то в принципе понятно, почему отказали, и куда расти (даже если расти в ту сторону и не особо хочется). А отказ после «собеседования-разговора» всегда оставляет некоторое недоумение: я что, как-то не так разговариваю?
Один раз я прошел в компании всю техническую часть, и мне тимлид сказал, что тестовое задание я выполнил лучше остальных кандидатов. После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
Один раз я прошел в компании всю техническую часть, и мне тимлид сказал, что тестовое задание я выполнил лучше остальных кандидатов. После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
Надо было не много думать, а много радоваться, что не вышли на работу в компанию, которая устраивает такие «culture interview».
Как бы вы изменили мир, обладая неограниченными возможностями?
Варианты «вернулся бы назад во времени, чтобы не проходить это интервью» и «уменьшил количество тестов, выглядящих бесполезными» были правильными или нет?
Вам разве в вашей Германии не попадались токсичные люди, проводящие собеседования? Мне попадались, и ещё как. Но это было давно…
Скорее всего он был супер работягой и мог спокойно по 10 часов в день сам решать задачи отдела, проблемы решаются начальство не интересует как для них наоборот збс что денег не требуют на людей, а он наоборот приходил виноватый что никого не взяли ну ладно сам всё сделаю.
JavaScript implicit conversion Expert.
Просто интересно, как и почему вы стали собеседующим? Кем вы были в тот момент в компании?хмм… я на 5м курсе (в армии не служил) стал сходить на собеседования вместе с моим ПМом — она задавала общие вопросы, а я — технические.
А что именно вас удивляет? Человек собеседует себе будущих коллег, так что какие могут быть еще варианты?
По приблизительным оценкам, человек имеет за плечами два года опыта, возможно меньше. Проводить техническое собеседование должен кто-то из технических специалистов высокого уровня.
И вовсе не из за каких-то эфемерных регалий. На собеседовании не надо оценивать умение сортировать массивы, надо понять, насколько человек знаком с основными технологиями проекта и рабочими инструментами, понимать направление развития, понимать в какой области навыков команду надо усилить и на какую можно не обращать внимания.
Удивляет меня то, что человек с двумя годами опыта в компании является одним из таких людей. Это возможно, но выглядит крайне странно.
И вовсе не из за каких-то эфемерных регалий. На собеседовании не надо оценивать умение сортировать массивы, надо понять, насколько человек знаком с основными технологиями проекта и рабочими инструментами, понимать направление развития, понимать в какой области навыков команду надо усилить и на какую можно не обращать внимания.
Удивляет меня то, что человек с двумя годами опыта в компании является одним из таких людей. Это возможно, но выглядит крайне странно.
Проводить техническое собеседование должен кто-то из технических специалистов высокого уровня.ну, вот он и был тем специалистом высокого уровня.
Про себя — на тот момент, мы только-только внедрили одну систему со своим внутренним языком и ИДЕ (язык похож на питон и яву). Так что никого более продвинутого по ней не было во всей компании (хотя там были огого спецы по С++, Ява ЕЕ и т.д.)
Я искренне хочу верить в ваш сарказм, но как-то не получается. Ну ладно, буду считать нормой пятнадцатилетних капитанов двухгодовалых сеньоров.
А причём тут сеньоры? Вот взяли вас джуном куда-то, где нет ни сеньоров, ни миддлов. Ну или один миддл есть, но он уволился, порекомендовав вас на своё место тимлида. Откажетесь от позиции тимлида? Или от позиции нет, но собеседовать людей откажетесь к себе в команду?
Точно. Синьор — это же годами опыта измеряется.
Вы вообще никакого когнитивного искажения не видите? Нет, ну вот правда, почему вы считаете, что человек с двумя годами опыта считающийся сеньором это нормально? Да за это время квалификационный разряд повара не факт что повысят.
Но, впрочем воля ваша. Я сплю крепко даже если в интернете кто-то не прав.
Но, впрочем воля ваша. Я сплю крепко даже если в интернете кто-то не прав.
del
я видел людей с одним годом работы, но которые были поумнее и попрактичнее и поработоспособнее (не работоголичнее!) иных с «5 лет опыта».
Поэтому у меня свое когнитивное искажение в работе и на собеседованиях: я больше всего ценю скорость и гибкость мышления.
Поэтому у меня свое когнитивное искажение в работе и на собеседованиях: я больше всего ценю скорость и гибкость мышления.
Лично знаю человека, который за два года работы от малоопытного вчерашнего джуна стал не просто сеньором, а пишущим проджектлидом, достаточно уважаемым в своих кругах. Вопрос не чистого времени же.
1. Проджектлид это совсем другая профессия и проджектлид может не уметь программировать или программировать на уровне мидла или уверенного джуна (если он «пишущий»). Его функции совсем другие и больше менеджерские (если вы не навешиваете ему дополнительно роли архитектора или технического лида),
2. Время все-таки важно. Да, есть те кто и за десять лет остался джуном, но есть определенный опыт, который нельзя просто выучить, как нельзя научится водить профессонально машину только уча теорию и за десяток уроков в автошколе — тоже. Я бы сказал, что нужно 3-5 лет, чтобы стать действительно опытным разработчиком,
3. Во многих фирмах уровень старшего разработчика дают тем кто даже не стал уверенным джуном, поэтому часто сеньоры весьма дутые,
2. Время все-таки важно. Да, есть те кто и за десять лет остался джуном, но есть определенный опыт, который нельзя просто выучить, как нельзя научится водить профессонально машину только уча теорию и за десяток уроков в автошколе — тоже. Я бы сказал, что нужно 3-5 лет, чтобы стать действительно опытным разработчиком,
3. Во многих фирмах уровень старшего разработчика дают тем кто даже не стал уверенным джуном, поэтому часто сеньоры весьма дутые,
Не ну программисты это другое дело, тут очень большой % по сравнению с другими, людей который просто живут своей профессией, буквально пишут код на работе, идут домой пишут код отдыхают, не потому что они такие упорные рокки а просто потому, что в кайф.
А я в школе пять лет на уроках труда пилил деревяшки, поэтому я высококвалифицированный столяр-краснодеревщик.
Научитесь читать внимательно. Сейчас автору 24, два года назад он проводил собеседования. 24 — 2 = 22. Вряд ли он в армии программировал, да и первый курс этому не особо способствует.
Определённо есть выдающиеся разработчики и в 18 лет, но никак не могу понять, почему вот уже шесть человек на серьёзных щах пытаются доказывать что это норма.
Научитесь читать внимательно. Сейчас автору 24, два года назад он проводил собеседования. 24 — 2 = 22. Вряд ли он в армии программировал, да и первый курс этому не особо способствует.
Определённо есть выдающиеся разработчики и в 18 лет, но никак не могу понять, почему вот уже шесть человек на серьёзных щах пытаются доказывать что это норма.
Ну вот у нас в компании директор говорит набирать только джуниоров. А новых джуниоров надо кому-то собеседовать. Эйчар во всем этом не шарит. Вот и достаются собеседования джунам…
Стоит признать, что сейчас все нормальные кандидаты (миддлы за вменяемые деньги, например) высосаны с рынка известными всем авитами, смузи банками и прочими популярными компаниями.
Как результат — по собеседованиям ходят в основном джуны, либо люди лишенные всякой тяги к саморазвитию и расширению кругозора. Поэтому они никому особо и не нужны.
И вполне может оказаться что 100 интервью были проведены с такими же людьми как (похоже и сам) автор.
И да, знание одного лишь JavaScript еще не делает вас программистом.
Как результат — по собеседованиям ходят в основном джуны, либо люди лишенные всякой тяги к саморазвитию и расширению кругозора. Поэтому они никому особо и не нужны.
И вполне может оказаться что 100 интервью были проведены с такими же людьми как (похоже и сам) автор.
И да, знание одного лишь JavaScript еще не делает вас программистом.
Знание любого из языков программирования не делает вас программистом.
Стоит признать, что сейчас все нормальные кандидаты (миддлы за вменяемые деньги, например) высосаны с рынка известными всем авитами, смузи банками и прочими популярными компаниями.
Как результат — по собеседованиям ходят в основном джуны...
Никто не мешает перетягивать людей из других компаний, но вообще опытные программисты тоже ходят на собеседования, возможно, тут дело не в них, а в вашей вакансии?
ну я еще добавил бы требование скоростьи печати на английском языке к программистам. Нормальный уровень программирования это около 300 строк в 2 часа осознанного текста.
«Senior frontend developer» с кратким опытом по технологиям: JS: 1 год, React: 4 месяца, Ruby (on Rails): 2 года".
Я программист, осознавший едва,
Всю суть программистских контор.
Я мидл опять в свои двадцать два,
А в двадцать один был сеньор.
(с) graninas
Нафига собеседовать рубистов если в компании нет руби в стеке?!
Так собеседовали-то, судя по всему, на JS-позицию. Если у человека есть проекты на технологии, не требуемой для вакансии, то все равно что плохого в том, чтобы их продемонстрировать? Тем более, если собеседующий сам этим заинтересовался.
Ну вот захотел рубист стек сменить, или теперь технология однажды выбранная это клеймо на всю жизнь?
И передается по наследству от отца к сыну.
Все рубисты с которыми мне приходилось работать отличались высокой работоспособностью и постоянным желанием все переписать с нуля. Они любили пилить новые архитектуры, использовать всякие хайповые штуки и делать инструменты для инструментов. В тот момент, когда проект начинал шататься под грудой новшеств и несовместимых архитектурных решений, эти рубистры быстро и незаметно сваливали в другое место. Так что да, в моем случае, в какой-то степени это клеймо. Хотя наверное Руби тут вторичен.
25 лет — это и есть возраст, когда мозг завершает свое развитие. Автор просто повзрослел и набрался жизненного опыта…
Вообще это прекрасный результат — «мудрость приходит с годами, но иногда годы приходят в одиночестве». Тут человеку повезло, да. Отличный возраст, впереди много лет для работы и творчества.
Вообще это прекрасный результат — «мудрость приходит с годами, но иногда годы приходят в одиночестве». Тут человеку повезло, да. Отличный возраст, впереди много лет для работы и творчества.
- Это совсем «немного» спорно.
- Даже если мозг перестаёт «улучшаться», не перестают оттачиваться профессиональные навыки.
Так что 25 это не вершина, это самое начало профессионального пути.
И будет как в университете у «профессоров»:
На 5 знает бог, на 4 знаю я, а кандидат максимум на 3. Конкретно этот на 2 — он даже не знает «Почему NaN имеет тип числа»
Серебряной пули найма не существует. Решение о найме в любом случае принимает тот кто будет платить нанятому. Когда бизнес хочет делегировать вопрос найма, он ищет конкретного человека, а не случайного сеньора. И если такой человек окажется сеньором, то фраза "«Сеньоры» не должны принимать решение… " дает противоречие.
На 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)
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, и что никто из ранее нанимавших не пожалел. Точнее, это обычно никого не интересует.
работать хочешь и любишь, и учишься быстро, и готов впитывать как губка 24/7, и что никто из ранее нанимавших не пожалел. Точнее, это обычно никого не интересует.э! Обычно — это «много», но не «все поголовно».
Вот когда я собеседовал лет 10 тому назад, то мы смотрели как раз на характеристики «учится быстро» — я до сих пор вспоминаю, как мы смогли нанять к себе в отдел одну девушку с радиофиза (хотя потом она все равно ушла от нас в РубиГерлз :) ), так она тогда вообще не умела программировать, зато алгоритмы схватывала — токо в путь. Эх!
Очень хороший подход, по-моему, с «что знаешь из этого списка?»
в целом да, но, как мне кажется, не в этом конкретном случае.
Там были общие теоретические понятия, которые в этой области используются не часто. Если знания не системные, а прикладные, то тут подобный подход ничего не покажет. Кроме того, спустя пару дней я уже и эти понятия заботала, и могла бы рассказать лучше, но явно не на собесе сразу.
Лично я апологет ситуативного подхода, когда смотрят как человек мыслит, есть ли логика, понятие о необходимости предусмотреть косяки и т.д., а спрашивать теорию я бы не стала. Но никому не навязываю
Там были общие теоретические понятия, которые в этой области используются не часто. Если знания не системные, а прикладные, то тут подобный подход ничего не покажет. Кроме того, спустя пару дней я уже и эти понятия заботала, и могла бы рассказать лучше, но явно не на собесе сразу.
Лично я апологет ситуативного подхода, когда смотрят как человек мыслит, есть ли логика, понятие о необходимости предусмотреть косяки и т.д., а спрашивать теорию я бы не стала. Но никому не навязываю
Подобные вопросы позволяют определить кругозор и интересы человека в предметной или профессиональной области, а также определить набор тем для дальнейшего общения.
Решающими ответы не должны быть в общем случае, но «будет большим плюсом» вполне.
И вообще совет: не относитесь к собеседованию как к экзамену, даже если ему явно стараются придать такую форму.
Решающими ответы не должны быть в общем случае, но «будет большим плюсом» вполне.
И вообще совет: не относитесь к собеседованию как к экзамену, даже если ему явно стараются придать такую форму.
Спасибо за статью! Недавно тоже пришел к этой мысли. Интересно было бы посмотреть на результаты Ваших экспериментов. Очень буду рад почитать такую статью.)
Еще подумал, что возможно HR-у хорошо бы собирать у кандидатов фидбек по результатом собеседования, чтобы понимать, что им понравилось, что не понравилось в процессе. А то недавно ходил на собеседование, так один из интервьюеров уткнулся в телефон, и пока я отвечал на вопросы в тесте, он глядя в телефон смеялся, периодически переводя на меня взгляд. Возможно смеялся с мемасов, но, блин, это же жутко неприятно. Спасибо второму интервьюеру, с которым мы вполне хорошо общались в этот момент. Мне кажется, что если бы был фидбек, то человеку хотя бы поведение скорректировали. А так он и будет возможно продолжать такой фигнёй страдать.
Еще подумал, что возможно HR-у хорошо бы собирать у кандидатов фидбек по результатом собеседования, чтобы понимать, что им понравилось, что не понравилось в процессе. А то недавно ходил на собеседование, так один из интервьюеров уткнулся в телефон, и пока я отвечал на вопросы в тесте, он глядя в телефон смеялся, периодически переводя на меня взгляд. Возможно смеялся с мемасов, но, блин, это же жутко неприятно. Спасибо второму интервьюеру, с которым мы вполне хорошо общались в этот момент. Мне кажется, что если бы был фидбек, то человеку хотя бы поведение скорректировали. А так он и будет возможно продолжать такой фигнёй страдать.
Проверить нужно мотивацию и то что тебе действительно интересно заниматься инженерным делом, остальное дело наживное.
Видел подобное, только в тестировании. И отсутствие подготовки к встрече, задавание вопросов из готового списка, при чем в течение 2х и более часов. Бывало, что вместе с 2-3 командами одновременно искали примерно одного уровня кандидата и вместе делали ревью тестового задания. Формулировки отказа по заданию были всякой степени абсурдности, включая «вроде все ок, но оформление не очень». И по тому же тз «понимали» каков человек как личность. Я смотрел на это и видел преподов из универа, которым главное соблюсти все их стариковские стандарты, а не качество работы. Что забавно, ведь собеседующие — сами вчерашние студенты.
Так что согласен и про «завалить» и про «становимся теми, от кого настрадались».
Хорошо, если с опытом начинают глаза открываться, как у автора.
Так что согласен и про «завалить» и про «становимся теми, от кого настрадались».
Хорошо, если с опытом начинают глаза открываться, как у автора.
Прошел похожий путь в плане проведения собеседований как и автор. И тоже пришел к выводу, что можно брать почти любого. Научить можно всему.
Я связываю это с тем, что почти любая технология стала гораздо доступней, чем 5-10 лет назад. Отдельные технологии оформились во фреймворки, в которых пару строк кода и готово, по другим написали более удачные книги. Третьи технологии перешли на другой стэк, более понятный людями и намного легче осваиваемый.
Потому в современном собеседовании не особо важны знания тех или иных узких мест. Просто кандидат должен быть адекватным и стремиться к развитию. А уж как определить, обладает ли кандидат этими чертами, совсем другая история.
Я связываю это с тем, что почти любая технология стала гораздо доступней, чем 5-10 лет назад. Отдельные технологии оформились во фреймворки, в которых пару строк кода и готово, по другим написали более удачные книги. Третьи технологии перешли на другой стэк, более понятный людями и намного легче осваиваемый.
Потому в современном собеседовании не особо важны знания тех или иных узких мест. Просто кандидат должен быть адекватным и стремиться к развитию. А уж как определить, обладает ли кандидат этими чертами, совсем другая история.
У меня в чём-то похожая история, но с другими выводами.
Я тоже провёл сотни собеседований и брал действительно примерно 4-х из сотни.
И один раз я поддался напору кандидата, который не прошел собеседование, но был очень активен, присылал попытки разбора заданий.
В итоге те 4, которые прошли собеседования — прекрасные специалисты, я просто счастлив, что позвал их.
И ещё я мучаюсь с тем «активным», потому что он работает в разы медленнее, косячит в разы больше, и вся его активность куда-то пропала после найма.
Поэтому, лучше я откажу хорошему кандидату — он с лёгкостью устроится в другую контору, чем возьму фигового и не буду знать, что с ним делать.
Я тоже провёл сотни собеседований и брал действительно примерно 4-х из сотни.
И один раз я поддался напору кандидата, который не прошел собеседование, но был очень активен, присылал попытки разбора заданий.
В итоге те 4, которые прошли собеседования — прекрасные специалисты, я просто счастлив, что позвал их.
И ещё я мучаюсь с тем «активным», потому что он работает в разы медленнее, косячит в разы больше, и вся его активность куда-то пропала после найма.
Поэтому, лучше я откажу хорошему кандидату — он с лёгкостью устроится в другую контору, чем возьму фигового и не буду знать, что с ним делать.
ну автор конечно дикий троль и мразота-редкосная… если по резюме видно, что опыта нет, то чего мучать себя и работника? Вы не пробовали приглашать на собеседования людей с опытом работы и с портфолио, чтобы не мучать невинных вопросами? с другой стороны нужно быть очень толстым тролем чтобы потратить 100 собеседований с результатом в 0. 100 собеседований это почти 2.5 недели (с собеседованием по 1 часу). По мойму тебе просто в армии отбили голову… что так плохо начал время проводить… Как вообще дали задание человеку без высшего образования подбирать персона?
Высшее образование вообще не показатель адекватности человека. Даже больше, люди с высшим образованием часто считают что они выше чем люди без вышки. Это глупость полная.
Ну и образование образованию — рознь. Кто-то MIT заканчивает, а кто-то филиал не очень хорошего университета в русской глубинке. Равнять двух этих людей по навыкам после получения образования никак нельзя.
Ну и образование образованию — рознь. Кто-то MIT заканчивает, а кто-то филиал не очень хорошего университета в русской глубинке. Равнять двух этих людей по навыкам после получения образования никак нельзя.
У меня в компании высшее образование есть только у половины сотрудников, но в своей сфере они могут дать фору любому спецу того же возраста. Пока одни получали высшее образование и изучали всякую психологию и педагогику с риторикой на технических специальностях ВУЗов, мои коллеги получали опыт и набивали свои шишки в профессии. Это несомненный плюс для людей без высшего образования.
Я как дипломированный специалист работаю от силы 2 ч. в неделю, а в остальное время смотрю видео в нете и читаю посты на хабре. Так и проходит моя 40 часовая неделя. Думаю что без образования чувак на моем месте косячил бы как черт. При этом что зарплату выплачивают за весь месяц. Меня даже не раздражают минусы к коментариям на хабре.
без высшего образования в нашей стране можно только курьером работать и в армии служить. Кругозор с вышкой колосален, я сам как дипломированный специалист могу рассуждать о высших материях на достаточно высоком уровне. А людей без вышки легко обвести вокруг пальца всякими новыми технологиями которые уже 100 лет в обед давно известны.
Кругозор с вышкой колосален
Ага, особенно у ребят, которые раз в семестр конверт заносят в деканат, а потом приходят за дипломом.
А откуда взять бабло студенту?
Вы так говорите, как будто в университетах нет людей с богатыми родителями.
У меня однокурсники катались на машинах за несколько миллионов рублей. Были даже люди с ягуарами (машина, не животное).
У меня однокурсники катались на машинах за несколько миллионов рублей. Были даже люди с ягуарами (машина, не животное).
Работая, разумеется. Это ж только в вашей вселенной без вышки можно только курьером работать и в армии служить. В моей — вполне успешно устраиваются работать, пусть даже менеджером по менеджерству в ООО Вектор, а универ — чтобы не служить. Сумма в конвертике даже близко не астрономическая, за полгода отлично копится.
это настолько жирно и глупо, что я даже спорить не буду. удачи с таким взглядом на мир.
sarcasm mode?
Кругозор с вышкой колосален
Судя по написанию последнего слова, с кругозором вышла заминочка. :D
Отличная логика! Люди без высшего образования косячат потому что высшее образование требуют работодатели… Даже если это вдруг правда — вы перепутали причину и следствие.
А реально лично я за 5 лет учёбы изучил всего 1 полезный предмет (сети ЭВМ) и 2 интересных (теория автоматов и электроника). Лучше бы я 3 учебника за 3 для прочитал и пошёл сразу же работать.
А реально лично я за 5 лет учёбы изучил всего 1 полезный предмет (сети ЭВМ) и 2 интересных (теория автоматов и электроника). Лучше бы я 3 учебника за 3 для прочитал и пошёл сразу же работать.
Вот еще пример. Я живу в Королеве, и там одни заводы… Без высшего образования можно поработать техником. С высшим образованием можно поработать инженером с профессиональным уклоном. Зарплаты разительно отличаются, а работа почти одна и таже — сидеть. Может раз в неделю что-то из работы и перепадет… Но без высшего образования — работа за еду. Плюс на королевских заводах не все высшее образование котируется. Там больше РКТ нужно, а все остальное они отсылают лесом. Конечно можно устроится и на вакансию без высшего образования… скажем повором или грузчиком. Но там в РКК Энергия больше средне профессиональное образование рулит. и зарплаты от 35 т.р.(просматривал вакансии 21.02.2019).
Очень интересная статья и интересный опыт.
Мне тоже приходится искать и собеседовать специалистов. У нас небольшая ИТ компания и основная потребность в сотрудниках технической поддержки и системных администраторах. Учитывая, что у нас нет отдельного HR, да и знаний о том, как нанимать людей у меня не было, я сразу начал применять беседу как способ узнать о человеке (возможно, тут сыграла моя лень, мне было лениво составлять универсальный список вопросов для теста), о его способах мыслить и о том, насколько он хорошо разбирается в тех технологиях, которые описаны у него в резюме.
И вот, компании уже 5 лет, и я ни разу не пожалел о том, что именно так нанимал людей.
З.Ы. поделился своей историей в комментах, возможно, для кого-то она станет дополнительным стимулом изменить свои подходы к найму людей.
Мне тоже приходится искать и собеседовать специалистов. У нас небольшая ИТ компания и основная потребность в сотрудниках технической поддержки и системных администраторах. Учитывая, что у нас нет отдельного HR, да и знаний о том, как нанимать людей у меня не было, я сразу начал применять беседу как способ узнать о человеке (возможно, тут сыграла моя лень, мне было лениво составлять универсальный список вопросов для теста), о его способах мыслить и о том, насколько он хорошо разбирается в тех технологиях, которые описаны у него в резюме.
И вот, компании уже 5 лет, и я ни разу не пожалел о том, что именно так нанимал людей.
З.Ы. поделился своей историей в комментах, возможно, для кого-то она станет дополнительным стимулом изменить свои подходы к найму людей.
Я пытался писать на рубях когда-то, но меня стало тошнить.
использовали бездушное, что-то вроде C# или Java
Подпись:
Senior Frontend Developer
Вы уверены, что вы сениор? Просто сениор подразумевает некоторую ментальную зрелость. Даже в качестве провокации такие вещи сениору не придут в голову в принципе.
Хотя в нашем мире девальвированных погон…
Кстати, а почему некоторые так любят сортировку пузырьком. Если нужно костыль писать для сортироки 10 элементов, то пузырьком писать дольше, чем выбором наибольшего элемента. А если по нормальному(и нет встроенной функции), то надо применять быструю сортировку, алгоритм которой можно посмотреть по гуглу.
Просто проверяют, что кандидат умеет писать реализации для известных алгоритмов. Сортировка пузырьком тут является примером достаточно простого и известного алгоритма (ну или считается таковой).
Да, тем более его очень просто рассказать на словах:
берем центральный элемент, все элементы, которые меньше — заносим в массив А, все элементы, которые больше в массив Б, а потом делаем
В отличии от пузырька, который описать сложнее, как мне кажется.
берем центральный элемент, все элементы, которые меньше — заносим в массив А, все элементы, которые больше в массив Б, а потом делаем
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 и почему это плохо. И так далее.
Это нужно, чтобы понять, знает ли человек, чем отличается 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 и отдельно копировать конец одной пловины, если вторая кончилась, но это на сложность алгоритма не влияет.
> И в этом разговоре мы бы неминуемо пришли бы к тому, что худший случай у квиксорта O(n^2) всегда.
Нет. См. ниже.
> Почему же его вообще тогда используют вместо того же 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 раза медленнее.
Нет. См. ниже.
> Почему же его вообще тогда используют вместо того же 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 на списках в ФП стиле как-то вредно), поэтому я в эту сторону и не смотрел. Для связных списков, да, больше смотрят в сторону слияний (ну или переделывают их таки в массив и сортируют уже массив, это уже где как удобнее). Тут ещё зависит от возможностей доступного ФП. В 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 раза продублируются.
Но, все-равно, это бесполезное упражнение. Квиксорт не используют для иммутабельных контейнеров, потому что есть более быстрые и практичные алгоритмы. Единственная ниша для квиксорта — сортировка массива на месте.
Ох, да, тут вы правы, я ошибся с gte. Просто хотел уже закончить этот код:
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)))
);
}Ну уж как есть. JS вообще очень плохо для ФП подходит. А как бы выглядело читаемо на другом языке?
Опять Хаскель? А как же запрет?
Количество пар элементов, стоящих в неправильном порядке (неважно, подряд или нет), уменьшается с каждой заменой на единицу (все остальные элементы относительно двух заменённых как стояли, так и стоят, а эти два встали правильно). Пока хотя бы два стоят неправильно — замены будут происходить, потому что будет хотя бы два стоящих неправильно рядом (в силу того, что ключи должны образовывать линейный порядок — иначе о сортировке вообще говорить странно). Это будет считаться достаточным доказательством (для собеседования, конечно, не для экзамена)?
Логичнее, наверное, требовать, чтобы для стоящих рядом выполнялась принадлежность отношению, иначе, к примеру, в Вашем случае список (a, c, a) и даже (c, a, c) будет отсортирован, что довольно странно (почему бы одному и тому же ключу стоять и до, и после другого, если у нас есть хоть какое-то разумное понимание порядка?) Другой вопрос, что тогда будут существовать несортируемые списки (как раз два приведённых мной примера), но это, имхо, меньшее зло, если уж мы берём в качестве «порядка» отношение, которое порядком не является.
Для порядков без транзитивности задача о сортировке списка является альтернативной формулировкой задачи о гамильтоновом пути в графе.
Она решаема, но я бы дважды подумал прежде чем решать чтобы то ни было через поиск гамильтонова пути :-)
Она решаема, но я бы дважды подумал прежде чем решать чтобы то ни было через поиск гамильтонова пути :-)
А теперь докажите, что эта процедура завершится.
Количество инверсий в массиве после каждого свопа уменьшается на 1. Количество инверсий изначально — конечно (меньше n^2). В итоге будет выполнено только конечное количество свопов.
В квиксорте всё очевидно только при работе с иммутабельными структурами данных. При работе с мутабельными массивами есть несколько различных алгоритмов разбиения, и ни один из них не является простым.
Кстати, интересно, может ли достаточно умный компилятор свернуть каноничный ФП-недоквиксорт в инплейс-сортировку. Линейные типы там какие-нибудь, хз.
Никак, только если конкретно этот случай разработчики компилятора не захардкодили.
Не надо хардкодить сортировку, достаточно выразительных систем типов, как всегда.
Вообще не в этом проблема. Ладно, даже если компилятор поймет, что вместе вызываются filter(gt), filter(lt) и filter(eq), и больше нигде не используется исходный массив, он не может заменить это на процедуру разбиения, потому что она не стабильная, а фильтры эти — стабильны. Другого метода получить меньше, равно, больше в массиве на месте — нет (пока не придумали, по крайней мере).
Но до этой фундаментальной проблемы, надо еще как-то понять, что эти несколько вызовов filter, можно сделать вместе. Иначе нельзя выкинуть первый и переиспользовать исходный массив, ведь этот же самый массив используется во втором фильтре. Т.е. нужно именно что захардкодить этот конкретный случай.
хорошая статья
Имхо, лучший способ проверить человека — дать ему небольшое тестовое, на несколько часов, с задачей приближенной к рабочей. И всё сразу становится на свои места.
Мы на старой работе собирали вопросы с собеседований, и часто спрашивают очень странные вещи, которые никак к реальной работе не относятся.
Мы на старой работе собирали вопросы с собеседований, и часто спрашивают очень странные вещи, которые никак к реальной работе не относятся.
Еще на работу не взяли уже заставляют работать, я к тому что задачи все таки должны быть чтобы потом нельзя было применить хотя бы.
я написал приближенной к рабочей, и 2-3 часа вполне разумный срок. На самом деле большинство кандидатов отваливается, ибо они не хотят напрягаться. И это очень круто, потому-что зачем нужен сотрудник который не хочет напрягаться. На данный момент все сотрудники которых приняли с нормальным тз — не разочаровывали.
Почему они должны быть такими, чтобы нельзя было применить?
«Даже мысль не проскакивала, что я могу быть мудаком сам» — квинтэссенция статьи.
Seriously, синдром инженера — это ужасная вещь. Educated fools.
Многие айтишники мечтают построить новый дивный мир, управляемый такими же айтишниками. Но мне кажется, это будет ад а не рай.
«Моя точка зрения самая верная», уверенность в понимании всего в мире, «если я чего-то не хочу значит это не надо никому », проблемы с эмпатией, да много чего еще. Прямо золотой набор предпосылок тирании и антиутопии.
Seriously, синдром инженера — это ужасная вещь. Educated fools.
Многие айтишники мечтают построить новый дивный мир, управляемый такими же айтишниками. Но мне кажется, это будет ад а не рай.
«Моя точка зрения самая верная», уверенность в понимании всего в мире, «если я чего-то не хочу значит это не надо никому », проблемы с эмпатией, да много чего еще. Прямо золотой набор предпосылок тирании и антиутопии.
Что-то Ваш взгляд на таких айтишников напомнил мне взгляд Ортеги на «массового человека». Хотя возможно Вы к нему и ссылаетесь.
Не могу, к сожалению, продолжить вашу мысль — понятия не имею кто такой Ортега :)
Хосе Ортега-и-Гассет, если быть точным. В кратце: частично он говорил, что чем больше человек образован в своей специализации, тем меньше он понимает принципы функционирования общества, перестает с ними считаться и начинает судить обо всем на свете с помощью своей специализации. Тут чуть подробнее, если вдруг стало интересно.
Возможно, сейчас меня занесет в полную противоположность — но будь моя воля, я бы может брал вообще всех, кто хочет работать.Еще к этому стоит добавить адекватность.
Собеседование с вопросами, про какие-то лютые тонкости — поршлый век. Доступность информации на порядок выше и на первый план выходит способность идентифицировать и решать проблемы оптимальным способом. Эксперты нужны, но каждый разработчик не должен быть экспертом.
При собеседовании меня скорее интересует путь решения проблемы, а не конечный вариант. Условия могут измениться, требований, технологии. Сегодня ты пишешь на C#, завтра надо написать под iOS или Android. И вопрос не в том, что знаешь или нет, а за сколько узнаешь.
Или взять любой проект, хорошего кода видел мало, зато тех, кого нанимали знали и про GC и про таблицу виртуальных методов и т.д. Что толку с того, что человек досканально знает как процессор параллелит на конвеере инструкции, если ему наплевать на успешность проекта. Знание технических тонкостей не делает проект успешным, проект успешен тогда, когда люди стремятся идентифицировать узкое место и его улучшить и именно таким способом получаешь знание и опыт по месту.
А теоретическое запоминание материала напоминает плюшкина, который собирает все, а применяет лишь небольшую долю, КПД такого работника не высоко, потому, что он получает информацию, которая не решает его проблему.
Очередное доказательство, что жизнь несправедлива. Холиварную статью из разряда дневники красной туфельки заплюсовали нещадно. Информативные статьи, которые стоили труда и приносят пользу наберут пару десятков плюсов.
you ARE arrogant and stupid
С уважением ваш grammar nazi
С уважением, Ваш grammar nazi
В — большая, когда речь идет об уважительном отношении, а не множественном числе. И очень круто смотриться с запятой.
Я специально оставил там мягкий знак, чтобы Вы могли мне отомстить и не считали себя должником.
В — большая, когда речь идет об уважительном отношении, а не множественном числе. И очень круто смотриться с запятой.
век живи — век учись.
Ну а по поводу запятой, гуглил, кто-то пишет, что писать надо, а кто-то нет.
Вот этот источник, в принципе, можно считать авторитетным. А вот тут очень хорошо объяснена причина:
В русской грамматике правила постановки запятой после фразы «с уважением» и подписью автора письма не ставилась.
Сейчас сложилась традиция, что после «с уважением» запятая ставится обязательно, потому что при чтении на месте запятой интонационно просится пауза.
Есть две крайности у ит людей, или чсв или «синдром самозванца».
Может быть молодой человек не оканчивал вуз и сразу после школы пошёл работать, условно, 24-18 = 6 лет опыта без малого, можно и лычку сеньора получить, особенно если опыт набирался не в шаражкиных конторах и все нужные скиллы с талантом на месте.
..
Сам я тоже скептически к этому отношусь.
По поводу сложности интервью — бывают и другие случаи. Пару недель назад проходил pre-interview screening у хедхантеров, позиция — Senior PHP Developer. Дали 50 минут и 6 задач. Без шуток:
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 — не знаю, но вилка зарплат вроде подходит. Завтра интервью, беспокоюсь, что еще спросят.
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 — не знаю, но вилка зарплат вроде подходит. Завтра интервью, беспокоюсь, что еще спросят.
Большинство тех, кто приходит на собеседование на Senior слились бы ещё на первой задаче. Говорю как человек, который провел десятки собеседований в ВГ.
А на что эти люди рассчитывают?
На софт скилс и отсутствие нормального технического интервью (либо на вопросы из сборника тысяча вопросов при собеседовании php программиста), разумеется.
Либо банально переоценивают свои навыки, часто бывает рисовал пару лет простейшие html страницы с минимумом php на первой работе, получал вместо повышений звания мидла и синьора, а потом приходит на собеседование, уверенный, что он крут и все может, а там не может написать ничего внятного.
Либо банально переоценивают свои навыки, часто бывает рисовал пару лет простейшие html страницы с минимумом php на первой работе, получал вместо повышений звания мидла и синьора, а потом приходит на собеседование, уверенный, что он крут и все может, а там не может написать ничего внятного.
А, я что то про утрирование не подумал. Просто не могу себе представить в реальности здорового человека который не может именно первую задачу решить. Впрочем все три первых задачи достаточно элементарные и даже к программированию отношения не имеют, достаточно школьных знаний, но первая то по моему вообще из младших классов.
Нет, никакого утрирования. Согласен с аргументами vedenin1980 на 100%
Впрочем все три первых задачи достаточно элементарные
Вроде да, но бывают нюансы. Если вас собеседуют на не родном языке, то 3 задача может дать жару. Говорю как человек с довольно слабым английским (Middle Intermediate), который недавно проходил много технических интервью.
А дело всё в том, что обычно требуют при этом "мыслить вслух". И я вот на себе проверил, что мыслить вслух что-то мутное (перебирать все варианты яблок\коробок\следствий) и при этом мыслить продуктивно очень сложно. Большая часть мозга вынужденно занимается построением внятных формулировок. На задачу почти ничего не остаётся. Такое чувство… отупения наступает.
Я бы столкнувшись с этой яблочно-апельсиновой задачей приуныл. Хотя с другой точки зрения, можно везде хитрить. Скажем — попросить время на подумать. И дать сразу готовый ответ.
Вообще понятия не имею. Что не собеседуют? Что смотрят только по резюме? Почему тут столько вайна: «вот, у меня резюме такое клевое, но посмели на собеседовании вопрос задать и отказали»?
Или так:
Блин, да если бы он этого не написал — я бы в жизни такого вопроса не задал! Не понимаю — неужели так сложно перед собеседованием хотя бы СВОЕ СОБСТВЕННОЕ резюме прочитать? Такое впечатление, что им просто друг клевое резюме написал.
При собеседовании на позицию геймдев не могут своими словами рассказать, как бы они написали игру Орел-Решка. Ну то есть вопрос без подвоха. Две кнопки — орел, решка, угадал-неугадал. Затык в том, что человек просто не умеет пользоваться функцией Math.random для того, чтобы с вероятностью в 50% вывести текст «орел» и с вероятностью в 50% вывести текст «решка».
Более сложные вещи типа: «Возьмите из колоды в 36 карт 6 случайных» — это у нас была самая сложная задача. Когда люди не знают как я решить — я обычно подсказываю, спрашиваю, играли ли они в Дурака и как давали людям 6 случайных карт.
Приходит человек, у него в резюме написано: имею опыт создания Highload-проектов.
У него лид спрашивает:
— В каких Highload проектах принимали участие?
— Ни в каких не принимал!
— А зачем в резюме написали?
— Все пишут — вот и я написал!
Или так:
— Расскажите, что вы знаете о Design Patterns (обычно я такие вопросы не задаю, но тут попалось на глаза)
— Эмс, ничего не знаю, а что это?
— Ну вот же, у вас третим пунктов знаний в вашем же резюме
— А, ну я просто на русском писал и переводчиком переводил, потому не знаю такого термина
— Ну хорошо, тогда что такое «Паттерны проектирования»?
— Эмс, не знаю
— Ну Сигнлтон, к примеру
— А, ну да, Сингтон
— Еще какие?
— Нуууууу…
— Фабрика?
— Да, Фабрика, знаю такое
— Ну хорошо, расскажите о Фабрике
— Ну фабрика — это… фабрика… Она создает… Ну вот, короче.
Блин, да если бы он этого не написал — я бы в жизни такого вопроса не задал! Не понимаю — неужели так сложно перед собеседованием хотя бы СВОЕ СОБСТВЕННОЕ резюме прочитать? Такое впечатление, что им просто друг клевое резюме написал.
При собеседовании на позицию геймдев не могут своими словами рассказать, как бы они написали игру Орел-Решка. Ну то есть вопрос без подвоха. Две кнопки — орел, решка, угадал-неугадал. Затык в том, что человек просто не умеет пользоваться функцией Math.random для того, чтобы с вероятностью в 50% вывести текст «орел» и с вероятностью в 50% вывести текст «решка».
Более сложные вещи типа: «Возьмите из колоды в 36 карт 6 случайных» — это у нас была самая сложная задача. Когда люди не знают как я решить — я обычно подсказываю, спрашиваю, играли ли они в Дурака и как давали людям 6 случайных карт.
На то, что у одного из 100 работодателей прокатит.
Была тут как-то статья, где объяснялся этот эффект: чем меньше человек знает и умеет, тем больше он ходит по собеседованиям.
Была тут как-то статья, где объяснялся этот эффект: чем меньше человек знает и умеет, тем больше он ходит по собеседованиям.
Расскажите как там процесс построен? :)
Не удалось с ними пообщаться как-то до сих пор.
Процесс собеседования или процесс работы?
Интересен опыт про собеседования больше.
По опыту работу я краем уха слышал, но как по мне всё сильно зависит от проекта и людей настраивающих процессы.
Про собеседования — так же. Очень сильно зависит от тех специалиста.
У нас (мы разрабатывали игру на JS и Canvas — острие web-технологий на тот момент, куча багрепортов в браузеры, никакой инфы в интернете) HR встречала человека, общалась 5 минут о чем-то, пока придет тех специалист. Лично я был лидом клиентской команды и всегда собеседовал сам. Давал несколько относительно простых. По JS это было на знание прототипов вроде такой:
Спрашивал, что будет, почему, как сделать, чтобы результат был более ожидаем, если человек шарит — мог повести разговор в то, как это реализовано в новом на тот момент ES6, TypeScript, всяких фреймворках. Если же не шарит — говорил, что выведет, спрашивал, почему может быть такой результат
Следующая задача — это понимание замыканий:
Вопрос — что выведет при клике на любой элемент, почему? Как исправить неожиданное поведение?
Самый правильный ответ — IIFE (название не обязательно, достаточно описать общий принцип).
Потом спрашивал, какие нестандартные способы могут назвать люди. Самый популярный правильный ответ — dataset.
Из менее популярных — forEach, with, let, bind (короткий и длинный варианты). Но это уже так — на совсем увлеченность
Эти две задачи показывали, что человек реально имеет базовый опыт работы с JS, умеет распознавать типичные сложные паттерны. Часто с протипами люди не работали вообще (а они у нас часто встречались), но это не так критично, если по остальным пунктам человек хороший.
А вот если не может ответить про проблемы с замыканием — тревожный звоночек, все JS-специалисты не раз сталкиваются с этим шаблоном и это свидетельствует или о вранье в резюме или о слабом опыте (да, есть 5 лет опыта, но только подключение одинаковых плагинов на JQuery, без глубины). У нас же было тьма очень сложного кода, игра в паблике, на которую мы постоянно заливаем обновления и было лучше не нанять хорошего специалиста, который боится общаться с людьми, чем нанять плохого специалиста и потом на боевом сервере получить тьму багов потому что он не смог распознать замыкание.
Code Review у нас было (при чем довольно строгое — минимум два аппрува от других членов команды для мерджа), но все-равно лишней головной боли не хотелось — и так есть над чем страдать.
Потом задача про игру орел-решка. Потом поспрашивал по резюме, выбирая интересные моменты, пообщался на отвлеченные темы, про будущее технологий, про архитектуру, поотвечал на вопросы.
Если человек недостаточно силен — обычно сразу указывал на то, что нужно подтянуть, какую литературу почитать и говорил, что жду через год на новом собеседовании.
Потом шел за HR (а у нас почти со всеми ими были дружеские отношения, лично я считал, что они у нас хорошие), рассказывал в двух словах:
— Кандидат не очень, максимум слабый мид, сказал, что подтянуть
— Кандидат хороший, можно брать
— У кандидата слабый язык, но хорошая верстка — можно посоветовать в веб-команду (тогда с веб могли пригласить на собеседование их спеца)
Потом HR приходила, общалась, провожала или предлагала деньги.
Обычно все собеседования заканчивались за один день и максимум 2 часа.
Хотя был случай, но я уже слабо помню точно, что сильного кандидата, которого я советовал для найма очень долго протянули и он был очень оскорблен и ругался. Там что-то вроде: «человек, который ответственный за бюджет и должен поставить свою подпись — уехал в отпуск, а его зам попал в больницу со сломанной ногой». Короче, бред какой-то и мы все были очень недовольные, но такой случай только один помню.
Но, опять же, все очень сильно зависит от офиса, HR и от команды. Это я про киевский офис рассказывал.
У нас (мы разрабатывали игру на 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 JS Developer — какие подходы к сборке мусора я знаю и когда они используются.
У меня совершенно не конвеерный подход — я стараюсь нащупать глубину знаний каждого кандидата. Но не хочу базироваться на потенциально холиварных засадах
У меня совершенно не конвеерный подход — я стараюсь нащупать глубину знаний каждого кандидата. Но не хочу базироваться на потенциально холиварных засадах
На Senior сейчас бы спросил — знает ли кандидат как реализуется let при транспиляции
Думаю, ренеймингом ;)
Эмс, что? Типа в var переименовывается?
Типа да :)
Меняется на 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. Зависит, конечно, от версии
Правда, тот сайт, который дали вы — транспилирует с багами. Вот пруф. Такой код:
Он оттранспилирует в ошибочный:
Который выведет в консоль неправильное значение.
Правда, программист, который специально игнорирует контекст, чтобы придраться.
Тем более, если он при этом ошибается. Это особенность как раз let, а не for. Зависит, конечно, от версии
Правда, тот сайт, который дали вы — транспилирует с багами. Вот пруф. Такой код:
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 годами и более.
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 годами и более.
UPD: сегодня с утра звонил еще один хедхантер (сезонное обострение у них, что ли). Говорит, людей с опытом на PHP более 2 лет на рынке практически нет. Больше 10 лет опыта на PHP — вообще единороги. Я так понял, что рынок это практически только что осознал, и пока зарплаты не последовали за спросом. Я решил пока затариться попкорном и посмотреть, что будет дальше.
Говорит, людей с опытом на PHP более 2 лет на рынке практически нет.
Это из-за чего с-но? Вдруг случилась какая-то болезнь которая выкосила всех тех людей, кто писал на пыхе ~5 лет назад?
Подозреваю, что болезнь эта называется JavaScript (в очень широком смысле). Такое ощущение (и это подтверждается беседами с кандидатами), что народ массово ломанулся изучать JS, Python и прочую бигдату… пару лет назад еще блокчейн был в тренде. Все хотят получать по 200 штук и ездить на гироскутерах, попивая смузи — о чем почти прямым текстом на собеседовании и говорят. Я серьезно — как только им говоришь, что надо развивать базу кода, которой более 10 лет, вместо того, чтобы писать очередной FB, они киснут лицом. Проблема в том, что потребности в таком количестве JS-ников на рынке, собственно, нет. А вот надеть свитер с оленями и колупаться в потрохах старого софта, разбираться, *почему* что-то работает именно так, а не иначе — не, это не мимими, у них лапки.
Еще вижу кучу людей, всерьез спрашивающих меня — слушай, а в разработке же много платят, да — так я счас пойду за 3 месяца изучу что там надо, буду кнопки давить, комп все сам сделает, и мне тут же дадут 100+, это же так работает? При этом нет ни огня в глазах про собственно разработку, ни даже отдаленного понимания, зачем им это, кроме денег. Как результат, имеем вакуум в области настоящих, любящих свое дело профессионалов, тем более с опытом.
Еще вижу кучу людей, всерьез спрашивающих меня — слушай, а в разработке же много платят, да — так я счас пойду за 3 месяца изучу что там надо, буду кнопки давить, комп все сам сделает, и мне тут же дадут 100+, это же так работает? При этом нет ни огня в глазах про собственно разработку, ни даже отдаленного понимания, зачем им это, кроме денег. Как результат, имеем вакуум в области настоящих, любящих свое дело профессионалов, тем более с опытом.
Проблема в том, что потребности в таком количестве JS-ников на рынке, собственно, нетСудя по раздутым зп и количеству вакансий — JSников категорический дефицит. Жаль, что нормальных Геймдев вакансий очень мало.
Не надо про свитер с оленями шутить, у меня он до сих пор на полочке в шкафу лежит. И код который начинал писаться в начале-середине 2000-х пощупать довелось 1сный (пришел в программирование в 2014 году), не особо приятные ощущения. Я в чем то тех кто ломится в JS понимаю, хоть сам веб стек не люблю, но тоже ушел в модный/молодежный котлин. Тем не менее если к вебу отвращения нет — то js наверно самый удобный вариант. И фронт, и бек, и даже за их пределами что то попилить можно. Ну а свежие проекты обычно всегда предпочтительней старых, хотя наверно исключения и есть какие то.
У меня тоже такой свитер есть. Как Linux на ноут накатил — жена-маководша через год подарила, подсмеиваясь — так что горжусь :) По новым проектам скорее соглашусь. По JS — не поймите неправильно, я ни в коем случае не хочу ругать технологию (при этом лично продолжая предпочитать проводить время с чем-то другим, если есть выбор). Дело ИМХО в том, что даже в вебе на одном JS далеко не уедешь — да хоть SQL надо хотя бы на базовом уровне понимать. На рынке же полно джунов, которые чуть что начинает притормаживать / подглючивать, задирают руки и зовут маму (даже на SO зайти не могут, болезные) — но на собеседовании хотят зарплату сениора и печеньки мешками. Кругозора у многих нет, и как результат нет способности выбрать правильную технологию.
Опять же, в пятницу на собеседовании интервьюер спросил, почему у меня опыт в основном с MySQL, а не Mongo и другие более современные вещи. Рассказал — use case у меня другие были, итп, объяснил в деталях, насколько позволяли NDA. Он еще немного приподнял брови, когда выяснилось, что я в курсе разницы между MariaDB и MySQL. А потом он мимолетно признался, что многие, кого он собеседовал (на сениора, на секундочку), даже не в курсе разницы между RDBMS и NoSQL движками — оно как-то само работает у них через любимый %framework% (ну или не работает), и используется, потому что модно. Иногда приходится взрослым людям после 5 лет в профессии объяснять, зачем нужен статический анализ кода, что такое отладка, и что она дает по сравнению с printf(), как пользоваться отладочными прокси… Я знаю людей, у которых упавший на 3 месяца (!) из-за конфликта портов xdebug (отладчик для PHP, если вы не по этой теме) не стал препятствием для работы на уровне архитектуры немаленького такого приложения. Я не знаю как так можно жить… и так много с чем.
Опять же, в пятницу на собеседовании интервьюер спросил, почему у меня опыт в основном с MySQL, а не Mongo и другие более современные вещи. Рассказал — use case у меня другие были, итп, объяснил в деталях, насколько позволяли NDA. Он еще немного приподнял брови, когда выяснилось, что я в курсе разницы между MariaDB и MySQL. А потом он мимолетно признался, что многие, кого он собеседовал (на сениора, на секундочку), даже не в курсе разницы между RDBMS и NoSQL движками — оно как-то само работает у них через любимый %framework% (ну или не работает), и используется, потому что модно. Иногда приходится взрослым людям после 5 лет в профессии объяснять, зачем нужен статический анализ кода, что такое отладка, и что она дает по сравнению с printf(), как пользоваться отладочными прокси… Я знаю людей, у которых упавший на 3 месяца (!) из-за конфликта портов xdebug (отладчик для PHP, если вы не по этой теме) не стал препятствием для работы на уровне архитектуры немаленького такого приложения. Я не знаю как так можно жить… и так много с чем.
да хоть SQL надо хотя бы на базовом уровне пониматьНе обязательно, сейчас большинство JSников-серверщиков его совершенно не знает и пользуется NoSQL базами.
На рынке же полно джунов… на собеседовании хотят зарплату сениора
Такое во все времена на любом языке. К примеру, в 2012-м наблюдали такое в Java
Самое смешное что свитер с оленями мне подарил человек с компьютером на Вы общающийся)) А ситуация на рынке да, грустная. Периодические такое рассказывают в комментариях что волосы дыбом становятся, что я даже вспоминаю своих прошлых коллег 1сников с радостью. Пусть с ними не получалось поспорить на темы статическая vs динамическая типизация и они не слышали про замыкания например, но по сравнению с некоторыми образцами о которых тут рассказывают они просто боги программирования. Просто они больше в предметную область ушли, чем в собственно программирование, но тем не менее при необходимости написать компоненту на плюсах или разобраться с субд новой, или там рест апи прикрутить — они всегда бы смогли самостоятельно.
Прям орнул =) Хочу продолжения, хотя бы в лс.
Почему-то думал, что «расслабить и расположить собеседника к себе» упоминается во всех статьях про интервью, но гугл показал, что нет.
Чем-то мне это напомнило рассказ Аверченко «Бельмесов». Не по смыслу, а, скажем так, по юморичестической составляющей)
Заголовок спойлера
–Кто такой этот Бельмесов?–нетерпеливо спросил я.
–А как же! У нас же служит.
–Да кем? Что он делает?
–А как же. Инспектором у нас в уездном училище. Где я директором состою. Дока.
–Это он-то дока?
–Он. Вы бы посмотрели, как он на экзаменах учеников спрашивает. Любо-дорого посмот-реть. Уж его не надуешь, не проведешь за нос. Ён, как говорится, достанет. Посмотрели бы вы, ка-ким он орлом на экзамене…
–Много бы я дал, чтобы посмотреть!–вырвалось у меня.
–В самом деле хотите? Это можно устроить. Завтра у нас как раз экзамены –приходите. По-сторонним, правда, нельзя, но мы вас за какого-нибудь почетного попечителя выдадим. Вы же, кстати, и пишете –вам любопытно будет… Среди учеников такие типы встречаются… Умора! Смотрите, только нас не опишите! Хе-хе! Вот вам и адресок. Право, приезжайте завтра. Мы глас-ности не боимся.
II
За длинным столом, покрытым синим сукном, сидело пятеро. Посредине любезный старик с белой звездой, а справа от него торжественный, свеже-накрахмаленный Бельмесов, Иван Демьяныч. Я вскользь осмотрел остальных и скромно уселся на стул.
Солнце бегало золотыми зайчиками по столу, по потолку и по круглым стриженым головенкам учеников. В открытое окно заглядывали темно-зеленые ветки старых деревьев и приветливо, одобрительно кивали детям: «Ничего, мол. Все на свете перемелется — мука будет. Бодритесь, детки...»
— Кувшинников, Иван, — сказал Бельмесов. — А подойти к нам сюда, Иван Кувшинников… Вот так. Сколько будет пятью-шесть, Кувшинников, а?
— Тридцать.
— Правильно, молодец. Ну, а сколько будет, если помножить пять деревьев на шесть лошадей?
Мучительная складка перерезала загорелый лоб Кувшинникова Ивана.
— Пять деревьев на шесть лошадей? Тоже тридцать.
— Правильно. Но тридцать — чего?
Молчал Кувшинников.
— Ну, чего же — тридцать? Тридцать деревьев или тридцать лошадей?
У Кувшинникова зашевелились губы, волосы на голове и даже уши тихо затрепетали.
— Тридцать… лошадей.
— А куда же девались деревья? — иронически прищурился Бельмесов. — Нехорошо, тезка, нехорошо… Было всего шесть лошадей, было пять деревьев и вдруг — на тебе! — тридцать лошадей и ни одного дерева… Куда же ты их дел?! С кашей съел или лодку себе из них сделал?
Кто-то на задней парте печально хихикнул. В смехе слышалось тоскливое предчувствие собственной гибели.
Ободренный успехом своей остроты, Иван Демьяныч продолжал:
— Или ты думаешь, что из пяти деревьев выйдут четыре лошади? Ну, хорошо: я тебе дам одно дерево — сделай ты мне из него четыре лошади. Тебе это, очевидно, легко, Кувшинников, Иван, а? Что ж ты молчишь. Иван, а? Печально, печально. Плохо твое дело, Иван. Ступай, брат!
— Я знаю, — тоскливо промямлил Кувшинников. — Я учил.
— Верю, милый. Учил, но как? Плохо учил. Бесмысленно. Без рассуждения. Садись, брат, Иван. Кулебякин, Илья! Ну… ты нам скажешь, что такое дробь?
— Дробью называется часть какого-нибудь числа.
— Да? Ты так думаешь? Ну, а если я набью ружье дробью, это будет часть какого числа?
— То дробь не такая, — улыбнулся бледными губами Кулебякин. — То другая.
— Откуда же ты знаешь, о какой дроби я тебя спросил? Может быть, я тебя о ружейной дроби? Вот если бы ты был, Кулебякин, умнее, ты бы спросил: о какой дроби я хочу знать: о простой или арифметической?.. И на мой утвердительный ответ, что — о последней — ты должен был ответить: «арифметической дробью называется — и так далее»… Ну, теперь скажи ты нам, какие бывают дроби?
— Простые бывают дроби, — вздохнул обескураженный Кулебякин, — а также десятичные.
— А еще? Какая еще бывает дробь, а? Ну, скажи-ка?
— Больше нет, — развел руками Кулебякин, будто искренно сожалея, что не может удовлетворить еще какой-нибудь дробью ненасытного экзаменатора.
— Да? Больше нет? А вот если человек танцует и ногами дробь выделывает, это как же? По-твоему, не дробь? Видишь ли что, мой милый… Ты, может быть, и знаешь арифметику, но русского языка — нашего великого, разнообразного и могучего языка — ты не знаешь. И это нам всем печально. Ступай, брат Кулебякин, и на свободе кое о чем подумай, брат Кулебякин. Лысенко! Вот, ты, Лысенко! Кондратий, скажешь нам, что тебе известно о цепном правиле? Ты знаешь цепное правило?
— Знаю.
— Очень хорошо-с. Ну а цепное исключение тебе известно?
Лысенко метнул в сторону товарищей испуганным глазом и, повесив голову, умолк.
— Ну что же ты, Лысенко? Ведь говорят же: нет правила без исключений. Ну, вот ты мне и ответь: есть в цепном правиле цепное исключение?
Стараясь не шуметь, я отодвинул стул, тихонько встал и, сделав общий поклон, направился к выходу.
Любезный директор с белой звездой тоже встал, догнал в передней и сказал, подмигивая на экзаменационную комнату:
— Ну, как?.. Не говорил ли я, что дока. Так и хапает, так и режет. Орел! Да только, жалко, не жилец он у нас… Переводят с повышением в Харьков. А жалко… Я уж не знаю, что мы без него и делать будем?.. Без орла-то!
–А как же! У нас же служит.
–Да кем? Что он делает?
–А как же. Инспектором у нас в уездном училище. Где я директором состою. Дока.
–Это он-то дока?
–Он. Вы бы посмотрели, как он на экзаменах учеников спрашивает. Любо-дорого посмот-реть. Уж его не надуешь, не проведешь за нос. Ён, как говорится, достанет. Посмотрели бы вы, ка-ким он орлом на экзамене…
–Много бы я дал, чтобы посмотреть!–вырвалось у меня.
–В самом деле хотите? Это можно устроить. Завтра у нас как раз экзамены –приходите. По-сторонним, правда, нельзя, но мы вас за какого-нибудь почетного попечителя выдадим. Вы же, кстати, и пишете –вам любопытно будет… Среди учеников такие типы встречаются… Умора! Смотрите, только нас не опишите! Хе-хе! Вот вам и адресок. Право, приезжайте завтра. Мы глас-ности не боимся.
II
За длинным столом, покрытым синим сукном, сидело пятеро. Посредине любезный старик с белой звездой, а справа от него торжественный, свеже-накрахмаленный Бельмесов, Иван Демьяныч. Я вскользь осмотрел остальных и скромно уселся на стул.
Солнце бегало золотыми зайчиками по столу, по потолку и по круглым стриженым головенкам учеников. В открытое окно заглядывали темно-зеленые ветки старых деревьев и приветливо, одобрительно кивали детям: «Ничего, мол. Все на свете перемелется — мука будет. Бодритесь, детки...»
— Кувшинников, Иван, — сказал Бельмесов. — А подойти к нам сюда, Иван Кувшинников… Вот так. Сколько будет пятью-шесть, Кувшинников, а?
— Тридцать.
— Правильно, молодец. Ну, а сколько будет, если помножить пять деревьев на шесть лошадей?
Мучительная складка перерезала загорелый лоб Кувшинникова Ивана.
— Пять деревьев на шесть лошадей? Тоже тридцать.
— Правильно. Но тридцать — чего?
Молчал Кувшинников.
— Ну, чего же — тридцать? Тридцать деревьев или тридцать лошадей?
У Кувшинникова зашевелились губы, волосы на голове и даже уши тихо затрепетали.
— Тридцать… лошадей.
— А куда же девались деревья? — иронически прищурился Бельмесов. — Нехорошо, тезка, нехорошо… Было всего шесть лошадей, было пять деревьев и вдруг — на тебе! — тридцать лошадей и ни одного дерева… Куда же ты их дел?! С кашей съел или лодку себе из них сделал?
Кто-то на задней парте печально хихикнул. В смехе слышалось тоскливое предчувствие собственной гибели.
Ободренный успехом своей остроты, Иван Демьяныч продолжал:
— Или ты думаешь, что из пяти деревьев выйдут четыре лошади? Ну, хорошо: я тебе дам одно дерево — сделай ты мне из него четыре лошади. Тебе это, очевидно, легко, Кувшинников, Иван, а? Что ж ты молчишь. Иван, а? Печально, печально. Плохо твое дело, Иван. Ступай, брат!
— Я знаю, — тоскливо промямлил Кувшинников. — Я учил.
— Верю, милый. Учил, но как? Плохо учил. Бесмысленно. Без рассуждения. Садись, брат, Иван. Кулебякин, Илья! Ну… ты нам скажешь, что такое дробь?
— Дробью называется часть какого-нибудь числа.
— Да? Ты так думаешь? Ну, а если я набью ружье дробью, это будет часть какого числа?
— То дробь не такая, — улыбнулся бледными губами Кулебякин. — То другая.
— Откуда же ты знаешь, о какой дроби я тебя спросил? Может быть, я тебя о ружейной дроби? Вот если бы ты был, Кулебякин, умнее, ты бы спросил: о какой дроби я хочу знать: о простой или арифметической?.. И на мой утвердительный ответ, что — о последней — ты должен был ответить: «арифметической дробью называется — и так далее»… Ну, теперь скажи ты нам, какие бывают дроби?
— Простые бывают дроби, — вздохнул обескураженный Кулебякин, — а также десятичные.
— А еще? Какая еще бывает дробь, а? Ну, скажи-ка?
— Больше нет, — развел руками Кулебякин, будто искренно сожалея, что не может удовлетворить еще какой-нибудь дробью ненасытного экзаменатора.
— Да? Больше нет? А вот если человек танцует и ногами дробь выделывает, это как же? По-твоему, не дробь? Видишь ли что, мой милый… Ты, может быть, и знаешь арифметику, но русского языка — нашего великого, разнообразного и могучего языка — ты не знаешь. И это нам всем печально. Ступай, брат Кулебякин, и на свободе кое о чем подумай, брат Кулебякин. Лысенко! Вот, ты, Лысенко! Кондратий, скажешь нам, что тебе известно о цепном правиле? Ты знаешь цепное правило?
— Знаю.
— Очень хорошо-с. Ну а цепное исключение тебе известно?
Лысенко метнул в сторону товарищей испуганным глазом и, повесив голову, умолк.
— Ну что же ты, Лысенко? Ведь говорят же: нет правила без исключений. Ну, вот ты мне и ответь: есть в цепном правиле цепное исключение?
Стараясь не шуметь, я отодвинул стул, тихонько встал и, сделав общий поклон, направился к выходу.
Любезный директор с белой звездой тоже встал, догнал в передней и сказал, подмигивая на экзаменационную комнату:
— Ну, как?.. Не говорил ли я, что дока. Так и хапает, так и режет. Орел! Да только, жалко, не жилец он у нас… Переводят с повышением в Харьков. А жалко… Я уж не знаю, что мы без него и делать будем?.. Без орла-то!
Это в значительной части рассказ про заваленную работу руководства компании: и менеджеров, и HR. Не понимаю, почему такие люди допускаются до собеседований в принципе. Если же это маленькие компании, и больше собеседовать некому, то можно только посочувствовать.
Про личный опыт:
1) С точки зрения соискателя. Самые качественные и интересные интервью те, где тебе предлагают что-то спроектировать на ходу или обсудить, как должно работать в идеале. Какое-то решение живой бизнес-задачи с помощью твоего стека. Естественно, подходит только для миддлов-сеньоров, джунов таки стоит гонять по азбучной теории.
Самые некачественные интервью — там, где спрашивают точное знание встроенных методов или алгоритмы решения отвлечённых задач. Каждый раз выходишь: а что это было и зачем?
2) С точки зрения нанимателя. Хорошие интервью получаются, когда сам наниматель понимает, под что он берёт работника, может рассказать, в каких конкретно процессах ему придётся участвовать, какую пользу он принесёт. В больших компаниях с этим проблемы, да.
Плохие интервью получаются, когда руководство решило просто расширить штат, потому что не очень сбываются его ожидания по скорости решения тасков. Короче, когда у собеседующего нет внутренней уверенности в нужности сотрудника
Про личный опыт:
1) С точки зрения соискателя. Самые качественные и интересные интервью те, где тебе предлагают что-то спроектировать на ходу или обсудить, как должно работать в идеале. Какое-то решение живой бизнес-задачи с помощью твоего стека. Естественно, подходит только для миддлов-сеньоров, джунов таки стоит гонять по азбучной теории.
Самые некачественные интервью — там, где спрашивают точное знание встроенных методов или алгоритмы решения отвлечённых задач. Каждый раз выходишь: а что это было и зачем?
2) С точки зрения нанимателя. Хорошие интервью получаются, когда сам наниматель понимает, под что он берёт работника, может рассказать, в каких конкретно процессах ему придётся участвовать, какую пользу он принесёт. В больших компаниях с этим проблемы, да.
Плохие интервью получаются, когда руководство решило просто расширить штат, потому что не очень сбываются его ожидания по скорости решения тасков. Короче, когда у собеседующего нет внутренней уверенности в нужности сотрудника
Я бы с осторожностью брал в России крутых специалистов. Лучше набрать опытных середнячков и не с завышенной самооценкой.
Профессионал часто оказывается с трудных характером, склочный, амбициозный, будет вечно шантажировать уходом, тянуть лямку на себя, спорить, что его решение самое лучше, что это он тут все сделал, а чем вы занимались? Будет подставлять коллег, не будет командной работы и духа, будет неуступчив. Т.к. он профессионал он моментально напишет код, и остальные 7 часов будет почивать на лаврах ничего не делая, жалуясь, что задача написана криво, что пусть тестируют тестировщики. Не будет делиться знаниями и опытом. Не будет мыслить в интересах команды и клиента, а только в своих.
Из-за этого я первую очередь смотрю на личностные качества человека, на его характер, soft skills вобщем
Согласен с автором, что можно брать почти любого, кто правда хочет развиваться и обладает нормальный характером
Профессионал часто оказывается с трудных характером, склочный, амбициозный, будет вечно шантажировать уходом, тянуть лямку на себя, спорить, что его решение самое лучше, что это он тут все сделал, а чем вы занимались? Будет подставлять коллег, не будет командной работы и духа, будет неуступчив. Т.к. он профессионал он моментально напишет код, и остальные 7 часов будет почивать на лаврах ничего не делая, жалуясь, что задача написана криво, что пусть тестируют тестировщики. Не будет делиться знаниями и опытом. Не будет мыслить в интересах команды и клиента, а только в своих.
Из-за этого я первую очередь смотрю на личностные качества человека, на его характер, soft skills вобщем
Согласен с автором, что можно брать почти любого, кто правда хочет развиваться и обладает нормальный характером
Это собирательный типаж конечно, все вместе это было бы горе-дитя как вы написали. На самом деле людей с одним из вышеописанных качеств примерно 10-15% в коллективе, но этого хватает чтобы система работала не нормально, не можешь положиться полностью на команду
Я тоже так думал пока не поработал заграницей, есть совсем другие люди с другим менталитетом. Может мне так повезло, но факт для меня
Ответ berez похож опять же на спор что я описывал выше. Нет никакого согласия, понимания и поиска консенсуса, бессмысленный спор
Ответ berez похож опять же на спор что я описывал выше. Нет никакого согласия, понимания и поиска консенсуса, бессмысленный спор
Я не согласен, что спор бессмысленный. Он скорее однобокий: мы обсуждаем некого абстрактного кандидата без привязки к коллективу и проекту.
Это хорошо, что вы упомянули про заграницу. Там действительно работают по-другому. Но дело тут не только в менталитете (в конце концов, там и наши эмигранты работают в больших количествах — и ничего, менталитет не мешает). Мне кажется, дело скорее в отношениях между работодателем и работником.
Вот как я это себе представляю (для сферы IT):
В Европе работодатель хорошо защищен социально, но при этом понимает, что социалка зависит и от его активности тоже. Отсюда — крепкие профсоюзы, а работодатели идут на компромиссы.
В Америке с работником «договариваются» зарплатой. Работник хорошо впахивает потому, что деньги нужны, работодатель хорошо платит потому, что иначе хорошие работники разбегутся.
У нас, к сожалению, социальной защищенности нет. Т.е. каждый работник по сути сам за себя. Но и с зарплатами не фонтан — ибо конкуренции не так уж и много. Вот и получается с одной стороны — имитация рабочего энтузиазма, а с другой — имитация заботы о работнике и «коллективные ценности».
Это хорошо, что вы упомянули про заграницу. Там действительно работают по-другому. Но дело тут не только в менталитете (в конце концов, там и наши эмигранты работают в больших количествах — и ничего, менталитет не мешает). Мне кажется, дело скорее в отношениях между работодателем и работником.
Вот как я это себе представляю (для сферы IT):
В Европе работодатель хорошо защищен социально, но при этом понимает, что социалка зависит и от его активности тоже. Отсюда — крепкие профсоюзы, а работодатели идут на компромиссы.
В Америке с работником «договариваются» зарплатой. Работник хорошо впахивает потому, что деньги нужны, работодатель хорошо платит потому, что иначе хорошие работники разбегутся.
У нас, к сожалению, социальной защищенности нет. Т.е. каждый работник по сути сам за себя. Но и с зарплатами не фонтан — ибо конкуренции не так уж и много. Вот и получается с одной стороны — имитация рабочего энтузиазма, а с другой — имитация заботы о работнике и «коллективные ценности».
Профессионал часто оказывается с трудных характером, склочный,
Это можно определить на собеседовании, разве нет?
амбициозный,
А это вот вообще ни разу не недостаток. Да, есть проекты (всякий maintenance), где амбициозность не нужна, а нужны другие качества. Но вот для стартапов амбициозность очень даже неплоха.
Задача рекрутера и собеседующих — определить, подходит ли данный конкретный человек к вашему конкретному проекту. В том числе психологически.
Не за что, ваш К.О.
будет вечно шантажировать уходом,
Если ваш проект не подходит для «звезд» — возможно и будет. С другой стороны, если гражданин в проекте прижился и «расцвел», то он один в случае чего сможет вытянуть на себе весь проект.
тянуть лямку на себя, спорить, что его решение самое лучше, что это он тут все сделал, а чем вы занимались?
Это вы описываете какого-то молодого да раннего звездуна, как мне кажется.
Я с трудом представляю себе опытного специалиста, который вдруг ни с того ни с сего вот так вот «зазвездился». Опытного — значит, поработавшего в разных проектах и разных коллективах. Такие люди, как правило, трезво понимают свою роль в коллективной разработке.
Будет подставлять коллег, не будет командной работы и духа, будет неуступчив.
Другими словами, bad team player & trouble maker.
Опять же, даже такому гражданину иногда находится применение — например, некая узкая зона ответственности, где он может в одиночку творить что ему заблагорассудится. Узкая — чтобы в случае чего эффект автобуса был не слишком большим. :)
Т.к. он профессионал он моментально напишет код, и остальные 7 часов будет почивать на лаврах ничего не делая, жалуясь, что задача написана криво, что пусть тестируют тестировщики.
По поводу «моментально напишет код» вспомнилась коронная фраза одного бывшего коллеги: «как мы все знаем, хороший программист работает от силы пару часов в день. Но это не повод уходить с работы в 12». :)
Не будет делиться знаниями и опытом.
Значит, менторство — не его. Ну и что? Кому-то ведь нужно и просто работать.
Не будет мыслить в интересах команды и клиента, а только в своих.
Опять же, зависит от проекта. Иногда клиентов-то и нет еще (я имею в виду всяческое RnD).
А для воспитания очень уж самовлюбленных граждан, бывает, применяют штрафы. Как регулярная мера они, конечно, сильно портят атмосферу в коллективе, но как разовая мера — очень даже помогают отдельным личностям приобщиться к проблемам клиентов на собственной шкуре. Ну и — если вдруг гражданин решит уволиться — туда ему и дорога, не так ли? :)
Пост хорош. Жаль что мало народу пытается собеседовать по конструктиву. У меня в опроснике тоже вопросов десять всего. Они нужны только для затравки, чтобы начать разговор.
Я провел сто собеседований, отказал сотне людей — и только потом научился собеседовать