Комментарии 237
Может быть вы специально искали работу, где нужны алгоритмы и знания вещей, которые в обычной жизни программист использует редко, но для Джуна это выглядит, как перебор.
Я не знаю как в других конторах, но по моему мнению, джун должен уметь думать, системно мыслить и быть обучаемым. А специфическим вещам и алгоритмам, которые используются он может научиться позже, во время выполнения задач. В общем, джун, это как стволовая клетка. Зачем задавать ему вопросы из совсем разных областей для меня загадка.
В общем, джун, это как стволовая клетка.
А почему? Чем он 4 года в колледже занимался?
Зачем задавать ему вопросы из совсем разных областей для меня загадка.
Чтобы убедиться что материал всех 4х лет хорошо усвоен.
Я не знаю как в других конторах, но по моему мнению, джун должен уметь думать, системно мыслить и быть обучаемым.
Понимаете: вы, как и все соискатели, пишущие 100500ю статью на тему “почему у известных контор такие безумные собеседования” — смотрите на задачу со своей стороны (хотя иногда проблески встречаются, например соискателей на младшие позиции валят на собеседованиях пачками и для этого в компаниях, видимо, есть специальные «сеньоры» — это уже теплее).
А смотреть нужно со стороны работодателя. Вы ж к нему идёте, а не он к вам.
Не те книги вы читали, ох не те. Какой смысл вообще идти на собеседование, забыв знаменитое Паркинсоновкое:
"Требуется премьер-министр Руритании. Рабочие часы - с 4 утра до 11:59 вечера. Соискатель должен выдержать три раунда с чемпионом в тяжелом весе (в перчатках). По достижении пенсионного возраста (65 лет) - мучительная смерть во имя родной страны. Если соискатель знает парламентскую процедуру лишь на 95%, он будет физически уничтожен. Если он соберет меньше 75% голосов при проверке популярности по методу Гэллапа, он также будет уничтожен. Кроме того, соискатель должен обратиться с речью к съезду баптистов и склонить их к изучению рок-н-ролла. В случае провала будет уничтожен.
Явиться в спортклуб (с черного хода) 19 сентября в 11:15. Перчатки предоставляются; кеды, майка и шорты - свои".
Да, понятно, что до выкидывания в урну половины CV из пачки с заявлением “нам не нужны неудачники” не доходит, но, в принципе, любые требования, уменьшающие количество кандидатов и улучшающие их качество годятся.
Что вас удивляет? Что у вас спросили задачку с LeetCode или кусочек спецификации языка, на котором вы уже не один год работаете? А почему нет, собственно? Это же улучшит качество не отсеянных кандидатов? Значит — годится.
И да, если кандидатов не хватает требования приходится снижать. Об этом Паркинсон тоже пишет…
А если не придет никто?
Значит, в чем-то мы завысили требования.
То же самое небольшое объявление предложим в измененном виде. Например, 95% заменим на 85, 75 -на 65, а три раунда - на два. И так далее, пока соискатель не придет. Предположим, однако, что придут двое или трое.
Это покажет, что мы допустили промах в научных расчетах. Быть может, мы слишком занизили проценты - их должно быть 87 и 66. Как бы то ни было, дело плохо. В приемной два, а то и три соискателя. Надо выбирать, а мы не вправе тратить на это все утро. Можно, конечно, начать испытания и отсеять менее достойных. Но есть и более быстрый путь.
Примем, что у всех троих есть все нужные качества. Остается прибавить еще одно и провести простейшую проверку.
Мы спрашиваем какую-нибудь девицу (машинистку или секретаршу): "Который вам больше нравится?" Она тут же отвечает, и вопрос решен. Нам возразят, что мы полагаемся здесь на чистую случайность, как бы бросаем монету. Это не так. Мы просто ввели новое качество - мужскую привлекательность.
А вы, не усвоив азов технологии собеседований, лезете в какие-то технические детали…
Что вас удивляет? Что у вас спросили задачку с LeetCode...
Ни в коем случае! Я обеими руками за LeetCode, и особенно за многочасовой LeetCode. Мне это очень помогает разобраться с вакансией и минимизировать затраты времени, связанные с ней.
Сарказм в отношении многочасовых собеседований выдает в Вас человека, не знавшего на своей шкуре что такое 2008, увольнения сотнями в NYC и виза H1B. Сейчас Вы просто наслаждаетесь рынком, который к Вам повернут лицом. Там получить приглашение на 3 интервью, каждое по 2 часа было за половину счастья и неделю радости.
Вы знаете, а я с Вами отчасти согласен. Есть ощущение, что IT-рынок действительно повернулся лицом к соискателю, особенно после 2020 года. И я этим невозбранно пользуюсь. Пока у меня есть возможность выбирать между двумя вакансиями: с долгим и сложным тестом и без него — я не стану долго думать.
Что касается сокращений работников с визами в 2008-м. Эти люди когда-то приняли осознанное решение ехать за рубеж на жестких условиях с минимальными гарантиями. Отсутствие "плана Б" на случай непредвиденных обстоятельств называется халатная беспечность.
А что было в 2008? Я начал ездить в NYC в 2009 и был настолько востребован, что в 2010 меня перевезли в NYC по L1 (а не по рабской H1B).
Давайте предположу, может быть так: лишилась работы кучка бесполезных разрабов живущих на крошки со стола строителей пирамид Credit Default Swap (aka Lehman Brothers, Bears Sterns вместе с AIG). А разрабы в компаниях производящих реальную пользу (то есть в нормальных бизнесах - без признаков мошенничества) продолжила жить как и раньше.
Расскажите мне, как важно учиться в колледже О-большому, чтобы не вляпываться в пирамиды из которых вас вышвырнут при первом удобном случае...
Это индивидуальный опыт, сокращения были по всей индустрии, даже в полупроводниках, сокращали целыми отделами.
А разрабы в компаниях производящих реальную пользу (то есть в нормальных бизнесах - без признаков мошенничества) продолжила жить как и раньше.
У компаний, "производящих реальную пользу" вполне себе мог быть клиент, закредитованный по самую МакКинли. И не производящий столько "реальной пользы", но дающий ей основной cas flow. Он дохнет, а следом на улицу через пару дней идет вся компания "производящая реальную пользу". Скажете, нереальный сценарий? И кстати, да, к лету 2009 попустило, стали на интервью приглашать даже в другие штаты. А вот с августа 2008 по где-то апрель 2009 - писец...
Я больше о том, что строить какие-то теории о том какие разработчики "должны быть" на рынке на основе историй, происходивших с программистами работающих тесно на нерыночные организации (которые и "упали" в 2008) - странное занятие. Подавляющее количество оказавшихся на улице программистов тогда - никчемные бездельники, которые существовали только за счет нерыночных механизмов, а не за счет знания большого-O. Но им, конечно, приятнее думать, что это все из-за их уникального ума и образования...
Да, зацепило, наверное кого-то кто и был не при делах, но они спокойно отдохнули 3-6 месяцев, получили unemployment, и пошли дальше продуктивно работать (о чем ярко говорят данные уже 2009). Вообще, если нет буфера на 3-6 месяцев, то проблемы с финансовой грамотностью - не верен, опять же, что поиск в глубину поможет таким людям...
А с чем, собс-но, минусующие в таком количестве не согласны?
А почему? Чем он 4 года в колледже занимался?
А всегда ли в коледже дают, то что надо конторе? Ведь даже процессы разработки в конторах разные, по-моему, достаточно увидеть, что человек имеет базу и может самостоятельно разобраться в чем то. Что он обучаем. Вот зачем спрашивать обход деревьев, если в 99℅ это не нужно?
Вы, что будете деревья обходить? Скорее всего вы будете использовать легаси код или библиотеки, где это уже все есть. А алгоритмы изобретать, это такое узкоспециализированное.
Чтобы убедиться что материал всех 4х лет хорошо усвоен
Вы же сами написали, что не знали и этого вам по всей видимости не давали, таким образом, вы просто пошли и набили руку на этих деревьях на онлайн тестах, но это ничего не говорит о том, усвоен материал или нет так как, через пару лет, если лет этого не используете, вы просто забудете всё и будете чист как стеклышко. В своё время я знал около 7-8 способов быстрого извлечения корня, когда писал на ассемблере для мотороллы. Но сейчас мне это не надо, у меня есть 1 ассемблерная команда, которая это делает. И я их все забыл.
Я думаю, что вопросы могут по неизвестному, но нужно смотреть не на то, знает человек это или усвоил за время обучения, а на то какой у него подход к решению задач, о которых он понятия не имел до собеседования, каковы его шаги. Что он будет делать в этой ситуации.
Не стоит ожидать от Джуна ответов на все алгоритмы и тонкости работы фреймворков.
А всегда ли в коледже дают, то что надо конторе?
Разумеется нет.
Вот зачем спрашивать обход деревьев, если в 90℅ это не нужно?
Затем, чтобы выяснить — собирается ли идивидуум делать то, что от него просят или нет.
Если он в колледже, вместо того, чтобы учиться, водил романы с барышнями — где гарантия, что он у вас будет чем-то другим заниматься?
Вы же сами написали, что не знали и этого вам по всей видимости не
давали, таким образом, вы просто пошли и набили руку на этих деревьях на
онлайн тестах, но это ничего не говорит о том, усвоен материал или нет
так как, через пару лет, если лет этого не используете, вы просто
забудете всё и будете чист как стеклышко.
Бред какой. Послдний раз я Кормана открывал больше 10 лет назад, но это не мешает мне спокойно решать все эти задачки с собеседования.
Они ж простенькие все, никто не будет вас просить писать что-то, что потребует больше 100 строк кода.
Не стоит ожидать от Джуна ответов на все алгоритмы и тонкости работы фреймворков.
А чего, извините, от него ещё ожидать? Самое же главное ведь даже не то, сможет ли он чем-то там обучиться. Куда важнее другой вопрос: а захочет ли?
И задавая вопрос про деревья вы, одновременно, отвечаете на оба этих вопроса.
Да, только у тех, кто учился в колледже, но в чём проблема-то? Отсевом остальных можно просто пренебречь. Читаем Паркинсона ещё раз.
Но сейчас мне это не надо, у меня есть 1 ассемблерная команда, которая это делает. И я их все забыл.
Но сейчас вы же и не будете на позицию джуниора устаиваться.
Но сейчас вы же и не будете на позицию джуниора устаиваться.
Т.е. джун должен быть умнее мидла?
Если он в колледже, вместо того, чтобы учиться, водил романы с барышнями — где гарантия, что он у вас будет чем-то другим заниматься?
Если он в колледже учился и не водил романы с барышнями — где гарантия, что он у вас будет этим же заниматься?
Скорее даже иначе: если он в колледже был вынужден учиться так, что на романы с барышнями не оставалось времени, то с чего вы взяли, что он вообще обучаем?
Был у меня прекрасные преподаватель в универе, который зубрил не любил намного больше, чем просто раздолбаев. Потому что вторых научить еще был шанс (что он постоянно и делал), а вот первых научить шансов уже не было, т.к. знание вроде бы и есть, а вот понимание отсутствует.
Если он в колледже, вместо того, чтобы учиться, водил романы с барышнями — где гарантия, что он у вас будет чем-то другим заниматься?
А что если в учебном заведение так учили? То есть качество образования было так себе, а примера и понимания что учить не было?
Во-первых, Вы заставили меня зарегистрироваться на данной платформе исключительно ради того, чтобы ответить Вам. С учетом того, что я тут обитаю достаточно долго и желания завязать обсуждение у меня не возникало, Вы можете считать это своим небольшим личным достижением.
Во-вторых, Вы в корне не правы касательно взгляда на процесс труда. Не я ищу помощи, а компания. Я чудесно смогу кодить и без работы в компании (думаю у большинства разработчиков есть pet-project или даже несколько), а на поприще фриланса, по крайней мере в области front-end'а, достаточно работы, чтобы деньги на жизнь были, от простой вёрстки до SPA с возможностью выбора фреймворка. Развиваться я прекрасно могу самостоятельно, мои знания от компании тоже зависят в меньшей степени. Так что мне не нужна компания для постоянно работы. А вот разработчики ей нужны, без разработчиков компания не сможет создавать и поддерживать свои IT-продукты, получать прибыль, расти и развиваться. Открывая вакансию работодатель просит помощи у соискателя, предлагая обменивать время жизни человека на деньги во благо организации, выполняя поставленные задачи. Да компании и работники взаимозаменяемы. Но вот беда, без работников компания умрет, но без компании работник жить сможет. Я не должен вставать на место работодателя, это его дело и его проблемы, я выполняю задачи и получаю за это оплату, интересны компании и мои не пересекутся, и уж точно мои не станут ниже по приоритету. Я откликаюсь на просьбу о помощи, так что это не мне нужен работодатель, это мы его необходимы.
P. S. На данное мнение отвечать не стоит, в эту ветку я в любом случае не зайду и Ваш ответ не увижу. Всего Вам наилучшего и успехов.
но без компании работник жить сможет.
Это только в нынешнее время, после 20 года, когда на рынке произошел невиданный как минимум 20 лет поворот лицом к работнику ИТ сектора. До этого картина была с точностью до наоборот, особенно для низовых позиций.
Даже для низовых позиций, я вспоминаю про Фитиль, где инженер умолял его перевести на должность уборщицы. А можно даже уборщицей не работать - я постоянно вижу просто попрошаек и уличных музыкантов разной степени паршивости.
Понятно, что последний айфон с таким lifestyle не купить, но у меня вот тоже нет айфона или аналогичного флагмана на Андроиде, хотя вроде работаю, и работаю немало.
Это только в нынешнее время, после 20 года, когда на рынке произошел невиданный как минимум 20 лет поворот лицом к работнику ИТ сектора. До этого картина была с точностью до наоборот, особенно для низовых позиций.
Зависит от области. В веб программирование все было хорошо и до 2020, а после стало еще лучше.
Это действительно работает, если вам все равно, как этот джун потом работать будет. Или вы полагаете, что они все одинаковые.
Почитал. Тот факт, что до 1997го года проблема не существовала и, соответственно, в тех книжках по которым я учился, упоминаться не могла, оправданием являться не может, как и то, что проявляемые симптомы ровно такие же, как у проблем с кешами (ровно потому что речь идёт, фактически, о кеше внутри планки памяти).
Самое обидное, что о том факте, что SDRAM, в отличие от более ранних DRAM, может выдавать более одного бита после “открытия” строки я когда-то даже читал (да, собственно, на этом все эти DDR/DDR2/DDR3/DDR4/DDR5 основаны, иначе в них бы особого смысла бы не было). Но вот о том, что контроллеры SDRAM могут тупо не закрывать строку и продолжать её держать открытой после забора строки в кеш… даже не думал как-то. Интересно, что будет, если банально ничего не “оптимизировать” и передав столько байт, сколько нужно по протоколу, (для DDR5 это, соотвественно, 256 байт), закрывать строку? Точно потери в производительности будут настолько существенными, что это станет проблемой?
Однако… конечный вердикт остаётся неизменным. Как в части “кандидат очень умён”, так и в части “не брать ни в коем случае”. Потому что что во время собеседования опции “я потроллю собеседующего, он “проникнется” и предложит мне работу его начальником” у вас просто нет.
Если вашей задачей явлеяется устройство на работу, то никакого троллинга собеседующих вы себе позволить не можете. Даже же вы хотите просто потратить их время… троллинг всё равно контрпродуктивен: обычно отказать таким кандидатам гораздо быстрее и проще, чем тем, кто чего-то не знает. Так что, в конечном счёте, вы своего времени потратите больше, чем рекрутерского.
Потому что что во время собеседования опции “я потроллю собеседующего, он “проникнется” и предложит мне работу его начальником” у вас просто нет.
Вы так и не поняли? Нет ни у кого цели потроллить и устроиться на работу. Вам говорят о том, что вы в данном случае ничем не отличаетесь от такого троллящего, который вам так не нравится. И точно так же не знаете каких-то отдельных технических вопросов, по которым можно сделать такой же неправильный вывод, что вы нихрена не знаете и какой вы нафиг сениор.
К чему все эти сложности? Я для вас придумал революционный способ, сокращающий расходы на найм и экономящий кучу времени и сил. Просто давать всем пришедшим на собеседование задачу подкинуть монетку 10 раз так, чтобы на ней выпадал только орёл. В среднем отсеивается 1023 кандидата из 1024. Добавляем броски если ожидается большее количество людей и отбавляем если меньшее. Идеальное собеседование готово (с поправкой на то, что может отсеяться больше или меньше нужного, но там уже если несколько человек справится, например, то можно им устроить бег на короткую дистанцию по офису, победителя принимают на работу), не благодарите.
Чем он 4 года в колледже занимался?
Так об этом и спросите. Он изучал такие-то алгоритмы? Спросите по ним. Изучал языки? Спросите по ним. Реализовывал проекты? Спросите по ним. Реализовывал их не один? Спросите, как организовывали командную работу, была ли иерархия.
Вообще если бы расказчик написал в гугле "Вопросы на собеседовании на C# разработчика" он бы сразу получил этот список: GC, hash table, сортировка, обход дерева и т.д.
Так что так себе он готовился.
А про что надо спрашивать джуниоров? Если я попрошу его рассказать этапы инициализации спрингового контекста, это будет вопрос хуже или лучше сборщика мусора?
А может пойти от обратного? Начать с того, чтобы джун рассказал о своих достижениях и уже на основе этого задавать вопросы.
А зачем? Я понимаю, если бы джунов не хватало и за ними охотились бы… но ведь нет этого. Их на любую вакансию толпы приходят, задача же как-то из этой толпы выбрать двух-трёх.
Можно считалочку использовать, столь же бессмысленно как спрашивать реализацию обхода деревьев, но по крайней мере более весело для всех участников процесса
Почему же бессмысленно? Умение реализовать обход дерева показывает, что собеседуемый:
Учился таки тому, чему должен был учиться на соотвествующем направлении
Способен обучаться в приципе и имеет желание это делать
Ну и умеет написать-таки какой-то код.
Вполне себе пользительные качества, я бы сказал.
А считалочка… да, веселее, но улучшить качество кандидатов она же неспособна.
Учился таки тому, чему должен был учиться на соотвествующем направлении
В ВУЗе в котором я учился не учили обходу деревьев.
Может, он не учился в ВУЗе обходить деревья. Может, он и вовсе не учился в ВУЗе.
Если хотите узнать больше про ход его мыслей, лучшим вариантом будет то, что предложили выше. Спросите про его достижения. Спросите, какие задачи он решал, с какими при этом сталкивался проблемами, как искал решение, какое решение нашел. Ну и в таком же духе.
Порассуждайте вместе с ним (да, самому тоже надо включать мозг на собеседовании, а не задавать вопросы с заготовленными заранее ответами).
Предложите усложнение его же задач. По принципу "А что если вам захотелось бы добавить новую фичу (конкретика от вас, какую фичу)". В этом случае он будет в контексте (погружен), поэтому потребуется меньше времени на ответы. К тому же, сможете в реальном времени увидеть, что он не просто болтологией занимается, а действительно умеет решать задачи.
Сначала целиком был за ваше мнение, дескать "совсем офигели, джунов про бинарные деревья спрашивать", а потом понял что обход бинарного дерева это же тривиальщина. Ну типа visit(cb, node) {cb(node); visit(cb, node.left); visit(cb, node.right);}
Банальщина? Тем более, не стоит спрашивать банальщину, которая не встретится в работе. Всегда можно придумать интересные небанальные задачи, проверяющие умение мыслить, а не эрудицию.
Так а чем вам деревья не угодили? Если соискатель раньше сталкивался с ними, то набросает алгоритм обхода за пару минут. Если не сталкивался, то это как раз будет для него задачкой, проверяющей умение мыслить.
Почитайте про индексные структуры автора базы данных SQLite Ричарда Хиппа. Который с командой таких же топовых спецов два десятилетия все еще оптимизирует "обход дерева":) Очень много нюансов с оптимизацией кэша, находится ли дерево на диске или в памяти или и там и там, и еще много всего. В PostgreSQL тоже регулярно оптимизации добавляют в обработку "обхода дерева".
Читал :) Но вы серьезно от джуна это собираетесь требовать?
Ну что вы - это требовать надо от упомянутого в статье "сеньера сеньоров", чтобы ему сложнейшие концепции не казались тривиальными в силу личной некомпетентности. Тогда и ответивших на вопросы будет больше. А то, знаете, напоминает, как ко мне пользователи некоторых моих опен сорс проектов стучатся - "а вот мне надо сделать я еще не понял что, ваша программа так умеет?":)
Нет, с учетом времени и условий, которые есть на собеседовании, это плохая задачка на умение мыслить. Видели картинку, где программист код парсера разбирает? А разобраться в алгоритме, который уже есть на экране, гораздо проще, чем придумать алгоритм, неизвестный ранее.
А тем более, весь код обхода, по сути, уже выше написан, это однострочник. Хотите код поразбирать? Не вопрос, покажите ему вот это, и спросите, в каком порядке обход дерева в этом примере, и как модифицировать, чтобы порядок стал другим. К этой задаче можно подойти с десяти разных сторон, и видоизменять ее, меняя сложность на пару порядков.
Если подразумевается реальная реализация - это, скорее, мультидерево с кэшем незакоммиченных изменений в многопоточном приложении, и поиск оптимальной структуры данных и порядка обхода это предмет исследований. Если вопрос теоретический - сейчас исследования ведутся в отношении методов создания конфигурируемых би-, квадро- и так далее деревьев и именно они представляют теоретический и практический интерес, пространственные индексы в PostgreSQL и SQLite посмотрите. А про чисто бинарные деревья новых публикаций уж с полвека как нет, ибо незачем - это сразу уточнять нужно, если спрашивающий полвека в анабиозе провел и задает чисто исторические вопросы :)
С вашей точки зрения наверное это верно. Но это совершенно необязательно. Просто любой парсер любого языка, синтаксическое дерево, и его обход с кодогенерацией. Может быть сколь угодно простым, и при этом задача такая вполне реальна.
И не забудьте, что тут про джуна говорили.
Многие выпускники физмат вузов в коммерческом программировании новички, при этом прекрасно понимают сложность обсуждаемого вопроса. Странно ожидать, что джун психологически и технически уверенно докажет, что все собравшиеся просто невежи и его еще на работу возьмут :)
Мы же говорим о задаче — и эта задача почти всегда модельная, потому что время на интервью не бесконечно. В реальности может быть у задачи есть миллион нюансов, которые джун не обязательно знает (и не должен). Если же он знает, что у задачи есть второй и третий уровень сложности, типа тех, о которых вы выше говорили — значит он знает пределы применимости своих знаний. Тем лучше для него. Если же нет — значит мы ограничились простой задачкой на алгоритмы и структуры данных.
>Многие
По-моему выпускники ВУЗов по большей части новички в коммерческом программировании. Тупо потому, что они не программировали за деньги во время обучения, а все-таки учились. Это нормально, и я бы не ждал от них, что они как раз это хорошо понимают.
знает пределы применимости своих знаний
Вот оно - ключевое знание. Если человек реально оценивает, что именно он не знает, то он это сможет найти и разобраться, а иначе будет бесконечно делать что-то, но не то и не так. Вроде как именно это и есть задача высшего образования, кстати говоря, "научить учиться". Если же просто пытаться оценить знания в данной сфере на данный момент - это бесполезая оценка для любого специалиста, способного учиться, а еще очень искаженная из-за субъективных факторов. Так что слушать надо на интервью, что кандидат может интересного рассказать о своей работе или учебе, а не спрашивать выдуманные вопросы в зачастую невнятной формулировке.
Зависит от языка программирования. Игрища с указателями в Rust, например, это отдельная дисциплина.
Не согласен. Если я прохожу собеседование, и я, и работодатель оба хотим, чтобы я начал поскорее получать задачи и денежки. В идеально честном мире собеседование вообще не нужно — я просто говорю свои знания, они — свои требования, всё:
— да мы просто не знаем, что спросить — у нас обычное перекладывание джсона туда-сюда и форпошлепство, какие деревья, лол
— я что-то слышал про деревья, но мозг вроде работает, разберусь.
— вы приняты
Поговорить о том что в дереве могут быть циклы, как эту проблему решить. Нужно ли обходить дубликаты (если они возможны). Спросить про направление обхода дерева. Как оптимизировать производительность если структура дерева не помещается в памяти, а подгружается блоками с диска. Упомянуть «вот у Кнута было, но сегодня я не согласен, так как с появением SSD ...»
И вот это, как правило, уже лишнее. В 99% случаев, про деревья вспоминается только на собеседовании. Зачем? И уж точно джуну не надо знать, как оптимизировать насколько большое дерево, что его ещё надо на диск писать. Ещё и привязываться к SSD/HHD. Да и большинству сеньоров оно не надо. Не, правда, ЧТО вы разрабатываете для таких вопросов?
Перечитал статью:
Вероятно, увидев в моем лице очередную проблему для бизнеса, он решил сразу озадачить меня обходом бинарного дерева. К этому, признаться, я был не очень готов. И если простой обход я кое-как вспомнил, то какой-то хитрый подсчет суммы в дереве, где надо было использовать какой-то метод скользящего окна (попробуй придумать это, стоя у доски), я конкретно запорол.
Нет, всё таки офигели у джуна спрашивать подсчет суммы через скользящее окно.
Я бы ответил — это преждевременная оптимизация, так делать не нужно.
Ну про время уже издевательство :)
Хотя если вопрос "How old are you?" имеет ввиду сколько тебе лет, месяцев, дней, часов, минут, секунд в текущей часовой зоне, то ОК.
В дереве не может быть циклов. Оно по определению ациклично.
Джунов нанимают для выполнения каких-то задач и в надежде, что прежде чем они покинут компанию, они дорастут до мидлов, а лучше до сеньеров. Если послушать кандидата, что и как он будет рассказывать о задачах которыми занимался и желательно подробности о самых увлекательных для него проектах, то это поможет понять насколько он будет заинтересован расти в вашей компании, да и в целом насколько интересуется разработкой. Ваш же подход практически не отличается от подкидывания монетки.
Хотя в целом к алгоритмическим задачкам отношусь очень хорошо: мне кажется их решение развивает мозги, кроме того, дает более глубокое понимание кода, который ты пишешь, особенно касаемо алгоритмической сложности как самого алгоритма, так и используемых струкрур. Не очень приятно, когда UI тормозит потому-что там жабоскрип с 4-мя вложенными циклами написанных сеньером. Зато, наверное, все знает о поколениях сборщика мусора в C#
это поможет понять насколько он будет заинтересован расти в вашей компании, да и в целом насколько интересуется разработкой.
Это в мире розовых поней так.
Ваш же подход практически не отличается от подкидывания монетки.
Ой ли? Вот возьмите мистера мне-все-работодатели-должны-ноги-целовать. Который аж специально зарегистрировался, чтобы высказать до какой степени он велик и заявить, что интересны компании и мои не пересекутся, и уж точно мои не станут ниже по приоритету.
Какова вероятность того, что такой, с позволения сказать, работник, вообще согласится проходить ваше собеседование и какова вероятность того, что у него окажутся нужные для этого знания?
Правильно: примерно где-то в районе нуля. Что снижает затраты на общение с ним как у инженеров, так и у HR.
А вот как раз про разные “самые увлекательные для него проекты” он может много чего нарассказывать.
Джунов нанимают для выполнения каких-то задач и в надежде, что прежде
чем они покинут компанию, они дорастут до мидлов, а лучше до сеньеров.
Джунов нанимают для того, чтобы они делали что им скажут. Точка.
Рассказы про богатый внутренний мир и прочие душевные переживания они могут оставить при себе до того момента, пока не станут руководителями какого-нибудь стартапа и не придут с каким-нибудь интересным продуктом. И будут продвать, тогда, уже не свои руки и голову, а этот самый продукт (вместе с командой, да).
И да, в принципе, ваши разговоры по душам тоже могут прояснить эту ситуацию, но они требуют гораздо больше усилий по интерпретации.
Или если джуниор, то спрашивать можно только про метод save и findById, а остальное он знать не обязан, научите его сами?
Я буду говорить с джуном лишь после того, как он выполнит несложное тестовое задание. Задание должно прояснить навыки джуна в программировании и умение применить их используя наш технологический стек. Это - первый фильтр который отсеет людей не способных решать задачи.
На собеседовании я спрошу джуна, с какими задачами она сталкивалась и как их решала. Мы рассмотрим сделанное задание, обратим внимание на то, как написан код, есть ли тесты, как оформлен репозиторий и т.д. Обсудим технологии, книги, лекции.
Задача-то не в том, чтобы узнать как хорошо джун умеет обходить бинарное дерево. Задача в том, чтобы понять, как быстро окупятся (и окупятся ли вообще) вложения копании в обучение джуна. Не так важно, что джун сможет сделать в течении следующих пол-года. Гораздо важнее, что он сможет сделать и кем он будет в вашей компании через год, два, пять лет.
Я джун и не делаю тестовые. Мне его дали один раз и там нужно было написать целую игру. Я решил что это как-то не оч круто по отношению ко мне :)
Я бы сказал, что зависит от игры. Скажем если бы это были "крестики-нолики", "змейка" или "пинг-понг" - можно ли считать такое задание достаточным и не выходящем за рамки тестового?
Смотря что ожидается в результате. Реализовать двумерный массив с поочередным вводом позиций крестиков и ноликов и проверку правил после каждого ввода можно быстро. Но для пользователя это выглядеть может по разному, от консольной программы, которая считывает позиции крестиков и ноликов из stdin и выводит получившееся поле в виде текста, до полноценной игры с графикой, сделанной на Unity например
Там просили полноценную игру на графическом движке с обработкой коллизий объектов и тд
Гораздо важнее, что он сможет сделать и кем он будет в вашей компании через год, два, пять лет.
Что-то мне кажется, что большинство джунов поменяет работу в первый же год (дабы скакнуть на +500$).
Или если джуниор, то спрашивать можно только про метод save и findById, а остальное он знать не обязан, научите его сами?
Если джуниор, то остальное он может не знать не потому что он фиговый программист, а потому что еще об этом не узнал в силу небольшого времени получения опыта.
Если джуниор прочитал только первую главу книги, а дальше не стал читать, "и так сойдет", то из него ничего хорошего не выйдет.
Возможно. А как это связано с тем, что я сказал?
Потому что условно говоря методы методы save и findById это первая глава книги, а то, о чем я писал это середина, даже не приложение. В любой книжке по хибернейту подробно разжевывают все внутренности фреймворка, а книжка про спринг всегда содержит разъяснение того, как работает вся "магия" аннотаций.
И вот это "первоглавство" как раз часто характеризует выпускников курсов, которые сасм ничего не читали, а которым разжевали простейшие юзкейсы библиотеки/фреймворка.
подробно разжевывают все внутренности фреймворка, а книжка про спринг всегда содержит разъяснение того, как работает вся "магия" аннотаций.
Зачем джуниору подробное знание внутренностей фреймворка и принципы работы магии аннотаций? Если он хорошо в этом разбирается, значит сможет и сам такое написать, а если может сам написать фреймворк, то он уже не джуниор, а миддл. Умеет уверенно пользоваться, этого достаточно, остальное приходит с опытом.
А про что надо спрашивать джуниоров?
Что в универе на лабах делал, что сам писал, как это работает.
Вы это знание регулярно используете в своей работе? А зачем, если не секрет?
Вообще никак и компания, которая будет это спрашивать, сразу получит виртуальный -1 к карме.
Зачем спрашиваете то, что вообще не понимаете? Сфероид лишь аппроксимирует геоид для некоторой выбранной территории, но планета вовсе не является геоидом, геоидом является поверхность гравитационного поля, описывающая средний уровень моря. А вы своим вопросом приравняли форму планеты к некоторой математической абстракции одного из ее свойств (гравитационного поля). Имхо, этот вопрос на уровне вопроса "почему Земля плоская", притом кандидат ясно понимает, что возражения не принимаются.
Я много собеседовал джунов и подход был совсем другим.
Попросить описать "так, чтобы дурак понял" наиболее интересную задачу из тех, что он решал
Ковырнуть поглубже именно в той области, где он считает себя спецом.
Всегда исходил из того, что джун должен быть умным и готовым учиться. А знаний, нужных мне, у него априори нет.
Как будто бы есть какая то разница, где они хранятся.
Конечно есть. Важно же, на самом деле не где конкретно они хранятся, а что для обращения к ним не нужно ходить через указатель.
Хотя среди интервьюеров процветает карго-культ, когда задаются разумные вопросы (типа того же вопроса про устройство GC), но вместо вещей принципиальных (например про наличие нескольких поколений объектов и вытекающих из этого практических следствий) ударяются в умение цитировать спеки.
Как будто их зазубривание кому-то помогает в работе.
Прочитал. Офигел. И теперь такой офигевший и сижу.
Потому что, с одной стороны, присланные мне проблемы весьма реальны.
С другой стороны — найти по словосочетанию “row buffer” что-то имеющее отношение к описанным проблемам так же легко как по словам “вёсла”, “проливы” и “гребной винт” — что-то, имеющее отношение к высшему пилотажу.
Вот по ключевым словам starvation, cache coherency, false sharing и так далее — легко.
А row buffer… ну вот тут на картинке можете посмотреть что это такое и понять почему к быстродействию это всё не имеет ни малейшего отношения (а вот к безопасности — таки да).
А так-то да. “Троллить сеньоров”, рассказывая им, что они понятия не имеют о том, как летать на самолётах, потому мало чего знают о том, как течения влияют на морские грузоперевозки… ну, такое.
и можно мне тоже?
но не суть - просто про row буфер
Я про row buffer только в контексте RAM знаю.
Ведь там реально может производительность просесть в 100 раз при неудачном стечении обстоятельств
Если вы про row hammer, то это вообще не производительность, а про безопасность.
Или вы о чём-то другом вообще?
Частично согласен, в 9 случаях из 10 - это просто повод формально докопаться и не взять кандидата. Но, вроде как в том же Deutsche Bank практиковалось ручное насилие над GC, так что с их стороны вопрос про понимание what's under the hood вполне оправдано.
Ответ джуна - структуры в шарпе, будучи типом значения, хранятся по месту объявления. Если это переменные в методе, то в контексте метода на стеке вызовов. Если это поля класса, то вместе с классом в куче. А где они ещё могут храниться, если не там и не там? Мне правдо интересно, вдруг когда-нибудь спросят. Ещё можно заодно - всегда ли классы хранятся в куче?
Такие вопросы иногда задают. И, рас задают, хотелось бы быть способным на них ответить
>Такие вопросы ничего не решают. Вот пример - всегда ли параметры (рассматриваем параметр value type) с ключевым словом ref передаются в метод без копирования данных ?
Насколько я понял в вашем примере копирования при передаче ref параметра нет. Меня смущает два call в CalculateSalary, хотелось бы понять, что за процедуры вызываются. Возможно первый call это конструктор object. Последнии call, наверное, вызывает WriteLine(object), а vmovdqu используется чтобы сделать box для структуры на стеке.
Тут происходит передача фактических параметров — ничего интересного.
Нет, это присваивание свойств структуры.
Payment<long> payment = new Payment<long>()
{
amount = 1,
currencyId = 2,
...
};В этом коде вызывается конструктор без параметров, а потом выполняется инициализатор свойств, фактически просто присваивание по очереди. Ваш конструктор с параметрами тут не вызывается.
Это вызов метода CalculateTax():
lea rcx, [rsp+0x50]
call 0x00007ffcbcf90470Значит payment находится в rsp+0x50. Он занимает 40 байт (0x28).
Сначала инициализируется временная переменная со значением {1, 2, 3, 4, 5}, потом она копируется в payment, потом payment передается по ссылке.
Копирования при ref тут нет.
xor ecx, ecx
vxorps xmm0, xmm0, xmm0
// обнуление временной переменной
vmovdqu [rsp+0x28], xmm0
vmovdqu [rsp+0x38], xmm0
mov [rsp+0x48], rcx
// инициализация временной переменной
mov qword ptr [rsp+0x28], 1
mov qword ptr [rsp+0x30], 2
mov qword ptr [rsp+0x38], 3
mov qword ptr [rsp+0x40], 4
mov qword ptr [rsp+0x48], 5
// копирование 0x28 байт в payment
vmovdqu xmm0, [rsp+0x28]
vmovdqu [rsp+0x50], xmm0
vmovdqu xmm0, [rsp+0x38]
vmovdqu [rsp+0x60], xmm0
mov rcx, [rsp+0x48]
mov [rsp+0x70], rcx
cmp edx, 0x4bd // if ()
jne short L007f
lea rcx, [rsp+0x50] // ref payment
call 0x00007ffcbcf90470 // CalculateTax()Уже ответили, но могу подтвердить, что тут нет копирования ref параметра. Есть вызов конструктора и последующее копирование созданного объекта в переменную payment. Это выглядит странно, второе копирование не нужно. Но это все же не копирование ref параметра.
Edit: копирование вообще 3, сначала память на стеке запивается нулями, затем туда записываются свойства 1,2,3,4,5, затем все это копируется в переменную.
Думаю дело в способе инициализации структуры. В случае byref() компилятор догадался обьединить создание и присваивание, в CalculatePayment нет. Другая гипотеза - компилятор заинлайнил метод, увидел вызов WriteLine(object) и заранее создал box вне if.
Если вы про копирование через vmovdq после mov с константами, то возможно потому что в CalculatePayment() вызывается конструктор без параметров и инициализатор, а в BYREF() конструктор с параметрами. Представьте например, что в пустом конструкторе присваивается значение по умолчанию в еще одно свойство, которого нет в инициализаторе, тогда по-другому и не сделать. Тут конечно пустой конструктор ничего не делает, но возможно компилятор не настолько умный, чтобы отследить эквивалентность 2 этих ситуаций.
Насколько я понимаю, там 4 штуки потому, что mov не может перемещать из регистра в регистр.
Вам бы какую-нибудь книжку про то, как устроены компиляторы купить, что ли?
Последнее дело пытаться что-то обсуждать, глядя на ассемблерный код.
Вот, например, встречный вопрос: а где находятся объекты, размещённые с помощью malloc и освобождённые с помощью free? В куче, да?
Чёрта с два: они тоже могут вообще не существовать. Получите, распишитесь.
И Java так умеет. И C#. Это вообще не о размещении объектов, а о банальном as if правиле: компилятор может сделать с вашей программой и с вашими объектами и структурами что угодно, пока это невозможно заметить “снаружи” иначе, как с помощью дизассемблера.
Когда обсуждается вопрос “а где хранятся структуры (или не структуры)” всегда обсуждается семантика в рамках C-машины, C#-машины, Java-машины.
Нафига сюда тащить то, что к делу отношния не имеет?
P.S. А вообще я с подобными троллями на собеседованиях иногда сталкиваюсь. Отзыв обычно такой: “кандидат очень крутой, очень много знает, действительно вау… не брать ни в коем случае”. Потому что кроме умения решать те или иные задачи и чего-то там знать нужно ещё понимать: будет ли этот человек применять знания во благо или во вред. Ну и, как бы, после такого… вывод однозначен. Ещё троллей мне на работе не хватало.
Интересно к чему вы это спросили? У вас какая-то обида или презрение к этой компании?
У меня был опыт взаимодействия с ними. Ходил к ним в офис на бесплатные курсы по шарпу. От курсов максимально положительное впечатление - интересные задачи, в которых есть проект с каким-то каркасом и функционалом, в нём надо разобраться, дописать требуемое задание и прогнать через тесты. Собственно, я решил углубляться в шарп именно благодаря их курсам. На группу в 10 человек было 2 ментора, что как по мне очень хорошо, что бы можно было качетсвенно всех проревьюить.
Другое дело, что компания большая, у меня был опыт только в одном городе, одном офисе и всего с несколькими людьми. Я у них не работал, по зарплате ничего сказать не могу. Менторы, кстати, тоже там уже не работают, хотя проработали по 3-5 лет. И меня это удивляет, потому что я, наверное, впервые слышу что бы в компании была токсичность. Вы говорите про выпускников Иннополиса. Может быть дело в том, что офис был далеко от Иннополиса и Казани
Тоесть Конрада Кокосу вы бы тоже не взяли, а то мы с ним обсуждали данный момент
Если бы Конрад начал чушь пороть про то, где структуры хранятся и мешать в одну кучу C#-машину из спеков и реальный компилиятор? Нет, не взяли бы.
Но вот чегой-то я сомневаюсь, что он бы начал всё рассказывать в таком тоне.
Люди, которые, с упорством, достойным лучшего применения, рассказывают про то, что про математику спрашивать не нужно, про деревья спрашивать не нужно, просить писать программу — да как вы смеете и так далее, почему-то не задумываются, что ваше отношение ведь видно и в обсуждении любых других, чисто технических вопросов.
Условно:
Кстати в большинстве случаев собеседующие сами не знают корректного ответа, так как структура может хранится и не в куче и не на стеке
“Умён… крут… не брать”
Да, структура хранится в стеке, а обычные объекты — в куче, но так как любые абстракции протекают, то в случае реального компилятора всё может быть не совсем так… а давайте об этом поговорим поподробнее…
И, скорее всего: “умён… крут… брать”.
Видите разницу?
В одну строку. Очень просто, если работать не в контуре и знать как ValueType'ы могут передаваться в методы, конечно же.
Да-да. Это — самый лучший способ быстро и надёжно получить отказ. Когда интервьюеруемый, внезапно, забывает, кто тут кому работу предлагает… вывод быстро становится очевидным.
Самый феереичный пример у нас был, когда кандидату, который ответил на все вопросы все пять интервьюеров выставили оценку “не брать”. Вот именно за это.
И да, продолжайте в том же духе: это очень облегчит мне мою работу по отсеву неадекватов.
P.S. И да, подобные эффекты иногда можно и пообсуждать, почему нет. Но, как правило, не на собеседовании и уж точно не когда интервьеруемый считает, что это ему кто-то там чем-то обязан, а не наоборот.
Вам бы какую-нибудь книжку про то, как устроены компиляторы купить, что ли?
Какой вы горячий, право слово. Очень не рекомендую в реальной жизни так начинать общение с незнакомыми людьми.
@xJAYx Я не силен в C#, но из любопытства был бы рад, если бы вы разжевали мне свое утверждение. Вы сказали, что структура может храниться и не в куче и не на стеке, а где тогда?
Какие зажравшиеся империалисты. Видел кучу претендентов на мидла в РФ, которые не могут рассказать чем кластерный от не кластерного индекса отличаются.
К сожалению, у меня есть опыт собеседований только с бывшими "империалистами" :)
Не смотря на это, надеюсь, что моя информация кому-нибудь пригодится.
Понятия не имею (теперь имею), чем они отличаются, но вполне успешно работаю. Что лишний раз подтверждает, что вопросы на собеседованиях абсолютно случайны и отражают интересы спрашивающего. Причём, когда прям уже надо кого-то нанять, внезапно оказывается, что вот такие вещи можно и не знать, и реально важно совершенно другое.
Я посмотрел "пример собеседования" - за 15 минут до вашего таймстампа.
Это получается, что человек, который пишет статьи на Хабре "что в IT неправильно и как нам IT обустроить" - просто некомпетентен в базовых вопросах. Жесть.
ПС
Вопрос про "мьютекс-семафор" - ок не его стек.
Но вопрос про HashCode - всё-таки вопрос из +/- его стека. Плюс когда он даёт ответ (неверный) он просто говорит "самый вероятный сценарий вытекающий из его занний" и не валидирует его "к каким последствиям приведёт решение, сделанное так, как я сказал".
В общем ужас. Одни разбираются в IT. Другие пишут: что же такое IT на самом деле ((
Самое смешное, что такие "интервьюеры" могут вас вообще ничего про SQL не спросить. Ну или попросить про REST рассказать в двух словах. Ну вообще прощупать диапазон кандидата. Они так зациклины на алгоритмических задач, что по большому счёту под конец собеседование про кандидата так ничего и не узнали!
И мне вот непонятно. Задача узнать способности кандидата, понять как он в команду вписывается. Это круто, когда кандидат знает и мютексы и несколько ORM, да еще и хороший алгоритмист. А надо это в работе?
Как при найме водителей
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми
автомобилями, троллейбусами, трамваями, поездами метрополитена и
фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном
ходу, боевыми машинами пехоты и современными легкими/средними танками,
находящимисяна вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны. Опыт управления
болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и
роторных двигателей, автоматических и ручных трансмиссий, систем
зажигания, антиблокировочных систем, навигационных систем и
автомобильных аудиосистем ведущих поизводителей — обязательны. Опыт
проведения кузовных и окрасочных работ — приветствуется. Претенденты
должны иметь сертификаты Mercedes, BMW, а также справки об участии в
крупных международных ралли не более чем двухлетней давности.
Зарплата: испытательный срок 1-3 месяца, зарплата по результатам собеседования.
(с) когда-то с хабра, но оригинальный permalink оказался не очень persistent
Беседовал я с сеньором всех сеньоров
Крутой титул ) по средневековым европейским обычаям он был бы не сеньор над джунами и мидлами)
В целом да, иногда слишком упарываются в литкод или какие-то тонкие и малопрактичные вопросы. Чувство меры - не то свойство, которое присуще только лишь всем.
Задача про [-100....100] вроде несложная - пройтись по массиву, составить карту (S, C), где S - сумма подмассива от 0 до i (только отрицательные), C - количество таких сумм. Потом снова пройтись, и для каждой суммы S (которая больше 0) подмассива от 0 до i добавить в результат количество для -S. Для нулевых сумм S, если такие будут, просто добавить в копилку C(C+1)/2
Задачка действительно несложная, но только для того, кто какое-то количество таких задачек прорешал. То есть, внезапно, джуна после колледжа.
А учиться сейчас народ не очень любит, хотят пройти курсы “как научиться проходить собеседование в FAANG” за 21 день и после этого устроиться на работу на зарплату в верхних 10%.
Некоторым, кстати, удаётся вполне себе проскочить, но тут надо даже не столько круто готовится, сколько сходить на сотню-другую собеседований, авось где-то да проскочишь.
Какие-то у вас завышенные ожидания для студента колледжа. Там такому просто не учат. В лучше случае студенту дадут графы и алгоритмы сортировки. И это в вузе.
В лучшем случае студенту дадут графы и алгоритмы сортировки. И это в вузе.
Это "средний" случай. А в лучшем случае вузовская программа выглядит примерно так
Мне кажется что ещё проще первым проходом записать интегральную сумму в каждую позицию ( сумма всех элементов до данной позиции) а потом подсчитать количество одинаковых чисел через хеш мап. Получится О(n)
интегральную сумму в каждую позицию ( сумма всех элементов до данной позиции) а потом подсчитать количество одинаковых чисел через хеш мап.
это и есть "карта (S, C)" из моего коммента.
Вообще то не совсем одно и тоже ( я предлагаю сразу складывать все подряд, без разницы положительные или отрицательные) но это не принципиально. Лень спорить.
Это классический метод нахождения частичных сумм из интеграла. На картинках даёт большой выигрыш в скорости (integral image)
Что-то я там с положительными и отрицательными протупил. Всё действительно проще, за один обход.
код
var subarraySum = function(nums, k) {
const map = new Map();
let result = 0;
for (let i = 0, sum = 0; i < nums.length; ++i) {
sum += nums[i];
const countSum = map.get(sum) || 0;
const countSumMinusK = map.get(sum - k) || 0;
map.set(sum, countSum + 1);
result += countSumMinusK;
}
return result + (map.get(k) || 0);
};
Не очень понятно, что за параметр К. И ещё я не очень уверен, но мне кажется подсчет интегральных сумм не будет работать, так как для вот такого массива [0, 0, 0] ответ должен быть 6:
[0][0][0][0, 0][0, 0][0,0,0]
ну или по индексам элементов:
[0][1][2][3][1,2][2,3][0,1,2]
Так как в условии ничего не говорится про уникальности или непересекаемость
Заранее извиняюсь, но в алгоритмах я крайне плох, поэтому пытаюсь разобраться в любом, который попадается на пути
Налажал с индексами [0][1][2][0,1][1,2][0,1,2]
Параметр K - это для более общей задачи, выше в комментах на неё кидали ссылку: сколько найдется подмассивов, сумма которых равна K. В нашем случае K = 0.
Функцию можно проверить в консоли браузера. Для вашего примера, subarraySum([0, 0, 0], 0) вернет 6
Да, я бы тоже делал именно так.
Если бы! Я подавался в компании следующих направлений:
видеонаблюдение и безопасность;
инвестиционные компании, банки и quantitative trading;
разработка приближённая к железу (OpenCL и Embedded C);
машинное обучение и data science (здесь Вы, пожалуй, правы).
CV отправлял как напрямую, так и через рекрутеров. Везде отношение ко мне было аналогичным описанному выше.
Странно, в росийских вакансиях цифр 10 лет опыта можно редко найти. Даже обидно, присылает в линкедине очередной hr вакансию, опыт требуется от 3 лет. А если 15 лет опыта - то что? Что я вообще делаю в разработке, почему я не менеджер-лид-директор департамента?
И второе, про СДиА. Забавно получается, вы удивляетесь, как это у джуна, недавно выпущенного из вуза, можно такое спрашивать. А сеньоры на собеседование говорят, что уже всё забыли, эту вашу математику не нужную. Кто тогда её помнит?)
Очень интересно, а какой правильный ответ на вопрос "«как быть, если ваш коллега — аутист»"?
Я вижу два:
- "I will give it detailed answer if it will ask me" — максимально лояльный.
- "I will ignore it because talking to special people is dangerous" — максимально честный.
в последнее время, благодаря HackerRank и LeetCode, любители "почесать ЧСВ" на интервью получили новый мощный стимул.
Это, кстати, про кого? Про кандидатов, или собеседующих?
Мой поинт: почесать чсв можно, только если ты кандидат. Затащить, отвечая на сложные вопросы, особенно если ответы или решения более крутые, чем предполагалось. А собеседующий, при взгляде со стороны, - просто "чувак с домашними заготовками". Даже если он закидает соискателя этими заготовками аки камнями, всё равно это не триумф его разума.
Во первых, с 2 годами опыта уже не принято записывать себя в джуны.
Во вторых, это не только для джунов, это на всех уровнях.
Вот позавчера было у меня собеседование с Майкрософт в Сиэттле. Опыта 10+ лет.
Решил на Leetcode порядка 400 задач средней и высокой сложности на протяжении последних 3 лет.
Было 4 разных алогритмические задачи. Я не прошел, потому что собеседующий (русский эмигрант оказавшийся кстати) решил проверить как я за 15 минут напишу функцию Eval для арифметических выражений, да еще перебирающая все варианты как будто приоритет операций не известен. Я расказал принцип, но писать даже и не собирался начинать.
Нас спрашивают алгоритмические головоломки и если бы работа состояла бы из них я бы был бы только рад. Ведь какая красота иметь мозг не над системой с миллионом строк кода с большой и сложной структурой данных, которую местами не протестируешь не проведя major refactoring, куча мест где нет документации и те люди которые девелопили это уже не работают там, система которая отваливается когда нагрузка чуть больше чем когда провели нагрузочное тестирование, memory leaks то тут то там.
Я бы с удовольствием предпочел решать вот такие задачи какие они дают на собеседованиях, а не с тем что в реальности мне приходится сталкиваться.
Знания и скиллы чтобы пройти собеседования и выполнять работу настолько различаются, что это требуется отдельная и различная подготовка к каждому.
Раньше был тренд еще спрашивать об участии в каком нибудь опенсорс проекте и твоем программировании после работы. Это какой-то просто маразм ожидать например от бухгалтера, что вот после работы она как хобби берет заниматься учетом финансами своих друзей или какого то другого может быть вымышленного предприятия. Или от врача практикующем вырезание аппендицита как хобби в свободное время. Но это норма в нашей индустрии, из-за скорее всего психотипа людей работающей в нашей области. Многие не имеют жизни вне IT и настолько бесхребетные, что готовы тратить сутки/недели просто на то чтобы твою кандидатуру рассмотрели при приеме на работу. Есть ли какие то другие сферы с подобными практиками? И мы не говорим о первой работе, а вообще для всех.
"Или от врача практикующем вырезание аппендицита как хобби в свободное время. " У хирургов, особенно молодых, обычно все свободное время быстро превращается в ту же работу - дежурства, консультации и тп. Тот, кто скажет что отработав 50 часов с понедельника по пятницу едет на рыбалку с друзьями вызовет недоверие приверженности профессии.
Раньше был тренд еще спрашивать об участии в каком нибудь опенсорс проекте и твоем программировании после работы.
Раньше — это когда? Я много раз слышал об этом в стиле “одна бабка сказала, что так делают”, но никогда не видел этого воочью.
Ну разве что у совсем “зелёного” кандидата, у которого в CV вообще ни одного места работы и институт какой-то непонятный, так что уж совсем нет никаких сигналов об адекватности.
Забавно, кстати, что предложения о том, чтобы такое поспрашивать скорее исходят от самих кандидатов. Типа это полезнее, чем деревья обходить.
Да собственно вот тут же, в очередной раз нам рассказывают о GitHub, о том, чтобы вы код показали и так далее — как о правильном способе отбора кандидатов.
Тот факт, что огромный процент хороших кандидатов связаны NDA и никакого кода вам показать не смогут (а индусы, наоборот, покажут вам код написанный, хорошим знакомым и набросают вам кучу лапши на уши) — не учитывается совершенно.
Было 4 разных алогритмические задачи. Я не прошел, потому что собеседующий (русский эмигрант оказавшийся кстати) решил проверить как я за 15 минут напишу функцию Eval для арифметических выражений, да еще перебирающая все варианты как будто приоритет операций не известен. Я расказал принцип, но писать даже и не собирался начинать.
Это вам так сказали, что вы из-за этого не прошли? Вообще странно: я не думал, что в Microsoft разрешено кандидатам такие вещи говорить. Хотя если от них начали требовать писать официальную причину отказа, то могли и так написать, возможно.
Вообще поражает вот именно эта уверенность кандидатов в том, что их “отсеивают” из-за того, что они чего-то там не сделали, какую-то задачу не решили.
Ну не “отсеивают” за это! Разве что в совершенно диком, паталогическом, случае, когда вы не решили вообще ни одной задачи и не ответили ни на один вопрос.
А вот за “кривляния” (в духе @xJAYx ) — “отсеивают” легко. Потому что, внезапно, если вы устраиваетесь в компанию, то людям интересно, чтобы вы делали то, что нужно компании, а не то, что интересно вам.
Помните Джоела? Умный человек, способный решать проблемы — вот именно это то, чего хотят увидеть. Только Джоел важное слово пропустил (хотя из последующего текста видно, что он его подразумевал): нужен не просто умный человек, способный решать проблемы, но умный человек, способный решать поставленные перед ним проблемы (а не те, которые захочется).
И “отсеивают” вас не за то, что вы чего-то там не знаете, а за то, что вы “на блох” переехать пытаетесь. Вот если бы у рыбы была шерсть, то в ней были бы блохи… — вот это вот то, чего категорически не хочет видеть интервьюер.
Он хочет увидеть как вы будете решать вот конкретно эту, конкретно данную вам данную, проблему (а не что-то ещё). И самая ужасное, что вы можете сделать — это, вместо того, чтобы решать ту проблему, которую вам дали, попытаться как-то “переехать” на ту тему, которая вам знакома.
Я бы с удовольствием предпочел решать вот такие задачи какие они дают на
собеседованиях, а не с тем что в реальности мне приходится
сталкиваться.
Ну дык интервьюер тоже так же, резонно, считает. Вам дали простую проблему, а “в позу” становитесь.
И да, интервьер, если у него есть опыт, прекрасно знает, что некоторые простые проблемы для каких-то людей оказываются сложными. Это не страшно. Всегда можно дать вместо 15 минут на задачу 30. Или, наоборот, увидеть, что и за 30 минут ничего не решится и попросить решить что-нибудь другое.
И даже если вас реально отсеяли из-за той задачи с приоритетами, то не за то, что вы её не решили, а за то что, что посчитали себя “имеющим право решать” — стоит там код писать или нет.
Вы, ёлки ж палки, посмотрите с другой стороны: человека ещё не только не взяли на работу, он ещё даже собеседование не прошёл — и он уже присвоил себе право решать: нужно ту или иную работу делать или нет. А что потом будет? Когда и если его таки на работу возьмут?
Это вам так сказали, что вы из-за этого не прошли?
А мне нужно на каждую очевидную вещь официальное письмо с подписью?
а за то что, что посчитали себя “имеющим право решать” — стоит там код писать или нет.
я сказал прямо что я не успею за оставшееся время, особенно когда на коленке в блокноте такое писать. Вы видели решение? Я видел в более простой вариации. За 15-20 минут можно писать если ты выучил наизусть до этого.
И да, там было 3 задачи другие, которые я сделать корректно успел.
Похоже на этом интервью вы явно были, а не я. Так как явно лучше знаете что там было .
Похоже на этом интервью вы явно были, а не я. Так как явно лучше знаете что там было .
На этом интервью меня, конечно, не было, зато я был на нескольких сотнях других интервью.
И очень хорошо запомнил урок, преподанный одной снежинкой.
Которой я прямо сказал, почему я не могу эту нежную душу (с уровнем знаний о программировании примерно как после прочтений одной клавы в книге “как изучить Java за 21 деньс и, буквально, без представления о разнице между if и while) рекомендовать.
Ну есть же какой-то предел, после которой абсолютно безнадёжному кандитату можно прямо сказать, что он безнадёжен?
Оказалось нет: получил жалобу рекрутеру, где объяснилось, какой я гад, нехроший, какую душевную травму нанёс и что если бы не я, то ей бы предложили работу.
Далее — изрядный втык, разбор полётов и спасло меня только то, что я был единственным, кто рекомендовал через годик позволить проинтервьюироваться ещё раз.
Остальные (которые успешно создали, по итогу, впечатление, что собеседование пройдено отлично, можно было бы готовить документы, если бы не злой я) были куда как более категоричны и большинство рекомендовали сделать отметку в базе, чтобы в будущем время не тратить на безнадёжную кандидатуру.
Потому в вашем случае (если бы это было бы можно проверить) зная о том, что кандидат, который, как вы считаете, вас завалил — русский эмигрант, я бы поставил хорошие деньги на то, что он написал если не лучший о вас отзыв, то близкий к лучшему.
А наихудший отзыв вы, почти наверняка, получили от американца, который лучился счастьем и говорил, что вы поражаете его своими знаниями.
Ну не умеют русские так! Сначала изображать “искреннее восхищение”, а потом повернуться и написать рекомендацию в течении пяти лет даже не приглашать вас на интервью.
А мне нужно на каждую очевидную вещь официальное письмо с подписью?
Нет, не нужно, но тут нет “очевидных вещей”.
Русских не учат в школе, в течении десяти с лишним лет, что главное — чтобы, не дай бог, “творческая натура“ не ощутила себя обиженной и не потеряла веру в себя (а для того, чтобы её не взяли в команду, не рекомендовали в сильный класс, не приняли на работу и так далее есть объективная оценка, которая “творческой натуре“ никогда и ни при каких условиях не сообщается).
Американце учат и они умеют это делать в совершенстве.
Потому из вашего описания истории я и делаю совсем-совсем другой вывод, чем вы.
Даже отказ можно оформить вежливо без фальши. Многие выходцы из нашей культурной среды не понимают, что со стороны то, что они воспринимают как прямоту и честность, для людей иной культуры выглядит как наезд и хамство с переходом на личность.
И очень хорошо запомнил урок, преподанный одной снежинкой.
Которой я прямо сказал, почему я не могу эту нежную душу рекомендовать.
Далее — изрядный втык, разбор полётов
По этой логике кандидат имеет полное право дать вам по морде в случае отказа. Ну а что, вы же не снежинка, потерпите. Вы считаете, что кандидат должен не возникать если вы сделали что-то неприятное для него (причем такое, что дошло до разбора полетов с руководством), значит и вы не должны возникать, если он сделает что-то неприятное для вас.
В контексте приема на работу нет терминов типа "нежная душа" и "безнадёжен", или тех, из-за которых у вас произошел разбор полетов, поэтому их использование это исключительно следствие ваших моральных качеств, а не знаний кандидата, как бы вам ни хотелось верить в обратное.
Причем можно сказать, что вы из этой ситуации извлекли не тот урок, который нужно, а потому обучаемость у вас никакая. Ситуация, когда у кандидата недостаточно знаний, обозначается термином "недостаточно знаний". Если после описанного случая вы это не поняли, может быть вы… безнадёжны?
чтобы, не дай бог, “творческая натура“ не ощутила себя обиженной и не потеряла веру в себя
Может оно и к лучшему, а? Типа, опасение потерять даже один талант из тысячи, даже если он выглядит совсем не как талант? Ну разве нормальный человек назовёт серьёзную фирму Яблоком, а современный компьютер Плащом? А тут, глядишь ты, компы/смартфоны по всему миру и мощный пинок всей индустрии в правильную сторону.
А если б его тюкали всю дорогу "правдой" о нём, может и не стал бы рыпаться, а просидел бы как все - куда взяли или куда родители пристроили. М?
А в вашей компании нет правила, что даже если кандидат полностью провалился, то у него всё равно надо оставить о компании, интервьюере и процессе хорошее впечатление? Потому что он может через несколько лет подкачаться, а прямо сегодня у него могут быть толковые друзья, которых не стоит отпугивать.
присвоил себе право решать: нужно ту или иную работу делать или нет
Удивительно, но до 30% времени на любой работе у меня и моих коллег уходит именно на это
Во первых, с 2 годами опыта уже не принято записывать себя в джуны.
Вот кстати, меня тоже этот момент удивил. А на какую позицию автор собеседовался? Точнее, так: на какую он рассчитывал, и какую квалификацию ждали собеседуюшие?
Двухлетний опыт в моем представлении предполагает позицию мидла. Если джун за полгода не вырос до следующего ранга — это повод поинтересоваться почему. И если придет на интервью человек я работал 2 года на аналогичной должности — собеседовать лично я его буду на мидла. Просто из-за своего когнитивного искажения, из-за ожидания что человек за два года дорос до этого уровня.
А на какую позицию автор собеседовался?
На позиции уровня Junior Developer. На Linkedin, например, об этом часто пишут прямо в вакансии.
Двухлетний опыт в моем представлении предполагает позицию мидла.
На мидла я тоже отсылал резюме, но на интервью почему-то не звали.
... какую квалификацию ждали собеседуюшие?
Сложно сказать. Как уже отметили в комментариях, причины отказа не обязательно связаны с задачками. Здесь мы скорее упираемся в посредственное отношение нанимателей к джунам в целом.
Прошу прощения за любопытство. Если возможно конечно, не расскажете пожалуйста про опыт эмиграции в США? очень интересно узнать судьбу русскоязычных программистов которые там работают (и какие области программирования там более востребованы)
Я знал одного кренделя, который когда набирал людей себе в отдел первым вопросом спрашивал - знаете ли вы формулу Тейлора, а вторым вопросом - можете ли доказать её. Вот так вот, на собеседовании, у доски или на бумажке доказать формулу Тейлора...
Наверное вы подумали, что он набирал людей для каких то сложных околонаучных задач? Нет, так он набирал себе людей в команду тестировщиков мануальщиков. Шах и мат, погромисты.
Я наверное не очень удачно выразился. Шах и мат означает не то, что тестировщики мануальщики всех круче, это я так пытался выразить то, что считаю ситуацию совершенно абсурдной.
Я так спросил у HR - зачем они дают тестировщикам задачку на знания C?
HR ответила мне - их придёт 100, нам надо как-то их отобрать.
Ну, знания языка English - отсеит 50.
Задачка на логику - отсеит 30. Останется 20. - А нам надо взять 10 на курсы то!
Вот как выбрать этих 10? - просто взять каждого второго?
Вот и придумываем хоть что-то чтобы выбрать 10 то - ибо в общем-то они почти все ребята то одинаковые.
Ну и много набрал?
Как то он умудрялся набирать. Человека 3 в его отделе было. Видимо нашлись такие ботаны, которые хорошо помнили вузовскую программу матана. Вот чем он их подкупил я не знаю. Наверное возможностью работать на штаты с призрачными шансами что там тебя заметят и пригласят к себе (такие случаи у нас редко, но бывали - меня например пригласили и я даже поехал, но закрепиться там к сожалению не смог)
Оказывается синдром вахтера можно экстраполировать
Всегда поражали вопросы на собеседованиях про сборщик мусора, или подсчёт ссылок. Обычно идёт первым в списке. Более бесполезного знания на боевых проектых сложно представить
ЕМНИП, про сборщик мусора учат например в УЦ ЭПАМа — выпускники УЦ идут работать джунами.
- Мне поэтому неудивительно, что об этом спрашивают на собеседованиях: ведь это есть в программах обучения (понятно, что не везде — но ведь не везде и спрашивают).
- Раз этому уделяют время на учебе, значит считают что это важно знать. Конкретную мотивацию ЭПАМа не знаю, но рискну предположить что это одна из базовых вещей (наряду с идеями ООП), без которых более сложные концепции становятся непонятными.
Более бесполезного знания на боевых проектых сложно представить
А как вы объясните джуну, что складывать строки в цикле — это плохо, и как будете настраивать параметры GC, если не знаете про сборщик мусора?
А как вы объясните джуну, что складывать строки в цикле — это плохо
А как знание GC поможет ответить на вопрос про иммутабельность строк? GC там будет много работать уже как следствие
ок, значит придется рассказать и про иммутабельность строк, и про GC.
Без истории про GC совсем неочевидно, когда это плохо, а когда — пойдет, нельзя понять почему тормозит локально, а на проде — нет, но случаются завалы иногда система зависает, и кучу других нюансов.
Опять же, я не шарпист, и тем более не учу писать на нем. Но раз об этом рассказывают в курсе люди с продуктовым опытом и посвящены главы в книгах — значит они считают что это достаточно важно.
А как вы объясните джуну, что складывать строки в цикле — это плохо
Как ни странно, так и объяснять — в C# объекты можно создавать и не удалять, потому что есть такая штука сборщик мусора, которая их удаляет потом, а когда строки складываются в цикле, на каждую новую строку создается отдельный объект, что потом создает лишнюю нагрузку при их удалении, поэтому складывать строки в цикле это плохо. В таком объяснении нет совершенно ничего сложного.
И, что интересно, это объяснение не совсем верное. Основная причина, что строки нельзя складывать — это асимптотика, не а GC memory pressure.
А вот такое в Сишарп не завезли?
после УЦ trainee -> junior -> middle ... сразу джуна в большинстве аутсорсинговых компаниях не дают
Глупо, конечно. Это ведь то самое overqualified. Другое дело, что у больших компаний денег много, и они об этом не задумываются.
На собеседовании вы (компании) изображаете из себя по меньшей мере Илона Маска, ракеты в космос запускаете, ищете лучшего из лучших. Но что вы будете делать, когда найдёте такого ниндзю среди программистов - об этом хоть кто-то думает? Человек, который спокойно проходит подобные интервью, начинает работать и видит, что задания по сложности "пятиклассник справится", и, соответственно, интерес от этих заданий на том же уровне. Что он будет делать? Я вижу два основных варианта:
Поплюёт в потолок месяц-другой. Походит по интервью в это время, поищет более адекватную своим скилам компанию. А потом с этой свалит. А вы, как работодатель, потратите на него время (эти два месяца), деньги, и в ответ не получите ничего. Такое вот своеобразное "наказание" за обман на собеседовании.
Начнёт всё усложнять. У человека квалификация ракеты строить, вы его наняли как строителя ракет, а потом даёте задание бумажный самолётик сложить. Чтобы работать было интересно и были вызовы, он начнёт вредить бизнесу. Например, если весь бекенд можно запустить на калькуляторе за сто рублей, он будет проектировать крутую облачную архитектуру, с отказоустойчивостью и прочими докерами, которая будет стоить миллион баксов в месяц, и по факту нафиг не нужна.
Обычно уходить через пару месяцев не принято, резюме портит такая строчка, так что большинство выбирает именно второй вариант. Постоянно такое вижу.
А всё почему? Потому что выпендриться хотят. Если ты не гугл - не отбирай людей так, как это делает гугл. Если всего делов - сделать очередной сайт на популярном фреймворке, не нужно искать тех, кто деревья в уме вращают. Спрашивать про деревья и внутренности языка нужно тем, кто разрабатывает, например, базу данных, операционную систему, или, к примеру, занимается высокочастотной торговлей. То есть там, где человек, обладающий этими навыками, сможет их использовать в повседневной работе, а не там, где он будет скучать, и от скуки придумывать себе интересные занятия.
Есть ещё третий вариант: насчёт всё оптимизировать, потому что ему скучно.
Спокойно пишу код. Спокойно обкладываю тестами. После работы у меня есть достаточно сил а главное желания заниматься чем-то еще. С этим были проблемы на выжимающих работах, когда пишешь код на пределе возможностей то дома на что-то требующие еще мозговых усилий меня уже хватало.
Это вам очень сильно повезло. Потому что обычно эта самая ситуация идёт в варианте "в поте лица продолжаем катить продукт на квадратных колесах", а то еще и скатываясь в овертайм. Разумеется, любая попытка заменить колеса на круглые — встречает сильное сопротивление, и так некогда, а тут еще дивные новые предложения.
И причем в приложении к джунам — более хороших выходов из такого процесса обычно нет, это человек с длинным послужным списком еще (иногда) может чисто на авторитете смочь протащить в проект скругление колес. А ценных советов джуна обычно никто слушать не хочет.
Ещё хуже, когда сеньоров собеседуют так же.
И такое бывает.
Ну, не знаю, не знаю. Ваше сочинение как то слабо корелирует с моим опытом. Прям так и хочется возопить "не верю"... Так то: не верю, что качества джуна не выяснят без всяких тестов за пару минут. Даже не нужны разговоры про какие то никому сортировки или натягивание женского органа на уши с доступом по хэшу. Разве что этим "специалистам" заняться нечем, кроме как людям голову дурить. Гыыы. Вы пришли собеседоваться C# кодером? Зачем мне скользящее окно от джуна, пусть лучше он мне объяснит что такое есть фрэймворк и чем он отличается от библиотеки. Или что такое пространство имен, ну и т.п. Вот такие пустячки на понимание - вполне достаточно. Нахрена мне кодер C# который не понимает что есть фрэймворк, но знает как обойти в дереве листья. Мда... И для работы будет гораздо более полезно, если любого уровня программер сможет просто сделать грамотную декомпозицию и будет уметь думать абстракциями архитектуры, чем самоудовлетворяться пытаясь шаблонизировать грядущее собеседование, пытаясь угадать возможные вопросы. По этому - не верю.
Знаете вы или нет, но в подавляющем большинстве случае, проработав программером пол жизни, профессионалы так ни разу и не сталкиваются с необходимостью создавать свою хэш функцию, не говоря уже о реализациях алгоритмов по разрешению коллизий. 85% рынка это вообще сплошной WEB - фронт, бэк, БД - и я вас заверяю, что там о таких вещах обычно и не вспоминают, хотя исполюзуют постоянно не зная что это такое. Тот же алгоритм работы браузеров наверное совокупность кучи хеш функций гыыыы)))))))) По этому - не верю.
И много еще во что не верю. А верю вот во что:
Из моего богатого опыта собеседований я почерпнул, что в большинстве случаев твои профессиональные кондиции очень часто не слишком то влияют на результаты собеседования. Вот ты пришел на собес. Весь такой профессионал-профессионал, ума палата, нафарширован скилами под брови, прям сочишься благодатью. Любой кто тебя видит сразу понимает - ты надежда и опора ИТ индустрии. А там на собесе тебя встречает местный кадр на две головы ниже тебя и... И он быстренько просекает, что ты - его финансовая смерть в этой фирме, и ты, весь такой из себя Брюс Ли программирования, валишь мимо кассы. Как то так.
Да и вааще. Нужно бы помнить, что основная масса народа вас собеседующего - лохи. Просто лохи, которые силою обстоятельств оказались на месте собеседующего. И все. Что делает лох в случае нестандартной задачи, например необходимости проводить собеседование? Правильно. Он лезет в инет и пишет "гугл помоги". И скармливает вам первое, что Гугл (Бог) подаст. Вот и все. Редко встречаются истинно знающие люди, и вот они как раз не станут изголяться. Во первых им не интересно, ибо они решают проблему кадров, а не ищут реализатора алгоритма быстрой сортировки. Разницу чувствуете? А во вторых на глупости нет времени. Жизнь конечна.
А клоунов хватает.
Встречал такое. Теплое место. Белая ЗП. Должность Ведущего. А у руководства свои планы. Новое направление, новый проект. Тогда они ищут лоха, потому как первопроходцами быть не хотят.
Нет. Просто я уже достаточно не молод для отрасли и порядком подустал от многого. Я пятидесятилетний глупый программист с устаревшими понятиями и знаниями 20-30 летней давности. Что я там могу понимать - сущую безделицу. Какое нибудь говно, вроде того как работает весь этот железный фуфел, и в сравнении с тобою я устаревшая модель. Меня скоро просто спишут в утиль. Поэтому мне приходится конкурировать за место под солнцем. А ты царь горы и конечно же ничего не слышал о конкуренции, ибо стоишь на несравненно более высоком профессиональном уровне, чем все потенциальные претенденты на твою должность и знания твои впечатляющи. Ты шутя выдержишь любое сравнение. Твоя фамилие случаем не Гейтс? Нет, вроде RDO это технология принадлежащая Гейтсу. Или у тебя включен Режим Бога? Ну да ладно, мне в принципе пополам. Живи себе в своей параллельной реальности,ник RDO . Remte Data Object. Написал пару join-ов и считаешь, что тебе нечего волноваться о своей мягкой подушечке не кресле? Это вряд ли парень. Бритва Оккама слышал? Так вот, эта самая бритва скажет тебе (если ты снизойдешь что бы ее услышать), что скорее всего ты просто сидишь на никому не интересном месте, поэтому тебе никто на пятки никогда не наступал. Вот только если ты сидишь на таком не интересном месте, это не значит, что жизнь изменила свои принцыпы.
Предлагаю вопрос для обсуждающих:
"Что нужно экономить при разработке ПО время разработчиков или время конечных пользователей?"
Предлагаю высказать желающим с обоснованием. Вообще вопрос имеет косвенное отношение к подбору разработчиков и вообще индустрии разработки.
Все просто, вы для них слишком дорогой. те умный где то промелькнула что для вас мало 40 к, так это им и нужно было. От этого мнения и надо плясать. И второе, вы им не понравились. Новичков ведь всегда видно. И тех кто знает себе цену. А всякие там несуразные дополнительные вопросы, лишь легализация возможного отказа соискателю
Вопрос подборки джунов в компанию на вырост в миддла или сеньёра, достаточно прост и тривиален и содержит 3 этапа.
Первый - оценить социальную аддекватность - 5 - 10 минут разговоров о себе, о компании, о том о сём.
Второй - беседа о компетенциях вакансии и более общая профессиональная компетенция - 30 минут максимум.
Третий - тестовое задание.
Если человек адекватен, если он разбирается хотя бы в одном сложном вопросе, ВАЖНО - не во всех, а хотя бы в одном, то это уже показывает что человек сможет разобраться и в остальных нужных для данной вакансии.
Ну, если человек написал тестовое - можно брать.
Понятно что компания может выбирать из кандидатов, тех кто белее компетентен или тех кто достаточно компетентен, но более симпатичен руководству и тому подобное.
Так же считаю что у любого нового сотрудника в порядочной фирме должен быть куратор на период месяц - другой, что бы ввести в курс дела, так как подходы к процессу в разных фирмах могут очень отличаться.
Много же лет говорят, что программисту не обязательно знать, но обязательно уметь искать решение. Зачем вообще спрашивать новичка по памяти всякие нюансовые штуки выше уровня вузовской программы? Можно просто попросить найти решение в интернете за ограниченое время и объяснить. Найдёт одно, найдёт и второе. Главное, чтоб был обучаем и самообучаем. А к нюансам придут уже на рабочем месте от старших товарищей или сам, в процессе. Или бы если соискатель бы заходил как стажер "без опыта" его бы не гоняли так?
Потому что современное айти уже достаточно плотно насыщенно специалистами (и не только). Сейчас уже ищут не специалиста который бы тупо делал своё дело, сейчас уже придирчиво выбирают из толпы набежавших. Прошли времена когда собес был конструктивным диалогом на равных. Сейчас работодатель это принцесса, а кандидат это лошадь на базаре.
Если бы оно было насыщено специалистами, то не было бы у джунов настолько высоких зарплат. И да, в случае специалистов высокого уровня именно специалист собеседует работодателей, а не наоборот.
Если бы оно было насыщено специалистами, то не было бы у джунов настолько высоких зарплат.
Нет у джунов никаких высоких зарплат, не надо выдумывать. Зато у них есть конкурс в две-три сотни человек на позицию.
И да, в случае специалистов высокого уровня именно специалист собеседует работодателей, а не наоборот.
Если это "Рога и копыта" в положении слива всех сроков контракта, отчаянно ищущих хоть кого-нибудь, то, пожалуй, да. А в чуть более пафосных и расслабленных конторках такому фраерку быстро укажут его место если он начнёт "уважаемых пацанов" "собеседовать". Вцелом конечно тема соблюдения негласной субординации и иерархии в айти ещё некопанна и достойна изучения и публикаций.
не уверен, что ситуация на рынке такая, как вы ее описываете
Вы совершенно правы, когда говорите, что разработчиков достаточно, если не имеете в виду "хороших разработчиков". А вот с ними ситуация несколько иная:
https://habr.com/ru/company/headzio/blog/578792/
https://vc.ru/flood/244370-deficit-programmistov-k-chemu-eto-vedet
https://lenta.ru/articles/2021/07/27/golod/
https://www.cnews.ru/news/top/2021-02-17_v_rossii_katastroficheskij
Сейчас работодатель это принцесса, а кандидат это лошадь на базаре.
По факту все ровно наоборот. Только не для джунов, конечно.
Я у джунов спрашиваю про жизненный цикл HTTP запроса, что бы увидеть понимает вообще он как все это работает. Уровень знаний ООП показывает насколько интересно программирование. Если профильное образование то что-то из программы универа, вроде того как представить граф программно, или как программно интеграл вычислить, и т.п., все то что недавно должен был учить, к сожалению многие сыпались на этом, потому что 5 лет только протирали штаны в универе, что говорит об отношении к обучению.
Достаточно ли знания на уровне HTTP/1.1 и GET/POST-запросов?
многие сыпались на этом, потому что 5 лет только протирали штаны в универе
Или потому что занимались нормальным интересным для них программированием, а не какие-то циферки туда-сюда гоняли.
или как программно интеграл вычислить, и т.п., все то что недавно должен был учить
Недавно это когда, неделю назад? Вычислительная математика кажется на 3 курсе идет. То есть человек, который к вам пришел после универа, изучал это 3 года назад, один из которых армия. Много вы помните из того, что изучали 3 года назад по рабочим задачам на прошлой работе? Вот прям так, чтобы на собеседовании на любой вопрос по ним ответить.
Сильные джуны спокойной отвечали на эти вопросы, а вот посредственные так же отмахивались как Вы! Это же элементарно сказать как запрограммировать интеграл, даже когда изучал это 20 лет назад.
Элементарно, и я наверно мог бы сказать про это пару предложений вида "ну вроде как-то так, интеграл это сумма отдельных частей", но уж точно не написать на собеседовании работающий код или предусмотреть все нюансы при разговоре. Но дело в том, что и без этого знания я мог бы написать весь код, который написал за несколько лет опыта. И я рассматриваю это знание не как следствие того, что я хорошо учил всю теорию, а как случайное стечение обстоятельств — был на этой лекции, преподаватель понятно объяснил, давали лабы на эту тему (причем на производные точно были, а вот на интегралы не припомню, хотя вроде логично что должны быть), не забылось за N лет неиспользования на практике. Ваш вывод на основании этого факта о личных и профессиональных качествах кандидата некорректен.
Хотите проверить умение программировать — проверяйте умение программировать. У любого сильного джуна есть программы, которые он писал сам помимо университетской программы, вот их и можно обсуждать. Или дать тестовое задание до собеседования.
Во первых я не требую написать рабочий код, достаточно объяснить как сделать. Во вторых у джуна который недавно закончил универ единственный опыт это учебный, и если человек не может представить математические абстракции ввиде программного решения, то это о каких профессиональных качествах может идти речь? Понабирают таких "профессионалов", а потом ужасаешься что смена состояний у сущьности описана ввиде сотни вложенных if/else, вместо лаконичной и гибкой к изменениям матрицы переходов, потому что видетели мы "не помним" ничего с теории графов.
если человек не может представить математические абстракции ввиде программного решения
Но вы-то проверяете не это. "Представить математические абстракции в виде программного решения" означает, что вы даете ему задачу "интеграл считается вот так вот, напишите код", а он представляет ее в виде программного решения. А вы проверяете случайный факт, что он заранее знает эту задачу, при том что в реальном программировании она встречается крайне редко.
смена состояний у сущьности описана ввиде сотни вложенных if/else, вместо лаконичной и гибкой к изменениям матрицы переходов
Я не знаю, что у вас за предметная область, и матрица конечно лучше кучи вложенных if/else, но мне за все время работы понадобилось описать смену состояний сущности в виде матрицы переходов примерно ни разу. Конечные автоматы это довольно специфичный кейс, и такой код сложно поддерживать. Если в технических областях типа написания компилятора такой подход оправдан, то в "обычной" бизнес-логике таких случаев практически нет.
Не расскажете подробности, что это за сущность? Может быть можно сделать по-другому.
Статья не так хороша, как жаркие комментарии к ней.
Какой то шакал сидит в конторе по расчету з/п и тестирет претендентов на знание теории устойчивости неустойчивых стульев на плывущих лъдах.
Программирование - if, go to и все, остальное временные знания до следущего фреймворка, ос, супервизора и т.д фигни.
Любой человек по рождению программист, так как он планирует свои и чужие действия, находит решение миллионов задач в онлайне, без подготовки. Каждый следующий шаг - это сотни if в несколько вложениях.
Если кому то нужен программист именно по какому то пулу задача, он должен четко и ясно обозначить пул задач, инструмент, окружение и т.д.
Возможно суть была в тестовых заданиях - что то изоморфное задачке поставившей в тупик всех "синьЁров" фирмы. А тут тысячи новых людей изо всех сил предлагают (за бесплатно!) свои решения (лучшее что могут), ктонибудь обязательно предложит что то годное.
Самое интересное-то тут и не раскрыто - как распознавать такие "звоночки" неадекватности-то?!
Здесь нет единого рецепта, и многое зависит от опыта. Например, чтобы научиться распознавать подозрительные обстоятельства нужно посетить хотя бы одно собеседование с хорошим отношением. Иначе не с чем будет сравнивать. Среди "звоночков" я бы выделил следующие:
плохие отзывы от клиенов, сотрудников или кандидатов, например, на Glassdoor;
зарплаты ниже рынка, в т. ч. и у младших разработчиков, и, как следствие — текучка кадров;
много этапов собеседования и, особенно, неопределённое количество этих этапов;
растягивание процесса найма на несколько недель и дольше без очевидных на то причин;
объёмные домашние задания и тесты на время дольше 60 минут;
странные, не технические вопросы, как попытка спровоцировать раздражение и оценить реакцию.
В идеале, ничего из вышеперечисленного не должно присутствовать. В рельности же, часто встречается комбинация из разных "звоночков".
Собеседование джунов должно быть адекватным к работе, которую нанимаемый джун будет выполнять. Если это будет банальное формошлепство и пересылка JSON с одного места в другое то и смысла особого нету мучить человека.
На моей первой работе в качестве программиста, собеседование зайняло может 20 минут - мне задали буквально 5 вопросов (один из которых "когда могу приступить к работе"). Отработал там почти 4 года, когда увольнялся, то спросили сколько мне дают там, где я иду и предложили больше.
Собеседования джунов — вся жесть вопроса