Comments 909
Полтора года назад завалил подобное собеседование. Очень рад был недавно увидеть эту позицию незакрытой до сих пор. Мне даже неинтересны подробности — до сих пор ли они ищут кандидата, умеющего одновременно и олимпиадные задачки на скорость и способного взаимодействовать с ТЗ, либо набрали кого-то из антисанитарных стран до первого бетонного самолета.
Ну почему же. Я уверен, менеджер искренне хочет найти здравомыслящего сотрудника, который способен реализовывать бизнес задачи соответственно заданиям, реагируя на обязательно возникающие изменения. Однако, автоматизация процесса рекрутинга, решение в пользу которой было принято даже не обязательно этим же менеджером, выдаст в итоге не вполне однозначные результаты. Это в случае компании, которая просто хочет "срезать углы" в процессе поиска специалиста. Есть же еще компании, где программист — заменяемый ресурс. С вытекающими следствиями как рекрутинга, так и отношения в процессе работы. По личному наблюдению — действительно ценных людей туда принимают в обход всего автоматизированно-бюрократического геморроя, чтобы, упаси боже, не спугнуть.
Но и другая проблема тоже есть — умение быстро решить олимпиадную задачку не гарантирует, что человек сможет работать программистом изо дня в день.
Годы опыта хотя бы дают такую надежду.
Тут дело даже не в переобучениях, а в том, что умение решать олимпиадные задачки, хоть и коррелирует с навыками сеньора до какой-то степени, но по сути это две разные области. Можно взять тренированного 10классника, но сеньором от своего умения не станет. Хотя в него будут верить больше, чем в тех, кто эти задачи решать не умеет.
Меня недавно спросили теорему Чёрча-Росса о ламбда исчислении. А оно мне надо?
тогда какой смысл?
А что вы подразумеваете под наукой? Пришёл в лабораторию и плюёшь в потолок, придумывая новый способ оптимизировать суб-экспоненциальный алгоритм исправления ошибок в линейных кодах? Нет, конечно. Научная работа - это бесконечные конференции, педагогическая (лекторная) практика, сопровождение молодых учёных или кооперация с "дедами науки", выбивание грантов в околоинженерных историях, чтобы отрабатывать технологии, которые пару лет назад были лишь дисертациями на бумаге. И лишь иногда - не столько поиск, сколько проверка новых гипотез. А поиск, он стохастичен.
Меня недавно спросили теорему Чёрча-Росса о ламбда исчисленииБыло бы забавно проверить проверить знания рекрутера в этой теме, например, предложив ему выразить какое-нибудь несложное выражение через стандартные комбинаторы )))
Ощущение двоякое. С одной стороны чувствую, что решение задачи на скорость мало говорит о том, насколько я программист. Я даже в шахматы блиц не играю, хотя классику могу более-менее пристойно для любителя.
С другой проблема того, как понять кандидата за час действительно есть. Когда сам собеседую, предпочитаю дать несложную задачу на дизайн/рефакторинг без единственно правильного ответа — для того, чтобы понять как кандидат рассуждает и какие у него стиль кодирования.
Ну или услышать «диплом купил, сам ничего не писал, хочу хотя б 100 тыщ» и не тратить время.
Затем в другой очень известной фирме с высокими зп тоже напрягся и решил эти тестовые задания на codility. На решение дали уже меньше — 1.5 часа, что непонятно: спортсменов по программированию или рабов на галеры нанимают: даже тестовые задания нормально не успеваешь составить на проверку и производительность кода. Но потом этот бред продолжился: тестовые задания дали ещё и на последующем техническом интервью, только решить уже нужно было в присутствии интервьюера за 15-20 мин — решил за 21 мин — отказ. Что происходит?!
Уже нарешался этих задач на codility массу — аллергия на них уже, если б это ещё получение работы гарантировало. Они могут мои предыдущие тесты посмотреть?! ;)
А вообще тому кто предлагает задачки сеньор или лид разработчикам с 15+ годами — надо просто пойти на хер))) Ибо они не адекватны)))
Полностью с тобой согласен, у меня как раз 15+, но приходится смирять гордыню и самомнение и на общих основаниях со всеми проходит, хотя возможно что-то изменится. Возможно в себе нужно что-то менять.
до первого бетонного самолета
Простите, а можно пояснить для неопытных эту фразу?)
СЕО моей первой компании рассказывал анекдот, чем отличаются программисты СНГ от программистов повосточней. Действие происходит задолго до моды на аджайл и прочие техники контроля проекта.
Приходит ТЗ двум командам, востоку и нашим — создать бетонный самолет.
Первые говорят — нефик делать, месяц работы. Заказчик приходит через месяц — стоит бетонный самолет. Красивый, большой, документированный.
- Окей, молодцы. А как он летает?
- Летает? — спросили разработчики — Этого не было в ТЗ!
- Блин, чуваки, это САМОЛЕТ. Он должен летать. Перемещаться в воздухе.
- … многозначительное молчание
Наши говорят — два месяца, приходите. Заказчик возвращается в назначенный срок. Стоит паровоз. Обычный паровоз, не бетонный, на колесах, на рельсах, пыхтит.
- Че это?
- Понимаете, в чем дело. Мы просмотрели ТЗ и пришли к выводу, что самолет — это не то, что Вам надо. Ну бетон, да, дешево, но вы его потом замучаетесь саппортить, кроме того он не взлетит как надо. А Вам же перемещаться. Вот в пределах проектного времени мы запилили вот это средство передвижения. Удобное, поддерживаемое, надежное, предсказуемое.
Потому что
а) заказчик может не быть специалистом во всем, что ему надо (например, некоторые заказчики могут просить сделать полностью одинаковый интерфейс для андроида и айфона)
б) некоторые противоречия становятся понятны только в процессе решения задачи
Если разработчик не пытается выяснить, что именно надо заказчику и объяснить ему последствия его решений, я бы не сказал, что это Senior.
Но даже тут постоянно возникают заковыки — когда ты пытаешься менеджеру объяснить даже не какие-то технические аспекты, а просто логические — условное:
— так нельзя сделать, потому что если юзер введёт имя длиннее 15 символов, то…
— так сделайте поле в 25 символов!
— а если в имени будет 30 символов (Характерный момент — обычно технари при проектировании не сходят на конкретику, а закладывают все возможные варианты. Т.е. оперируют алгеброй, а не арифметикой. Гуманитариям же кажется что достаточно поднять лимит и проблема решена)
— сделайте поле в тысячу символов!
— тогда это поле не влезет ни в один интерфейс!
— Когда я копирую в поле логина содержимое третьего тома Войны и Мира, у меня зависает браузер! У вас баг на сайте!
вариант:
— укажит софт, который позволил вам выделить и скопировать третий том без зависания
PS: отмена!
обычный браузер позволяет легко выделять и копировать третий том
при попытке вставления в разные формы ввода в том же браузере было получено
— просто не реагирование формы вообще
— Некоторые при вставке из буфера — просто обрезали текст до минимальной величины
— зависания получено пока не было, но я не настоящий QA
Вообще это часть работы Senior Developer — рассказывать заказчику, что он может упускать из виду.
Вообще-то это задача аналитика переводить с клиентского на программистский.
Вообще это часть работы Senior Developer — рассказывать заказчику, что он может упускать из виду.
Уточняющие вопросы, говорите? Их есть у меня! Усаживайтесь поудобнее, мы здесь задержимся надолго.
Конечно, надо подходить к вопросу разумно. Текст прекрасен как шутка, но если всерьез, то просто надо сразу спросить, почему нельзя использовать стандартную функцию.
А иногда заказчик сам не понимает, как ему надо. И тогда разумно предложить "сделаем пока так, а если что — переделаем". Как правило, останется как есть — т.е. заказчика все устраивает.
Если разработчик не пытается выяснить, что именно надо заказчику и объяснить ему последствия его решений, я бы не сказал, что это Senior.
Иногда можно не выяснять все до конца, а написать самодиагностирующуюся программу. Если все выяснять, то заказчик потеряет терпение.
А вы знакомы с документами типа https://classinform.ru/profstandarty/06.035-razrabotchik-web-i-multimediinykh-prilozhenii.html. Раздел B части трудовые функции
737 MAX? (MAX имеет значение, т.к. 737 сам по себе уже достаточно старый самолётик)
The coders from HCL were typically designing to specifications set by Boeing.
В соответствии со спецификациями, MCAS работал правильно
Ошибка сделанная Боингом — системная/архитектурная, никакое стороннее тестирование MCAS как отдельного модуля на соответствие спецификации, не выявило бы проблему, что этот модуль полагается на данные только от одного датчика.
Это было решение индусов, не распространять информацию о появлении новой системы среди пилотов?
Это вина индусов, что пилоты оказались не готовы к «штатному» отказу «самовольная перекладка стабилизатора»?
Кроме того, презрительный комментарий по поводу 9$ в час — это 90к рублей в месяц. Какие там зарплаты сейчас у Сухого или Яковлева?
Вы внимательно читали мой комментарий? Я индусов винил?
Определенно, да. Иначе я не знаю, как можно было прочитать этот комментарий:
Там вроде выяснили что ПО писалось через одно место индусами за 2$/час.
В итоге мы выяснили, что проблема не 9$ баксах в час, не в индусах и не в софте
— Топ менеджеры, которые доят бренд 737го слишком долго
— Маркетологи, которые продали MAX как «тот же NG, только новый и экономичный». Переход с NG на MAX это 1 день наземного тренинга.
— КБ и главный конструктор, который допустил что в самолете есть система без дублирования
— Авиаконтролирующие органы (как в Штатах так и международные), которые сертифицировали этот самолет
— Авиакомпании, которые заставляют пилотов летать только на автоматике, с минимум практики управления руками. (Сгоревший суперджет, это как раз туда же)
— Пилоты, которые молча хавают и соглашаются с этой политикой.
Но сми форсят факт «это просто индусы наговнокодили»
Ну вотт новый Суперджет поимел проблемы при посадке с превышением посадочной массы после удара молнии — ~половина выжила.
«Штатная» работа одной систем Боинга — выживших немае.
Странная нонче адекватность у людей.
Простите покорно, но "новый Суперджет поимел проблемы при посадке" всё же не "из-за превышения посадочной массы", а потому, что доходяга-пилот его об полосу бил-бил, и на третий раз таки разбил (смотрите сами). Как-то так.
Так что косяки пилотов косяками, но и помимо этого ИМХО были объективные факторы.
9 баксов в айти за бугром это очень мало для такого ответственного проекта. Я по молодости даже вмордпресс не допиливал на фрилансе меньше чем за 20. При отсутствии менеджмента и прочего бюрократического буллшита, с ним — нужно больше.
Моя поправка была относительно модели самолёта, у вас — 777 указан.
Поищите историю с Боингом, это недавнее. Они наняли индусов для своего ПО с ожидаемым анекдотическим результатом.
Там не проблема в ПО, а в менеджерах и вызванном этим плохом инженерном дизайне. Из-за маркетинговых требований пытались сделать новый самолет с точки зрения пилота точно такой же, как старый, только более эффективный. В итоге нагородили всяких костылей типа этого MCAS, который управлял самолетом игнорируя пилота и зависил от одного единственного дешевого датчика, который, сюрприз-сюрприз, иногда выходил из строя.
Если бы этой особенности уделили достаточно внимания при тренировке пилотов — трагедий можно было бы избежать, но для поддержания иллюзии "совсем как старый, только лучше" этого не делали.
Почему? А госконтракты. По некоторым из них у исполнителя должно быть X специалистов по специальности Y. «Смотрите! У нас тут открыта вакансия по специальности Y и уже есть 100500 откликов на эту вакансию, мы уже завтра наймем человека!»
С другой стороны, как вы в большой организации будете проверять адекватность работы отделов? Нет KPI — нет оценки, и в этой ситуации часто разводится имитация бурной деятельности.
Вот был я в Тунисе. У чистильщика пляжа есть KPI: чистота пляжа. Этот чёрт чистит пляж на тракторе, а потом скидывает весь мусор в море. Зато KPI выполнен: пляж с утра идеально вычесан от мусора. Правда, море превратилось в дерьморе.
Русские туристы пару раз чуть не побили его, но что ему делать? «Умный» манагер не предусмотрел вывоз мусора. Куда его девать, если за его наличие на берегу тракториста штрафуют?
А вот найти адекватных составителей KPI — нереально. Эти люди должны знать всё об оцениваемом участке работ, а сегодня начальнички «не любят погружаться». Знакомая фразочка? То-то!
Такая ситуация — явный признак больших проблем в управлении. Там, где молятся на показатели, люди стремятся только к достижению показателей.
Тунисский пляж, короче говоря.
С разработкой так не работает по той причине что большую часть выполняемых работ невозможно исчерпывающе описать и задать адекватные критерии качества.
Разработчики ребята в основном неглупые и ленивые, и всякие KPI часто воспринимают как вызов, сам даже за собой замечаю. Вы мне KPI, а я вот найду способ нихрена не делать и иметь самый высокий из возможных KPI, не потому что так уж хочу ничего не делать, а просто из спортивного интереса :)
Оцениваем разработчика на основе объективных данных
Единственный нормальный вариант, на мой взгляд — работа относительно небольшими командами, в таких командах все на виду и халявщики особо не побездельничают. Коллеги лучше видят кто чем занимается, кто пашет, а кто фаллосы пинает. Просто руководству надо больше внимания уделять коллективу, общаться и люди сами все расскажут как есть, без всех этих шаманских KPI.
Перевести их на то, что лет 30 назад в Союзе называли "хозрасчёт".
На самом деле сейчас выпускные классы сводятся именно к натаскиванию на решение определенного шаблона проверки знаний. Зачастую вам не пытаются составить всю структуру знаний, а дают именно подход для корректной сдачи экзамена. При этом в реальности человек может вообще не понимать, как эти знания применять. Точно как в примере с собеседованием — проходить умеют, а работать — нет.
ЗЫ это субъективный опыт, основанный на собственно сдаче (больше 10 лет назад) и на том, как учатся на текущий момент младшие братья\сестры жены, аккурат возраста сдачи ЕГЭ и ГИА…
При этом в реальности человек может вообще не понимать, как эти знания применять.Там все еще хуже — в половине предметов знать как применять знания вместо тренировки шаблонов может легко дать заметно худший результат. Потому что проверять будут по шаблонам, но шаблонный ответ не всегда вообще правильный.
За все предметы не скажу, но, объективно, ЕГЭ по информатике усложнился за 10 лет.
А еще я тоже сдавал ЕГЭ 10 лет назад)
Ну я вот заканчивал школу когда этот ЕГЭ только еще вводился в пилотном режиме: в некоторых школах и некоторых регионах, и только потом его уже начали вводить массово. Плюс я в высшей школе, включая учебу, провел лет эдак 15 наверное :-) Зато вот жена у меня как раз попала на ЕГЭ, еще и сдавала его дважды с большим гапом — после школы и после технаря :-)
До ЕГЭ выпускные классы натаскивали на выпускные экзамены и решали шаблонные задачки, и параллельно выпускники ходили к репетиторам, чтобы те их натаскали на вступительные экзамены.
После введения ЕГЭ — старшеклассники натаскиваются на ЕГЭ и параллельно ходят к репетиторам дабы дополнительно натаскиваться на этот же ЕГЭ.
Вот ничего не изменилось. Вообще ничего.
Единственная ощутимая разница, что распределение выпускников стало меняться (не сразу причем): если раньше заметная часть оседала в универах недалеко от места жительства, то сейчас «стобальники» ломятся в столичные вузы. В общем свободы поступления стало больше. Хз, хорошо это плохо, но если бы я попал под ЕГЭ, то однозначно пошел бы в МГУ, а так пришлось учиться в универе по-проще. Коррупционная составляющая походу также уменьшилась: подозрительных выпускников «стобальников» встречалось куда меньше чем подозрительных медалистов, и частота подозрительных медалистов стала в общем-то уменьшаться.
А самое главное, в школе в общем-то особо больше и нечего делать, кроме как натаскиваться. Основные школьные знания — это по большей части тупо механические навыки элементарной алгебры и геометрии, в которой, ну вообще нет ничего такого, особенного, и правил русского языка — это вот обязательные предметы. И именно это ЕГЭ и проверяет, причем проверяет достаточно широко: если взять математику, то там ровно те задания которые школьник и должен уметь решать, причем делать это механически — если человек не помнит тригонометрические тождества или не может сходу решить квадратное уравнение, то в институте ему будет грустно… правда в институте уже достаточно много возможностей чтоб схитрить, а контроль знаний уже не является таким всеобъемлющим. А уж такие специфические школьные предметы как биология или физика, и аналогичные, лучше вообще забыть сразу после школьного выпуска — они очень далеки от реальности и в универе их придется все равно учить заново, но уже по-нормальному: они и до введения ЕГЭ и после введения ЕГЭ являются чисто ритуальными.
Замечу что в США тесты вообще везде сдаются, причем школьный выпускной SAT больше похож на тест по IQ + тест по английскому языку. И далее тесты сдаются на протяжении всего обучения, в том числе и в аспирантуру (GRE и GMAT). Вроде бы не жалуются — вон в прошлом году нобелевскую премию по физике очередной раз получили американцы (один из них правда французско-американский ученый) из американской же Bell Lab, но у них не только там достижения…
Кстати, то, что остатки хвалёной советской системы образования с трудом справляются с тем, чтобы подготовить среднего школьника к сдаче довольно простого (пока вы не целитесь в 80+, большинство экзаменов не очень сложные) экзамена без зубрёжки — это больше говорит об этой самой советской системе образования, чем о ЕГЭ и ГИА.
Т.е. это косяк реализации, а не косяк самой абстрактной модели и ее целей\задач
более прозрачная система
Абы какие выпускные в школеДействительно, очень прозрачно и полезно.
а потом уже подросток сам решает что хочет делатьДа и сейчас решает.
И от этого уже зависит что он будет сдаватьИ сейчас зависит, набор предметов и разница между профильной и общей математикой определяется именно тем, куда вы будете поступать.
и в каком объемеУниверсальный стандарт, определяющий. что вузы набирают не «кого понравится», а людей, которые по некоторому универсальному показателю показали себя лучше остальных — однозначно вин, это не обсуждается даже.
Универсальный стандарт, определяющий. что вузы набирают не «кого понравится», а людей, которые по некоторому универсальному показателю показали себя лучше остальных — однозначно вин, это не обсуждается даже.
Егэ не решение проблемы коррупции на вступительных экзаменах, оно конечно решило эту проблему, но привнесло еще кучу новых в и без того полную проблем систему образования. Вузы теперь вынуждены снижать свою планку до уровня егэ, либо терять студентов. Выпускники спецшкол с углубленным изучением теряют преимущество.
Вуз должен набирать тех, кто понравится вузу, а не государственным экзаменаторам. Выпускной экзамен не должен заменять вступительный.
Вузы теперь вынуждены снижать свою планку до уровня егэ, либоНет, вузы просто набирают полные потоки олимпиадников.
терять студентов.
Выпускники спецшкол с углубленным изучением теряют преимущество.Нет, они гораздо легче сдают ЕГЭ, пишут олимпиады, и тем самым или получают 100 баллов за предмет автоматически, или вообще поступают без вступительных испытаний.
Государственный вуз, работающий на мои (и, вероятно, ваши — вы же тоже в/из России, как я понимаю) налоги не имеет никакого права набирать «кого понравится», должны быть объективные критерии.
Объективные критерии: результаты вступительных экзаменов. Пускай в той же форме, что ЕГЭ, но вот содержание каждый вуз точно должен иметь право выбирать сам.
Ваш вариант работает только в случае если приемом занимаются кристально чистые люди на всех уровнях.
Государственный вуз, а мы говорим о них, это не частная организация. Это организация с как минимум частичным бюджетным финансированием, которое осуществляется в том числе из налогов. И такая организация не должна принимать решения по воле левой пятки учёного совета или отдельных людей в структуре вуза, потому что чем больше власти замыкается на этих людей, тем меньше вероятность того, что эти решения будут приниматься ангельски честно. Они уже так не принимаются, это я вам как недавний студент скажу — в вузах очень много внутреннего политиканства, стремления ухватить побольше денег из самых разных источников, и так далее.
Автономный внутренний экзамен — это очень хорошая мотивация делать курсы в ключе «готовься у нас или
Абы какие выпускные в школе
Действительно, очень прозрачно и полезно.
Можете обосновать необходимость выпускных экзаменов в школе?
Система оценки знаний может и хорошаяя, но вот использование её в качестве основного критерия приёма в вузы — нет.
Просто изначально верная задача «отсеивать неподходящих кандидатов» неверно решается. Вводя формальные признаки фильтрации надо понимать, что искомая выборка характеризуется этими признаками. И вот на этом этапе облом, потому что искомая выборка «ведущие программисты» не обладает признаком «умеет решать алгоритмические задачи».
Очень редко пишут про работу в консалтинге, интересно что это за зверь такой. Можете пару слов писануть — как это работает, есть ли такие компании в России, правда ли что там авральный режим но огромные зарплаты и периоды безработья ?
С российской спецификой консалтинга знаком поверхностно, однако автор текста тоже не в РФ работает.
Если коротко, то консалтинговая фирма сосредотачивается на технической и/или функциональной компетенции сотрудников, продавая их клиентам на проекты по дневной ставке на несколько месяцев. Миссии экспертизы/аудита более короткие, от нескольких дней до недель. Клиент доверяет фирме, поэтому на короткие миссии вообще никаких собеседований не происходит, на длинные — одно-два, обычно совмещенные. Зарплаты немного выше, чем на постоянных позициях, но не в разы, конечно. Неудобство разве что в сильной динамике среды. Тем, кто привык годами «пилить» одно и то же с теми же и на том же будет трудно.
В рунете подобные фирмы называются галерами и отношение к ним неоднозначное.
Консалтинговая фирма по определению небольшая. Когда она растет, то либо начинает брать заказы, проекты себе, либо превращается в «галеру» (бодишоп в США, продавцы мяса во Франции) и перестает быть консалтинговой — в крупной фирме нельзя удержать экспертов, большая текучка, уровень компетентности быстро падает.
В крупной фирме это дорого и хлопотно, поэтому их единицы, тогда как типовая консалтинговая фирма оптимального размера — 50-150 человек.
P.S. Минусовал не я, не люблю это дело. Только «лайки», LinkedIn рулит :)
Сколько времени может занимать консалтинг на одном проекте и когда это перестает быть уже консалтингом и становиться аутстафингом ?
Но дело не столько во времени, консультант должен привносить навыки и умения, отсутствующие в данный момент на проекте. Их и аккумулирует фирма, продающая услуги.
Если сотрудника просто послали на неделю пятым сишарп-программистом, чтобы заткнуть «дыру», то это чистый аутстаффинг.
Спасибо! Звучит очень интересно, пойду гуглить где такие специалисты нужны.
Успехов вам!
Ну и широкий кругозор — часто после внедрения системы Х будут спрашивать, что лучше внедрять и интегрировать к ней, продукт Y,Z или что-то ещё и если вы знаете о них, а лучше — и о подводных камнях этих систем, ваш контракт продлевают и расширяют.
Смотря откуда сотрудник и какие у него взгляды. Работаю в чём-то подобном в Японии и вижу полный спектр эмоций — кто-то доволен чисто потому, что в Японии; кто-то недоволен из-за того, что не дома; кто-то вообще на седьмом небе ибо палкой не бьют и хорошо.
Понятно, что у мьянмийца, который приехал с зарплаты в 70 баксов, будет кайф и стремление удержаться, а у кого-то типа меня наоборот — ибо платят меньше, ходить в офис надо, монитор мелкий, клавиатура из говна, мышка в руке теряется, вместо кода спагетти и вообще шавухи купить негде :-)
Ниже не про консалтинг. Консалтинг, это когда ты сам делаешь себе фирму, и сам платишь себе зарплату, выставляя клиенту счет за услуги: это может быть тюнинг виртуальной машины, оптимизация производительности, ускорение базы данных, перевод на новую платформу, а может быть и обычное программирование. Суть в том, что репутация работает на вас.
К консультантам обращаются, когда либо не хватает собственной экспертизы, либо нужно подтвердить уже разработанное решение именем известной компании.
В России консультантов на любой вкус. Размер зарплаты зависит от конкретного вида консалтинга, загруженность — от того, насколько хорошо дела идут у компании.
Альтернатива задачкам — работа в консалтинге
Для меня альтернатива задачкам сделать рабочий, оплачиваемый мини-проект перед устройством на работу. За это время познакомишься с командой, постановкой задачи, внедрением и другими важными подводными камнями и тараканами.
Там где спрашивают про задачи не работал, не сложилось, но 2 компании где делал тестовые проекты, перед устройством, самые классные (тфу-тфу-тфу).
Это была лично моя инициатива проверить компанию и что бы компания проверила меня.
Я уже описывал свои критерии выбора работодателя, повторятся не буду, может кому будет интересно habr.com/ru/post/423953/#comment_19142917"
Автор находится на самом начале пути, в стадии отрицания. Очевидно, что его 5-летний опыт не релевантен рынку, т.к.:
а) Он не менял работу и начал профессионально деформироваться (в компаниях редко бывают разнообразные проекты, если только это не consulting). Скорее всего, рынок ушел сильно вперёд.
б) 5 лет без собеседований. Крышки люков и автобусы теннисных мячиков постепенно уходят в прошлое, большое О и красно-черные деревья остаются, набирает популярность код в прямом эфире, тестовые задания больше походят на реальные проблемы.
в) Зона комфорта, высокомерие и тонкокожесть. Автор очень болезненно переживает стадию «окунания в г*но» на собеседованиях, возможно заболел по этой же причине. Лечится работой над собой и своими навыками: codewars.com, фильмами про Рокки, Karate Kid и тд.
г) Senior в одной компании != senior в другой. На новой работе выслуга лет и опыт работы с конкретными людьми над определенным продуктом могут обесцениться практически полностью. Остаются только эмпирический опыт и computer science.
б) устраивался в одну международную контору, они меня своими задачками три часа мучили, меня это откровенно на втором часу
в) окунание в гогно — это эдакий способ сбить цену работнику, так себе, если с ходу, незнакомого человека макают в гогно — лесом товарищей.
г) сеньор это таки не совсем про опыт, хотя он тоже важен, он скорее про способ мышления.
а) Пять лет — целая жизнь по меркам технологий. При найме человек, как правило, более-менее соответствует требованиям рынка, но со временем начинает отставать, тк бизнес ориентируется на проверенные временем, часто «уже не модные» решения.
Исключения тоже есть. Из моей практики это либо консультанты (у них каждый проект может быть уникальным, надо постоянно быть в тонусе), либо AAA-компании в авангарде индустрии (Google, Facebook и тд)
б) В последние разы меня просили написать более-менее реальные CRUD приложения, а один раз просто дали кусок продакшена и попросили запилить фичу, попутно разобравшись с их архитектурой кода.
в) Под «окунанием» я имел в виду сам процесс прохождения собеседований со стороны соискателя, особенно без знакомств. Не думаю, что кто-то наслаждается процессом общения с незнакомыми (часто неприветливыми) людьми, пытаясь доказать, что «не верблюд». На это уходит много нервов и сил, а результат неизменно непредсказуем.
г) Я использовал в контексте должности. Senior в ООО «Рога и копыта» != Senior в Google.
На определенном этапе карьеры должности перестают значить так много, как вначале. Иногда имеет смысл перейти работать на меньшую должность (и ответственность) и большие деньги в более высокотехнологичную компанию (win-win), а потом еще и получить там повышение (еще один win).
Совершенно не обязательно. Я неоднократно менял проекты в пределах компаний, и это был не консалтинг. Особо модных решений может и не было, но одинаковых все пять лет не было тоже.
По моему личному, субъективному, не претендующему ни на что 14-летнему опыту — интересные и актуальные решения на продакшене в энтерпрайзе встречались в 10% случаев.
> (в компаниях редко бывают разнообразные проекты, если только это не consulting)
Я и не спорю с вашим личным мнением. Я только уточняю, что исключения в этом пункте — не обязательно консалтинг. Это, к примеру, крупные и очень крупные банки. А таких видел не меньше трех.
Готовьтесь к решению тестовых задачек, пока время не поджимает.
Никогда не понимал, зачем. Потребность в программистах, а особенно в таких, кто реально может решать задачи, которые нужно решить — огромна, и пока что всё только растёт.
В таких условиях реагировать на попытки дрессировки тебя неумелыми нанимателями (через решение задачек, через вопросы о круглых люках, и прочую байду) — совершенно излишне. Просто идите к тем, у кого на собеседованиях нет повышенного градуса неадеквата, а от остальных немедленно уходите, встретив первые признаки неадеквата.
Когда не очень — … тогда придётся учиться проходить собеседования.
Но таких людей — единицы, среди безбрежного океана странных личностей.
Я в разное время видел много соискателей… и это грусть-тоска. =)
Я уже не говорю про то, что потом за ними в коде остаётся.
Так что — первых разбирают достаточно бодренько (по крайней мере, больше 3-4 собеседований они редко проходят, что бы не получить оффер), а последние — учатся проходить собеседования.
Лично у меня опыт просто противоположный. Да просто сделайте профиль среднего сениора на степстоне или монстере и посмотрите сколько предложений вам придёт в течении первого дня :)
Вы мне сейчас действительно хотите рассказать что в Германии стоит очередь в 20 человек на какое-то айтишное рабочее место, да ещё и в контору типа KPMG, где не особо новых технологий не используют, ни условия труда идеальными назвать нельзя, ни звёздочки на кунуну особого впечатления не производят? :)
Именно так. Потому как это мой свежий личный опыт с небольшим инсайдом + опыт коллеги, подававшегося туда же месяц назад. Просто они могут себе позволить хантить со всего ЕС + привет Brexit, подкинувший до фига народа из Англии на рынок во Франкфурте. По слухам, в Commerzbank ровно такая же картина — конвеер на сотни кандидатов.
привет Brexit, подкинувший до фига народа из Англии на рынок во Франкфурте.А как именно брексит привёл к этому?
таких обычно они отсеивают, потому-что непонятны мотивы почему человек в возрасте со знаниями на 300 000 идет на 30 000, ибо это явно не тот предел для такого специалиста.
А открыть рот и словами спросить человека, почему он так делает — не? Слишком сложно?
1. на куда джуна проще пройти если до этого программированием почти не занимался, например раз в неделю (электронщик или админ) или
2. или есть желание просто попробовать новую отрасль без заморочек со всеми этими свистоплясками с 5-10 собесами и цирком у доски. или просто хочешь обучиться чему то нахаляву да ещё на кофе заработать (почему бы и нет?).
3. есть очень хорошие компании которые совершенно не умеют искать и собеседовать людей и поэтому проще уйти на минимальную должность (умолчав что ты спец в искомой ими области с 20летним стажем) и быстро получить повышение, тем-более если финансовый жирок позволяет.
4. Я знаю одного человека который тусил по компаниям которые пользовались трудом неопытных студентов с ставкой в 20-30тр и в свой стартап набрал оттуда сливки — команду крепких разрабов которые остальных тащили и задалбывались, в итоге стартап выстрелил в тех плане.
Если вы хотите в фейсбук, амазон или "неадекватный" гугл, задачки решать пртдется научиться.
Я поясню, почему скажем я совершенно не хочу в фейсбук. Для начала — на мой взгляд, все их видимые снаружи продукты — полное г. Я не утверждаю, что мои продукты скажем лучше — просто у меня не возникает желания ассоциироваться с этим. Иначе говоря, доверие к компании — на нуле. Гугль… ну это другое, но не сильно лучше. Наверное, в дебрях алфавита можно найти очень интересные проекты с высокой зарплатой, но вот так чтобы бежать туда ради виллы в Испании?
Охотно верю при этом, что могут быть и другие взгляды на это, в данном случае это всего лишь мое лично мнение.
А если нет?
>Теперь с почти неограниченным пулом претендентов они могут себе это позволить.
и
>Потребность в программистах велика как никогда и тем более в Senior Developer'ах.
Когда я бывал на стороне нанимателя, я ни разу не видел живьем этот «почти неограниченный пул претендентов». И даже не слышал про такой. Только второй вариант имеет место — большая потребность, и малый выбор кандидатов. И даже не на синьорские позиции иногда.
А то, что я вижу, будучи кандидатом (особенно в случаях, когда не ищешь работу, а просто анализируешь поступающие самотеком предложения), как раз выглядит так, будто наниматель (не обязательно условные фейсбук и амазон, но и они тоже) вообще никакой потребности не ощущает.
>если вам после этих плясок туда не расхочется, разумеется
Очень может быть, что и до них.
Проблема в том, что не все. Я вот например не хочу. Причем давно. И не столько потому, что задачки не хочется, сколько потому, что хрен их поймешь, в какой проект тебя засунут в итоге. И именно гугли с фейсбуками этим как раз страдают в большей степени.
Впрочем, если сравнивать с любой другой типовой конторой — то да, у некоторых практически неограниченный. Ну и так, просто на заметку — из текста вроде бы не следует, что речь конкретно о гугле. Оно там как-то неявно очень сильно обобщилось.
И каждый раз я у них спрашиваю: мне все еще придется у вас 5 часов рисовать на доске фломастером всякие квик-мерж-хип-сорты, жонглировать красно-черными деревьями и считать О-большое?
Говорят — придется. До свидания.
А что именно за политика?
Понятно, ну его нафиг тогда.
Всегда предполагал, что все эти цветные офисы со столами для пинг-понга лишь для создания иллюзии уюта, а по факту большинство как на обычной галере торчит по 12 часов на работе и ничем этим не пользуется.
У нас в японской компании де-юре самопрокачка запрещена в силу белого списка софта и отгороженного политиками интернета.
Де-факто наш офис какой-то "удалённый" и поэтому имеет обычный неограниченный интернет, поэтому SSH с иксами домой в РФ и оттуда можно делать что хочешь.
Отстрелялись с релизом, клиенты ещё не пришли в себя от празднования, делать нефиг всё равно, так можно Rust покурить :-)
Работаю, чтобы накопить на перевозку крупногабарита и уехать домой, ну и параллельно по концертам всяким походить :-)
Здесь-то ограничений на сети нету, но на не-своём компе логиниться куда-то в свои аккаунты не хочется, поэтому удалённые иксы и только.
А до того сидел в компании, принадлежащей одному автопроизводителю, там да, был интернет через прокси и с кучей лимитов (в том числе отрублен habrastorage). Зато там видели моё собеседование и поэтому забивали на то, что я в свободное время пишу что-то своё, и игнорирую вайтлист, лишь бы не сбежал :-)
В локалке нашелся установочник макоси, засунул в виртуалбокс и вспоминал былое в икскоде.
А код в обход всех их изощрений прекрасно дёргался на гитхаб протоколом Git-over-GoogleMaps :-)
Впрочем, у них изощрения как раз были оправданными, ибо там серьёзные данные на машины, которые конкурентам были бы мягко говоря интересны. Что не отменяет того, что отношение удручает — ты NDA подпиши, но зондов мы тебе всё равно напихаем.
А код в обход всех их изощрений прекрасно дёргался на гитхаб протоколом Git-over-GoogleMapsВы имеете в виду Git over Google Translate?
Нет, именно мапсы.
Тянем репу зипом с гитхаба (ибо git не алё). Распаковываем, создаём внутри репозиторий гита. Уходим на бранч develop.
Работаем с кодом. Делаем коммиты как обычно.
В конце рабочего дня делаем (Cygwin)
git format-patch master --stdout | gzip --best | base64 > /dev/clipboardОпционально можно добавить шифрование.
Идём в гугловский My Maps, ставим пин на любимую кафешку, в описание делаем Ctl-V, чуть-чуть ждём и сохраняем.
Придя в безопасное окружение открываем мапсы, копируем то, что насохраняли и делаем (Cygwin)
cat /dev/clipboard | gunzip - | base64 --decode | git applyВуаля, коммиты из закрытой среды перетекли в открытую. Пушимся, на следующий день повторяем. Если из дома не работать, а только пушиться, можно зип не тянуть каждый раз (в моём случае было актуально для репы под 300 метров).
Можно было, конечно, всё заскриптовать, но больно сложно для пары раз.
В теории так выносятся любые файлы, как показала практика, емнип до 25 мегабайт (до закодирования) влезало в один пин спокойно, лишь бы браузер не грохнулся.
Заносить было проще, на крайняк приклеиванием хедера и куска от PDF к зашифрованному tgz с последующей выкачкой.
Что как бы намекает на всю эту "безопасность" без эиргапа...
Часто поуплрны пинг-понги всякие, когда пораньше уйти домой, получая те же деньги, нельзя
О пользе физической активности я в курсе, обычно хватает короткой прогулки, полезно для организма и дает возможность оторваться и подумать.
Если меня припечет работать именно в Гугле (или прочих буквах FANG) — пойду, конечно, обратно вспоминать все эти сортировки и прочее, которые мне пока в реальной работе пригодились примерно ноль раз. Поэтому я считаю что это бесполезное занятие на собеседованиях, в отличии от того же Distributed Systems Design который у них есть на SRE.
Но хрен с деревьями этими, у них же по личным занятиям в свободное время политика драконовская.В Европе, вроде, такое невозможно. Представляю себе что тут начнется если работодатель начнет мне указывать чем в свободное время заниматься… дикость. Минус 1 балл к переезду в US :)
Уже давно, вроде как, можно писать код не на доске, а на предоставляемом ноутбуке. Да, в примитивном текствовом редакторе, без автодополнения и подстветки синтаксиса, но никто и не смотрит на интервью, если вы опечатаетесь где-то или порядок аргументов в библиотечной функции перепутаете.
В Гугле, техническое интервью представляет из себя общение с сеньором/лидом на технические вопросы и последующее решение задачки, но онлайн и без привязки к синтаксису (хоть псевдокодом), лишь бы логика была верная.Так это первый, удаленный этап же. Потом ты топаешь к ним в офис и имеешь 4-5 интервью по часу с разными людьми и вайтбордом. Может вайтборд уже и позволяют заменить на ноут, как указали выше, но это не делает процесс более полезным на мой взгляд.
Ответ был такой: есть несколько команд которые заинтересованы, поэтому на очном интервью, будут этапы с каждой из нихНет там команд в контексте интервью. Каждое из них с отдельным человеком — он потом пишет отзыв в Hiring Committee, который уже по совокупности отзывов от всех интервьюеров решает брать тебя или нет. И вот уже после этого только возможен выбор команды.
Это насколько я понял как раз один из их способов избежать предвзятости при найме. Сомнительный, как по мне…
В итоге я тоже на эти галеры не попал, о чем нисколько не жалею.
В любом случае я давно уже не связываюсь с местами где неоплачиваемая работа в выходные считается нормой рабочего процесса, поэтому ни о чем не жалею.
А раз чёрные списки скорее всего существуют, то проблема в статье ещё сильнее усугубляется: Даже если предположить что только часть компаний их придерживается, то при невезении всего с одной все остальные лишаются специалиста. И наверное поделом им.
После этого решил на зазывания их рекрутеров забить, только время тратить без обратной связи нормальной.
a = 1
b = a
a == b vs a is b
Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++. В итоге интервьюер надменно «очень удивлюсь если это действительно так». Через HR я попросил передать ему книжку Python для чайников и больше не писать мне.
a = 1Не могли бы раскрыть свою мысль и направить в документацию в правильном направлении?
b = a
a == b vs a is b
Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++.
На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
a == b # сравнение по значению
a is b # сравнение по object id, на который ссылаются переменныеa = [1, 2, 3]
b = a # произойдет присвоение по ссылке
с = a.copy() # произойдет присвоение по значению
d = a[:] # произойдет присвоение по значению
# Значения всех трех переменных равны:
a == b # True
a == c # True
a == d # True
# Но переменные a и b ссылаются на один и тот же объект списка:
b is a # True
# А переменные c и d ссылаются на отдельные объекты:
c is a # False
d is a # False
# Модифицируем данные:
a.append(4)
b.append(5)
c.append(6)
d.append(7)
# И получим:
a == b # True
a == c # False
a == d # False
b is a # True
c is a # False
d is a # False
# Через переменные a и b был поочередно модифицирован один и тот же объект.
# Значения этих переменных по-прежнему равны:
a # [1, 2, 3, 4, 5]
b # [1, 2, 3, 4, 5]
# А для переменных c и d - нет:
c # [1, 2, 3, 6]
d # [1, 2, 3, 7]Небольшие integers (кажется, до 16 но не ручаюсь) существуют в памяти Python программы как синглтоны и все ссылки указывают на один и тот же объект в памяти.
Если размер переменной меньше, чем указателя, её таким образом не оптимизируешь.
Нет, я не путаю с интернированием строк. В этом и суть плохого интервьюера: свои рассуждения ставить превыше знания того, как работает интерпретатор. Все прекрасно оптимизируется, только не так, как вы думаете.
docs.python.org/2/c-api/int.html
В памяти хранится весь массив int в пределах, который попадает под оптимизацию.
В чем в примере выше ошибка по существу?
Был бы признателен за конструктивную критику.
По поводу, "больного", запыхавшегося. Я бы сходу выдал что-то подобное: "так к вам спешил, что аж дыхание сбил, да и погода внезапно намекнула, что одеться нужно было полегче". Имхо, много бы вопросов сняло :) Я, бывает, вставляю словечки, которые актуальны для игроков в онлайн PRG, так меня с опаской сразу спрашивают — в онлайн игры играете? Приходятся говорить, что любимая RPG — Fallout 2, разок в год-два пробежаться. В общем, тут скорее вопрос коммуникации. Честно, каким бы мегаграмотным не был бы человек, с ним ещё общаться нужно.
Ваша реплика про опыт в ЕПАМ укрепляет меня в догадке, что уже даже среди программистов подбор персонала стал «не про специальность» (ну и градации, в зависимости от компании, от «совсем не про специальность» до «не совсем про специальность»).
Про «нравишься» и «не нравишься», про возраст (скоро стукнет 45), про рынок труда который отдельные представители HR так структурировали (есть примеры корпораций и компаний), что приходящие вновь команды не могли не то, что специалиста нанять… На интервью никого затащить. При весьма конкурентных предложениях, ведь в кругу нужных специалистов 3% слила одна из предыдущих команд, 15% побывали на интервью и были растоптаны.
И в этом контексте желание научится решать задачки выглядит довольно мило.
Их обязательно нужно уметь решать. Однако это сомнительный гарант устройства на работу.
А потребительское отношение к кадровому ресурсу — короткая дорога, оканчивающаяся тупиком.
Хорошо если 1 час. В некоторых компаниях приходится проходить N собеседований по часу, на которых решаешь задачки. Где N зависит от количество команд, в которых открыты вакансии. Может быть 5, а может 11.
А если в итоге прошел, остаток жизни приходится жевать сопли на бесконечных митингах, где менеджеры, дизайнеры, тестировщики и разработчики спорят, в какой цвет красить кнопочку.
Хотя изначально надо было просто узнать форму корпуса и чёртёж посадочного места что обычно делается за пару бесед с адекватным бизнес процессом не нацеленным на оправдание завышенной стоимости. Да они потратив миллионы рублей на совещания потом ещё тянули до последнего с оплатой несчастных 50тр.
Это у ракутена такие приколы?
Помню, они пытались меня схантить, видимо хорошо, что не поддался :-)
А что… Пишешь эссе с названием "Моя (не)великая борьба" где просто стебёшься над тремя месяцами собеседований. Да ну его нафиг, им специалист или жополиз нужен?
Оффер получил, не поехал.
О, я тоже в Ракутен собеседовался, мне тоже дали книжку. Я прямо спросил "Это обязательно? А то я не люблю весь этот успешный успех", мне ответили "Ну не хотите — не читайте, положено предлагать, а дальше дело ваше. Всё равно, никто не спрашивает."
"А что, так можно было!?" :)))
Видимо, можно, оффер-то мне выдали. Я даже думал его принять — всё же, Япония, экзотика, пару лет вполне можно поработать, но огорчил отпуск — 11 дней и нельзя выбирать самому даты. Даже с учётом золотой и серебряной недели это слишком мало.
Скорее, это Ракутен считается "гайдзино-дружелюбной" компанией в сравнении с остальными.
11 рабочих дней за год положено после полутора лет работы. См. 4.5.8 здесь.
ИМХО, это только если очень хочется "за границу". Либо ну очень сильно к их культуре тянет. Климат тоже… Теплее, чем у меня во Владивостоке, но так же влажно. Да и менталитет относительно работы у них другой.
Верно угадали. Приятель проходил два года назад, он забил после 11 собеседования. Я проходил этот квест в июне было 5. Никаких вопросов про паттерны, языки программирования, базы данных и т.д. Тупо решаешь задачки.
Но проблема в том, что многие интервьюверы считают решение задачек чуть ли не единственным критерием адекватности нанимаемого. Бывают даже забавные моменты когда проводящий интервью знает меньше по теме и поэтому любое отклонения от его (не совсем верного) ответа считает полным провалом.
Или отсутствии корреляции с тем, что надо будет делать на новой позиции как верно подмечено.
То есть, если очень уж хочется задачки, но их надо считать больше дополнением, а не основной темой собеседований на работу.
Все правда, все о нас...
Однако обижаться не стоит. Просто цена ошибки при найме довольно высока, а нормальных способов оценки кандидатов нет.
нормальных способов оценки кандидатов нет
Есть. Но они требуют наличия собственных профильных специалистов уровнем как минимум не хуже. Если таких нет — то всё сложно, да. Либо устраивать конкурсы олимпиадников и в итоге нанимать профессионального проходителя собеседований, либо пытаться просто по человечески пообщаться, и нанять того, кто не может работать, но может навешать достаточно лапши.
Если же собственные спецы есть, то просто разговор «по душам» о прошлом опыте и сложных случаях из жизни плюс минимальная проверка способности писать код (не олимпиадные задачи на время, а что-то уровня FizzBuzz), чтоб исключить профессиональных обманщиков — вполне достаточна.
разговор «по душам» о прошлом опыте и сложных случаях из жизни
Может быть проблемным, если много что под NDA.
Вряд ли NDA защищает диаграмки вида "вот тут у нас сыпались сообщения в очередь, сервис разбирал и писал в эластик, а вот тут фронт оттуда читает"
Я сказал, что есть задачи, к которым очень сложно задать разумные вопросы, и от которых совершенно невозможно отойти вправо-влево и развить беседу, если не понимать бизнес-задачи проекта, которые могут быть закрыты NDA.
Я спрашивал нескольких разработчиков, которые работали в этой компании, как им приходилось использовать эти конкретные знания в работе. Самый лучший ответ: «Знание о том, как работает сборщик мусора, нужны чтобы пройти интервью. Больше они не нужны.»
Знание как работает GC нужны, чтобы понимать когда объект будет удален, чтобы понимать что если мы только что освободили большой объект и хотим сразу создать еще один большой объект, то нельзя расчитывать что память уже есть, её вполне может не быть(правда тут надо смотреть на конкретный GC, потому что есть такие, которые увидят что памяти не хватает и грохнут ранее освобожденный объект, а есть такие, которые так не делают. и это надо знать).
В общем и целом, такие особенности рабочего окружения знать надо.
Если ваши коллеги и вы живете без этого знания, скорее всего вы либо пишите мелкий софт, либо плохой.
Как часто вы создаете объекты размером со всю доступную VM память?
Как часто вам встречаются бизнес задачи, требующие создания объектов размером со всю доступную память?
Как часто вы создаете объекты размером со всю доступную VM память?Это и не нужно. Достаточно в цикле читать и обрабатывать какую-нибудь таблицу (или запросы). Если в этом цикле используются любые ресурсы ОС, то забыть закрыть ресурс (а с ним и все связанные объекты) очень даже легко. И даже если не забыть, то не факт, что сборщик будет чистить так, как вам бы хотелось. Мне как-то довелось оптимизировать память процессу на яве. Поставил явный вызов GC, хоть во всех мануалах пишут, что это делатьне надо. Коллеги на ревью удивились, но после демонстрации уменьшения памяти на 50% смеяться перестали. Так что всяко бывает, а памяти всегда мало.
забыть закрыть ресурс
Это не "объект размером с память", это баг.
не факт, что сборщик будет чистить так, как вам бы хотелось
Для этого придумали пулы объектов.
Поставил явный вызов GC
Вам сильно повезло. Обычно жор памяти в Java = утечка. С множеством короткоживущих объектов GC справляется без полной остановки, чисто за счет Эдема.
Вам сильно повезло. Обычно жор памяти в Java = утечка.Вот код без утечек, только-что запускал:
public class MyTtest {
public static void main(String argc[]) {
while(true) {
List<String> arr = new ArrayList<String>();
for(int i=0; i<10000000; i++)
arr.add(new String("abc"));
System.out.println(new java.util.Date());
System.gc();
}
}
}
Запустил без строчки с GC, процесс быстро набрал 2GB оперативки, CPU циклично скакал от 25 до 90%,
Mon Jul 22 15:39:31 EDT 2019
Mon Jul 22 15:39:34 EDT 2019
Mon Jul 22 15:39:34 EDT 2019
Mon Jul 22 15:39:35 EDT 2019
Mon Jul 22 15:39:35 EDT 2019
Mon Jul 22 15:39:37 EDT 2019
Mon Jul 22 15:39:37 EDT 2019
Mon Jul 22 15:39:39 EDT 2019
Mon Jul 22 15:39:39 EDT 2019
Mon Jul 22 15:39:42 EDT 2019
Mon Jul 22 15:39:43 EDT 2019
Mon Jul 22 15:39:43 EDT 2019
Mon Jul 22 15:39:46 EDT 2019
Mon Jul 22 15:39:46 EDT 2019
Mon Jul 22 15:39:47 EDT 2019
Mon Jul 22 15:39:50 EDT 2019
Mon Jul 22 15:39:50 EDT 2019
Mon Jul 22 15:39:51 EDT 2019
Mon Jul 22 15:39:51 EDT 2019
Mon Jul 22 15:39:51 EDT 2019
Mon Jul 22 15:39:53 EDT 2019
Mon Jul 22 15:39:53 EDT 2019
Mon Jul 22 15:39:54 EDT 2019Запустил с GC, процесс не кушал более 1GB, CPU установился на 60-65%,
Mon Jul 22 15:31:54 EDT 2019
Mon Jul 22 15:31:54 EDT 2019
Mon Jul 22 15:31:54 EDT 2019
Mon Jul 22 15:31:54 EDT 2019
Mon Jul 22 15:31:54 EDT 2019
Mon Jul 22 15:31:54 EDT 2019
Mon Jul 22 15:31:55 EDT 2019
Mon Jul 22 15:31:55 EDT 2019
Mon Jul 22 15:31:55 EDT 2019
Mon Jul 22 15:31:55 EDT 2019
Mon Jul 22 15:31:55 EDT 2019
Mon Jul 22 15:31:56 EDT 2019
Mon Jul 22 15:31:56 EDT 2019
Mon Jul 22 15:31:56 EDT 2019
Mon Jul 22 15:31:56 EDT 2019
Mon Jul 22 15:31:56 EDT 2019
Mon Jul 22 15:31:57 EDT 2019
Mon Jul 22 15:31:57 EDT 2019
Mon Jul 22 15:31:57 EDT 2019
Mon Jul 22 15:31:57 EDT 2019
Mon Jul 22 15:31:57 EDT 2019
Mon Jul 22 15:31:58 EDT 2019
Mon Jul 22 15:31:58 EDT 2019
Mon Jul 22 15:31:58 EDT 2019Резюме: явный вызов GC в правильном месте делает программу менее требовательной к памяти, быстрее, и без лагов. Везение тут не при чем.
Резюме: так писать не надо, и вот почему:
- с добавлением ноликов в условие цикла разница будет все менее заметной
- в многопоточном приложении вы получите паузы во всех потоках, и это не обязательно то, что вам позволено
- более того, явный вызов GC совершенно не гарантирует запуск GC, это зависит от множества факторов и малопредсказуемо в общем. Например, в моем случае (openjdk-11/i7-8750H/16G) в данном примере постоянный вызов GC жрал те же 100% проца и вдвое больше оперы, чем без явного вызова. Зато замена GC на Thread.sleep(500) успокоила процессор в прежних пределах памяти.
- если придираться: конкретно в этом случае стоит использовать пул. Думаю, это понятно и так, просто сделано в угоду постоянному выделению большого куска памяти, но на практике такое даже джуны себе не позволяют. Кейсы с массивным выделением памяти обычно предсказуемы и предусматриваются архитектурой приложения в особом порядке.
с добавлением ноликов в условие цикла разница будет все менее заметнойвообще-то, если добавить нолик, то у меня программа без GC просто падает достигнув 2GB RAM (java se 1.8 под виндой). А с GC работает.
в многопоточном приложении вы получите паузы во всех потоках, и это не обязательно то, что вам позволеноне факт, ведь я же не получаю паузы в одном потоке, даже наоборот — в данном однопоточном быстодействие с GC в разы выше.
более того, явный вызов GC совершенно не гарантирует запуск GCздесь полностью согласен, нужно экспериментировать
если придираться: конкретно в этом случае стоит использовать пуля список сделал такой большой чтобы сразу было понятно чем занята память процесса — надо же чем-то заполнить пару гигов. Но при других значениях счетчика я получил похожий результат, что с GC работает лучше: видимо моя имплементация GC прислушивается к советам, и это позволяет оптимизировать программу.
Вобще всему этому есть объяснение: только программист может знать когда в его программе лучше сделать сборку мусора, так как это зависит от множества факторов, которые из кода и рантайма вычислить или невозможно, или слишком сложно, и поэтому такая задача сборщику может быть в принципе не под силу. Поэтому хотелось бы, чтобы со сборщик перестал быть черным непредсказуемым ящиком.
только программист может знать когда в его программе лучше сделать сборку мусора
…
Поэтому хотелось бы, чтобы со сборщик перестал быть черным непредсказуемым ящиком.
В чём проблема? Пишите на Rust.
программа без GC просто падает достигнув 2GB RAM (java se 1.8 под виндой). А с GC работает.
Что вообще-то ненормально — разница всего лишь в явной рекомендации вызова мусорщика. При тесной физической памяти мусорщик должен вызываться и без запроса.
ведь я же не получаю паузы в одном потоке, даже наоборот — в данном однопоточном быстодействие с GC в разы выше.
Я не о том. В случае сервера приложений вам прямо запрещено так вызывать мусорщик — будут остановлены все потоки, которые заняты неизвестно чем и насколько важным для пользователя.
Поэтому хотелось бы, чтобы сборщик перестал быть черным непредсказуемым ящиком.
В языках, предусматривающих высокие нагрузки, это не просто не черный ящик, это хрень с кучей параметров и ручек для тонкого тюнинга под конкретные задачи, требующая отдельных скиллов. Даже у нас здесь получились противоположные результаты, хотя язык один и тот же.
А с чего вы это взяли? Или про nop не читали? И да, вот это ваше — «это не просто не черный ящик, это хрень с кучей параметров и ручек для тонкого тюнинга под конкретные задачи» тогда как понимать? Ну и для полноты — вы в курсе как ведёт себя GC при наличии нескольких class loader? С учётом кучи параметров и ручек для тюнинга, разумеется.
- Несмотря на то, что GC в JVM постоянно улучшается, энтерпрайзные заказчики крайне неохотно перелезают даже на Java 8, не говоря уже о более поздних версиях. И я не слышал о полном отказе от stop-the-world тактики в худших случаях GC даже с Java 11, такое умеет (умел?) только Azul — то есть всегда есть шансы получить StW, которые возрастают при ручном вызове
gc(). Может если порыть офдоку, где-то найдется явное упоминание StW независимо от количества потоков приложения (я не задавался целью найти), но просто по логике — общая куча + Full GC + старые не ThreadLocal-данные = хороший повод для StW. - Количество класслоадеров влияет на мусорщик только в том плане, что для деинициализации объекта нужен соответствующий его классу лоадер. В старых джавах была проблема чистки пермгена в случае нескольких лоадеров, потому что пермген в силу своей природы херово чистится. Сейчас с общим метаспейсом проблем мусорщика, связанных с класслоадерами, нет или мало (исключая случаи кастомных класслоадеров, но это еще более отдельная тема). Но я говорил о потоках, а не класслоадерах, а если потоки шарят общую кучу, StW вполне реален.
- Я вам не отвечку про настройки GC, потому как последний раз явно касался этого еще при Java 6, с коих пор прошло достаточно времени и изменений JVM, о которых знаю лишь в теории. В большинстве случаев вопрос о тюнинге памяти встает только после проблем с производительностью, и решение этого вопроса очень индивидуально.
Ваш подход аналогичен (да, немного утрировано, но...) написанию всего на ассемблере — быстро, не зависит от сборщиков мусора и т.д. Но только крайне дорого.
Да, здесь вступает уже личный опыт работы в финтехе. После нескольких случаев остановки сервера на переваривание хипа, только потому что кто-то не очень умный загружал сразу все данные без оглядки на их количество, а потом, видимо, наткнувшись на тормоза в стресс тестах, добавил gc() для успокоения совести, уже на наличие этой строки смотрится с двойным подозрением. Можно сказать, повезло, что эта строка там была, иначе ловить нам уже не тормоза, а падающий энв.
Я имею в виду, что что шансы StW сильно повышаются при явном вызове. И про черный ящик я не говорю, наоборот опровергаю — высокая нагрузка требует понимания внутренностей и подгонки их под конкретный случай, а это должно быть позволено языком/VM и документировано. Но я бы не спрашивал о тонкостях управлением GC на интервью, разве что позиция напрямую требует.
Явный вызов GC — это скорее симптом того, что у вас что-то не в порядке с самим алгоритмом. Как правило, в таких случаях достаточно несложно переписать так, чтобы, в принципе, минимизировать аллокацию памяти.
Это звучит примерно как: нас устраивало O(nˆ3), и всё было нормально до тех пор, пока n не начало расти.
С этой фразой всё в порядке.
На небольших n И/ИЛИ маленьких константах и n^3 может быть вполне нормально, т.к. всё равно быстро, а напишется за минуту в 4 строчки, скорее всего.
O() само по себе, в отрыве от значений констант и практических значений n, не несёт большого смысла. Вот когда n стремится в бесконечность, когда да, несёт, а так — нет.
Ну все хорошо, пока поведение гц такое. А учитывая что с любым апдейтом это может сломаться решение довольно хрупкое. Чтобы закостылить падающий прод еще норм, а вот оставить на постоянку такое. С такими приколами никто никогда не сможет обновить ни версию рантайма, ни сменить гц на альтернативный, потому что приложение внезапно начнёт странно падать.
Поэтому, посмотрев на результаты тестов, посоветовавшись внутри команды, и, естественно, с клиентом, коллегиально был сделан выбор вставить строчку с GC в код, а не переписывать кучу legacy-кода.
Клиент был очень доволен, так как этот вариант позволил решить проблему минимум на пару лет, а там условия и требования скорее всего опять изменятся.
Клиент был очень доволен, так как этот вариант позволил решить проблему минимум на пару лет, а там условия и требования скорее всего опять изменятся.Можно так сказать. Пофиксить умирающий прод действительно сойдет.
А можно сказать — «накинули еще тыщу техдолга в общий котел», если после фикса на эту строчку все благополучно забили.
Явный вызов GC — это скорее симптом того, что у вас что-то не в порядке с самим алгоритмом.
На самом деле нет. Учитывая особенности работы перемещающих сборщиков, сдвинув время вызова gc, можно на десятичные порядки снизить затраты на этот gc. Потому что сам по себе сборщик не знает, когда у вас достижимые объекты дают локальный минимум.
Я про то, что сначала стоит задаться вопросом: как избежать создания большого кол-ва объектов на ультракороткий срок? А не сразу переходить к вопросу: как побыстрее собрать мусор?
Чисто не там, где убирают, а там, где не мусорят )))
Я про то, что сначала стоит задаться вопросом: как избежать создания большого кол-ва объектов на ультракороткий срок?
Это как раз не вопрос, т.к. данный кейс нормальными сборщиками отрабатывается наиболее оптимально, в этом случае сложно заставить тормозить, а не наоборот :)
Так что избегать создания объектов на ультракороткий срок, обычно, не надо.
Проблема возникает в объектах со средней продолжительностью жизни — когда у вас етсь некоторая задача и выделяемые объекты нужны до окончания ее работы. И, конечно, зачастую можно справиться перереботкой алгоритма и ворохом микрооптимизаций. Но нередко одна строчка с вызовом гц даст значительно больший эффект.
Очень печально, конечно, что в той же jvm вызов гц по ручной команде не обязателен.
Вообще, жаль, что обычно программисту не дают способа локального тюнинга гц "изнутри" программы. Вроде как "вот на этом участке гц не вызывай" или "сделай мне здесь nursery размером Х" и т.п. вещи.
Как раз на днях конвертил ~100Gb видео потока. Немного ошибся с реализацией стрима и бац) Но я смог)
Знание как работает GC нужны, чтобы понимать когда объект будет удаленПри этом сама концепция GC создавалась, чтобы программисту не приходилось заморачиваться тем, когда объект будет удален.
Весь гугл в своё время был завален обсуждением Android bitmap recycle.
И это только одна тема, где играю особенности GC. А так — GC везде очень активно обвешан костылями и особенностями.
Android bitmap recycle
Только потому что очистка битмапов требовала явного вызова в версиях ведра до 3.0, из-за странной архитектуры контрола и бажной имплементации.
Факт есть факт — просто принять «у меня GC» и больше не думать о том, что так под капотом — не получается почти никогда.
Так это баг АПИ, документированный и впоследствии исправленный. Конечно же, документация открывалась после первого ООМа. А сейчас уже вполне можно следовать заповеди "у меня GC", с текущими-то гигабайтами оперативки в смартфонах. Чем разработчики невозбранно и пользуются — приложения жрут все больше и больше.
Ну и в целом это лишь пример. Таких примеров — вагонами.
Насчет вагонами — очень спорно. В случае широко известных приколов, где GC не работает, как выше, вопросы задаются конкретно под них. Еще меня бывало спрашивали про ключи JVM, имеющие отношение к управлению памятью, но это было собеседование внутри компании на сеньорность после релиза проекта, где нужно было нестандартно тюнить кучу и GC.
С тех пор эти знания на практике не пригодились ни разу, даже на проекте с очень активной работой со всей доступной оперативной памятью.
Похожая ситуация с сортировками и бинарными деревьями (но пару раз пригождались, как и знание О большого разных алгоритмов).
А вот знание принципов проектирования, рефакторинга, тестирования — требовалось на каждом проекте. Теорвер, мат. логика и работа с координатами реже, но тоже бывало.
Одно дело — понимать, как работает GC и не заморачиваться потому, что многие подводные камни он помогает решить и об этом не надо думать в процессе написания кода.
Другое — когда вообще нет знаний о том, как хотя бы примерно работает сборка мусора в используемом языке.
Это действительно средство от человеческого фактора — невнимательности, а не от нежелания разбираться с инструментом, которым пользуешься. GC всё-таки инструмент, которым может либо помочь что-то хорошее созидать, так и наговнокодить рано или поздно, если не знать про особенности.
Единственный раз когда мне понадобилось понимать устройство гц — когда у меня приложение падало с ООМ и я лазил по дампу, пытаясь понять, какая строчка кода вызывает эту хрень. В остальных случаях можно спокойно считать волшебными гномиками, которые объекты удаляют. Ну и разве что для общего развития можно покопаться, что внутри.
Я не писал, что не прошёл такое первое интервью. Я просто получал оффер из другой компании раньше, чем эта компания звала меня на следующее интервью, у них очень длительный процесс найма.
Мне приходилось проводить технические интервью, то есть я был по обе стороны в процессе найма на работу. Я готовил вопросы на темы, которые плотно используются в проекте, на который мы искали кандидата. Время интервью ограничено и сроки поиска нового программиста в команду тоже не резиновые. Поэтому лучше уж спрашивать знания того, что конкретно используется в проекте, чем знания о внутреннем устройстве Java, которые при достаточно прямых руках могут и не понадобиться.
Я знаю лично много программистов, которые затрудняются объяснить устройство сборщика мусора, но при этом пишут нормальный код с минимальным количеством проблем. И знаю также программистов, которые идеально расскажут как устроен сборщик мусора и как работает память в Java-приложении, но при этом пишут вот такой код:
class SomeClass {
private String someValuableData = "Most Valuable Information";
/* Getters and Setters are ommitted. */
public void updateData(String newData) {
this.setSomeValuableData(this.getSomeValuableData());
}
}
Пример утрированный конечно, но суть проблемы демонстрирует. Реальный пример из реального проекта.
На хабре был хороший цикл статей по ним ( если интересно — тык )
Скоро мне стукнет 45 и свой стартап (где был CTO) я покинул в декабре. С тех пор я завалил не меньше 10 тестов и интервью на программиста. Пишу код при этом я уже почти 20 лет, включая создание прошивок (по образованию я инженер-электронщик) и полномасштабные распределенные веб-приложения с интеграцией IoT. Я с нуля создавал ПО для крупных специализированных производственных объектов по всему миру. Тем не менее, я просто не могу устроиться программистом, потому что постоянно проваливаю эти тестовые задачки.
Тем-же занимаюсь по сути, и кодингом и железом, iot и все что с ним связано, также есть крупные реализованные проекты, есть свой стартап, но переодически уделяю время прохождению интервью, хоть и работать там как правило не собираюсь. Очень нравятся собесы по Skype и тп. Для меня обычно выглядит так, 2-3 интервью проваливаю, потом есть предложение и я отказываюсь. Вопросы на 1-3 интервью практически однотипные, и по факту на повторение. Некоторые вещи, которые никогда не применяю, да и в здравом уме они не нужны, просто записываю, и потом на следующем интервью отвечаю.
С этого года ноу-хау добавилось, спрашивают часто про контроль версий, про управление задачами, проектами, и другие инструменты, ну и вообще как ты придумываешь, как и куда записываешь, с кем обсуждаешь и как реализуешь.
Все это превратилось уже даже не в решение тестовых задачек, за решение которых тебя все равно не возьмут, тк ты не знаешь jira или еще какой инструмент, а в банальные как нужно отвечать и как не нужно отвечать. Психопатия. Это и называется навыком прохождения интервью.
Работают два HR, опытный и молодой. Приходит стопка резюме на должность топ-менеджера. Опытный сразу берет и половину стопки отправляет в корзину. На удивленный взгляд молодого коллеги коротко отвечает: — А зачем нам топ-менеджер — неудачник ?!
Вероятно, айти придет к способу найма специалистов по принципу врачей — рекомендацией проверенных знакомых. Никаких олимпиад на скорость, максимум разговор по душам.
В моем случае могу даже больше сказать — если на горизонте маячит любая задача на время, результат собеседования предсказуем. За последние три года таких было около десятка, что субъективно подтверждает сказанное в статье.
В противовес: один раз получил оффер после парного программирования с будущим архитектором, один раз выполнил довольно разумное тестовое задание по совершенно незнакомым мне ранее технолониям. Пару раз мне вообще задавали только вопрос вида "ну ты ж шаришь, да?" (да, оба раза по рекомендации).
Интервью больше напоминало обсуждение тенденций в современном IT и обсуждение применимости стандартных решений/библиотек.
если будет какое-то монотонное «поддержка ХХХ… сопровождение YYY...», то должно напрячь) можно спросить «а зачем указан в вакансии С++42, где он у вас там применяться планирует?» Я когда на работу устраивался, спрашивал как применяются указанные в вакансии технологии, мне вполне без утайки все сказали.
Опять же странно если начнут отмазываться корпоративными секретами, ибо всегда можно найти способ как не сказать слишком много)
откроешь проект, а там — контроллеры с методами по 4-е экрана
для чего все этоВозможно, как раз для того, чтобы преемники не писали такой говнокод, а то и старый в порядок привели?
Я не хочу сказать, что это главное, что есть в разработчике, но и забивать, делая вид, что это никогда не пригодится не стоит. Может пригодиться. Причем обязательно там, где не ждешь (и даже не в самой большой системе)
Это не отменяет необходимости понимания, что полный перебор — плохо, а кэширование — хорошо.
В реальном мире, когда у нас есть performance-critical часть приложения, то у нас есть и время все обдумать, почитать, посоветоваться с коллегами, и нет никакой необходимости решать такую задачку на доске за 15 минут.
Помимо основного неплохо знаю C++, писал расширения для PHP, решал задачи по ML и много чего ещё.
Не собеседовался только уже как лет 7. Два собеса я уже не прошёл :-)
Много чего делал за 8 лет разработки и буквально недавно не прошел лайвкодинг на проверке открывающих закрывающих скобочек в потоке.
}{, ][, )(
Ожидается такой поток: {[<()>]}, и проверять нужно было именно правильность открытия-закрытия))
В любом случае, я получил оценку «procedure inefficient» за реализацию и был послан hr далеко и надолго)
Во-вторых, для разных вариантов скобок за 5 минут делается примитивный стэк.
Все так и было сделано)Эээ… А что тогда у них считается эффективным?
Ну, например, найти решение, когда поток (вернее уровень вложенности скобок) на порядок больше объёма доступной памяти.
(А потом ещё проверять, помещается ли количество скобок в этот счётчик??
(Так и до числа Грэма дойти можно.))
К каждой скобке в стеке добавить счётчик?
Счётчик не поможет, важен порядок.Почему не поможет-то? К каждой скобке:
"{((([[(..." — здесь в стеке:
("{", 1), ("(", 3), ("[", 2), ("(", 1).
При появлении такой же (или парной) скобки, как в вершине стека, — увеличивать счётчик в вершине стека (соответственно, уменьшать (и выбрасывать при достижении нуля)).
Иначе будут проходить потоки типа "{([}])"Как это получится?
Если ожидаются сотни одних открывающих скобочек — то наверное какая-то экономия будет. Если нет — то едва ли.Если нет, то при формулировке
«например, найти решение, когда поток (вернее уровень вложенности скобок) на порядок больше объёма доступной памяти.»
задача становится немного слишком сложной.
(Можно, конечно, пытаться, например, использовать код Хаффмана или ещё что-нибудь для сжатия стека, но это уже извращения начинаются (мой вариант был "RLE-encoding", как в некоторых старых форматах картинок).
Или ваш вариант — упаковка в битовые поля (для трёх-четырёх видов скобок уже нужно по 2 бита — не очевидно, хватит ли памяти, если " уровень вложенности скобок на порядок больше объёма доступной памяти" (что бы это ни значило) ))
С трудом себе такое представляю. Разве что гигабайтные потоки скобочек разбирать на 512 байтах памяти.
Такой пример ваш валидатор пропустит?
<div<span>>
А такой?
Первый пример — нет, второй пример — правильная скобочная последовательность, заданием было не написать парсер HTML.
std::vector< std::vector< int > >Разве что по поводу отсутствия пробела между ">" варнинг выдавать.
5 раз тупые шарады и конкурсы, на которых тебя отсеют, потому что «вспотел через чур».
А 1 раз, с тобой поговорят по душам и не проверяя реальных знаний возьмут на тестовый срок.
Вот на тестовом сроке ты и показываешь на что способен.
С одной стороны понятно: поток резюме от разных проходимцев и людей, которые хотят войтивайти у таких компаний огромен. И для упрощения процедуры фильтрации этого потока делается эта стандартизация с однотипными вопросами и задачками, которые бессмысленны по своей сути. С другой стороны, у людей с достаточным опытом в сфере это чаще вызывает негатив, потому что они знают процессы и то, что задачки им не пригодятся в дальнейшем, а нужны лишь для прохождения собеседования.
У компаний поменьше размером такое встречается реже, но бывает. Там больше вопросов из теории и практики современных подходов к разработке. Они в целом гибче относятся к найму. И там очень много горячих предложений для сеньоров с менее изматывающим процессом найма.
Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.
Я никогда не собеседовал, только собеседовался, но неужели так трудно отличить человека с опытом от проходимца? Спросите про последний проект, что было сделано так, что не так, что бы поменять хотели, и как именно.
Дайте задачку на проектирование простенького модуля (если речь про сениора). Ну там "как бы вы сделали логирование с разных модулей", "а вот теперь нам хотелось бы трекать время выполнения запросов", "а вот у нас куча IO-bound задач на сервер валится, а он не справляется, что это может означать?"...
Я предполагаю, что большим корпорациям часто не столь важен специфичный опыт. Им удобна стандартизация. Вопрос про проектирование модуля очень сильно может быть привязан к специфике языка, его инструментов (у корпораций свое море внутренних библиотек), и в целом отношения к проектированию и кодированию в компании (например, в одной допустимы небольшие нарушения инкапсуляции для общения между модулями, а в другой за этим строго следят и не допускают их). Потому и задают вопросы, которые имеют отношение к программированию в целом, но не имеют отношения к реальным проектам.
И да, многие сеньоры могут не подходить большой компании именно по причине своего специфичного опыта и некоторой закостенелости в плане сформировавшегося вкуса к написанию кода, потому что им будет сложнее переучиться на иные подходы к разработке, которые сформировались в этой компании.
Для меня персонально "закостенелый" и "разработчик" это очень плохо дружащие факторы.
20 лет писать на одном стеке, звучит как-то грустно.
У меня за 9 лет произошел переход сначала от процедурного к ООП, сейчас вот от ООП к ФП, дальше наверное можно будет к формальным доказательствам двигаться, когда языки соответствующие подрастут.
А с другой стороны человек, Который десятилетиями пишет одно и то же на одном языке, знает все подводные камни, но все равно периодически забывает/ошибается просто потому, что он не робот. Поискать что-то что кардинально решает проблему ему не хочется, максимум находит какие-нибудь средства в рамках существующего стека, чтобы чуть-чуть облегчить себе жизнь.
Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)
Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
… и, да — ничто не защитит от ошибок из разряда «он не робот».
Ну, если за это платят и это неплохо получается — почему бы и нет? Кто то же, в конце концов, должен. (поддерживать и развивать системы созданные в прошлом тысячелетии).
Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.
Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)
Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.
Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
- не все проекты такие
- есть хорошие книги по тому, как приводить легаси в адекватное состояние.
У меня были проекты, где старожилы говорили "Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень".
Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.Почему за боль? Работать в привычной среде и привычными инструментами? о_О
Выгорание — это о неправильно поставленном рабочем и жизненном процессе, а не о том, что он не меняет стек и работает там и так как ему нравится.
Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.Что если за эту работу платят достаточно неплохо и нет альтернатив работать меньше, а получать больше? Редкие и узкие специалисты по старым стекам частенько получают совсем неплохие деньги.
не все проекты такие
есть хорошие книги по тому, как приводить легаси в адекватное состояние.
У меня были проекты, где старожилы говорили «Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень».
Крупные проекты на старых стеках обычно именно такие.
Особенно которые живут в состоянии перманентной доработки и развития, а не рефакторинга и избавления от техдолга. (ну правда, попробуйте обосновать необходимость удвоения штата для переписывания всей системы и одновременного поддержания и развития существующей)
А про книги… читал я несколько. Но ничего что могло бы помочь переписать за разумный срок проект на, к примеру, Delphi/SQL, который жил и развивался 15 (или уже 20?) лет, включая динамический sql, динамическое создание dfm-ок, отсутствие тестов и документации я что то там не заметил. Особенно — без увеличения свободных ресурсов программистов.
И они довольно успшно таки пилят с предсказуемыми сроками и качеством решения. Вот только их качество уже во многом проигрывает тем молодым компаниям, кто пилят решения на каком-нибудь новом стеке.
Это какой-то ремесленеческий подход, который уже давно умер, еще в эпоху ренесанса.
В чем разница между жигули копейкой и теслой? И та и та везет ведь.
Это я все к чему? «Жуткое легаси» очень часто — это очень хорошо для бизнеса. Работал я как-то в одной конторе. Там ядро всего бизнеса крутилось на 15-летнем мэйнфрейме. Это был жуткий антиквариат. Но. Сколько думаете было суммарное время простоя этого ядра за 15 лет эксплуатации? Единицы минут! И то, уже ближе к 15-му году эксплуатации, когда электролиты на некоторых платах совсем уже пересохли.
И да, вокруг были обернуты всякие новомодные тогда веб-морды, импорты-экспорты из экселя, и прочие выдачи отчетов. И вот тут-то и возникали время от времени письма от админов: «Веб-морда поломалась, мы ее скоро починим, если что-то срочное — го в терминал с командной строкой, там все работает.» И были старожилы, которые застали еще время до веб-морд, которые делали все то же, что и через веб-морду, но в два-три раза быстрее…
Да даже элементарно. Вспоминая обучение «юзеров» во времена ДОСа и до них и обучение «юзеров» после появления виндоузов. С ДОСом и раньше — «вот тебе команда чтобы сделать это, вот тебе команда чтобы сделать то. Если что-то пошло не так и на экране не показывают :> с моргающей „|“ после — нажми „Esc“, если не помогает — то „Ctrl-c“. И человек мог через час продуктивно работать! Потом появился виндоус… И просто на то, чтобы человек мышкой попадал в кнопки и умел опознавать ситуацию, когда у него поверх всего диалоговое модальное окно, в котором что-то надо сделать — уходило по неделе и больше…
Вспоминается история из промежутка между чистым ДОСом и Виндоус. Когда уже появился NC… Вызывают моего друга бороться с вирусом. Приезжает. Просит продемонстрировать проблему. Дама достает тетрадочку. Открывает на правильной странице, щелкает тумблером на корпусе. Ждет синих окошек. Дальше по тетрадке: „7 раз вниз, энтер, три раза вниз, энтер, 15 раз вниз, энтер“. Дама тщательно отсчитывает нажатия и тщательно жмет энтеры. На экране все те же окошки, ничего не запустилось. Друг начинает разбираться. Оказывается на днях кто-то поставил новую программу на компьютеры бухгалтеров. И теперь, чтобы все работало, нужно начинать с „8 раз вниз“… Дали бы ей „набрать на клавиатуре cd С:\buh\base\ нажать энтер, набрать buh.exe нажать энтер“ — »вирус" бы никто не заметил…
PS: яркая демонстрация проблемы сейчас произошла у меня в предпросмотре коммента. Все кавычки съехали. Там где должны были быть "«" вдруг стали "»" а вместо "»" появились “. Но пока писал PS страница почему-то перерисовалась и большая часть багов пропала… Но остался »вирус" в конце…
С тем же успехом после каких-то изменений могло не видоизмениться меню, а, скажем, программа была бы перемещена из \buh\ в другое место, или перестала бы работать еще из-за чего-то. И получившуюся ошибку пользователь точно так же не смог бы разрешить.
Ну, а то, что он вместо семантики (выбор чего-то из меню) записал последовательность нажатия клавиш — это либо о его умственных способностях, либо о способностях обучающего, говорит нам нехорошее.
В наше время (да и по правде, почти с самого начала так было, просто мало кто этим пользовался) вы можете выкинуть стандартную оболочку и сделать нужную вам программу единственно доступной.
— Почему?
— А ты попробуй!
=))
Может всё-таки сформулируете чем лучше то для пользователей, раз уж взялись это утверждать?
Круто-круто.
Более того — не факт, что поддержка нового продукта будет дешевле, кстати, учитывая размер проекта.
Нет, я хочу увидеть ответ на
И они довольно успшно таки пилят с предсказуемыми сроками и качеством решения. Вот только их качество уже во многом проигрывает тем молодым компаниям, кто пилят решения на каком-нибудь новом стеке.
Качество — по каким критериям?
Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше. Иначе я не вижу логики в этом высказывании )
Вот мне и стало интересно — чем таким эти фреймворки ДЛЯ ПОЛЬЗОВАТЕЛЯ (как утверждает тот кому я это вопрос задал) лучше.
Вопрос то простой (раз всё так очевдно), но почему то ответа на него нет.
К примеру — классические легаси проекты на делфи/sql. Учёт там какой-нибудь, отчётики, гридочки и прочая классика. Чем так пользователям будет лучше на новых / более модных фреймворках? )
Цена полной переписки продукта развивающегося уже 15 лет — колоссальна и не сопоставима с ценой поддержания.
Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.
Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше.
И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.
Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки. =) А если не развивается — зачем переписывать?
И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.
И снова — что значит «качественнее»? И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )
Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки.
Не согласен. Растёт и то и другое, но стоимость поддержки по моему опыту всегда растёт быстрее.
И снова — что значит «качественнее»?
В данном контексте «качественнее» для меня означает менее подвержено багам и критическим ошибкам.
И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )
Это зависит и от того и от другого. Естественно архитектура и подход имеют большее значение, но и «инструменты» играют свою роль. Если бы это было не так, то до сих пор все бы писали исключительно на ассемблере или даже на перфокартах.:)
Не согласен. Растёт и то и другое, но стоимость поддержки по моему опыту всегда растёт быстрее.Очень субъективная оценка.
Большая часть проектов которые я видел нуждались в поддержке в большей степени из-за архитектуры и размера и в меньшей — из-за техдолга. Переписывание (кроме того, что это само по себе очень затратное мероприятие, хотя бы потому что на это время нельзя остановить разработку и поддержку оригинального проекта) в итоге приведёт примерно к такому же объёму работы по поддержке и развитию. Вдвойне по причине наличия новых багов (а если это новая технология, так вообще) и нюансов.
В данном контексте «качественнее» для меня означает менее подвержено багам и критическим ошибкам.Новые технологии, нюансы которых ещё не отшлифованы годами до блеска? Недокументированными возможностями, неустаканенными версиями и огромным проектом, который только что на этом всём написали?
Вообще говоря, достаточно спорное утверждение.
Я вижу «качественность» немного в других областях, если честно. Оптимизация скорости, объёма данных, прозрачность архитектуры, поддерживаемость итп. Как минимум, большая часть «качества» — это продуманность архитектуры и процессов. И она слабо зависит от модности фреймворков. В меньшей — реальная скорость работы и количество ресурсов для этого. Скорость в древних системах, обычно, уже дотюнингована до требований пользователя, а ресурсы… только ради них всё затевать — как то странно. Тем более что и выигрыш там обычно не так уж велик )
Это зависит и от того и от другого. Естественно архитектура и подход имеют большее значение, но и «инструменты» играют свою роль. Если бы это было не так, то до сих пор все бы писали исключительно на ассемблере или даже на перфокартах.:)
Я до сих пор вижу что люди пишут и новые проекты и ищут на существующие, к примеру, на Delphi. После определённого уровня абстракции разница в инструментах не так уж критичная, особенно когда умеешь ими пользоваться.
Весь мой профессиональный опыт говорит мне о том что в ИТ идёт постоянный прогресс и новые вещи обычно лучше старых. Естественно не нужно хвататься за каждую новую технологию и переписывать проекты с нуля каждый год, но внедрять новые фреймворки и технологие нужно.
А если кто-то хочет всю жизнь писать на Delphi и считает что ничего лучше в мире не существует, то это его личное дело :)
Весь мой профессиональный опыт говорит мне о том что в ИТ идёт постоянный прогресс и новые вещи обычно лучше старых. Естественно не нужно хвататься за каждую новую технологию и переписывать проекты с нуля каждый год, но внедрять новые фреймворки и технологие нужно.Ну, вот, я не вижу почему то чем новые вещи были бы принципиально лучше старых. Более того, один из проектов-таки переписали… но не смогли запустить. =)) так и остался суровый легаси вариант и дальше работать.
Возможно, новые продукты и проекты и впрямь стоит писать на новых фреймворках и технологиях (в конце-концов, их делают в том числе и с расчётом на более быструю разработку и конечный продукт как цель). С этим я даже спорить не собираюсь )
Но переписывать проекты с огромной кодовой базой, идущей ещё из прошлого тысячелетия, отказываться от текущих разработчиков и нанимать новых, поддерживать и развивать паралельно два проекта (включая тестирование пользователями и бизнесом), пока не будте перенесён весь функционал, а потом поддерживать уже новый — в этом я никакой особой выгоды (в плане технологий) даже среднесрочной я не вижу.
Вот в том, что бы пересмотреть архитектуру и избавиться от какой то части техдолга — определённо есть смысл, хотя и меньше чем может показаться.
Ну, с точки зрения бизнеса, если проект отлично живёт на Delphi, то почему бизнес должен считать что для проекта существует что то лучше в мире? И в каком плане оно вообще будет лучше? )
Ну, вот, я не вижу почему то чем новые вещи были бы принципиально лучше старых. Более того, один из проектов-таки переписали… но не смогли запустить. =)) так и остался суровый легаси вариант и дальше работать.
Я понимаю что то, что я сейчас напишу, звучит не особо приятно и я рискую нахватать минусов, но вы уверены что проблема в новых вещах, а не в тех кто их эвалуирует и применяет? :)
Ну, с точки зрения бизнеса, если проект отлично живёт на Delphi, то почему бизнес должен считать что для проекта существует что то лучше в мире?
Что вы будете делать если внезапно выясниться что по какой-то причине на Delphi он дальше жить не может? Что вы будете делать если ваши Delphi-программисты внезапно поувольняются или уйдут на пенсию, а новых вы не найдёте? Переделывать всё в авральном порядке?
P.S. И ещё раз: я не собираюсь здесь никого уговаривать или заставлять следовать моему примеру. Но сам я предпочитаю работать именно так.
Я понимаю что то, что я сейчас напишу, звучит не особо приятно и я рискую нахватать минусов, но вы уверены что проблема в новых вещах, а не в тех кто их эвалуирует и применяет? :)
О_О
На самом деле я уверен что почти всегда это именно так.
И это касается любых технологий, старых и новых %)
ЗЫ: причём, чаще всего проблема в тех, кто этим руководит.
Что вы будете делать если внезапно выясниться что по какой-то причине на Delphi он дальше жить не может? Что вы будете делать если ваши Delphi-программисты внезапно поувольняются или уйдут на пенсию, а новых вы не найдёте? Переделывать всё в авральном порядке?
1. Технологически, я слабо представляю, почему проект может не мочь дальше жить на этом стеке. Ну, допустим.
2. Такой риск, кстати, был. Но на рынке всегда можно найти необходимые програмистские ресурсы. Или обучить. Или предвидеть ситуацию и потихоньку набирать/обучать.
А если такое всё таки случится…
В таком случае компания просто закроется/ направление прикроют / поручат эту область ответственности другому подразделению и оно будет его создавать ещё пару лет в первом приближении. Примерно такие варианты )
Потому что переписывать такую хрень — реально затратное дело, и чаще всего требует новых специалистов. «Попробуйте включить-выключить».
ЗЫ: на самом деле не столько страшно, если Delphi нельзя будет использовать. В конце-концов, основная логика на сервере. Вот если MS SQL нельзя будет использовать и придётся переходить на что то принципиально не мигрируемое с него… вот тогда будет праздник )))
Стоимость к качеству обычно отношения не имеет. Смотрят как раз на соотношение цена/качество, если качество нужно, но не любой ценой
В следующий раз когда захочется какие то оценки порядка «качественнее-не качественнее» давать — стоит разобраться в том, как это оценивать.
Спасибо, что прояснил это )
ЗЫ: и, да — «техдолг» — понятие не связанное с фреймворком. =)
Вижу больше с твоей стороны попытку самоутвердиться, чем достичь истины.
Можешь считать, что я не знаю как объяснить, если тебе будет так легче жить. Ради бога, ни в чем тебя переубеждать не собираюсь. И так много времени потратил впустую на разговоры с тобой.
Ну раз попытки узнать, откуда информация про «качественность» в твоих постах — самоутверждение, то пусть будет так.
И так много времени потратил впустую на разговоры с тобой.Не насилуй себя )
Качество оцениваю по таким критериям — отзывчивость и доступность и время требуемое для внесения и стабилизации изменений (в конечном итоге время трансформируется в стоимость)
Вот есть легаси приложение. Любое действие — перезагрузка страницы. Кроме того — потеря части введенной информации, как это часто бывает. И приходится много полей перезабивать снова, если есть ошибка валидации данных. Это все время. Время деньги. Но ведь решение то надежное по твоим словам. Это ладно если одни раз. А если это происходит снова и снова каждый раз. А за день оператор может вбивать множество данных. Непрерывно, если это кровавый энтерпрайз.
Дальше. решение то старое, горизонтальное масштабирование приобрело особую значимость после облачной революции, всякие там докеры, кубернетесы и «прочая ненужная модная шняга», тут только как правило вертикальное масштабирование. А нагрузки то растут. Покапаем новый проц, или железо за овер милллиард, вместо «простых, тупых» машин, за 2-3 тысячи вечнозеленых.
Это еще что. Тут бос насмотрелся понтов от таких же босов как он сам, и хочет мобильное приложение, чтобы им щеголять, лежа на шезлонге своей яхты. Ну что, будет нанимать iOS специалиста, Android специалиста, и еще можно blackberry тоже охватить. Это ведь сферический легаси в вакуме, чё там, будем пилить 3 раздельных приложения с одной и той же функционалностью. Зачем нам новые модные фишки типа RactNative или NativeScript нафиг нам этот хипстерский хайп. Только хардкор, только MS DOS.
Любое действие — перезагрузка страницы.
Ну перезагрузка. И что? Сохранять данные, введенные на странице, при перезагрузках страницы, разработчики с руками растущими из верхней части туловища умели задолго до появления HTML. Да, сейчас появились фреймворки, которые как-то помогают и тем, у кого руки растут из нижней части туловища. Но и там умельцы умудряются добиться перезагрузки страницы и потери данных. Или делают разлогин через минуту отсутствия на странице и пока ты ищешь какой же там нужно ввести почтовый индекс… Го логин страница, го вводить все данные по-новой.
горизонтальное масштабирование приобрело особую значимость после облачной революции
Облачная революция случилась в 70-х? Если я ничего ни с чем не путаю, где-то как раз тогда появились мэйнфреймы, которые позволяли добавлять процессоры, память и системы ввода-вывода на ходу. Без остановки работы приложений.
Покапаем новый проц, или железо за овер милллиард, вместо «простых, тупых» машин, за 2-3 тысячи вечнозеленых.
Тут, как всегда, есть выбор. Можно купить «простых тупых» машин и тратить уйму сил и ресурсов на поддержку, ремонты, апгрейды и т.п. А можно купить что-нибудь из наследников мейнфреймов чуть дороже и тратить намного меньше сил на поддержку и ремонты (с апгрейдами — как с вендором договоритесь. Скидки бывают очень интересные).
Виртуализация помните откуда взялась? OS VM, помните? Для IBM 360 или 370? Напомню, разрабатывалось и тестировалось на поздних модификациях 360, продавать начали в 1972 году для IBM 370. Ага. 47 лет назад. И там были и виртуальные машины, и «гостевые ОС», и примерно все остальное, чем так гордятся разработчики гипервизоров последние 10 лет.
«Клиент» — вообще штука динамично изменяющаяася и не требующая переделки ядра системы.
Когда я столкнулся с лютым легаси — мэйнфрейм, обертки вокруг, все такое. Все прекрасно работало. Никаких потерь данных, никаких отказов. Был день, когда сдохла от старости какая-то плата. И пока ее не заменили — при большом желании можно было заметить лаги. Ну типа нажимаешь энтер, а экран перерисовывают не сразу, а с задержкой типа 0.2 секунды. Если бы админы письмо не написали бы, что мэйнфрейм болеет, никто бы и не заметил.
Когда я столкнулся с ультрамодным супер-пупер современным… Ну что сказать… За год в среднем 3-4 выходных дня всему офису (кроме админов, у которых было «в ночное») добавлялись, т.к. «оно упало и починят завтра». А функционал у лютого легаси был, надо сказать, несколько круче. И тянул лютый легаси пару сотен пользователей на одном «энтри левел» мэйнфрейме, которому уже было что-то типа 15 или 20 лет. А «новомодная» система крутилась на вполне свежих серверах, 1-2 года возраста. И тянула она «аж» 20 пользователей.
PS: я чуть более старый перец — я с компьютерами близко познакомился уже учась в институте, в 1987-м году… И я накатывал Windows 3.1 на свою досовскую машину, потом 3.11, потом сервиспаки к 3.11, потом поверх Чикагу, потом поверх пререлиз, потом поверх пререлиза релиз 95-х. Потом случился глобальный крэш, который почти совпал с глобальным апгрейдом железа и переездом на Win 2000. И я до последнего сидел на Win 2000, пока не встала совсем остро необходимость подключать к компьютеру USB девайсы, а MS уперся, что нельзя к Win 2000 прикручивать драйвера USB… Потом была ХРю. Она была ничего. Но… Переход с ХРюши на семерку — был радостью. (А вы, похоже, что-то утаиваете. Между ХР и восьмеркой было что-то типа 10 лет семерки… Которые вы вдруг пропустили) Вообще, я не знаю никого, кто не радовался переходу на Win 7. Все стало работать быстрее на том же железе. Чему не радоваться? А вот дальше… Беда-беда-огорчение! Поменяли чуть-чуть интерфейс, сделали иллюзию более быстрой загрузки при включении, добавили кучу неубиваемой хрени для отслеживания всех действий пользователя… А я, наконец, поставил себе на семерку сервис-пак.
Вообще, я не знаю никого, кто не радовался переходу на Win 7
Я не радовался. Выход Висты заставил меня перейти на Линукс, а потом на работе пришлось перейти на 7. Я очень не радовался.
Вот обновление там же на 10 порадовало, потому что WSL появилось, пускай не полноценное линукс-окружение, но лучше чем git-bash
К примеру, обычные десктопные приложения, которые не сильно изменились в плане функционала и интерфейса за последние 20 лет.
Безусловно, сравнение приложений с отсутствием функционала и наличием его всегда будет простым. Но вопрос то в том, что функционал остаётся прежним, просто меняются технологии на которых оно написано.
Поэтому и возникло столько к Вам вопросов — мы просто разные вещи сравниваем. Вы — два приложения с разным функционалом и на разных технологиях, я — с одинаковым функционалом и на разных технологиях.
Видел много. Сначала застал тех кто говорил — да нафиг этот Win 3.1, только MS-DOS, что за мышка дурацкая, что за аляповатый интерфейс. Не… Norton Commander наше все… только 60 на 24. Фу таким быть, я себе тогда сказал, еще в середине 90х. Потом видел чуваков, которые отчаянно не хотели переходить на WinXP — такое говно говорили они. Какие-то аляповые рюшечки, то-ли дело 95, а еще курче NT. Потом уже (ну про висту промолчу, говно конечно) на Windows 8 не хотели до последнего переходить с XP, со всей ее дырявостью и неудобством. Просто привыкли, не схвали тех фишек, который им принесла Windows 8 (вернее не совсем удачная Vista, ну первый блин комом) с ее переработанным подходом к ОС. Потом наблюдал тех, кто отчаянно цеплялся за Winodows 8, из того же теста, кто раньше цеплялся за Windows XP, и кто не хотел переходить на Windows 10, и отчаянно хаял эту систему. И это не только в отношении ОС от MS. Просто более наглядный пример. Одним словом я называю таких людей — ретрограды. Это камень и в твой огород дружище.
Norton Commander наше все… только 60 на 24.
Еретик, 80х25 всегда было!
1. Тут надо всегда смотреть в комплексе с решаемой задачей.
2. Эти инструменты не альтруисты производят, вот к примеру MS выпустила ось, где нашла идеальный баланс между всеми ее параметрами и что дальше делать MS? оставить только суппорт или что-то новое пойти изобретать? (никогда не поверю что они на такое пойдут) Даже вспоминается анекдот — кто раньше ACDSee или Nero станет операционной системой, имхо эти программы были идеальны в определенный момент времени, но потом баланс был потерян и они разжирели.
в России нет неограниченного пула кандидатов
В России это называют очередью за воротами))))
Почему программистам не могут сделать так же?
Потому что реальные задачи старшего разработчика: а) не решаются однострочником, б) не описываются одной строкой, в) очень часто нелинейны и не решаемы без обратной связи с заказчиком/БА/менеджером.
например, дается кусок кода, задача уменьшить время исполнения в два раза, чем не практическая задача?
Кстати, очень хороший вариант. Можно даже без уточнений во сколько раз… просто ускорить. Кто сильнее ускорит, тот и больший молодец :-)
Без запуска в реальном окружении практически невозможно сказать, какой из двух вариантов для более-менее сложной задачи выполняется быстрее.
Ну например один выполняется лучше если у процессора быстрый кеш, а второй — если SSD чуть быстрее.
Оценка алгоритмической сложности. Кстати, хороший вариант задачи. К тому же жизненный, если зовут на рефактор проекта, изначально написанного и оплаченного по количеству строк кода.
Но бесполезный, если на проекте пофиг на время выполнения кода, то есть в 99% проектах. По-моему опыту либо на проекте производительности даже питона за глаза, либо с производительностью проблемы, но все они IO bound и нужно уметь запросы в базу писать да шардирование настраивать, а не сортировки бенчить.
Ну, не многие конторы пишут софт под конкретное железо. Можно изначально рассчитывать на SSD и более-менее современный проц, но жёстко оптимизировать под конкретные модели — это слегка перебор в большинстве случаев.
А так, можно и тестовый стенд выделить, чтобы все решения в одних условиях сравнивать. Во всяком случае, это достаточно реалистичная задача, которая позволяет отличать сеньоров от джуниоров.
А так, можно и тестовый стенд выделить, чтобы все решения в одних условиях сравнивать.
Нельзя. Это будет вариация анекдота про выкидывание половины резюме в корзину. Кому повезло угадать с железом, тот и победил.
Эм, а конфигурацию выписать и приложить к заданию сложно что-ли? Зачем гадать? Да и, по факту, не упрётесь вы в железо в рамках тестового задания. Что вы там собрались оптимизировать за 1-2 часа, чтобы модель процессора влияла на место вашего алгоритма в общей таблице результатов?
Ну так разговор же про "один выполняется лучше если у процессора быстрый кеш, а второй — если SSD чуть быстрее". Угадать в смысле выбрать код, который на этом железе будет работать быстрее. По конфигурации нельзя понять, какой вариант из них имеет место, надо брать оба и измерять результаты.
Это не разговор, это фантазии arheops. Вы такой код (завязанный на характеристики конкретных моделей железа) за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны, если речь не идёт о разработке под микроконтроллеры.
По конфигурации нельзя понять, какой вариант из них имеет место
Можно. Характеристики конкретных моделей никто не скрывает.
Вы такой код за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны
Так я говорю о том, что один так написал, другой по-другому, алгоритмы примерно одинаковые, но первый на тестовом железе выполняется быстрее из-за того, что лучше ложится на такое железо. Случайно, а не специально.
Что делать на проектах где важна произвотельность кода? Ну вот например у меня как-то MS SQL построил план на триллион строк, потому что оптимизатор решил что будет циклами джойнить, хотя если сначала через хэш мерж склеить две других таблички, то время выполнения с 3 минут падало до скольких-то миллисекунд. И никто не знает, почему.
В итоге я день потратил на поиски принципов, по которым оптимизатор определяет такой порядок, и еще сколько-то времени пытался понять какой вид запроса поможет ему сделать правильный вывод. В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.
Проблема в том, что в реальном проекте почти всегда будет вопрос к БД, и почти всегда каждая проблема будет уникальна. В другой раз я, например, пытался понять, почему парсер того же SQL Server ломается, если в контенте XML колонки встречаются значения с ведущими пробелами.
Ну и все в таком духе. Как это проверять?
Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
В принципе задание на оптимизацию конкретной выборки — это тоже вариант. Даёте доступ к БД, медленный запрос и задание ускорить выборку. Но если Вы сами потратили 2 дня, то странно будет ожидать, что другой человек справится за 1 час. А если справится, компания готова ему платить в 10-15 раз больше, чем Вам?
В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.
Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.
Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
Да, я ожидаю. Конечно, нужно упростить, чтобы реально было решить за час, и это не требовало конкртеных знаний конкретной страницы мануала, но в целом реальные задачи тем и хороши, что во-первых показывают уровень проблем проекта, а во-вторых позволяют оценить решение со всех сторон, т.к. вы долго над ним думали, прежде чем пришли к текущему.
Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.
Подзапрос не помогает. Фишка еще в том, что запрос формируется не в SQL, а через ORM, и те же хинты использовать не получится (ORM их не поддерживает). Собственно, задача была именно в том, чтобы придумать как через имеющийся апи сделать, потому что к хранимкам на проекте относились хуже, чем к таким костылькам. На SQL можно было просто влепить left hash join в нужном месте и все бы отработало как надо.
Хотя сейчас я наверное какой-нибудь даппер взял и прямой запрос написал. Просто этот подход плохо дружит с паттерном query builder, который используется чуть менее чем везде.
В чем юридическое соображение запрета задачки вида "у вас есть три таблички с такими-то записями, и вам нужно их поджойнить через общеизвестный фреймворк"?
И что?
Вы не можете просто так взять и использовать
Так не используйте.
А кандидат может претендовать на результаты деятельности вашего бизнеса, даже в случае совпадения предоставленного им решения.
Не может.
Вы правда думаете, что люди побегут рабочее решение (которое давно внедрено) перепиливать под идею которую озвучил рандомный кандидат на собеседовании? Особенно учитывая, что задачку отрафинировали, выкинув всю специфику чтобы не грузить ненужными подробностями?
в целом реальные задачи тем и хороши, что во-первых показывают уровень проблем проекта
Вы правда думаете, что люди побегут рабочее решение (которое давно внедрено)
Я думал, что у вас есть проблемы, а они уже решены оказывается.
Конечно, нужно упростить, чтобы реально было решить за час, и это не требовало конкртеных знаний конкретной страницы мануала,
Особенно учитывая, что задачку отрафинировали, выкинув всю специфику чтобы не грузить ненужными подробностями?
Выбросите всю специфику — это реальная задача? Чем она будет отличаться от задач из мануалов.
Сколько времени вы будете тратить на составление одной задачи рассчитанной на один час времени кандидата? Я думаю, минимум рабочий день. Сколько подобных задач вам понадобится составить за 1 год?
Бизнес не стоит на месте, возникают новые проблемы в проектах, их тоже нужно учитывать. Задачи, как и код — их нужно поддерживать, устраняя неточности и противоречия. И в любом случае, срок годности ваших задач будет истекать довольно быстро.
Я думал, что у вас есть проблемы, а они уже решены оказывается.
Реальные проблемы просто источник хороших вопросов. Понятное дело, что чтобы оценить решение кандидата нужно уже самим сделать, сравнивать-то с чем-то надо.
Выбросите всю специфику — это реальная задача? Чем она будет отличаться от задач из мануалов.
Сколько времени вы будете тратить на составление одной задачи рассчитанной на один час времени кандидата? Я думаю, минимум рабочий день. Сколько подобных задач вам понадобится составить за 1 год?
на одном из собеседований меня попросили спроектировать сервис коротких ссылок. Ну там с изменением требований и т.п. Сколько по-вашему должно пройти времени прежде чем этот вопрос устареет?
И в любом случае, срок годности ваших задач будет истекать довольно быстро.
Срок годности таких задач в пределах времени жизни фреймворка или технологии, для которой его сделали. Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.
на одном из собеседований меня попросили спроектировать сервис коротких ссылок. Ну там с изменением требований и т.п. Сколько по-вашему должно пройти времени прежде чем этот вопрос устареет?
Написать сервис коротких ссылок — это распространенное тестовое задание для мидлов, 3 часа — 1 день. Видимо у нас с вами разное представление о сеньорности.
Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.
Это вопрос знания технологии, можно обсудить устно, вы собираетесь усложнить его конкретикой, что бы дать в качестве тестового задания? Да, возможно получится хорошее задание, но…
Написать сервис коротких ссылок — это распространенное тестовое задание для мидлов, 3 часа — 1 день. Видимо у нас с вами разное представление о сеньорности.
Ну, видимо я ненастоящий. На миддла когда собеседовался про солиды и круды спрашивали, а архитектуру чет не особо.
А что значит "3 часа — 1 день"? Если время ответа, то там минут 20 на все, сразу понятно. есть понимание или нет. Если сколько они придумывали, то этого я не знаю.
Это вопрос знания технологии, можно обсудить устно, вы собираетесь усложнить его конкретикой, что бы дать в качестве тестового задания? Да, возможно получится хорошее задание, но…
Конкретика из разряда "вот у нас была такая табличка с таким вот паттерном доступа, и тут внезапно все сломалось. Что могло пойти не так и как чинить?" не должна сильно смущать.
Ну, видимо я ненастоящий.
Это не я сказал!
А что значит «3 часа — 1 день»? Если время ответа, то там минут 20 на все, сразу понятно. есть понимание или нет. Если сколько они придумывали, то этого я не знаю.
Приблизительное время на выполнение тестового задания, на которое нужно предоставить решение в виде исходного кода.
Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.
Ох не факт. Даже в разных версиях одной рсубд грамотное проектирование индексов будет отличаться. Особенно если мажорное обновление сделало совсем новых типы индексов типа функциональных или частичных.
Был такой случай:
- иду на собеседование
- хорошо так поговорили о способах решения абстрактных проблем с их техлидом, обсуждали плюсы и минусы двух подходов к проблемам консистентности, приходим к некоторому консенсусу, кроме одного пункта
- офер сделали, но отказался
- пошёл в другую компанию, прямого конкурента
- через год где-то вторая компания (вернее вышестоящий холдинг) покупает первую, дружественное слияние по отношению к топам, недружественное к персоналу, в частности всех программистов в ней увольняют "по собственному", большинству говорят две недели фактически не отрабатывать, но зарплату получат, нескольких просят "передать дела" нам и только потом на тех же условиях писать заявление, плюс свободный график чтоб собесы проходить и т. п. Почти все соглашаются в том числе тот техлид
Ну и в процессе передачи в одном месте говорит что-то вроде "ну вот тут сделано как мы с тобой тогда обсуждали, я дня три думал и решил это сделать как ты предлагал".
Мне просто приятно было и прикольно. Но кто-то на моём месте мог и по другому поступить. А техлид мог бы быть свидетелем истца, поскольку лояльности к его по сути бывшему начальству было меньше ноля после сделки.
недружественное к персоналу, в частности всех программистов в ней увольняют «по собственному»
И нафига они соглашались? Пусть сокращают по закону, со всеми положенными выплатами.
Ну мне помню пригрозили, что мою работу "из дома" зачитают за прогулы ибо в местном скуде учет по ссш не велся. Так шо такие дела.
Один мой знакомый в таком случае судился, но убил на это месяца 4. Так что это на любителя.
Жаль что у нас народ не любит бороться за свои права, чем всякие мудаки и пользуются.
Я во время кризиса восьмого года там попал под сокращение в одной дерьмоконторе. Уволили под сотню человек, последнюю зарплату выплатили только нескольким сотрудникам (в т.ч. и мне), которые не побоялись «покачать права». Правда я тогда был тоже плохо подготовлен и написал «по собственному», молодой был, глупый. Но все-же хоть что-то с них смог выдрать, в отличие от большинства «вошедших в положение».
Можно было пободаться, по ТК, записи в скуде не катят, должны быть документы, оформленные под вашу роспись в определенном порядке, их наверняка не было.
Еще раз: прецедент был, у знакомого, 4 месяца постоянной нервотрепки по судам. Можно было бы, но мне мое время дороже. Это как в магазине на другом конце города, где вас обсчитали на 20 рублей, а вы заметили только дома. Есть люди с гражданской позицией "поеду и настрочу жалобу в книгу", а есть кто скажет "да и хрен с ним, больше в тот магазин ни ногой".
Не меня сокращали, так что ничего сказать не могу в данном случае.
Хорошая история, так и надо.
Фишка еще в том, что запрос формируется не в SQL, а через ORM
Ну, это так себе фишка. Нет никакого оправдания городить днями костыли в угоду ORM для случаев, которые нормально решаются на SQL. Большинство ORM позволяют выполнить raw SQL или использовать его фрагменты в нужных местах. Если ORM этого не позволяет, то следует его отправить на другие 3 буквы ещё до старта проекта.
при чем тут это? Как правило в проекте довольно много все завязано на однотипный пайплайн, и выполнять сырой SQL в таком случае не очень. Ну типичный пример, у нас есть иерархия репозиториев, который автоматически на все запросы навешивает права вида executingQuery.Filter(x => UserHasPermissions(user, x)). На сырой SQL его не навесишь.
Всякие цепочки построения запросов — это понятно, бывает сплошь и рядом. Но возможность просунуть в них raw SQL должна оставаться, иначе момент, когда ORM начнёт вставлять палки в колёса — лишь вопрос времени.
автоматически на все запросы навешивает права вида
Хм, ну это как-то сильно на любителя. Почему ACL нельзя на уровне контроллеров оставить? Middleware какую-нибудь, которая будет отсекать роуты, которые совсем недоступны, а где нужна более высокая гранулярность — запоминать уровень доступа юзера, репозиториям останется лишь проверять этот уровень, не вмешиваясь в SQL всех запросов подряд. Да в каких-то случаях, типа списка доступных записей, вам придётся записать условие выборки в явном виде, но имхо это только к лучшему.
Всякие цепочки построения запросов — это понятно, бывает сплошь и рядом. Но возможность просунуть в них raw SQL должна оставаться, иначе момент, когда ORM начнёт вставлять палки в колёса — лишь вопрос времени.
Проблема в том, что у Raw SQL может не быть выразимого в виде языка типа. Как только мы вызывали сырой SQL мы ничего про код сказать не можем. В лучшем случае можем попробовать пообещать результат выполнения в стиле даппера, но оно не всегда работать.
Хм, ну это как-то сильно на любителя. Почему ACL нельзя на уровне контроллеров оставить? Middleware какую-нибудь, которая будет отсекать роуты, которые совсем недоступны, а где нужна более высокая гранулярность — запоминать уровень доступа юзера, репозиториям останется лишь проверять этот уровень, не вмешиваясь в SQL всех запросов подряд.
Могут быть права доступа/фильтры на основе схемы, а схему в миддлеваре не проверишь, про неё только бд знает. Типичный пример — асп.нетовские клеймы, хранятся в базе. Есть кука, но её взломать как нефиг делать, чинил как-то баг с этим связанный.
а схему в миддлеваре не проверишь, про неё только бд знает
Миддлвара вполне может спрашивать что-то у сервиса с доступом к БД.
Ну да ладно, не будем вдаваться в детали. Единственное, что я хочу Вам сказать, что жёстко связывать проверку доступа и сами запросы на получение/изменение данных — не очень хорошая идея. И лучше подумать, как развязать эти ответственности (с учётом специфики вашего проекта) до того, как это станет большой проблемой.
Так это не типовое тестовое задание. Тут уже есть код, который можно запустить без доп.настройки на готовом сервере. И 1-2 часа, чтобы ускорить этот код. Что успел ускорить, то успел. Поэтому долго не будет.
Подход хороший, видел его в некоторых крупных компаниях, и он действительно работает. Единственная проблема с таким подходом — скорее всего такой проект будет на одном языке, от силы на двух, а кандидат всегда может попросить написать на чем-нибудь своем.
Но даже тут в обсуждении находятся те, кто и три часа на домашнее задание не готов потратить.
Тут широкое пространство для манёвра. Вы ведь можете performance-проблемы раскидать по куску кода самыми разными способами. Какие-то явно будут заметны, даже если кандидат не эксперт по конкретному ЯП, но хотя бы может его читать. Какие-то могут быть с SQL связаны. А если ищете с хорошим знанием конкретного стека, то тут можно и что-нибудь framework-специфичное заложить.
Там было кучу проверок знаний в разных областях, в том числе и на внимательность
«было кучу» — тоже проверка на внимательность? Эти слова склоняются не так сложно, вроде.
Если отсечь откровенный обман, что тоже бывает, получается, что кандидат 10 лет не писал ни строчки, получал за это какие-то деньги, а только вы спустя 10 лет раскрыли этого сукиного сына.
Что-то мне кажется, что это проверка не на умение писать код, а на умение работать под прессингом. Это тоже важно, не спорю. Но не лучше ли спокойно пообщаться, а потом уже разбираться: если сотрудник стрессоустойчив — будет работать с заказчиками, если нет — ну ок, оградим его от стресса, будет пилить свой модуль. Зачем людьми сразу разбрасываться? Тем более «борзый» и «стрессоустойчивый» с более высокой вероятностью кинет вашу компанию, как только получит поинтересней офер. Спокойные же разрабы будут лояльней.
Если отсечь откровенный обман, что тоже бывает, получается, что кандидат 10 лет не писал ни строчки, получал за это какие-то деньги, а только вы спустя 10 лет раскрыли этого сукиного сына.
А вдруг он «читерил»? Вдруг в гугл лазил всё это время, а надо без него уметь! Как вот прочитал тут недавно где-то в интернете байку, типа разработчик из дома работает, ну кодит и постоянно гугл открывает, что-то ищет нужное. Жена ему говорит: «А разве ты не жульничаешь? Ты же дожен сам всё это знать, а ты в гугл лазишь!»
Если ты еще не решал данную задачу — логично погуглить, чем изобретать велосипед.
На том же SO можно по некоторым вопросам увидеть прямо «изобретение поезда»: вопрос задан, кто-то на него ответил, вроде даже правильно, потом в комментариях оказалось, что есть нюансы, потом оказалось, что эту задачу можно решить совершенно по-другому, потом, через пару лет, еще появился ответ с использованием каких-нить новых фич языка/инструментария.
Умение применять существующие решения, а не изобретать свои — очень хороший навык.
«Определим последовательность Трибоначчи как последовательность, первые 3 элемента которой равны 1, а каждый последующий равен сумме трех предыдущих. Написать функцию trib(n), которая будет возвращать n-ный элемент последовательности.»
С моей точки зрения, человек, имеющий минимальный опыт программирования, должен без труда справиться с этим заданием меньше, чем за двадцать минут. Я даю на это до 45 минут, при этом сразу говорю, что основное задание — написать работающую программу, пусть даже она не оптимальна. Разве это стресс?
— Сам факт экзамена
— Все эти игры с простыми/сложными задачками и кусками кода привели к тому, что не поймешь толи правда элементарщина, толи где то заныкали заковыку
— Этот код никогда не увидит жизнь, у меня например при этом мозг начисто отключается
— Разные критерии оценки: мне важно оформление кода и читаемость, вам оптимальность, 3ему обязательно нужно чтобы это было обернуто в класс, 4му знание математических формул и теорем, 5му знание встроенных функций языка, 6му знание плугинов/фреймворка, 7му слабодокументированных хитростей языка. И во всех этих случаях есть очень высокий шанс того, что вместо разговора двух профессионалов это превратиться в: Как, вы незнаете?!!! А вот это вы тоже не знаете? *мерзкий тон, осуждающий взгляд*. Это очень неприятно знаете ли.
— многим, в тч и мне не нравиться писать на листочке. Нет автодополнения, писать нужно ручкой (чего многие годами не делают), текст уползает (хоть кто бы дал листок в клеточку/линеечку) итд
ЗЫ ну вот я накидал примерчик, по-моему минуты 4 ушло, еще столько же пробелы расставлял, затолкал его в класс от нефиг делать, прописал нормальное имя (нам же читаемый код нужен, правда?), переименовывал функции чтоб читалось лучше(на листочке, ага), загуглил как пишеться Трибоначчи(«ааа, незнаете», помним, да?))
class TribonacciSequence
{
public static function getElement($elementNumber)
{
$sequence = [1, 1, 1];
if ($elementNumber >= 4)
{
return self::extendSequence($sequence, $elementNumber);
}
else
{
return $sequence[$elementNumber - 1];
}
}
private static function extendSequence(&$sequence, $targetElementNumber)
{
$elCount = sizeof($sequence);
$newElement = $sequence[$elCount - 1] + $sequence[$elCount - 2] + $sequence[$elCount - 3];
$sequence[] = $newElement;
if ($elCount + 1 < $targetElementNumber)
{
return self::extendSequence($sequence, $targetElementNumber);
}
else
{
return $newElement;
}
}
}
echo TribonacciSequence::getElement(10);Осталось 34 минуты, вспотел, переписал:
function trib($n)
{
$sequence = [1, 1, 1];
return $n >= 4 ? extendSequence($sequence, $n) : $sequence[$n - 1];
}
function extendSequence(&$sequence, $n)
{
$elCount = sizeof($sequence);
$newElement = $sequence[$elCount - 1] + $sequence[$elCount - 2] + $sequence[$elCount - 3];
$sequence[] = $newElement;
return $elCount + 1 < $n ? extendSequence($sequence, $n) : $newElement;
}
echo trib(10);
Осталось 32, еще переписал
function trib($n)
{
$first = 1;
$second = 1;
$third = 1;
for ($i = 3; $i < $n; $i++)
{
$curr = $first + $second + $third;
$first = $second;
$second = $third;
$third = $curr;
}
return $curr;
}
Еще 30… Да пока 45 прошли я бы в ужасе был, честно говоря)
У вас в финальном варианте $curr не определён при $n <= 3, и нет проверки что $n > 0
Ну и мемоизацию не помешало бы докрутить, а то нафига всю последовательность пересчитывать при каждом вызове xD
Так вот, как минимум 30%, а то и больше, кандидатов НЕ МОГУТ за 45 минут написать хоть как-то работающее решение.
Кроме того поймите, вот вы вроде адекватен, были бы на месте, мы бы с вами обсудили. Очень часто это заканчивается не так. Либо уже на первой задаче: «а вы знали что тут можно very_rare_function_name? Как нет?» И таким тоном, что поневоле начинаешь себя чувствовать идиотом, тем более что все это знаешь же. Либо задачи сменяют друг друга до тех пор пока не возникнет такой момент.
Однако, все еще зависит от постановки вопроса. Ну например «какие индексы бывают в PostgreSQL». Простой вопрос? По идее звучит просто, но на практике большинство разработчиков кроме b-tree в жизни своей ничего не использовали. Ну некоторые вспомнят GIN/GIST, возможно даже hash (хотя он редко упоминается во всевозможных гайдах да и пользоваться им ну очень редко кому приходится), BRIN не вспомнит никто (если вы недавно не читали документацию и то врядли). Да и сама постановка вопроса ставит в тупик: что значит какие? многоколоночные, уникальные, частичные, функциональные. Вот только часто разговор двух профессионалов и будущих коллег больше похож на допрос и тут прям простор для фантазии. А это всего лишь один простенький вопросик, к задачам еще может добавиться отсутсвие обратной связи, неочевидный синтаксис (ой а какие прелести можно вытворять с использованием магических методов в php) и разные критерии оценки.
Посему если собеседование начинается с задачи то сразу нет. Тем более если на листочке или на н часов.
Вот, кстати, да. Вопросы "Какие… вы знаете" в принципе нормальные. И когда я задаю подобный вопрос, то или предельно чётко, надеюсь, формулирую типа "типы данных в PHP" или ожидаю уточняющих вопросов по каким измерениям делить. Хотя вот тут сам попался на вопрос "какие виды репликации знаете" и начал говорить про бинарную, стейтмент, смешанную, синхронную и нет, а имелось в виду мастер-слейв и мастер-мастер. Вот как-то совсем из головы вылетело.
С другой стороны: очень хорошо, что это видно на собеседовании а не позже.
Одно из самых разрывающих в клочья собеседований (а оно ли это, работу я не искал, просто пришел послушать что скажут) вроде было в крупной компании, достижения и методы очень впечатляли (хотя офис — нет). Основной собеседующий не представился, очень удивился когда я попросил рассказать о компании (еще более когда услышал, что я их оцениваю в той же мере, что и они меня), выражал крайнее нетерпение, выдавал аргументы в стиле «это говно» и вишенкой на торте: когда я попросил стакан воды прям так закатил глаза как будто я икры намазать попросил. Как представлю, что я сними работаю, брррр.
Хотя второй был приятен, улыбался, говорил интересные вещи. Полагаю первый был нач отдела, второй тимлидом.
За Whitesmiths coding style я бы сразу не взял.
Если человеку это нравится, он очень странный!
Очень странно когда компания переживает не о том насколько оптимальным/читаемым/etc будет код, а о том как будут расставлены скобочки и пробелы)
The advantages of this style are similar to those of the Allman style. Blocks are clearly set apart from control statements. The alignment of the braces with the block emphasizes that the full block is conceptually, and programmatically, one compound statement. Indenting the braces emphasizes that they are subordinate to the control statement. The ending brace no longer lines up with the statement, but instead with the opening brace.
Whitesmiths, along with Allman, have been the most common bracing styles with equal popularity according to the Jargon File
Давным давно, когда я еще был маленький, отец меня учил C++ и я усердно читал книжки с листингами сишного кода, вот как раз в таком стиле. Потом были Basic,Pascal, PHP, Java, SQL etc и большая часть кода с которым работал была написана в таком же стиле. Конечно, когда я дописываю библиотеку или участвую в проекте с другим стилем я копирую его в точности, кроме жуткого легаси, где давно всем плевать.
Вот что кстати забавно, begin/end никто не ставит на ту же строку, а вот скобочку уже очень всем хочется. Но вообще то совершенно все равно, код, кроме всего прочего, можно форматировать единым стилем при комите. А вот именование в стиле i,j,k,x,y,z уже не пофиксишь, mont/mons/mesyac уж тем более, говнокод тоже никуда не денется.
Хотя форматирование SQL единой простыней заслуживает порицания. Ибо я не верю, что это вообще можно прочесть.
ЗЫ Вы знаете, за 20 лет вы первый кто поднял этот вопрос)
Да я вообще пошутил скорее. :)
Но, как говорится, в каждой шутке есть доля шутки. Whitesmiths style не используется примерно нигде, и человек с опытом работы в команде давно бы уже отвык, потому возникает подозрение, что кандидат "не такой, как все" и будет вечно спорить по ерунде вместо того, чтобы сделать "как тут принято". Разумеется, это проверяется провокационными вопросами, ну вот как щас :-)
Нести свет у меня нет никакого желания уже давно. Фреймоврк? Да пофигу какой, код стайл? Ссылочку. Хотя… давайте зарежем ваши богомерзкие недоБД и воткнем постгрес, да и вместо монги тоже)
А ну еще могу по UX попрыгать)
ЗЫ вообще отвыкать причин не вижу, даже после продолжительного времени работы в другом стиле мне все равно нравиться так. Кроме того у меня есть свои плюшечки, которых очень много, кстати.
Какая вам разница, как написан пример? В нормальном проекте у вас есть editorconfig/gitattributes/…, который форматирует весь код всех участников единообразно. Предъявлять человеку что у него другой стиль это… Такое.
Можно разве что спросить "у нас на проекте используются табы, а не пробелы, вам ок?" и дождаться логичного "да мне пофиг, лишь бы единообразно".
За редкими исключениями, конечно
Проверка на граничные условия — первое, что в нас пытались вдолбить на программировании на первом курсе в 1987-м году…
Ну и да, переменные объявлять и инициализировать тоже руками приходилось в те времена, обычно…
Причем, в первых двух вариантах вы выполнили проверку… А в третьем — почему-то проигнорировали.
$curr=1 подойдет только в том случае, если первые 3 равны
Ну они равны по условию задачи. Без этого придется передавать первые три значения и номер в последовательности в качестве аргумента…
В любом случае, хоть я уже и не занимаюсь кодингом 25 лет как, но про такую базовую проверку… Я когда первокурсникам помогал на лабах, в таких случаях просил их показать мне устройство чтения мыслей в компьютере и где у них в программе обращение к устройству чтения мыслей.
можно еще инициализацию в одну строчку собрать
… но у нас уже исходник не на перфокартах, где каждая лишняя строчка — лишняя перфокарта, которая может не прочитаться.
… но у нас уже исходник не на перфокартах, где каждая лишняя строчка — лишняя перфокарта, которая может не прочитаться.
И тем не менее народ упорно сокращает имена всего и вся, использует неочевидные приемы и сокращает код так, что не поймешь толи это набор смайлов толи regexp толи обработка данных.
Если внимательно посмотреть, можно увидеть, что curr это и есть third, кроме случаев от 0 до 2, когда он с ними совпадает по значению.
Поэтому можно просто заменить на return third. Нужно только чуть-чуть поправить цикл, чтобы он учел это изменение.
Такой подход позволяет сразу получить работающий код без стресса. Ну, кроме случая когда человек ну вообще программировать не умеет — бывают на первом шаге отлетают. И постепенно дойти до тонкостей — dictionary vs. hash, как устроены деревья. Ну и вообще посмотреть вживую как человек пишет — видно же сразу набита рука или нет.
Просить писать красно-черные деревья — перебор. Спрашивать как работает garbage collector — бред. Но и не просить писать код — это тоже же глупость, так реально нанять человека, который вообще не умеет код писать.
Таким подходом хорошо нанимать джунов, но не сеньоров же. Сеньор должен вас зае**ть на первом же этапе кучей вопросов. Почему города хранятся в массиве? Как часто возникает задача поиска городов? Проходит ли ввод от пользователя валидацию формата? Зачем мы даём пользователю вводить несколько городов в одно поле? Какую пользовательскую задачу мы вообще решаем? Какие SLA есть к этой задаче? И если вы вразумительно не сможете ответить на все эти вопросы, то контрольный: Нафига вы меня спрашиваете такую дичь?
Но и не просить писать код — это тоже же глупость, так реально нанять человека, который вообще не умеет код писать.
Ну конечно, как минимум 5+ лет работал программистом и не умеет писать код.
Работа сеньора состоит в том, чтобы сначала думать, а не бросаться кодить. Поэтому всякие учебные задачки и перестают работать. Если у задачи нет никакой практической пользы, то она может поставить в тупик лучших специалистов. Ведь их прямая обязанность — избегать решения подобных задач, т.к. решать любую бесполезную задачу — это прямые убытки для бизнеса.
Я вообще раньше сеньеров кодить не просил. Ну типа как-то неудобно — чувак с 10 лет опыта, а я его тупую задачку из института прошу делать. Но один раз пришел товарищ, который умел что-то там по теории рассказать, но не мог писать код вообще. Ну типа вот эту самую задачку — не смог. Типа «ну понимаешь, я лидил, забыл уже что там как». С тех пор, обязательно сначала исключаем волчанку.
Он просто сделает задачку быстро и четко
String.Split(" "), цикл, String.Find()
Вы это в контексте данной задачки считаете решением?
Она же изначально сформулирована не как задача, а как проверка "конформизм vs профессионализм": прогнётся ли человек под вас в стрессовой ситуации, поступится ли профессиональной этикой, начав писать то, что вы просите?
У этих прекрасных парней есть великое будущее без меня. Кто-то из посадит на золотой трон, вокруг которого стоят негры с опахалами, и приходят просители, и просят написать код, а они им объясняют что код этот писать не будут, и просителей казнят. А тут я такой — взял их, и принял! И это прекрасное их будущее прошло мимо них. Я же от совестливости сопьюсь и повешусь — великую жизнь большому человеку так бездарно испортить.
Так что я все-таки спрошу всех код написать, а если кто мне плюнет в лицо — сотру специальным платочком, его положу в сейф, и потом продам плевок великого Стива Джобса 2 за миллион денег. И всем хорошо будет.
Решать задачи на интервью — это уже нарушение профессиональной этики? :)
Смотря, что вы имеете в виду под решением задач.
Писать код, не выяснив какова его роль в удовлетворении пользовательской потребности, — да, нарушение профессиональной этики.
Писать код, который опирается на крайне неподходящую архитектуру, которая не является legacy, а просто потому что так сказали — да, нарушение профессиональной этики.
Если программист перестаёт задаваться вопросами "зачем?" и "почему так?", то ему лучше закрыть редактор кода и больше не открывать.
С другой стороны, вон кто-то и бездумных кодеров ищет, которым скажешь, что города хранятся в массиве и они не удивятся почему, а тупо примут как данность и будут что-то писать xD
Тут, наверное, надо разделять инженера-программиста и техника/программиста/программиста.
Можно много разделений придумать, но есть же уже Junior/Middle/Senior.
Если первые 2 могут не понимать что-то из-за нехватки опыта и знаний, то Senior должен быть способен понять и осознанно обсудить задачу, даже если путь её решения уже прописан архитектором или CTO. Тут уже нет места реактивному поведению.
Нет, Junior/Middle/Senior/Lead это подразделы Engineer/Developer/Coder, если придерживаться официальной (пост)советской квалификации. Можно условно считать, что Senior Developer (старший техник-программист) плюс-минус равен Junior Engineer (младший инженер-программист).
Мне уже интересно, а senior вообще должен программировать?
Или он все время будет замещать PM'а и software architect'а? :)
На самом деле есть компании/проекті, где Senior Software Engineer почти не программирует, а принимает задачи от PM'а и software architect'а?, декомпозирует, назначает на 3-4 подчиненных программиста и ведёт их за ручку тщательно контролирует выполнение.
Должен, только уже осознанно. Просто инвертируйте условия в предыдущем комментарии и получится:
Писать код, выяснив какова его роль в удовлетворении пользовательской потребности. При сомнениях в архитектурных решениях, обсуждать эти вопросы с архитектором или с CTO, или при их отсутствии с другими сеньорами.
P.S. Роль сеньора — это уже про ответственность по отношению к написанному коду. Поэтому проявления безответственности можно и нужно называть нарушением профессиональной этики.
P.P.S. Кстати, часть пользовательских задач вполне может решиться и без написания кода, когда выяснишь, что по факту нужно. А, как известно, лучший код — ненаписанный код. Такие кейсы, конечно, редко дойдут до сеньора, но с другой стороны не во всех компаниях есть архитекторы.
Из где-то сотни кандидатов, что я интервьюировал за последние года три, один или два получили оффер вообще не написав ни строчки кода. Но это скорее исключение из правил.
Задавал бы :)
- Как эта таблица будет выглядеть?
- А какой бы индекс построили?
- А как вообще индекс в БД в целом можете рассказать?
Задача должна быть предлогом пообщаться с человеком.
Зы формулировка 3 более чем странная
Может она странная потому, что я слово "работает" упустил? :)
Вот взять тот же вопрос про индекс в БД. Я когда его задаю, не ожидаю каких-то точных ответов. Интервью — это диалог. Некоторые говорят "ну, не знаю". Хорошо, давай тогда подумаем. Потом можно дойти до разных хэшей. А в чем недостаток хэша для индекса? А как его исправить? Так доходим до деревьев. А какое дерево? А кроме бинарных деревьев еще какие-то бывают? А почему не стоит использовать бинарное дерево? Вариантов для такого диалога масса.
Когда мне самому задавали такой вопрос в ING, причем к тому времени я его использовал уже пару лет, я ответил, что индекс это обычно BTree, а точнее BTree+. Но зависит от БД, есть и другие варианты. А там мы еще минут десять на эту тему беседовали.
Хеш индексы вообще мало кому нужны, ну за исключением тех что бд строит по primary key. А вот триграмм/частичные индексы нужны всем, но мало кто их использует.
Есть так же точка зрения, что это работа архитектора бд, а никак не backend-программиста.
ЗЫ а почему не стоит использовать b-tree?)
ЗЫЗЫ вы все уже уклонились от ответов на заданные вами вопросы)
95% использует бд на таком уровне, когда эти вопросы смысла особого не имеют
В тех компаниях, куда я нанимал — более чем используют :)
Хеш индексы вообще мало кому нужны, ну за исключением тех что бд строит по primary key. А вот триграмм/частичные индексы нужны всем, но мало кто их использует.
Прекрасный ответ, на самом деле.
это работа архитектора бд, а никак не backend-программиста.
Я как был в свое время и DBA, но не считаю, что это надо столь жестко разграничивать. Более того, у меня были кандидаты, которые вообще не работали с SQL, и это нормально.
ЗЫЗЫ вы все уже уклонились от ответов на заданные вами вопросы)
"индекс это обычно BTree, а точнее BTree+. Но зависит от БД, есть и другие варианты"
Примерно то же я ожидаю услышать и от кандидата.
Я так попробовал и мне не понравилось. Очень трудоемко и требует много времени. И я тороплюсь, и мой собеседник торопится, переговорка на час забронирована, и т. п. Я решил, что буду так делать, когда есть настроение, и я уже точно вижу, что этого человека я беру, т. е. на него потратить силы не жалко.
Уточнаю что все просто и без подвохов. Пишет String.Split(" "), цикл, String.Find() — пойдет.А «Великий Новгород» в массиве есть?
А надо ли находить «Петропавловск» в «Петропавловск-Камчатский»?
(И «Ростов» в «Ростов-папа»?)
Очередной тред боли на тему того, как бедных айтишников унижают мерзкие эйчары и прочие негодяи. Такие темы всегда хорошо заходят, так как, думаю, у любого есть хотя бы одна история неудачного собеседования. А уж представлять себя Д'Артаньяном, недооценненым нехорошими людьми, так и вовсе каждый первый любит.
А я вот тоже на собеседованиях даю простую задачку. И мой опыт найма программистов, хоть и небогатый, но однозначно показывает: тот кто не способен написать на собеседовании что-то типа FizzBuzz — тот и в реальности программировать не способен. Пусть хоть 10 лет опыта и стопицот дипломов и регалий — этот человек будет очень медленно решать простые алгоритмические задачи, которые регулярно всплывают тут и там. Он будет адово тупить и зависать на любых задачах сложнее чем "сконфигурировать что-то по шаблону" и "переложить объекты из одного апи в другое".
Я скорее джунов-миддлов собеседую, среди них примерно половина из тех, кто приходит на собеседование.
Я обычно даю задачку — обратить массив. Это простейший пример на понимание работы с циклами и индексами. Сразу предупреждаю, что не надо изобретать сложных алгоритмов, никакого подвоха тут нет и любое простое решение сойдет, даю настроенный ноутбук с ИДЕ, сам отхожу в сторонку и прошу позвать меня когда будет готово.
В итоге многие городят какую-то дичь, которая в итоге не работает и валится с выходами за границу массива.
Тут можно сколько угодно рассуждать на тему стресса и "написания кода под прессингом", но если человек такое не может написать (даже без лимита времени) — он не программист и на вакансию программиста претендовать не может.
Пару раз приходилось "на безрыбье" брать людей, которые с этой задачей справлялись плохо — в итоге результаты работы были соответствующие.
Помню из своей первой конторы еще историю — после одного собеседования проводивший его вышел из коридора, начал биться головой об стену и приставать к проходившим по коридору и задавать им вопросы. Что характерно, на его вопросы даже наши 3д художники смогли ответить (ну они у нас там подкованные в ИТ были, для Maya всякие скрипты автоматизации писать умели, но все-таки не программисты). А (по его словам) люди, приходившие на позиции сеньора, с опытом и внушительным резюме, не могли. Но при этом не стеснялись просить ощутимых денег.
Я обычно даю задачку — обратить массив. Это простейший пример на понимание работы с циклами и индексами.Ну а если он использует что-то типа array_reverse(), аналог которого есть в любом ЯПВУ, что вы тогда узнаете про
понимание работы с циклами и индексами?
Если кандидат предложит библиотечный метод то это хорошо и повод немного поболтать на тему знания стандартной библиотеки. Но потом я все-таки прошу сделать это ручками.
Но потом я все-таки прошу сделать это ручками.
Зачем?
Затем, что программирование это не только перекладывание из коллекции в коллекцию и вызов пары-тройки методов API. Иногда приходится своими руками что-то придумать. Ну вот пришел к вам набор данных, надо их отфильтровать, как-то упорядочить, преобразовать и только потом передать дальше.
Причем никогда заранее не знаешь, что и как потребуется обработать, иногда можно обойтись вызовом одной-двух библиотечных функций, иногда нет. Человек, который даже цикл написать не может, будет в таких моментах очень надолго зависать, тормозя всю работу.
При этом в рамках собеседований достаточно сложно родить какой-то содержательный пример "из жизни" — все они будут либо слишком большими (и тянут уже на тестовое задание, а не на задачку на собеседование, а такие задания — тоже источник постоянной боли и вайна на хабре), либо опять же очень синтетическими и упрощенными, и ничем не будут отличаться от таких абстрактных задачек. Поэтому в качестве эффективного фильтра приходится использовать такие вот простые упражнения.
Буду рад, если вы какую-нибудь такую задачку порекомендуете. Которая не настолько общеизвестная (как FizzBuzz), не требует написания больше 5-7 строчек кода и проверяет какие-нибудь базовые навыки программирования.
Но сейчас наверное и эта задача уже настолько же замылена, как и FizzBuzz.
При этом в рамках собеседований достаточно сложно родить какой-то содержательный пример «из жизни»
Поэтому лучше попросить кандидата написать абсолютно синтетический код, который никогда не понадобится?
Предлагали бы уже сортировку по заданным условиям делать, больше похоже на вменяемую задачу, чем «разверни массив с завязанными руками и без ноутбука».
И кстати, как бы вы ответили на встречный вопрос кандидата «зачем»?
Поэтому лучше попросить кандидата написать абсолютно синтетический код, который никогда не понадобится?
Любой код с собеседования скорее всего будет синтетическим и никогда в жизни не понадобится. Можно пытаться создать задачу исходя из своего релевантного опыта работы, но это как правило довольно нетривиально — суметь упаковать что-то несинтетическое в несколько строчек кода.
с завязанными руками и без ноутбука
Почему без ноутбука-то? Я как раз и пишу, что даю ноутбук с IDE и подготовленным проектом.
И кстати, как бы вы ответили на встречный вопрос кандидата «зачем»?
"Небольшая проверка на ваше умение писать простой код".
Повторюсь, я не проверяю знание алгоритмов, которые в реальности вряд ли пригодятся, я проверяю способность просто тупо написать три строчки работающего кода. Те, кто сами собеседования не проводят, обычно не представляют какое количество людей приходят на собеседования и не могут этого сделать.
но это как правило довольно нетривиально — суметь упаковать что-то несинтетическое в несколько строчек кода
Согласен. Но с моей точки зрения нужно объяснять ограничения: просьба развернуть массив не пользуясь библиотечной реализацией просто потому что интервьюер запретил, как раз и является очень синтетической задачей без предпосылок и искусственными ограничениями (читай с завязанными руками).
Небольшая проверка на ваше умение писать простой код
Так если вам писать простой код надо вы студента наймете? Вряд ли человек с опытом загорится желанием к вам идти чтобы писать простой код.
Да простой вопрос «а напишите map/reduce по таким-то условиям» уже на порядок лучше чем «разверните массив не пользуясь компилятором»
сами собеседования не проводят, обычно не представляют какое количество людей приходят на собеседования и не могут этого сделать.
Так может вам процессы пооптимизировать? Скрининг ввести, чтобы таких кандидатов отсеивать.
Опять же, я ничего против такого подхода не имею, просто для меняон выглядит иррациональным и слегка пассивно-снисходительным для кандидата.
А кто их отсеивать-то должен? По резюме? Так резюме обычно еще меньше о человеке говорят, чем умение решать задачки. По дополнительному собеседованию? Не у всех есть на это ресурсы, да и тут вон все воют когда вместо начальника отдела их начинают всякие хрюши мучать.
В общем нет тут правильного ответа, на любой вид собеседования найдутся те, кому он не понравится.
Я даю задачу, которою пришлось решать самому в нашем проекте. Вернее не решать, а перерешивать — там был написан вырвиглазный запутанный рекурсивный полный перебор, который можно было переписать на ДП, сократив в несколько раз, сильно ускорив и упростив при этом.
Пришлось ее немного упрастить, выкинув все некритичные детали, и абстрагировать от предметной области.
Мне конечно повезло, что я такую задачу нашел, но мне кажется что это не невозможно в любом довольно большом проекте. Не обязательно это должен быть какой-то умный алгоритм. В достаточно большом проекте будет хоть немного нетривиального кода, который как-то обрабатывает какие-то данные. Довольно часто из него можно сделать задачу на собеседование.
Затем, что программирование это не только перекладывание из коллекции в коллекцию и вызов пары-тройки методов API.
Как правило, оно и есть.
Ну вот пришел к вам набор данных, надо их отфильтровать, как-то упорядочить, преобразовать и только потом передать дальше.
Ну вот эту задачу и задавайте. Хотя я бы её так и решал xs.filter().group_by().map()....
От программиста следует ожидать самого простого способа решить задачу, а не вставлять палки в колеса "не используйте букву i в названии переменной цикла".
Предлагаете кандидата сразу брать? Пришел — молодец, нанят? :)
Честно говоря, мне с трудом вериться, что такие существуют. Я постоянно вижу в интернетах мнение, что они есть, но вживую подобных коллег никогда не встречал. У меня в голове не укладывается, как это возможно. Я перестаю с человеком общаться, если он не хочет расти и не хочет понимать, почему индексирующий сервис должен быть идемпотентным, а тут про физзбазз страшные рассказы.
Хмм… Я тоже завалил какую-то шнягу на трансформацию бинарного дерева в конторе "с совой". Потом еще какую-то другую шнягу на ограниченный поиск в другой такой же "перспективной компании".
Я думаю упражнения — это хорошо, но есть один нюанс. Проходить они должны в нормальных рабочих условиях, максимально приближенных к боевым. Как часто вы impromptu будете объяснять комнате полной инженеров как манипулировать двоичными деревьями? А кодить по тимвьюверу на чужой машине, параллельно объясняя ход своих мыслей? А как на счет оптимизации кода под конкретный GC без телеметрии? Может подъем кубов с масштабируемой трехзвенкой с нуля в проде за час? Вы правда именно так работаете? Если ответ — реально "да", то, простите, я ваш вертеп укурков не пойду работать ни за какие деньги. Если "нет" — тогда зачем весь этот цирк с конями? Что вы проверяете?
Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.
В интервью очень многое — дань моде, к сожалению. Раньше было модно думать за пределами коробки, потому были круглые люки и автобусы набитые шариками. Сейчас модно хипстерство и коллаборешн, поэтому задачки и интерактив. Завтра будет найм только через нетворкинг и по количеству звезд на гитхабе. Если контора гоняется за трендами как ошпаренная, десять раз подумайте есть ли смысл там работать за +15К в год.
Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.
Подход хороший, но ИМХО предельное время на задачу — 1-2 часа, причем желательно и собеседующего, и собеседуемого, иначе это какая-то домашняя работа строгого учителя. "Разошлю сотне претендентов задачку, пусть помучаются". И потом 2 минуты на проверку каждой.
В конторах, где мне собеседование проходить понравилось оно было устроено в виде итеративного дизайна на бумажке вместе с местным архитектором. В стиле "как программисты хлеб пекли".
Как software architect, именно так и стараюсь делать :)
Правда стараюсь не на бумажке, а на доске, но если кандидат очень хочет — можно и на бумажке, конечно.
"Разошлю сотне претендентов задачку, пусть помучаются"
Задачка "домой" дается только тем, кто смогли нарисовать адекватный дизайн на доске и связно объяснить. Это как раз ваша бумажная задача. У нас это порядка 30% от отфильтрованных по телефону и пришедших на интервью. За год это где-то с десяток-полтора у нас в отдел, из которых наймут 3-5.
Дизайн "слушают" 4 человека. Чтобы дать задачу, за кандидата должны проголосовать как минимум трое, один из которых будет проверяющим (ревьювером).
Ревьювер будет проверять, согласовывать упрощения, отвечать на вопросы и т.д. Ревью провести не 2 минуты, а как минимум час. Потому что проходит оно по всем внутренним правилам. Надо все собрать, прогнать тесты, прочитать код, контракты к нему, проверить исполнение контрактов, инварианты и т.д. Так что мы времени на проверку тратим приблизительно 30%-50% от того, что потратил кандидат.
Так что я думаю это просто еще один этап после бумажной фазы, призванный отфильтровать людей которые не могут аккуратно код писать, или с которыми никто не хочет работать.
У меня довольно много знакомых, которые вообще задачи не желают делать, причем корреляция такая, что чем выше скилл, тем меньше человек любит решать задачки.
Про 4 интервьювера тоже неплохо. Мне-то пофиг, меня однажды 10 человек одновременно собеседовали, хотя и не очень комфортно было, но я его прошел. А вот многие пугаются, когда больше 1-2 человек, не говоря уже про полдесятка.
Не слишком ли серьезный фильтр? Причем не очень релевантный.
5 человек — средний размер команды. Если кандидату не комфортно в переговорке с 4 людьми, наверное ему будет некомфортно и на стендапе с этими же 4 людьми. Кроме того дизайн — это субъективное упражнение. Отсюда и число 4:
- Если 1 интервьювер — нет гарантии непредвзятости (залип юноша на симпатичную девушку или наоборот).
- Если 2 — возможна ситуация, когда один за, а другой против, и не понятно прошел кандидат или нет.
- Если 3 — уже лучше, но там перевес всего в один голос, т.е. ошибка первого рода (пропустили дурня) и второго рода (зарубили гения) равновероятны (должны ошибиться 2 человека сразу).
- Для 4, чтобы получить ошибку первого рода надо чтобы ошиблись 3 человека сразу, а для второго рода достаточно по-прежнему ошибиться 2. С учетом того, что практическое упражнение стоит усилий с обеих сторон — такой подход оправдан.
У меня довольно много знакомых, которые вообще задачи не желают делать, причем корреляция такая, что чем выше скилл, тем меньше человек любит решать задачки.
Угу, бывают и такие. Благодарим, жмем руки, не связываемся. Для нас объективность — это один из главных критериев. В компании принято считать, что собеседование a-priori субъективно, следовательно, мы не можем гарантировать непредвзятость без формального этапа. С учетом того, что найм — это игра с нулевой суммой, поступать так было бы несправедливо по отношению к другим кандидатам.
Кстати, задачки дают даже менеджерам. На позицию продакт менеджера, например, дадут приоритизировать бэклог и разбить на спринты, а потом объяснить почему так. Без задачек могут нанять на роли, где решает либо история работы и мнение профессионального сообщества (executives), или сертификация (бухгалтерия).
Если кандидату не комфортно в переговорке с 4 людьми, наверное ему будет некомфортно и на стендапе с этими же 4 людьми
Есть очень большая разница между 4 хорошо знакомыми людьми и 4 абсолютно левыми.
5 человек — средний размер команды. Если кандидату не комфортно в переговорке с 4 людьми, наверное ему будет некомфортно и на стендапе с этими же 4 людьми.
Leap of logic
Отсюда и число 4
Адекватное количество собеседующих: 1-2. 1 обычно маловато все же для принятия решения, отсюда два. Непосредственный начальник и либо его коллега из другого отдела (того же уровня), либо ПО продукта.
А когда тебя собеседует 3 лида, 5 архитекторов и гендир (который тоже бывший разраб), и все одновременно, это нервирует. Часто мы общаетесь с такой компанией, где вы в центре внимания и все вас обсуждают (а не задачу)?
Угу, бывают и такие. Благодарим, жмем руки, не связываемся. Для нас объективность — это один из главных критериев. В компании принято считать, что собеседование a-priori субъективно, следовательно, мы не можем гарантировать непредвзятость без формального этапа. С учетом того, что найм — это игра с нулевой суммой, поступать так было бы несправедливо по отношению к другим кандидатам.
Да проводите как хотите, хоть игрой в дартс с развешенными на стене резюме, вопрос в том, насколько это коррелирует с качествами, которые хочется иметь на проекте. Возможно "Любители решать задачки" это одно из таких очень важных качеств, которые вы ищите.
Кстати, задачки дают даже менеджерам. На позицию продакт менеджера, например, дадут приоритизировать бэклог и разбить на спринты, а потом объяснить почему так. Без задачек могут нанять на роли, где решает либо история работы и мнение профессионального сообщества (executives), или сертификация (бухгалтерия).
У меня как-то было за две недели 24 собеседования. Если каждый собеседующий считает своим долгом кроме 1-2 часового собеседования еще задачку часа на 4 на дом дать, сколько времени у меня остается на сон и основную работу?
Leap of logic
Обоснуйте? Кандидата просят рассказать ваше решение относительно простой задачи, про которую он заранее спокойно обдумал в течении часа. Чем это не типовая ситуация, кроме аргументов про "я с ними не бухал и потому боюсь".
1 обычно маловато все же для принятия решения, отсюда два. Непосредственный начальник и либо его коллега из другого отдела (того же уровня), либо ПО продукта.
Зашибись. А инженеров мы спрашивать не будем. Действительно, нафига. Большая насяльника решила, холопам радоваться. Не допускаете ли вы мысль, что инженеры по части оценки скиллов коллег несколько компетентнее эйчара, соседского начальника и ПО вместе взятых?
Возможно "Любители решать задачки" это одно из таких очень важных качеств, которые вы ищите.
Не задачки, а поставленные задачи. Повторюсь: задача на дом — это упрощенный вариант того, что когда-то делала команда. Например добавить LRU кэш куда-нибудь. Проверяется умение работать с кодом, читать тикет, оформлять коммиты, спрашивать уточнения, гуглить или спрашивать непонятное. Базовые вещи для инженера. Таки да, если сеньор не может вышеперечисленное — простите, нет.
У меня как-то было за две недели 24 собеседования… сколько времени у меня остается на сон и основную работу?
Ни фига себе! Снимаю шляпу. Я последний раз сходил на три. Правда до этого пару десятков завернул по телефону… Возможно ответ кроется в том, что ковровое бомбометание резюме не самый эффективный метод поиска работы для сеньора? Есть же LinkedIn, Glassdoor, бывшие коллеги...
Обоснуйте? Кандидата просят рассказать ваше решение относительно простой задачи, про которую он заранее спокойно обдумал в течении часа. Чем это не типовая ситуация, кроме аргументов про "я с ними не бухал и потому боюсь".
Если человеку не комфортно при допросе 4 незнакомых людей, это не значит, что он плохо живет с людьми в команде. И наоборот.
Зашибись. А инженеров мы спрашивать не будем. Действительно, нафига. Большая насяльника решила, холопам радоваться. Не допускаете ли вы мысль, что инженеры по части оценки скиллов коллег несколько компетентнее эйчара, соседского начальника и ПО вместе взятых?
Не знаю как у вас, а во всех местах где я собеседовался собеседует как раз тех/тимлид, который немного шарит в инженерии. Для адекватного собеседования нужно иметь человека на уровень выше (если это возможно), чтобы он мог оценить по достоинству скиллы человека.
Не задачки, а поставленные задачи. Повторюсь: задача на дом — это упрощенный вариант того, что когда-то делала команда. Например добавить LRU кэш куда-нибудь. Проверяется умение работать с кодом, читать тикет, оформлять коммиты, спрашивать уточнения, гуглить или спрашивать непонятное. Базовые вещи для инженера. Таки да, если сеньор не может вышеперечисленное — простите, нет.
То есть да. Ладно, у меня случай запущенный, но даже когда я не так сильно искал, выходило штук 8 собеседований в неделю. Каждая на задачку на пару часов. это 20 часов в неделю. Кто-нибудь готов платить за эти задачку половину месячной ЗП разработчика?
Ни фига себе! Снимаю шляпу. Я последний раз сходил на три. Правда до этого пару десятков завернул по телефону… Возможно ответ кроется в том, что ковровое бомбометание резюме не самый эффективный метод поиска работы для сеньора? Есть же LinkedIn, Glassdoor, бывшие коллеги...
Я говорю с позиции собеседуемого. Я активно искал работу, и хотел рассмотреть все варианты. Пару задачек я решил, когда и задачка была интересная, и место норм. Но знаю полно отличных разрабов, для которых это недопустимо, тем более что математику я выше привел. Точно так же, хотя у меня гитхаб полон всякой фигни, не все хорошие разработчики в опенсорсе что-то делают.
Каким образом задачки делают ваше интервью объективным?
Оч правильный вопрос. Ответ выше — задача является упрощенным вариантом того, что команда делала раньше. Пример — есть обработчик асинхронных запросов, многопоточный (в реальности был брокер сливающий данные из нескольких стримов Kinesis, в виде эдакого лямбда-кластера). Даем кусок кода брокера, просим добавить LRU кэш обработчиков, чтобы они не создавались на каждый чих. Примеры ошибок:
- прекрасно написаный LRU кэш… запросов.
- статической хэш-таблица, про LRU и многопоточность — ни слова
- все завернуто в глобальные локи, обработчик стал практически однопоточным
- старый код полностью заменен новым, включая части которые менять было не нужно (ирония: новый код перестал гарантировать обработку сообщений).
- вместо кэша реализован синхронный пул обработчиков, хотя в контракте сказано что они реентерабельны.
- отказ делать задание, предложение заменить Kinesis на другую технологию
Как думаете, что можно сказать о кандидате в каждом случае?
А какие задачки с уточками для менеджеров можно придумать, я наверное лучше сдержусь :)
Я годный (надеюсь) пример привел выше — приоритизация бэклога и планирование спринтов. Если придумаете что-то типа этого с уточками, буду признателен.
С тех пор прошло два года. Я устроился в другую компанию. Решил просто огромную гору задач, разработал кучу виджетов, отрефакторил тонны старого кода, вырастил джуна, написал много документации и так далее. С коллегами обсуждали: кажется, не два года прошло, а четыре, работы реально много. Моим поделками ежедневно пользуются миллионы людей, и вроде бы компанию устраивает качество работы.
А те ребята ещё спустя где-то полгода всё искали человека. И потом ещё через год искали.
ps. Думаю, более-менее разумным выходом были бы сертификации в авторитетных центрах. Что-то типа прошёл двухнедельные курсы, показал себя со всех сторон, порешал сложные задачи, получил лычку и право называться senior. Тогда и собеседующим было бы спокойнее. Смотрели бы на собесах soft skills и мотивацию кандидата, а не знание на память всех встроенных методов. Но до этого, очевидно, далеко.
Гарантии вообще, обычно, нет.
Интересен не столько достигнутый результат (все тесты зелёные), сколько способ решения задачи / кодирования. Если предложенный вариант решения мягко говоря странен — начинается дискуссия по возможным улучшениям и/или краевым случаям, что позволяет оценить опыт кандидата и количество косяков в production, которые от него можно ожидать.
Экономит просто ТОННЫ времени и нервных ресурсов на собеседованиях и неплохо отделяет тех, у кого код на кончиках пальцев, от заучивших ответы про устройство HashMap.
Можно мне к вам на собеседование прийти?
Это один из наиболее здравых подходов, кстати. Видел такое у OLX и Atlassian как минимум.
Кстати, как-то было собеседование где предоставили ноутбук. С треском провалил прежде всего из-за ноутбука. Так состоялось моё первое личное знакомство с техникой и софтом Apple
За отпущенные 2 часа большинство не успевает.
Всего две задачи, можно использовать IDE.
Первая — разработать некий сервис + тесты, из сложностей — нужно уметь читать требования
Вторая — до 20 строк забагованного кода, нужно почитать и найти косяки (уже без документации).
Обе задачи вполне себе боевые, первая имитирует процесс разработки, вторая — кодревью.
За год я смог одобрить 9 человек, прошло через меня несколько десятков.
А резюме почти у все были хорошие. Многообещающие.
Зато многие кандидаты говорят, что это был их лучший собес за все время. )))
У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?Таки да. Сами при планировании дают оценки, а потом
А вообще есть только один способ узнать, может ли человек работать — это нанять его и поработать с ним вместе относительно длительное время.
Менеджмент к такому не готов, потому что на большом и сложном проекте человек за испытательный срок не выходит на полную мощность, а после — его уже просто так не уволить.
Так что приходится идти на компромиссы.
Но вы немножко передергиваете. Интервью не предполагает увольнения или наказания за «плохой код».
Это встреча двух профессионалов, которые должны решить, хотят ли они работать друг с другом, причем собеседуемый заранее знает, что от него будет требоваться.
Так домашние задания тоже не хотят делать :)
Из заданий, которые делал в последние годы:
- написать интерпретатор простого языка. Решил использовать наконец-то полученные кучу лет назад по теории трансляторов, все эти парсеры, токенайзеры, токены, AST и т. д. Бонусом было компиляция скрипта в LLVM
- написать простой CRUD на голом PHP. Применил по полной SOLID, продублировав частично PSR интерфейсы, создал adhoc DataMapper ORM+identityMap+UnitOfWork c детектором изменений (Doctrine/Hibernate like в общем), DI-контейнер и т. п.
- написать программу выявления десинка частот часов двух нод на ассемблере с очень ограниченным набором команд. Говорили что использовали систему команд каких-то реальных процессоров, но по ощущениям даже если так, то сильно порезали
Во всех случаях главное, что побудило согласиться их делать: задачи интересные сами по себе или легко делаются интересными, если не решать их в лоб. Всем остальным с тестовыми вроде "на хорошо известном фреймворке сделать CRUD веб-сервис с паблишингом событий в рэббит, и консьюмер, которые их тупо выводит консоль, но устойчивый к повторной отправке" отвечал "могу устно рассказать техспециалисту (задания давали рекрутеры) как их буду делать". По статистике соглашались на это на проектах с европейскими заказчиками, американские, израильские, японские и российские — нет: или решение, или "нам не нужны люди, которые вместо решения задач буду рассказывать как они их будут решать" (почти дословная цитата).
На мой взгляд, первое слишком объемное, а третье требует очень узкой специализации.
Первое можно было решить "в лоб" довольно коротко, язык куда проще первых PHP и JS — AST моя инициатива, иначе бы просто не стал делать. А третьте, по сути, на общую программистскую логику. Может тому, кто вообще с ассемблерами или хотя бы Си не игрался будет немного сложновато вникнуть, что такое, например, порт или прерывание, но, по-моему, этим можно пренебречь.
Чем пренебречь? Это прям мегаузкоспециализированно. Некоторые люди вообще ассемблер никогда не писали и не знают. Это особо не мешает бтв, разве что листини двух вариантов кода по-разному скомпилированному трудно самому оценить.
Максимальный адекватный объем тестового задания — распарсить что-то простое типа json.
Никто не требует от кандидата слишком многого.
Речь не идет о коде качества, достойного production. Сервис, который нужно сделать, имеет одну зависимость (с единственным методом), и сам тоже имеет единственный публичный метод. Протестировать нужно ровно те кейсы, которые упомянуты в требованиях, их три. Это много?
Я не считаю, что любая практическая задача на час-полтора позволит надёжно отличить даже хорошо знакомого со стеком толкового джуниора (в моей системе координат) с годом-полутора практического опыта от сеньора. Это как раз больше про теоретические беседы, понимание нюансов и технических, и командного взаимодействия.
Беседа по существующему коду даст больше, например — ввести в приблизительный контекст, показать код, попросить найти проблемные места — совсем необязательно ошибки per se, просто "это выстрелит нам в ногу при описанных условиях". Поговорить о командной работе, понять, комфортно ли вам с таким человеком взаимодействовать, достаточно ли вы схоже понимаете процессы разработки.
Если кандидат на практическом уровне знает Java и JDK, способен реализовать тестовую задачу с многопоточностью, способен понять, какие тесты нужны и написать их — сеньор почти наверняка.
Вот описанная вторая задача — она как раз по существующему коду, ее сеньор за 15 минут решает, если на четверку знаком с языком программирования и имеет
некоторый опыт поддержки реальных приложений.
Было за все время два интересных кандидата — правильно решили задачу на кодинг (с документацией и гуглом), но не смогли решить на ревью. Оказалось — сеньоры, но язвк недавно сменили. Умели тесты писать, принципы многопоточки понимали, но еще плохо знали JDK.
Таким образом, сочетание задач позволяет с приемлемой долей вероятности позволяет отличать новичков в Java, мидлов и джунов от сеньоров.
Году в 2017 гугл в поисковой выдаче выдал JSONPath и… весь мой код спокойно был пересажен на опенсорсную библиотеку, без правок на моей стороне (по селекторам). Я доволен :)
Слишком специфично. Я вот парсер-комбинаторы никогда не писал. Да, представляю, после того, как почитал книжку по ФП и там это был один из примеров монадической структуры данных, но — не писал. Написать в первый раз на собесе может и смог бы, не знаю. Но качество боюсь было бы не лучшее.
Если у вас работа основана на обработке данныхи у вас это альфа и омега — то конечно я вам тупо не подхожу, и задача хороша. Но как генерик-задача для сферического сениора в вакууме — не очень.
Я на такое ходил только чтобы потренироваться.
PS. Не знаю, может вы работаете и в одной из перечислинных компаний, тогда ок. Но описание не подходит.
Не Гугл, Фейсбук или Эппл.
А средняя зарплата — это какая, по вашему мнению?
Ну и ясно, что сложность реальных задач выше, чем сложность задачи с двухчасового собеседования.
Я из Беларуси и мне кажется эта цифра слишком заниженной.
Вообще, я говорил о том, что работник в основном оперирует двумя параметрами — ЗП и технологии. Если на проекте он отстает от трендов, то это должно компенсироваться деньгами. Если идет впереди трендов, то можно некоторое время работать с ЗП ниже рынка, чтобы потом свалить на ЗП в два раза выше там где нужны эти технологии. Ну еще если это Гугл или Яндекс, то можно поработать там на средней ЗП чтобы получить строчку в резюме и иногда хороший опыт.
Пока программисты будут собеседовать, ничего улучшаться не будет.
Примерно половина вайна на хабре про собеседования — про случаи, когда собеседуют не программисты, а всякие хрюши и прочие психолухи. Гениев от ИТ оскорбляет, что какой-то плебс, не разбирающийся в их специальности, почему-то решает их судьбу.
Это было бы прекрасно, если бы всем нужно было одно и то же от сотрудника (что технически, что с точки зрения работы в команде, что просто по человеческим качествам), но это, очевидно, совершенно не так, и потому будут 3-5 разных моделей собеседований, и, внезапно, они все имеют место быть. Это нормально и не плохо.
1) Ходите на собесы в нормальные конторы, где люди ищут себе коллег и готовы общаться по вашему опыту и проектам
2) Если хотите конкретно в Google, Amazon, Facebook, Netflix и тд прекратите ныть и примите их правила игры.
1. Может не пустить хорошего специалиста, который теряется, когда испытывает стресс на собеседовании
2. Может не пустить хорошего специалиста, который, блин, вот сегодня сам забыл, как инвертировать бинарное дерево, и придумать не успел.
3. Может отпугнуть хорошего специалиста, который считает, что ему негоже решать такие задачки и вообще это жуткий моветон, а такой работодатель — отстой.
Но
4. Люди, которых этот фильтр пропустил, не теряются в стрессовых ситуациях, они не из тех, кто не сложит себе цену, и, блин, они реально умеют программировать!
Так что я буду задавать задачки и дальше. Я переживу, если упущу какую-то звезду, есть и другие звёзды.
это люди которые уже прочитали книжку «крекинг какое-то там интервью», откуда вы взяли свои задачки и бинарные деревья, нарешали кучу задачек на хакеранке,
Прекрасно. Это именно то, что надо, вообще-то это и называется «уметь программировать» :)
Но есть одно «но»: человек, который умеет решать подобные таски, решит и любые другие.
Вы прикалываетесь? Все бы тогда джунами обошлись, если бы учебные задачки позволяли решать реальные.
Умение соображать проходить собеседования
Я не могу себе представить человека, который сможет сочинить нехитрый алгоритм на собеседовании, и не сможет сочинить его в другом случае. Зато легко представлю человека, который не сможет сочинить нехитрый алгоритм на собеседовании, и вообще нигде не сможет. Вторых и повидал предостаточно.
Я не могу себе представить человека, который сможет сочинить нехитрый алгоритм на собеседовании, и не сможет сочинить его в другом случае.
Он угадал, ему повезло.
Именно эту задачу он знает, как решить.
Уже задавали подобную задачу на предыдущем собеседовании. Подготовился к вашей задаче, интересовался у тех, кто проходил собес у вас.
И как из этого следует "решит и любые другие"? Другие задачи на то и другие, что они принципиально отличаются.
Это очень наивно так думать, мягко говоря.
1. Нельзя наизусть выучить решение задачи, не поняв «фишку» их решения. Вернее, можно, но это сложно, долго и непродуктивно. Вероятность встретить подобного «шулера» ненулевая, но ей можно смело можно пренебречь.
2. Я с 2010 года собеседую людей, с тех пор как получил свою первую команду. Этот критерий меня ни разу не подводил. Последний довод для меня в сто раз убедительнее всех ваших рассуждений, так что уж не обессудьте, но вы ошибаетесь :)
но если это и есть ваши 90% тасков, то зачем вы спрашиваете про бинарные деревья
Затем, что как раз те оставшиеся 10% тасков, которые требуют включения мозгов, определяют, насколько софт работает эффективно и надежно. Это не один таск в год. Речь не о тому, что программисту там нужно будет перебалансировать B-дерево или что-то отсортировать вручную. Но, например, у него не будет готовой библиотечной функции для быстрого расчета прогноза по складским остаткам, ему нужно будет составить эту страшную штуку под названием «алгоритм», которая учитывает различные стадии выполнения заказов продажи и закупки с определённой вероятностью.
Везде, где устраивался, в задачах были прописаны:
1. Получить допуски и прочитать доки
2. Реализовать и зарелизить фичу №1 ( с использованием половины тех.стека)
3. Реализовать и зарелизить фичу №2 ( используя оставшуюся половину технологического стека)
Итого: к концу испытательного срока я уже знаю весь процесс выпуска в прод, прошёл пару раз кодревью, у меня развёрнут и настроен git/svn/jira, я показал свои навыки по всему стеку технологий, с которым дальше буду (или не буду) работать, пообщался с командой — и здесь уже легко понять, нужны ли мы с этой командой друг другу или пора расставаться.
Можете подсказать контекст таких работ, любопытно стало?
Нельзя наизусть выучить решение задачи, не поняв «фишку» их решения. Вернее, можно, но это сложно, долго и непродуктивно. Вероятность встретить подобного «шулера» ненулевая, но ей можно смело можно пренебречь.
Осмелюсь спросить, вы с китайцами или индусами дело имели? Судя по такой оптимистичной оценки веротности — скорее, нет.
Это работает для миддлов, но совершенно не работает для senior-ов. Когда я там в последний раз инвертировал бинарное дерево вручную? Лет 20 назад? Не, ну соображу, конечно, если буду сидеть за ноутбуком и писать в IDE, но у доски с маркером — вот не знаю, может, и нет. И при этом то, что действительно требуется от senior-а, это не проверяет вообще.
Я на скайп-интервью прошу расшарить экран и, да, даю задачки, но простые (такие, которые любой нормальный программист уж точно решит в уме за 2-3 минуты и останется только код написать), разрешаю пользоваться привычной IDE, гуглить что угодно, кроме решения задачи, и смотрю на то, как человек работает в привычных ему условиях. Из того, как именно он работает в IDE, как мыслит, как пишет код, как называет переменные и функции, как по коду перемешается, если гуглит, то на английском ли, — сразу все ясно.
Ну и, конечно, это все не отменяет беседы, это такой относительно короткий этап. Самое интересное начинается потом, когда я даю очень примерную постановку задачи и прошу спроектировать.
Умение решать учебные задачи не означает умения решать реальные, но неумение решать учебные задачи настораживает. Как минимум оно означает, что человеку не приходилось никогда учить программировать других, да и самообразованием на досуге человек не особо-то занимается. Мы встречали "сеньоров", у которых "сеньор" означает выслугу лет, а не скиллы, вплоть до того, что единственное умение человека — это много лет копипастить со stackoverflow (не преувеличение) и выдавать чужую работу за свою.
Задачи на алгоритмы, кстати, в жизни встречаются чаще, чем принято думать. Их просто часто не замечают — из-за плохого знания алгоритмов же. Решают в лоб, каким-нибудь полным перебором, вообще не подозревая, что есть более простой способ. Такая вот разновидность эффекта Даннинга-Крюгера.
Задачи на алгоритмы, кстати, в жизни встречаются чаще, чем принято думать. Их просто часто не замечают — из-за плохого знания алгоритмов же. Решают в лоб, каким-нибудь полным перебором, вообще не подозревая, что есть более простой способ. Такая вот разновидность эффекта Даннинга-Крюгера.
Есть еще такие штуки, как понятность кода и границы применимости. Если вам надо обработать 10 элементов в худшем случае, то от того, что кто-нибудь очень «глупый» сделает эту обработку в лоб простым и легко читаемым способом за О(N!) — ничего важного для кода не изменится. Зато потом другие люди на этом месте не будут спотыкаться об код.
Нет ничего более печального, чем видеть лес красно-чёрных деревьев, который «ускоряет» работу кода, вызываемого один раз с 0.01ms до 0.005ms.
На этот случай есть готовые библиотеки реализаций алгоритмов. Вот так, чтобы под простую вещь не было приличной готовой реализации — это редкость. Обычно есть, но не находят, потому что не знают даже названий алгоритмов, а без названия фиг нагуглишь.
А еще часто бывает, что сам "алгоритм" — он в одну строчку и даже проще пишется, чем лобовое решение. Тут как раз показывали пример "найти недостающее число". Умный просто просуммирует числа и вычтет, а глупый начинает сортировать. Или, скажем, алгоритм суммирования Кэхэна, который экономит в первую очередь память по сравнению с алгоритмами, основанными на сортировке, а пишется тоже проще.
Самое печальное, что приходилось видеть — это когда говорили "ой, да у меня 10 элементов в худшем случае", а потом оказывалось, что 20 ("всего-то в два раза ошиблись"), а потом "ой-ой-ой, а что это оно зависло?" (ну правильно, 10! и 20! — как бы некоторая разница есть). А потом появляются посты про то, как плохо написан софт, что за время обновления винды можно было бы ее трижды с нуля переставить. Это ведь вот оно и есть.
Типичный пример выглядит так: вот надо человеку пробить строки по черному списку. Кто в курсе, тот понимает: "ага, тут подойдет Ахо-Корасик", расчехляет готовую библиотеку и решает задачу в две строки. Кто не в курсе, пишет for и получает там же 100 строк, да еще медленно работающих. Когда приходит жалоба ("тормозит"), начинает "оптимизировать" эти строки (ну профилировщик же на них указывает!) и "оптимизирует" до тех пор, пока не начнет глючить. В нашей практике был случай, подобный плохо написанный код год (!) пытались исправить, прежде чем согласились, что вывести и доказать алгоритм было бы быстрее (на митинге тогда говорили "да ну, мы сейчас за два дня пофиксим, а алгоритм две недели писать будем").
Решение не писать алгоритм должно происходить из знания алгоритмов. Алгоритм знаю, готовый поискал, подходящих не нашел, решил сделать субоптимально. Еще и с комментарием в коде: "Если вдруг начнет тормозить, то вот здесь переделай O(N!) на O(N), алгоритм называется так-то."
Кто не в курсе, пишет for и получает там же 100 строк, да еще медленно работающих.Кто не в курсе, гуглит %framework_name% multiple substring search.
Типичный пример выглядит так: вот надо человеку пробить строки по черному списку
ага, тут подойдет Ахо-Корасик
Типичное решение выглядит так:
Вариант 1
SELECT * from black_list WHERE value IN (...)Вариант 2
$hashTable = array_combine($blackList, $blackList);
$rowsFromBlackList = [];
foreach ($rows as $row) {
if (isset($hashTable[$row])) {
$rowsFromBlackList[] = $row;
}
}Работает не медленнее любой другой обработки данных, которая может встречаться в приложении.
Не проще ли создать временную таблицу с value_hash, заполнить её хэшами и сделать inner join по value_hash?
В самом ленивом случае — добавить триггер on after insert, который сам будет хэшировать value во временной таблице.
C индексом по value_hash этот вариант переживёт и 10, и 10! значений для проверки.
PS для варианта с небольшим черным списком, который не расширяется и не будет расширяться — подойдёт любое решение.
SELECT b.*
from black_list b
inner join value_hash_tmp t on b.value_hash=t.value_hash BTW, если каждый код, который вызывается один раз, ускорить с 0.01ms до 0.005ms, это даст двукратный рост производительности программы в целом. Для этого вовсе не надо переписывать сотни алгоритмов, так как алгоритмы обычно повторяются, и достаточно нескольких хорошо написанных дженериков. (И очень странно, если их приходится писать самому, обычно все уже написано до нас.)
BTW, если каждый код, который вызывается один раз, ускорить с 0.01ms до 0.005ms, это даст двукратный рост производительности программы в целом.
Который может быть нафиг никому не нужен, потому что дальше вам результаты работы ваших 0.005ms надо переслать на другой конец мира с latency минимум в 500ms в идеальнейших условиях.
Сам по себе «рост производительности программы» не имеет значения. Да хоть тысячекратный. Зато очень даже имеют значение усилия, которыми это будет достигнуто: если вы ради этого написали так, что ваш код плохо понимают коллеги, резко упал bus factor, и надо нанять второго спеца вашего уровня только для того, чтоб проект не встал, если вы уйдете — это всё имеет выразимую стоимость в деньгах. Тысячекратное ускорение, если имеющейся скорости было достаточно — не даёт ничего.
Дает упрощение архитектуры. Если удалось добиться тысячекратного ускорения, то решение можно не параллелить, кластер не нужен, многопоточность не нужна, никаких сетевых латентностей нет, так как система просто перестала быть распределенной. Можно сократить подразделение IT, можно выкинуть из кода все, что отвечало за параллельность и сократить программистов, которые эту параллельность поддерживали. Пара спецов, способных сделать 1000-кратное ускорение, точно окупится по сравнению со всем этим.
Оптимизация обычно выливается в усложнение, а не упрощение. Просто потому что по-определению программист изначально пишет максимально простым способом, который знает, и любое изменение ведет очевидно к усложнению.
Соглашусь с ответом Вам выше: Часто наивный полный перебор длиннее и непонятнее умного алгоритма. Сам с таким кодом встречался. Рекурсивный перебор был 100 строк сильно запутанного кода, когда как весьма простое динамическое программирование было всего 20 строк, из которых 5 — комментарий, полностью описывающий все происходящее, что даже человек ни разу в жизни не видевший ДП, мог бы нагуглить и все понять.
Часто наивный полный перебор длиннее и непонятнее умного алгоритма.
А часто — наоборот.
Выше «автор ответа мне» рассуждает про алгоритм Ахо-Корасика, который, например, если только не будет вызываться в одну строку из чужой либы, будет весьма так длиннее банального перебора через for.
Ахо-корасика писать не надо — он уже 100500 раз написан в библиотеках. Но знать, что есть какой-то алгоритм поиска среди набора строк, который работает сильно быстрее чем цикл for — надо.
Я же говорил про динамическое программирование вместо полного перебора. Обычно это замена сложной рекурсивной функции двумя-тремя вложенными циклами с несколькими простыми арифметическими операциями внутри.
А если вдруг почему-то не написан, то стоит написать и опубликовать. Суммарные трудозатраты на один книжный алгоритм будут меньше, чем на все места, где его можно применить в проекте. В пределах одной предметной области задачи обычно довольно похожи, поэтому алгоритм можно применить, скорее всего, не раз и не два.
Особо гадкий случай — это когда делают "по-простому" через if-else, а потом годами растет простыня этих if-else, по одной веточке добавляют. Со всякими парсерами сложных конфигов или сетевых протоколов так бывает. Сразу бы написали на каком-нибудь LL — сэкономило бы буквально месяцы потом.
Ахо-корасика писать не надо — он уже 100500 раз написан в библиотеках. Но знать, что есть какой-то алгоритм поиска среди набора строк, который работает сильно быстрее чем цикл for — надо.
Ну я вот не знал, я бы просто делал поиск в цикле по хэшсету. Работать за линию от входных данных вроде ок. Если бы вдруг этого не хватило, уверен в первой строчке гугла я бы нашел что мне нужно.
Когда я пилил бота для определения боянов в телеграм-канале до использования хэша цветового момента изображения я ведь как-то догадался, хотя до этого никогда с изображениями не работал. А вот на собесе бы не ответил.
О, да. Сколько я таких встречал. Приходит юноша бледный со взором горящим и начинает лепить самописные хеш-таблицы на десятиэлементный массив, втыкать likely в каждый if, одновременно накручивая по пять слоев абстракции "на будущее". А потом выясняется, что он захреначил древовидную шареную структуру без единого примитива синхронизации и на голубом глазу сообщает, что оно будет работать "само по себе". После объяснения, что не будет (началось с того, что полезли плавающие баги), втыкает биг факин лок на всю структуру, так как времени на нормальный редизайн уже нет.
У нас для этих товарищей уже даже название закрепилось — би-дровосеки (родоначальники запилили самописные би-деревья для какого-то коротенького списка).
Как минимум оно означает, что человеку не приходилось никогда учить программировать других, да и самообразованием на досуге человек не особо-то занимается.
Каким образом обучение программированию и самообразование связано с решением учебных задач?
Решают в лоб, каким-нибудь полным перебором, вообще не подозревая, что есть более простой способ.
Какой способ может быть проще, чем перебор в лоб?
Тут как раз показывали пример "найти недостающее число". Умный просто просуммирует числа и вычтет, а глупый начинает сортировать.
Задача программиста при написании кода состоит, в первую очередь, в том, чтобы объяснить другому программисту, что происходит в программе и зачем.
Так что вариант с сортировкой почти всегда более предпочтителен — сразу понятно что делается, в отличии от варианта с суммой, который понадобится откровенно декомпилировать, чтобы понять.
Я каждому кандидату, даже тем, кто мне не понравился, даю на дом решить одну задачу, трудоемкостью часа на 3, но без ограничения по времени.
Затем я полученное решение проверяю часа 4, выдаю кандидату список замечаний. Даже если задача сделана прям идеально (хотя такого не бывает), я чего-нибудь напишу по принципу "почему без шапки". Затем по телефону, или на 2-й встрече мы все эти замечания с ним вместе обсуждаем.
Хорошее предложение получает тот, кто в состоянии на профессиональном уровне обсудить свой собственный код, объяснить почему выбран тот или иной алгоритм, признать косяки, если такие нашлись, рассказать, как надо было сделать правильно.
Такой подход дает хорошие результаты, но чрезвычайно трудоемок.
Нет. Решение соискатель выкладывает из дома куда-нибудь на гитхаб. 4 часа требуется мне, чтобы все проверить и написать развернутые комментарии.
4 часа это все вместе. В задаче есть простор для фантазии, поэтому мне некоторое время приходится потратить на настройку своего теста. Иногда, когда в программе есть race condition, я свой тест дорабатываю, чтобы наглядно продемонстрировать ошибку, а не метать бисер. Написание замечаний — это последний час, как правило.
Процесс, как я говорил, трудоемкий. Но я параллельно решаю задачу, чтобы, если человек стоящий, он захотел со мной работать. Чтобы он не только за деньги у меня работал, а за возможность узнать что-то новое и повышать свой профессиональный уровень.
Иногда быстрее проходит. Когда код заурядный, я беру список замечаний к самым косячным решениям и выкидываю оттуда лишнее.
Да вы что. Обычно вообще никакого фидбека нет. Спасибо. Мы вам позвоним. Даже если возьмут на работу, фидбека, скорее всего не будет.
Даже если задача сделана прям идеально (хотя такого не бывает), я чего-нибудь напишу по принципу "почему без шапки".
Пожалуй, к вам бы я не пошел.
Почему? Не воспринимаете критику?
Только аргументированную. И когда "код написан идеально", а критика есть, значит это неаргументированная вкусовщина.
На мой взгляд, идеального кода не бывает. Но даже если кто-то думает, что он такой код написал, он должен уметь обосновать эту оценку и аргументированно отвергнуть придирки, а иначе от его перфекционизма будет мало толку.
Между "задать вопросы по коду" и "докопаться до запятых, потому что в остальном с кодом все ок" есть некоторая разница.
Э-э-э. Вы не поняли фишку. Это психологический прием. Чувак написал идеальный код. Ждет заслуженную похвалу. А вместо этого бац: "Почему импорты со звездочками?" Его переполняют эмоции. Он вместо того, чтобы спокойно выбирать между похожими оферами, сидит и думает, как же это возможно. И тут ему предлагают все замечания конструктивно обсудить, обсуждают, у него появляется возможность проявить свои софт-скиллы, он побеждает в деловом споре, и позиция в нашей команде для него начинает ассоциироваться с победой.
Я и говорю, дешевый психологический трюк, ориентированный непойми на кого.
Еще раз, вот допустим я вам скинул решение, если вы присылаете критику в стиле "а у вас тут запятые и пробелы неправильные" то мне не будет интересное предложение их конструктивно обсудить, потому что видно, что человек в неадеквате. И нет, я не буду мучиться бессоницей, чтобы понять, что не так у меня с запятыми. Слава богу, рынок достаточно велик, и вакансий на любой вкус хватает. А где не хватает, всегда можно по знакомым поспрашивать, где-то всегда вот уже вчера нужна голова для решения каких-то проблем.
Если у вас есть замечания к коду — отлично, обсудим. Докопаться до нормального кода чтобы развести человека на лишние разговоры — какие-то дешевые СЕОшные методики продвижения вакансий. Не знаю как остальные, а я и спамеров не люблю.
Вы сейчас целую историю рассказали, про то как и чего у потенциального кандидата в голове. Вот только к реальной голове реального кандидата она никакого отношения не имеет, беда-с.
он побеждает в деловом споре, и позиция в нашей команде для него начинает ассоциироваться с победой.Если человек действительно умнее вас, он сразу почувствует попытку манипулировать им, сделает фейспалм и уйдёт.
Почему Senior Developer'ы не могут устроиться на работу
Потому что они навесили на себя сеньерскую лычку и сеньерскую же зп после первого крупного проекта в качестве миддла, имея за плечами 1-2 года опыта и задрав нос? Пример из жизни, который, тем не менее, нашел себе работу
P.S. Статью не читал
А если у меня опыта программирования с 2004 (это только профессиональный — без учёта институтских проектов), два раза минимум на меня навешивали "сениорскую" лычку, но я вот за 3 строчки сходу, как тут в комментах кто-то писал, не заинверсирую бинарное дерево — я от этого перестаю быть сениором?
С другой стороны, меня можете хоть джуниором звать — главное чтобы деньги хорошие платили.
P.S. Мож и заинверсирую — лень пробовать :).
Не проверяли вообще ничего. Всему верили на слово.
Примерно так:
— Вы говорите на китайском?
— Да. Поговорим по-китайски?
— Нет, зачем? (Ставит плюсик)
А ещё я заметил, что хорошо прохожу собеседования в мелкие конторы, где собеседует сам гендир/собственник. И проваливаю собеседования, где присутствует Hr, начальник отдела и пара ведущих специалистов.
По словам проводящего тест, это был тест на логическое мышление…
Хотя это и неудивительно, учитывая моих бывших одногруппников…
Настоящие проблемы начинаются уже после выхода на новую работу. Когда с первого дня видишь, какие проблемы в менеджменте, как команда общается с тимлидом, как тимлид общается с «кем-то выше него», как поступают задачи, как сдаются задачи, и тд. В больишнстве случаев, за неделю можно примерно выявить, почему «ушел» прошлый сеньер.
Кстати очень помогает на собеседованиях совет, который вычитал на хабре когда еще был джуном: у техлида (или лица, который представляет «техлида» на собеседовании) спрашивать вопрос типа «как к вам поступают задачи, как вы их распределяете, и как вы их сдаете». Прошу заметить — спрашивать не у ПРа/ПМа, а именно у техлида. По ясности их ответа можно сразу очень неплохо прикинуть, как у них обстоят дела внутри.
В «хороших» компаниях (у которых всё нормально обстоит внутри) этот вопрос никогда не вызывает сложностей. И обычно техлид до мелочей может пересказать весь воркфлоу.
В «плохих» компаниях ответ выглядит как-то так: ну, у нас етсь ютрак, и в нем есть задачки, и разработчики их берут и решают.
Что если флоу правда состоит в том, что ПО создает задачки в ютреке, которые техлид потом декомпозирует?
Появляются задачи рода «не думай, просто сделай, так надо», которые делаются через одно место т.к. нет понимания глобальной задачи, а потом еще рефакторятся несколько раз из-за отсутствия понимания вектора дополнительных требований по данной задаче. Плюс такие задачи очень неприятно делать, появляется отстраненность от процесса. Будто ты фрилансер и тебе закинули задачку, а не часть команды разработки.
Не спорю, что так построить работу невозможно, но меня бы такой воркфлоу очень сильно насторожил. Я бы спросил несколько деталей прежде чем делать вывод, но поворот в не ту сторону уже был бы сделан.
Появляются задачи рода «не думай, просто сделай, так надо»
Как это связано с задачами в ютреке?
Плюс такие задачи очень неприятно делать, появляется отстраненность от процесса. Будто ты фрилансер и тебе закинули задачку, а не часть команды разработки.
Посмотреть на эпик, поговорить с лидом, поговорить с ПО не поможет?
Проекты работодателей показывать нельзя
А мне пофиг, просто покажу проект со своего ноута, когда придётся собеседоваться. Передавать на сторону ни одного байта не придётся, текущий работодатель не пострадает.
Ещё могу показать полный лог своей работы за несколько лет в виде задач на каждый день и всяких пометок к ним. Там нет чувствительной информации. Правда, понадобится русскоязычный сотрудник в нанимающей фирме.
Вот я пришел на новую работу, запилил уже два-три модуля, они уже обросли кодом от коллег, я сам уже без гита не скажу где там мой код, а где не мой. В любом более-менее большом проекте так.
ИМХО гораздо адекватнее на собеседовании попросить претендента рассказать о задачах, которые он решал, пообщаться с ним. В сущности таким простым разговором можно получить довольно адекватное впечатление о человеке как о профессионале и как о человеке вообще. Насколько адекватен в общении, что знает, что умеет. Да и такое интервью обычно проходит с самым низким уровнем стресса.
Как правило портфолио есть у фронтов, там сама суть кода в том что его не спрячешь или у вчерашних студентов — пока еще не работаешь где-то серьезно — есть время и желание пилить проекты по фану.
Раз уж тема снова всплыла, то оставлю свою историю о собеседовании, которое неприятно поразило меня больше всего.
Задал мне собеседующий простую олимпиадную задачку и стал равнодушно пялиться в свой ноут. Я начинаю рассказывать, как и что я делаю, обосновывать своё решение, а собеседующий — ноль внимания. Когда я решил задачу, он мельником на неё взглянул и бросил "Квадрат, не пойдёт!", а ведь я объяснял, почему я делаю за квадрат и как потом буду улучшать.
Решил задачку за линейное время, показываю ему, а он — "Ладно. Так… у вас ошибка" и снова смотрит к себе. Оказалось, я пропустил проверку на граничные условия, но упомянул о ней вслух.
Кое-как завершил собеседование, но так и не понял, что это было — недавний олимпиадник? Педант, для которого неверными будут все решения, кроме оптимального? А если бы у меня так же спрашивали задачу "на сообразительность", я бы просто ушёл.
Из российских компаний самое адекватное собеседование было у Jetbrains, но я довольно халтурно подошёл к решению домашней задачки, потому что уже почти был готов оффер от гугла — возможно, та команда решила, что я ленивый раздолбай. Да и мог бы нормально слиться и не тратить зря их время — тогда было очень стыдно.
Не оправдываю собеседующего но могу объяснить почему так происходит.
Потому что внезапно во время собеседования ему ещё нужно вести полный протокол с таймстампами вида начал решать в 12:00 задал первый вопрос тогда-то, тогда-то вручил первое решение во столько-то. И да замечаю что обычные комментарии вслух мало кто слушает, вот задаете вопрос а какие ограничения, тогда говорят… обычно это бывает либо на phone-секциях или секциях с кодом на листке, когда код на доске там уже точно будут смотреть.
Почему они так делают тоже объяснить просто, потому что после собеседования лениво заполнять отчет выдумывая таймстампы и прочие вопросы из головы и тратить на это время, а хочется просто работать. поэтому сидят и заполняют прямо на месте.
В этом и проблема — как можно оценить качества кандидата, если не слушать его рассуждения? И это было на личном собеседовании, причём, было ещё четверо собеседующих и все они слушали пояснения, иногда задавали уместные каверзные вопросы.
Понять причины такого поведения можно, но вот считать его нормальным — точно нет.
К тому же я слышал о собеседованиях, где кандидат вообще не умел программировать (не мог написать программу типа hello world)
Я Senior программист на C#.NET стеке и я… не напишу Hello World сходу.
Нет, если поставить задачу:
- Создать новый шаблон Console Application в Visual Studio 20XX
- Найти функцию Main вписать туда Console.WriteLine("Hello, World!"):
То с этим я вполне способен справиться.
Но если есть пустой файл документа (а некоторые умники вообще листок бумаги подсовывают), на котором надо написать всё без шаблона солюшена, автоподсказки и Intellisensa… то я скорее всего подвисну. Потому что точно помню, что класс program может быть без спецификатора доступа, а Main должна быть статичной… Но обязательно ли туда параметры вставлять или это опционально? Или какие там надо было namespace вписывать, чтобы всё заработало? System хватит или что-то ещё надо?
Я думаю — суть понятна.
Программисты уже давно переложили на IDE огромное количество рутины и теперь, когда подсовывают бумажку и предлагают напиши "Hello World!" от руки — это вводит в ступор. А они всё предлагают и предлагают бумажки.
P.S. Ну и я не отменяю иронии парадокса, что людей, которым на собеседовании подсовывают "напиши Hello World" — надо решать СОВСЕМ ДРУГИЕ задачи.
Как написание "Hello World!" коррелирует с задачей создания оптимальной архитектуры приложения или оптимизацией рабочих процессов — сие есть загадка неведома есьм.
Ну не знаю, имхо это базовые вещи. Напоминает статью про сениор сишарп разработчика, который не ответил зачем нужен кейворд virtual. Не, ну вопрос джунский, это очевидно, но люди почему-то забывают, что сениор по сути это надмножество джуна. Любую джуновую задачу сениор должен решать, причем сходу и максимально корректно. Да, он не должен этим заниматься, потому что во-первых недозагрузка интересными задачами сильно надоедает, а во-вторых потому что это тупо дорого. Но уметь он должен. Неужели от понимания как настроить шардирование и при каком виде нагрузки класс лучше спроектировать лок-фри или на простых локах человек может забыть то, что он ежедневно набирает?
Да, IDE помогает, но мозг она при этом не заменяет. Что мешает на бумажке написать:
svm
{
Console.WriteLine("Hello world!");
}А интервьюверу объяснить, что это сатнадртный класс объявления входной точки в Visual studio? Раз вы эксперт в IDE то должны это знать. Если же человек не может хелло ворлд ни на бумажке, ни в IDE написать, то это достаточно грустно, пусть и не имеет прямого отношения к реальным задачам.
В какой момент времени стало модным невежество? "Я не знаю как работает гц, это пусть джуны учат". "Какие там модификаторы доступа? Я же сениор, мне это знать не обязательно". "Что такое SOLID? Спросите чего поновее".
Ну то есть вопросы тупые и очевидные, но они тупые потому что любой человек считающий себя разработчиком обязанть знать эти ответы. Это все равно что спросить физика-ядерщика что будет с шариком, который толкнули в невесомости, в отсутствие других сил. Он хоть и давно в школе учился, но законы Ньютона вполне себе помнит.
Теперь когда берем сениора и спрашиваем его что-то из основ он высокомерно изгибает бровь и говорит что это дело плебса знать такие нюансы.
svm
{
Console.WriteLine("Hello world!");
}
А интервьюверу объяснить, что это сатнадртный класс объявления входной точки в Visual studio?
Что это за магия? Первый раз такое вижу. Гугл пишет, что это некая библиотека standard vector machine и Visual Studio требует устанавливать это отдельно посредством NuGet.
Вы уверены, в том что вы написали?
Это "static void Main" сокращенно, для тех, кто помнит что надо написать, но ему лень :-)
Аххх сниппет… Вообще не часто их использую.
Потому что в си принято было коды ошибок вовзращать, а в ентом вашем ООПэ — эксепшоны. Поэтому и код возврата в мейн функции перестал быть нужным. Соглашение по-умолчанию что если что-то пойдет не так система вернет HResult из эксепшона всех устраивает.
любой человек считающий себя разработчиком обязанть знать эти ответы
С тех пор как я узнал про SOLID, я всё меньше знаю что это. У меня нет однозначного ответа что такое, например, SRP. Вот полноценный объект, в котором есть и данные, и методы их обрабатывающие, и изменяющие — у него две ответственности или одна? Это без учёта самих данных и методов. Вот создаём объект с публичным свойством, инициализируем его в конструкторе. Понятно, что одна — хранить это свойство. Или две уже — дать клиентам возможность его изменять? Создаём геттер — добавляем ли ответственности за доставку клиентам значения свойства? А за защиту этого свойства?
Принцип SRP можно применить только в том случае, когда:
объекту класса становится позволительно слишком много;
доменная логика концентрируется только в одном классе;
любое изменение логики поведения объекта приводит к изменениям в других местах приложения, где это не подразумевалось изначально;
приходится тестировать, исправлять ошибки, компилировать различные места приложения, даже если за их работоспособность отвечает третья сторона;
невозможно легко отделить и применить класс в другой сфере приложения, так как это потянет ненужные зависимости.
Нужно различать ответственность и действия. Когда описываем объект, в графе: «Объект отвечает за» — должно быть одно значение, а не перечисление. В графе: «Для обеспечения ответственности объект делает»: тут может быть сколько угодно пунктов, главное что-бы все эти действия были подчинены одной единственной ответственности.
Разумеется, тут как и в большинстве принципов все до предела формализовать не получится, любую ответственность при желании можно разбить на части, тут все отдается на откуп здравого смысла исполнителя, потому что доведением до абсурда любой толковой идеи, можно превратить код в нечитаемый лабиринт из паттернов, ломающийся от любого небольшого изменения.
SRP это принцип, а не определение, который по сути говорит "декомпозируйте чаще и больше".
Но обязательно ли туда параметры вставлять или это опционально?
Математика 9 класс.
Я думаю — суть понятна.
Не совсем. Задача настолько сложная, что сеньору нужна IDE для решения этой задачи?
Это конечно сарказм, но с другой стороны интервьюеру стоит принять во внимание, что у сеньора возникают трудности в решении такой простой задачи. Это может быть как вопрос квалификации, так и вопрос психологии.
предлагают напиши «Hello World!» от руки — это вводит в ступор. А они всё предлагают и предлагают бумажки.
Одни раз за разом предлагают, а других каждый раз это вводит в ступор… Не пора бы привыкнуть? Или у вас есть решение, которое запретит предлагать hello world на бумажке?
P.S. Ну и я не отменяю иронии парадокса, что людей, которым на собеседовании подсовывают «напиши Hello World» — надо решать СОВСЕМ ДРУГИЕ задачи.
Как написание «Hello World!» коррелирует с задачей создания оптимальной архитектуры приложения или оптимизацией рабочих процессов — сие есть загадка неведома есьм.
Видишь суслика? Вот и я не вижу, а он есть!
Задача настолько сложная, что сеньору нужна IDE для решения этой задачи?
А забить гвоздь — задача настолько сложная, что для этого нужен молоток?
В кусок сливочного масла?
Нет, в графеновую пластинку не разрушив её, но чтобы держалось хорошо. На века.
Плотник 7 разряда сможет забить гвоздь без нейлера или без молотка?
Да нет — это просто реакция на слишком "умного" индивидуума, который после озвучивания задачи меняет её условия на облегчённые — выставляя опрашиваемого в невыгодном свете. После чего продолжает считать себе ещё и слишком хитрым, но когда ему, в саркастической форме, указывают на некорректность постановки задачи — сливается в демагогию.
В кусок сливочного масла?
Зачем вы забиваете гвозди в сливочное масло?
Я не забиваю.
Тогда зачем предлагаете делать это соискателю?
Вы имеете ввиду, зачем предлагать писать код на листочке, когда есть IDE?
Хотя я всего лишь имел ввиду то, что загнать гвоздь в мягкое масло, можно и без молотка, и это не должно вызывать существенных затруднений.
Код можно еще писать не просто на листочке, но еще подпрыгивая, или ногами вместо рук, или вниз головой, или одновременно насвистывая заданную мелодию. Почему из всего многообразия цирковых номеров выбрано только "на листочке"? Я не уверен, что одно такое представление сможет развлечь публику само по себе. Может, еще предложить поперемножать в уме большие числа? Зрителям такое нравится.
Вы имеете ввиду, зачем предлагать писать код на листочке, когда есть IDE?
Ага. Зачем? На практике у программиста будет и ИДЕ и гугл и все остальное.
Может, еще предложить поперемножать в уме большие числа?
Ну, математики это делают перед зрителем: умножают, делят, извлекают корни.
Ага. Зачем? На практике у программиста будет и ИДЕ и гугл и все остальное.
А еще вы будете работать на работе. Будут встречаться ТБ, дедлайны, сверхурочные, субординация и еще много очень страшных слов, не относящихся к непосредственному решению задач. Я понимаю, что все предпочитают наиболее благоприятные рабочие условия, но и работодателю хочется, чтобы вы писали код быстро и без багов.
Давайте будем обходиться без стресс тестов. На собеседовании вам преподносят рабочие условия так, как будто это фирма вашей мечты. Непосредственно, на работе вы осознаете, что попали в ад. Сразу уволиться вы не можете, придется терпеть и отработать какое-то время.
Тру стори, с другой позиции… Нанимается админ на ненормированный рабочий день, случается чп, требующее безотлагательного вмешательства, и админ начинает — не хочу, не буду, не обязан. Это нормально?
Тоже не понимаю этой страсти, сейчас такая проблема предоставить человеку на собеседование ноут с предустановленными несколькими популярными IDE?
Ну, математики это делают перед зрителем: умножают, делят, извлекают корни.
Ну так вам человек нужен для выступления перед зрителями?
А еще вы будете работать на работе. Будут встречаться ТБ, дедлайны, сверхурочные, субординация и еще много очень страшных слов, не относящихся к непосредственному решению задач. Я понимаю, что все предпочитают наиболее благоприятные рабочие условия, но и работодателю хочется, чтобы вы писали код быстро и без багов.
Не понял, к чему это все.
Еще раз — зачем соискателю задавать цирковые задачки, если он устраивается программистом к вам, а не циркачом? Он же не собирается у вас перед зрителями писать код во время езды на одноколесном велосипеде. Так зачем вы от него требуете этих непонятных скилов?
Ну да
Тру стори, с другой позиции… Нанимается админ на ненормированный рабочий день, случается чп, требующее безотлагательного вмешательства, и админ начинает — не хочу, не буду, не обязан. Это нормально?
Ну в договоре все это прописано? За переработки с двойным рейтом заплатят? Если да — не нормально. Если нет — нормально, конечно, т.к. в этом случае вам никто ничем не обязан.
Ну в договоре все это прописано? За переработки с двойным рейтом заплатят?
Конечно прописано. Переработки компенсируются 3 днями оплачиваемого отпуска.
Не понял, к чему это все.
Еще раз — зачем соискателю задавать цирковые задачки, если он устраивается программистом к вам, а не циркачом? Он же не собирается у вас перед зрителями писать код во время езды на одноколесном велосипеде. Так зачем вы от него требуете этих непонятных скилов?
К тому, что для интервьюера — это не цирк, а стресс-тест, который поможет отсеять не подходящую кандидатуру.
К тому, что для интервьюера — это не цирк, а стресс-тест, который поможет отсеять не подходящую кандидатуру.
Не подходящего в чем? Вы программиста ищите или работника мчс? Или, может быть, бойца спецназа? Почему тогда не проверяете навыки рукопашного боя и стрельбы? Не думали о том, чтобы забрасывать соискателя куда-нибудь в тайгу на недельку?
А то бумажка-то стресс не проверит никак, в чем стрессовость написания кода на бумажке?
Не подходящего в чем?
В деловых качествах.
Какие именно "деловые качества" проверяются стрессом?
И самое главное — зачем вы человека планируете тестировать именно так? Вы думаете он стал сениором БЕЗ испытывания достаточного количества стресса? Без срывов дедлайнов, объяснений с манагерами и т.д.?
Вы думаете он стал сениором
Сеньором?
- Hello World без IDE написать не может
- Алгоритмов не знает
- Математики не знает
- Пет проектов — нет
- Вклада в opensource — нет
- Синтаксис языка знает плохо
- Кейворды не помнит
- ...
Зато хочет прийти на собеседование, поболтать за жили были и подписать оффер на работу с 300к. Чтобы потом на работе 1/4 времени проводить, играя в пинг понг и попивая смузи. Оставшееся время он будет зависать в гугле и на стековерфлоу.
А вы сеньору идиотские вопросы задаете…
Hello World без IDE написать не может
Может, но не понимает зачем? И это займёт у него сильно больше времени плюс заставит сомневаться в адекватности опрашивающего.
Алгоритмов не знает
Одних — не знает, зато знает другие. Те, которые не знает опрашивающий. Может он преобразование Фурье наизусть запрограммирует (достаточно часто встречающаяся задача в процессах передачи/кодирования/шифрования звука).
Математики не знает
Это откуда такая инфа?
Пет проектов — нет
Может и есть, но с какой стати он обязан его показывать? Опрашивающий ведь тоже не рвётся дать доступ к реальному коду продукта и предложить "починить баг" — что было бы хорошей проверкой ВМЕСТО "хелло ворлд" на листочке.
Вклада в opensource — нет
А он обязателен?
Синтаксис языка знает плохо
Что значит плохо? Реальные задачи на предыдущих работах выполнял? Выполнял.
Кейворды не помнит
Указанный вами svm — не кейворд, а сниппет. Кто-то ими может вообще не пользоваться. А специфические и редко используемые — подсвечиваются в IDE — зачем их помнить?
P.S. Но вы так и не указали — какие именно "деловые качества" проверяются стрессом? И подразумевается ли то, что человек не сталкивался со стрессом в процессе роста до сениора?
P.S. Но вы так и не указали — какие именно «деловые качества» проверяются стрессом?
Не стрессом, а стресс-тестом. Способность выполнять свои служебные обязанности. Вас должны будут ознакомить с вашими обязанностями при подписании документов для устройства на работу.
Возникли проблемы с лицензией на IDE, вот тебе notepad++ — продолжай выполнять работу!
Чтобы потом на работе 1/4 времени проводить, играя в пинг понг и попивая смузи. Оставшееся время он будет зависать в гугле и на стековерфлоу.Если он при этом свои рабочие обязанности выполняет — то он реально классный )
Способность выполнять свои служебные обязанности.
В служебные обязанности входит написание кода на листочке? Это действительно прописано в вашем договоре? Если нет — то тогда способность выполнения каких именно служебных обязанностей проверяется просьбой писать код на листочке?
Hello World без IDE написать не может
Алгоритмов не знает
Математики не знает
Пет проектов — нет
Вклада в opensource — нет
Синтаксис языка знает плохо
Кейворды не помнит
Что характерно — ни один из перечисленных вами пунктов не является обязательным для отличного программиста.
Ну и да, если у вас работа программистом предполагает стресс — то следует начать с чистки менеджеров, а не с того, чтобы искать стрессоустойчивых соискателей.
Как говорится — меняем шлюх, а не двигаем кровати.
А я так не посчитаю, потому что не обладаю достаточной информацией, чтобы делать выводы.
Но другой информации у вас не будет, а вывод делать надо, и надо, исходя из того, что есть.
С точки зрекния соискателя это вопрос статистического характера. Есть аргумент за неадекватность, за адекватность аргумнетов нет — значит, статистически,
работодатель скорее неадекватный, чем наоборот. Значит, статистически, правильнее считать его неадекватным. Не факт, что он неадекватен. Но исходить из его недаекватности логически правильнее.
Я бы расстроился, сделал перерыв на кофе, затем продолжил бы писать в notepad++. Когда
Написание кода занимает очень малую долю в работе, с-но, вместо написания кода (раз уж писать его нельзя) всегда можно заняться анализом задачи, архитектурой и т.п. вещами, чтобы не тратить время неэффективно.
Ведь с иде писать код в любом случае будет эффективнее. Т.о., когда вы пишете код в блокноте (при отсутствии возможности писать его в иде) — вы обкрадываете своего работодателя. Точно так же, как если вы вместо работы смотрите котиков.
Написание кода занимает очень малую долю в работе, с-но, вместо написания кода (раз уж писать его нельзя) всегда можно заняться анализом задачи, архитектурой и т.п. вещами, чтобы не тратить время неэффективно.
Ведь с иде писать код в любом случае будет эффективнее. Т.о., когда вы пишете код в блокноте (при отсутствии возможности писать его в иде) — вы обкрадываете своего работодателя. Точно так же, как если вы вместо работы смотрите котиков.
Вам еще раз повторят, что вы должны сделать… Начнете писать?
Стрессоустойчивость. В некоторых процессах разработки она программисту нужна. Например, правка критикал багов, когда 10 человек вокруг тебя стоят и каждую минуту спрашивают "скоро? точно пофиксишь?"
И если я буду знать что в какой-то фирме так обстоят дела, то вряд ли я пойду туда работать :)
Ну вот есть у бизнеса проблема, они решили решать её путём подбора срессоусточивых сотрудников. Их право.
Другое дело, если решения такого не было, просто собеседующий не видит в этом ничего из ряда вон выходящего.
На мой взгляд в такой ситуации нужна не стрессоустойчивость отдельных программистов, а нормальная организация процессов в фирме.
И если я буду знать что в какой-то фирме так обстоят дела, то вряд ли я пойду туда работать :)
Вы знаете такие фирмы, где ничего и никогда не случается?
Но я очень удивлюсь если окажется что в РФ нет фирм где дела обстоят примерно так же :)
Если мы отвечает "да" на ваше риторическое заявление, то зачем дополнительный стресс-тест? Ведь мы уже знаем, что:
- Человек работал
- Человек работал в фирме, где случались стрессовые ситуации
- Человек доработал до статуса как минимум Мидла (ну если он переходит в новую компанию с повышением)
А значит доказано, что стресс-тест — бессмысленен. И является очередным шоу для самоутверждения опрашивающего.
А значит доказано, что стресс-тест — бессмысленен
А меня инопланетяне похищали. Значит доказано, что инопланетная жизнь существует.
Даже если этот человек истину глаголет, ни капли не лукавя, то ни коим образом не является доказанным ни первое, ни второе ваше утверждение.
Ну или пока был джуном стрессы его особо не касались, вырос до мидла — стали касаться, долго не выдержал и теперь ищет работу без стрессов.
А почему вы считаете, что джунов не касаются стрессы? Касаются. Мало того — их больше. Потому что когда приходит манагер и начинает чего то требовать — обычно только у мидлов и сениоров хватает опыта и стрессоустойчивости их посылать лесом. У джунов — наглости на такое ещё недостаточно.
Я не считаю, что ни одного из них стрессы не касаются никогда. Просто есть случаи, когда все их стрессы внутренние типа "не успеваю сделать задачу в срок, который сам же назвал", отвественную задачу от которой зависит судьба компании/проекта им просто никто не даст, "манагер" от них ничего требовать не будет серьёзно.
Ну, например, за стрессы доплачивают хорошо
Ну считайте тогда, что за отсутствие стресса из зП вычитают :)
От процесса и балагана зависит. Если процесс поставлен как конвейр с легко заменяемыми элементами, то платить там будут меньше. А если в балагане не ИТ-компании замкнёшь на себе ключевые ИТ-процессы и знания, то можно очень много получать, "двери~~ в бары-рестораны ~~ начальников департаментов открывать ногой". А уж если получить право решающего голоса на тендеро-подобных конкурсах по ИТ-услугам/товарам...
Но зачем работать в таком месте?Кого не устраивает текущее место работы, тот увольняется. Кого устраивает, тот продолжает работать. Hello world на листочке, тоже никто не обязан писать, можешь написать и продолжится собеседование, или можешь не писать, сделать выводы и уйти.
Я понимаю, что все предпочитают наиболее благоприятные рабочие условия, но и работодателю хочется, чтобы вы писали код быстро и без багов.Работодателю выгоднее привлекать экспертов комфортными условиями труда, чем пытаться компенсировать внутренний бардак заоблачными зарплатами.
И мы вроде как обсуждаем именно программистов, а не админов.
И мы вроде как обсуждаем именно программистов, а не админов.
Разница небольшая, случись что-то выходящее за рамки привычного и начинается та же песня — не хочу, не могу, не буду.
Держать всех на вахте — это очень нерациональное использование ресурсов, это как на сервер ставить real-time ядро.
Вы привели пример с notepad++, но подправить несколько строчек в коде — это не тоже самое, что вспомнить названия нужных include/import/using (без интернета, но со стоящим над душой интервьюером).
Вы привели пример с notepad++, но подправить несколько строчек в коде — это не тоже самое, что вспомнить названия нужных include/import/using (без интернета, но со стоящим над душой интервьюером).
А как вы себя поведете, если случится такая ситуация на работе, а не на собеседовании?
Я бы расстроился, сделал перерыв на кофе, затем продолжил бы писать в notepad++. Когда проблема будет устранена, написанный в notepad++ код скормлю IDE, в которой легко добавлю импорты и всё исправлю.
На собеседовании, если вас попросят написать код в блокноте, вы можете просто написать код так, как умеете или как сможете на данный момент. Возможно, после прочтения вашего кода, вам зададут вопросы. Возможно не зададут, а посчитают, что вы плохо знаете синтаксис.
Или можете сделать вывод, что это место работы вам не подходит.
В чем проблема? Я вам скажу свое мнение… Процесс собеседования нигде не идеальный, совсем не редкость, когда встречается интервьюер с завышенным самомнением и откровенно хамит.
А с другой стороны, тоже не редкость, когда на собеседования приходят сеньоры с таким же самомнением, но хелло ворлд написать не могут.
Или вы думаете проблема в том листке бумаги, на котором вам предлагают написать 5 строчек кода?
Там где не используют стресс-тесты, а сеньорам не предлагают писать хелло ворлд, происходит всё то же самое. Интервьюер всегда найдет на чем подловить, а сеньор найдет повод посчитать всех идиотами.
Если что-то действительно срочное и критичное, я, конечно, брошу все силы на затыкание пробоины. А потом отведу менеджера в сторону и обсужу с ним, как не допустить повторения чего-то подобного в будущем.
После второго раза я обсужу с ним косяки в организации разработки и взаимодействия между командами.
После третьего раза я предложу обсудить наше дальнейшее сотрудничество.
Допустим мы получили 7 резюме.
Из них 5 — от Senior JavaScript developer с опытом менее 2 лет. На позицию Java architect.
Скажите, у вас течёт слюна на пол если вы сидите неподвижно более 3 секунд?
Но с другой стороны, Senior Developer который не может инвертировать бинарное дерево (рекурсивное решение занимает 3 строчки кода) или написать за час BFS по графу, должен провести очень серьёзную «инвентаризацию» своих скиллов и сделать выводы.
(Правда, у меня ни на одном собеседовании такого и не спрашивали, бывали вопросы вообще про деревья, что такое и зачем, но знание алгоритмов с ними связанных никто не требовал)
Но я остаюсь при своём мнении, не навязывая его: если простая алгоритмическая задача ставит в тупик, то титул синьора как бы обязывает поправить ситуацию, не обязательно в контексте подготовки к собеседованиям.
Но я остаюсь при своём мнении, не навязывая его: если простая алгоритмическая задача ставит в тупик, то титул синьора как бы обязывает поправить ситуацию, не обязательно в контексте подготовки к собеседованиям.
Думаю большинство разработчиков от мидла и выше она ставит в тупик не по причине того что они не могут этот алгоритм закодировать, а по причине того что сам алгоритм уже основательно забыт.
Человеческая память так устроена, что все неиспользуемое ежедневно уплывает далеко на периферию и вспомнить старые знания чем дальше тем сложнее. Видимо эволюция неспроста так распорядилась, ресурсы ограничены и лучше потратить их на что-то более актуальное.
Если на интервью так уж хочется проверить умение работы с деревьями — я думаю стоит просто дать человеку ноутбук с нормальным (и желательно привычным ему) IDE, описание задачи, включающее в себя описание алгоритма, и посмотреть на результат. Если человек не программист, то он и со всем этим ничего сделать не сумеет, и по результату будет хорошо видно какой уровень у разработчика.
Особенно если задачка не на три строки.
Оформление кода, декомпозиция задачи, использование (переиспользование) переменных, умение внятно объяснить примененные решения.
А тестировать память… это такое. Ну окажется что человек имеет феноменальную память и помнит алгоритм, который он 20 лет назад в ВУЗе учил, и что дальше то? Он только от этого становится полезным членом команды? Не думаю.
Но, опять таки, от собеседующего требуется, при необходимости, пояснить необходимый минимум терминов:
1. Что мы подразумеваем под деревом? Другими словами, в какой форме мы его представляем?
2. Что мы подразумеваем под бинарным деревом?
3. Что мы подразумеваем под инвертированием бинарного дерева?
С поиском в ширину на графе чуть сложнее, но формулировку можно заменить на «Проверить наличие элемента в связном неориентированном графе». В такой формулировке задача вполне себе решаема без особых заученных алгоритмов.
И вот что скажу — требования к скиллу стали очень серьезные, всем нужны сеньоры, чтобы все видел и все знал. Середнячков особо не нужно, новичков и даром не возьмут.
С одной стороны это хорошо — есть мотивация всем нам расти. С другой, вполсилы работать в нашей индустрии не получится, надо быть лучшим или идти бумажки перебирать или говорильню говорить.
И вот что скажу — требования к скиллу стали очень серьезные, всем нужны сеньоры, чтобы все видел и все знал. Середнячков особо не нужно, новичков и даром не возьмут.
Ничего подобного.
Впрочем, если вы смотрите вакансии на ваш опыт работы и на соответствующие деньги, то неудивительно, что там «требования к скиллу». Или вы думали, что джунам тоже будут по 100 с лишним тыщ платить просто потому, что это вайти?
Скорее это значит, что:
- человек так и не увидел, как связать эти знания с реальностью, и заклеймил их как "ненужые", возможно, работая много лет на однообразной рутине,
- человек никогда не работал со студентами и стажерами, не обучал их и не собеседовал, и вообще никогда никого не учил программировать. Т.е., по-видимому, к человеку не обращались младшие за помощью.
Да, вы правы, лучше чем студенты на эти вопросы могут ответить их учителя. Они преподают это каждый семестр, конечно от зубов отлетает. Поэтому если это интервью на роль преподавателя, то все так.
Вот-вот. Меня в универе ещё бесил подход у некоторых заносчивых преподов (не все такими были, но немало). У них отношение такое, что типа «ну чего ты, дурак, этого не помнишь, я-то весь материал помню, всю теорию, вот какой я молодец!». Да, ты помнишь, вот только у тебя, дебила, ничего в жизни нет кроме своего предмета, который ты каждый день повторяешь по 100500 раз. А у нормального даже добросовестного студента без феноменальной памяти таких вот преподов и предметов с десяток одновременно, и попробуй-ка упомнить все формулы и доказательства. И какой-нибудь такой супер-препод гордый по теормеху скорее всего мог бы только лососнуть тунца, если я б ему задал вопрос по теорфизу, например.
Такая же фигня со всякими хитрыми алгоритмами и решениями задачек. Сейчас я нифига не вспомню их без гугла, а на момент окончания универа много такого знал и мог заодно решить всякие задачки по математике. И если бы сегодня собеседовали меня текущего и меня прошлого методом задачек без гуглежа, то моя прошлая версия прошла бы собес без проблем, вот только сходу хорошо работать эта версия не смогла бы по очевидным причинам и косяков была бы уйма при попытке делать реальные задачи.
Сеньор отличается умением решать сложные задачи(а не строгать простые) и его мозг заточен под сложные задачи. Когда на собеседовании дают что-то элементарное, то у такого разработчика случается диссонанс в мозгу и перестроиться без дополнительной практики сложно.
Под демонстрацию как нельзя лучше подходит анекдот про решение инженером проблемы нахождения объема синего резинового мячика — тот просто достал с полки справочник и открыл его на странице с таблицей "Объемы синих резиновых мячиков".
Не могу представить себе инженера который быстро и легко решит, скажем, задачу распределённого консенсуса («изобретёт» PAXOS-like протокол, например), но который при этом не сможет инвертировать бинарное дерево :)
Больше пользы с того, когда разработчик расскажет о тех проектах которые делал, опыте, который извлек из этого, сложностях, с которыми столкнулся и то, как он их решил. Но это оценит только такой же коллега, как и он сам.
А эта вся чепуха с задачками, как мне кажется, идет из попыток автоматизировать и формализовать этот процесс, особенно когда подбором персонала занимаются люди других специальностей, либо бывшие программисты, уже давно забывшие что это такое на самом деле.
Еще хотел отметить такой психологический момент. В некоторых компаниях он применяется. Когда уже прошло собеседование, и произведена оценка кандидата, получено первоначальное одобрение… и перед разговором о конкретных условиях и заработной плате, компания может «накидывать»… т.е. спрашивать какие-нибудь особенно каверзные либо очень сложные вопросы, чтобы снизить уверенность кандидата в собственных силах и знаниях с целью «ослабить позиции» перед переговорами о оплате труда.
Есть нюансы.
Во-первых если речь идет о джунах — у них просто нет еще проектов о которых можно рассказывать. У миддлов часто тоже нет, или они не могут нормально рассказать — зачастую они сидят и пилят какую-то тривиальную функциональность.
Во-вторых человек может просто врать — да, так тоже бывает. Совсем уж наглую ложь конечно легко развалить парой вопросов, но бывают и подготовленные люди. Тут на хабре где-то даже статья была с примерами, как обманывают рекрутеров.
В-третьих человек мог формально участвовать в проекте (и он может о нем рассказать), но по сути программировать он все равно не умеет. В крупных конторах вполне можно попасть на теплое местечко, ничего не делать, общаться в курилке с коллегами, имитировать бурную деятельность, но не писать код (или писать очень-очень медленно). Внутренняя бюрократия всяких там ЕПАМов таким людям позволяет держаться годами, увольнять там не любят, а будут перекидывать из проекта в проект.
Так что какая-нибудь простая задачка на код — единственный на мой взгляд способ проверить, что человек умеет этот код писать. При этом я тоже считаю что всякие "напишите красно-черное дерево на бумажке" это ерунда и не нужно. Достаточно какого-нибудь простейшего FizzBuzz или аналога, ну и естественно на компьютере и с IDE.
1. Созвониться, договориться о встрече. Этап — Телефонное интервью.
2. Встретиться с кандидатом, поговорить. Показать офис, условия труда. Этап — Предварительная оценка.
3. Тестовое задание. Из двух частей — опросник по навыкам (хард и софт скилы детально — 3-5 стр.), задание на разработку прототипа приложения (приход, расход товара, отчеты). Иногда можно дать дополнительное задание, специфичное для проекта (например на знание SQL, какой-либо библиотеки и т.д.). Предварительное время выполнения кандидат назначает сам. Этап — заключительная оценка.
4. Переговоры об условиях работы и оплаты труда. Этап — заключительное собеседование.
На мой взгляд это более-менее оптимизированный процесс приема не работу, не изматывающий марафон, но и не с кондачка.
Еще один нюанс. Если человек действительно сеньор с опытом, то он почти наверняка кого-то учил. Тогда он не может не знать учебные задачи. Очень слабо себе представляю ситуацию, как можно много лет работать и не столкнуться при этом с необходимостью объяснить кому-то устройство красно-черных деревьев. Ни разу никто не просил о помощи? Ни разу не курировал студентов? Ни разу не объяснял джуну, что внутри у std::map? За все эти годы?
как можно много лет работать и не столкнуться при этом с необходимостью объяснить кому-то устройство красно-черных деревьев
А нафига их знать, если в повседневной работе дело имеешь с Sharepoint, например? Или еще какой ERP системой?
Отъемлемый в работе. Команда может быть из одних сеньоров, например. Или из одного.
Идеальным вариантом для работодателя было бы организовать 10 рабочих мест и сразу взять 10 человек на испытательный срок, потом через неделю-две оставить одного-двух сеньоров, а остальных отправить искать работу дальше.
Но и с таким подходом тоже многие не согласятся и не захотят терять две недели своего времени. Так что же лучше для сеньора, потерять час на тестовом задании или две недели на испытательном сроке?
Самозванцу такую беседу не пройти наверняка, обман вскроется через мять минут общения.
Что же это за вакансии такие, куда 500 человек на место?
Мне кажется наоборот, в-основном есть куча проектов куда годами людей походящих найти не могут.
И каждый раз как в первый раз — в комментариях страсти аж жуть, люди стоят на смерть. Не наскучило?
>не рассчитывайте, что годы опыта купят вам беззаботное трудоустройство
Самым замечательным здесь я считают то, что это написано не абы кем, а таки программистом.
Но по существу, конечно, ситуация ровно такая же, как с проблемой «нечего надеть» и «перевелись настоящие мужчины».
Здесь может быть вопрос, что нужно компаниям (хардкодеры или междисциплинарнгсть) и что хотят люди (расширение своего профессионализма или глубокого кода ради кода/денег).
Если компаниям нужна monkeyjob- делай, что сказали, то у них есть бюджеты на то, чтобы ждать и искать лучшего по алгоритма наизусть, чтобы не лез в продукт. Если компания более подвижная, она возьмёт специалиста, кто сейчас метит в Джуны, и имеет большой опыт в индустрии.
Всё остальное программирование — так или иначе предназначено для решения прикладных задач.
Построить базу данных — это очень узкая специфическая область. Правильно пользоваться базой данных — другая, но менее специфическая. Современный фронт-энд это вообще отдельная песня, с кучей нюансов.
Но во всех этих задачах применимы паттерны, лучшие практики, идиоматические подходы языка/платформы и т.д. Фундаментальные вещи не меняются уже десятки лет, и если человек из знает и умеет применять, велика вероятность что он сможет (условно) быстро и качественно осваивать новые технологии и производить качественные решения. Именно такую «базу», я считаю, есть смысл проверять на собеседованиях/ассесментах, я не специфические знания фреймворка/библиотеки.
> кто сейчас метит в Джуны, и имеет большой опыт в индустрии
это как вообще?
И да, гуглам нужны не сеньоры, а такие люди, которые будут выполнять требования тим-лидов. Не рассуждать о программах, а долго и продуктивно кодировать. То есть это конвейер, куда нужны конвейерные работяги. Так с чего вдруг у конвейерного работяги будут спрашивать про его мнение?
Ласково и осторожно общаются лишь с очень важными кандидатами. Сеньор — не важный кандидат. И при этом умение решать задачки хоть как-то позволяет отсортировать явных неумёх. Поэтому поступающую на вход очередь желающих чисто промышленными методами прогоняют через чисто промышленный фильтр, который, как и принято в промышленности, имеет погрешности, которые, в свою очередь, вполне устраивают хозяина конвейера. Поэтому плакать и возражать — неконструктивно. Хотите получать 200к? Тогда решайте задачки. Не хотите решать? Ну тогда не будет вам 200к. Всё просто. И желающих — вагон. Се ля ви.
И да, фильтр реально работает. А на погрешность при огромной очереди на вход — просто плевать. Это как с вопросом про кота — почему он лижет яйца? Потому что может. И всё. Возражения он не принимает. Ну а ваша яркая индивидуальность и великолепный опыт… Ну в общем на конвейере это не интересно.
ЗЫ. А для джунов всё ещё неприятнее, но они не плачут, а тихо зубрят и устраиваются в богатые конторы, что бы через несколько лет получать 200к. А те, кто плачут, идут работать дворниками. Опять се ля ви.
Хотите по другому? Меняйте мир. Не получается? Но почему вы в этом гуглов обвиняете? Это вы не смогли подстроить мир под себя, а не они. Они, как раз, смогли.
А уже из этого «много кто хочет» рождается и конвеерный подход — действительно, если в желающих недостатка нет, то можно их фильтровать как угодно.
По мне так захайпованность — это признак неадекватности программиста. Он либо очень молод, либо не способен учиться. Как можно покупаться на виртуальную игрушку? Просто на абсолютно эфемерное ощущение величия (или чего они там от хайпа ощущают)? И при этом оставаться трезво мыслящим разработчиком. То есть трезвый подход не совместим с пьяным (одурманенным хайпом) состоянием.
Проблема как раз в том, что ТЕ, кто НЕ Гугл — переняли от Гугла ТОЛЬКО задачки. Не хайп, не процессы и уж конечно не зарплаты в 120-200к. А только метод отбора.
Ради 120-200к — я бы уж как нибудь смирил бы своё эго, но увы из всей конфетки — предлагают ТОЛЬКО фантик.
Стадо.
Вот что такой подход нормально сделать не позволяет, так это нанять людей с узким профилем. Узких профилей бывает много, чтобы стать профессионалом в некоторых нужно потратить годы. Тот же Google прямо говорит, что такие люди в большинстве случаев им не нужны, им нужны универсалы, способные потенциально работать в любой части корпорации, которых можно перераспределить в случае закрытия проекта и любой другой смене направления деятельности. Так как такие корпорации имеют тенденцию скупать технологически сложные перспективные стартапы, то есть определенный риск того, что покрыть узкие профили в этих проектах с таким подходом к найму им будет не просто. Поэтому разработчики, которые попали в корпорацию вместе с проектом и получают там космические ЗП, а если покидают компанию, то проект оказывается на грани забвения. Это создает редкие случаи, когда корпорация отступает от правил, и собеседует людей в индивидуальном порядке, еще часто и по рекомендации. Все остальные, если действительно хотят в Google, и чувствуют, что там им будет комфортно, к сожалению, должны научиться проходить фильтр.
Задачки, говорите? Я просто оставлю это здесь.
Основной вопрос тут такой — будет ли искомый человек потом на работе часто решать нестандартные задачи? В большинстве случаев — скорее всего не будет. Лично я выступаю за проверку знаний с помощью быстрых тестов, на подобии тех, что проводят для определения уровня владения иностранными языками (50-100 вопросов за 30-60 минут).
Поэтому неудивительно, что опытные специалисты плохо проявляют себя в олимпиадных задачах.
Олимпиадные задачи это вообще отдельная тема, нужно специально тренироваться, чтобы был ощутимый результат.
Затем в другой очень известной фирме с высокими зп тоже напрягся и решил эти тестовые задания на codility. На решение дали уже меньше — 1.5 часа, что непонятно: спортсменов по программированию или рабов на галеры нанимают: даже тестовые задания нормально не успеваешь составить на проверку и производительность кода. Но потом этот бред продолжился: тестовые задания дали ещё и на последующем техническом интервью, только решить уже нужно было в присутствии интервьюера за 15-20 мин — решил за 21 мин — отказ. Что происходит?!
Уже нарешался этих задач на codility массу — аллергия на них уже, если б это ещё получение работы гарантировало. Они могут мои предыдущие тесты посмотреть?! ;)
Я вообще не понимаю, как человек мог стать синьором, и как он решает большие задачи и не
Я в 2015 году радикально поменял стек, завалил десяток интервью, и чтобы приучить мозги думать на JS как раз таки пошел и тупо решал всё подряд на том же кодварс. Это очень интенсивный и эффективный метод.
Более того, в современных приложениях на React+Redux (мой основной стек в настоящее время), редьюсеры, селекторы и не только они, при чуть более сложном сторе требуют как раз таки ровно те самые навыки, которые и оттачиваются на подобных задачках. Поэтому я слабо представляю себе годного фронтенд-разработчика в наши дни, кто не умеет решать подобные задачи.
На самом деле в любом приложении, где нужно как-либо обрабатывать данные подобные задачи будут весьма полезны.
Поэтому повторюсь, позвольте не согласиться с Вашей позицией. Решать задачки нужно и весьма полезно, и зря синьоры от них носы воротят. Если они реально такие синьоры как о себе думают, то для них не будет проблемой пару месяцев побаловаться хоть на том же кодварс и проблема будет решена раз и на всегда. А если нет, то стоит задуматься…
2. Есть технологии/задачи/области, для которых задачки такого рода не показывают ничего.
3. Это из разряда «каждый программист должен быть математиком и отучиться несколько курсов изучая интегральное/дискретное и прочие исчисления». Вроде бы и должен, но большая часть — никогда не столкнётся с необходимостью использовать эти знания и просто забудет их через 10 лет.
4. Забывают конкретику, а принципы остаются. Конкретную задачу можно не решить или решить неправильно, но думать при этом правильными категориями и исходя из правильных критериев делать прикидки и суждения. Потому что конкретика забывается, а привычки остаются.
ЗЫ:
Но, да — если в конкретной работе/области/технологии часто встречаются такого типа задачи и необходимы именно эти навыки, то такие задачи помогают оценить кандидата.
Только речь как раз о задачах, которые не встречаются в работе )
У меня в 11-12 годах отросла корона, а потом пришлось менять компанию, походил впервые за много лет по собесам, корону отшибло начисто, вместе с гордынюшкой. :)
Люди частенько меняют работу или ходят на собеседования не думая заранее, что они будут это делать. (я, к примеру, просто ради мониторинга рынка хожу на собеседования и, конечно, получается что особо не готовлюсь к ним) И, как следствие, они готовы представить собеседователям свои навыки, свой опыт и что угодно, кроме того, что 10 лет уже как не используют и подзабыли… и скорее всего не используют и на этом месте работы. (чаще всего так и бывает)
Да и, некрасиво это — заставлять соискателей штудировать и тратить время на задачи, которые не используются в этом направлении и, особенно, в самой предстоящей работе просто ради… ради чего? )
Соответственно и реакция у соискателей на такие вещи не очень хорошая. =)
Из тех задачек что мне попадались на подобных интервью, никаких затруднений они у меня не вызывали, при том, что я ни разу не спортивный программер, просто стараюсь держать себя в мало-мальской форме. Да и в целом не знаю кому как, а мне интересно временами прорешать пару-тройку задачек, чисто по приколу. Плюс ученики постоянно подкидывают ту или иную задачку, а я, прежде чем им на пальцАх делать раскладки, разумеется сначала сам прорешиваю, иногда несколькими способами, смотрю другие решения… Короче это прикольно, имхо.
Я абсолютно убежден, что любой синьор, мидл, да даже джун за разумное время может порешать задачек и проблема будет исчерпана.
В 14-15 годах я осознал, что веб люто повзрослел, в него пришел энтерпрайз и все требования возросли на несколько порядков. И я, внезапно, превратился в седовласого, бородатого джуна. Я радикально поменял стек, смиренно штудировал доки, смотрел и слушал сотни часов обучающих материалов, покрывал белые пятна, прокачивал скиллы, выполнял десятки туториалов. Проваливал собес за собесом, получал фидбэки, работал над ошибками, пока, в некоторый момент, не начал получать офферы.
К слову сказать работу в этом же ключе я продолжаю и по сей день и не собираюсь успокаиваться на достигнутом. Сегодня каждый вынужден бежать что есть сил, только чтобы оставаться на том же самом месте…
И сколько времени всё это заняло?
Вообще, вы говорите о переходе на новые для вас технологии, а вам говорили про сеньора, который давно сидит на известных ему технологиях и именно по ним заработал своё сеньорство. Поэтому если в его работе встречались алгоритмические задачки, то он и их должен бы вместе со всем остальным хорошо представлять. Но бывает так, что алгоритмы в работе примитивные, и всё упирается именно в знание технологий. Это весьма распространённый вариант для бэка (ну пишет чел. OLTP 10 лет и ни про какие алгоритмы никогда не вспоминал). Хотя при этом работу с БД, целевой язык, библиотеки, инфраструктуру и много чего ещё он может знать очень хорошо (на много лучше джуна). И вот вы как поступите — откажете ему и возьмёте мало знающего джуна или? Хотя задачки сеньор может и решит, но медленно, медленнее джуна или ваших лимитов. А может даже чего-то не решит. Каков ваш выбор?
Любой спортсмен делает разминку регулярно. Любой музыкант постоянно фигачит гаммы и арпеджио. Певец распевается. Вот и задачки — такая же разминка для мозгов программиста. Не нужно из них делать проблему…
Кроме задачек грамотный эчйчар много моментов проверит. А вот когда маститый синьор не желает решить простенькую задачку, хотя по идее должен уметь щёлкать их как сэмки, то это звоночек…
Айти сфера развивается нереальными темпами, я в строю с 1995 года, и постоянно приходится держать руку на пульсе. Если человек 10 лет фигачил пусть даже какой-то очень забористый стек, и считает что он достиг пределов и развиваться ему нет нужды, ну что ж, как говорится желаем удачи…
Я вот постоянно помню, что горячие молодые разработчики, у которых ни ребенка, ни котёнка, которые готовы фигачить до потери пульса чуть ли не за еду, постоянно дышат в затылок и наступают на пятки. Писал выше и снова повторю, в наши времена нужно очень быстро бежать, чтобы только оставаться на том же самом месте…
Ах да, а еще Индия штампует десятки, если не сотни тысяч разработчиков каждый год. Прошу заметить, голодных и готовых почти на всё, разработчиков. И все они залетают на рынок. Наш российский айти сегмент спасает то, что эти друзья по русски ни бельмеса, а вот попробуйте на англоязычный рынок сунуться, ощутите во всей красе все прелести конкуренции с молодыми и голодными до всего, имеющими в распоряжении вагоны времени и энергии…
Эти аргументы похожи на что-то вроде английский знаю отлично, но слова забыл, т.к. давно не было практики
Нет, эти аргументы похожи на то, что китайский не знаю, т.к. давно не было практики, и он мне в работе не нужен. А на интервью его спрашивают по причине "Знание китайского покажет нам, как вы умеете по-английски говорить".
Потому что зачем? У него и без того хватает предложений. Вторая причина — наличие тупых задачек говорит об интеллекте менеджмента, а второй золотое правило хорошего работника гласит "не работай с идиотами".
А вообще не понимаю нытьё про задачки, я обожаю решать их когда собеседуюсь сам, почти все мои друзья обожают решать их, это культура интеллектуальных людей. Некоторые даже деньги платят, за то, чтобы им задавали задачки (см. всякие Квизиум и т.п.). Если человек любит сложности, любит учится, если главной движущей силой его жизни является любопытство (а не деньги, слава, секс или еда) — это наш человек и это сразу даёт +100 балов на собеседовании. Если нет — у вас тоже хорошие шансы, так как на рынке кадровый голод, но вам никогда не переплюнуть фанатиков, которые шевелят мозгами просто потому, что им это нравится.
Тут про кодварс и другие сервисы пишут. Никогда на них время не тратил, но задачи решаю замечательно. И чем менее типовые, тем больше шансов выделиться, просто за счёт общего интеллекта (который они и призваны проверять, а не время на кодварс).
Нет, видимо люди с вами не согласны, но не хотят объяснять каждую ошибку.
Задачки нужны для того, чтобы проверить общий интеллект, который влияет на способность человека быстро обучаться новому.
Умение решать алгоритмические задачки не влияет на способность человека быстро обучаться новому. Что такое "общий интеллект" не очень понятно, но из того, что можно предположить, задачки его не проверяют.
обычно я задаю задачки на интеллект новичкам, у которых нет всех необходимых знаний, чтобы понять, смогут ли они быстро добить недостающее
Если новичок не решил задачку, это не значит, что он не сможет быстро добить недостающее. Это значит, что он не умеет решать такие задачки.
А вообще не понимаю нытьё про задачки, я обожаю решать их когда собеседуюсь сам, почти все мои друзья обожают решать их
И вы считаете, что всем людям должно нравиться то же, что и вам, а если их вкусы отличаются от ваших, значит это плохие специалисты?
Если человек любит сложности, любит учится, если главной движущей силой его жизни является любопытство
"Движущая сила жизни человека", если можно так выразиться, складывается из нескольких факторов, и деньги один из самых важных. Если взрослый человек этого не понимает, противопоставляет любопытство и деньги, значит и отношение к нему будет негативное. Вы можете считать так сами, но не вправе считать других хуже, если они считают по-другому. Кроме того, у вас присутствует подмена понятий, любопытство не означает стремление решать задачки, а стремление решать задачки не означает любопытство. Особенно любопытство в сферах, которые действительно нужны для профессиональной деятельности специалиста.
которые шевелят мозгами просто потому, что им это нравится
Еще одна подмена понятий. "Шевелить мозгами" не означает только и исключительно решение задачек, о которых идет речь. А также следующее из этого некорректное противопоставление — "не решает задачки — это плохо, решает — это хорошо".
Умение решать алгоритмические задачки
Я не говорю про алгоритмические, они показывают только учил человек предметную область или нет. Я говорю про задачки вроде этих tproger.ru/articles/problems. Почему-то некоторые с них бесятся, хотя специальных знаний не требуется.
Если новичок не решил задачку, это не значит, что он не сможет быстро добить недостающее
Если не решил ни одну из десятка — всё же можно сделать некоторые выводы. Плюс интересно послушать рассуждения, это говорит о многом.
деньги один из самых важных
Деньги один из ресурсов, не самый мощный. Деньги сильно пиарят, потому что только так государство и компании могут заставить вас тратить на них по 40 часов каждую неделю.
любопытство не означает стремление решать задачки, а стремление решать задачки не означает любопытство
Наблюдение показывает, что они сильно коррелируют, имеют одни корни.
Еще одна подмена понятий
Это не подмена понятий, а связь между ними. Статистическая, не 100% верная, но отлично работающая в реальной жизни. Если что-то не так — всегда можно объясниться и найти общий язык с интервьюером. Когда я собеседуюсь, я открыто говорю, что не знаю алгоритмов, так как не проходил их в ВУЗе и никогда не применял в работе. Это не мешало получать хорошие должности, так как никто не знает всего и это все понимают.
не решает задачки — это плохо, решает — это хорошо
Смотря какие задачки. Если вы спрашиваете человека 2+2 и он не отвечает, стоит ли брать его? А чуть посложнее? Математика и логика это только инструменты мышления, и если человек ими не владеет (хотя бы на интуитивном уровне) — он не будет их применять в работе, значит он будет делать плохую работу. Можно спросить про индукцию и получить ответы от людей, начитавшихся книжек, а можно дать задачку на индукцию и получить ответы от практиков, применяющих её пусть даже не осознано.
Вы можете считать так сами, но не вправе считать других хуже, если они считают по-другому
Вы правы, но почему я должен нанимать их в свою команду, вместо того, чтобы набрать дримтим из единомышленников со схожей культурой и ценностями? Пусть финансово-ориентированные идут в свою песочницу, а мы с интеллект-ориентированными пойдём в свою. И будем играть совсем в разные игры в наших компаниях.
Я говорю про задачки вроде этих
В статье говорится в первую очередь про алгоритмические. И нет, задачки вроде этих тоже не влияют на способность человека быстро обучаться новому.
Если не решил ни одну из десятка — всё же можно сделать некоторые выводы. Плюс интересно послушать рассуждения, это говорит о многом.
Вы еще их десятками задаете? Тем более. Самый вероятный вывод, который можно сделать — это то что он не хочет решать кучу бесполезных задач, где надо угадать, что хочет услышать интервьюер. Второе предложение это подтверждает. Кто его знает, что вы там себе навыдумываете.
Деньги сильно пиарят, потому что только так государство и компании могут заставить вас тратить на них по 40 часов каждую неделю
Деньги сильно пиарят, потому что без них можно умереть с голоду. Или получить проблемы со здоровьем. Или иное уменьшение уровня жизни.
Наблюдение показывает, что они сильно коррелируют, имеют одни корни.
Это не наблюдение показывает, это вы делаете такой вывод. Те, кому приходится их решать, делают из наблюдений противоположный вывод.
Статистическая, не 100% верная, но отлично работающая в реальной жизни.
В том-то и дело, что не работающая. Гугл, говорят, даже провел исследование и отказался от таких задачек. И в статье по вашей ссылке даже есть ссылка на информацию об этом.
Математика и логика это только инструменты мышления, и если человек ими не владеет (хотя бы на интуитивном уровне) — он не будет их применять в работе
Вот именно про такие ошибки я и говорю. Если человеку не нравится решать бессмысленные по его мнению задачи, это не означает, что он не владеет математикой и логикой. А вы не только считаете, что означает, но и делаете выводы из некорректной предпосылки.
Можно спросить про индукцию и получить ответы от людей, начитавшихся книжек, а можно дать задачку на индукцию и получить ответы от практиков
А можно дать нормальную практическую задачу и получить ответы от практиков, которые решали ее, а не задачки с собеседований. Либо заменить ее на обсуждение практических задач из опыта кандидата. О чем и идет речь в данном обсуждении.
Вы правы, но почему я должен нанимать их в свою команду, вместо того, чтобы набрать дримтим из единомышленников со схожей культурой и ценностями?
Очередная подмена тезиса. В вашем изначальном комментарии вы высказывали сомнение в профессионалных качествах тех, кто не хочет решать такие задачи. "Человек не подходит в мою команду" и "Человек не умеет обучаться новому" это не одно и то же. Вы ничего не должны в отношении своей команды, но и не должны высказывать негативные оценки в отношении профессиональных качеств других и обвинять их в отсутствии интеллектуальной культуры только на основании того, что они не разделяют ваше увлечение задачками.
Что касается аргументов по существу — вы не хотите их понимать, превращаете в фарс, а значит смысл мне что-то доказывать?
Если говорить о задачках, предположу что начать следует с самого начала — со сбора требований. Кто из негодующих в состоянии четко сформулировать требования к take home assignments?
— Kакие цели мы можем принять за достижимые?
— Какие цели следует осознанно исключить из списка?
— Какие есть внешние ограничения? А ведь они есть и их больше, чем кажется на первый взгляд.
Попробуйте после этого предложить если не «тот самый» формат take home assignment, то хотя-бы patterns / antipatterns. Do's and dont's. Хочу сразу предупредить, однако, что это не так-то просто [1], [2].
Наличие жёсткого первоначального фильтра
Поддерживаю! Это лучший способ создать однобокий, скучный продукт. Что бы сделать продукт универсальным нужны разные люди, с разными способностями.
прохождения теста на уровне кандидатского минимума по финансам
Хороший способ подтверждения квалификации - это непосредственная работа над проектом (пул реквест/переводы/дизайн/issue/другое участие). Это подтвердит как заинтересованность в работе, так и возможность улучшить продукт.
Даже не стал бы пытаться пробиться в такую компанию. Ну пролезешь туда всеми правдами и неправдами, потом тобой будут помыкать аргументируя это тем, что "за забором еще 500 таких-же".
Почему Senior Developer'ы не могут устроиться на работу