Comments 461
Тема про БАЗУ вытекает из того, что 90% интервьюеров - лентяи. К собесу надо готовиться с обеих сторон. В резюме надо вчитываться и корректировать свой пул вопросов под конкретного человека, продумывать тактику разговора. Но зачем, если можно подрочить в сотый раз устройство хэшмапы и шлифануть литкодингом. Говорю это как интервьюер, если что (надеюсь, что не лентяй).
А в чем собственно проблема вопросов по базе? Если человек действительно эксперт то легко ответит на них за 5 минут и дальше можно перейти к чему то более интересному, а вкатыши в айти которые знают только то с чем работали и нафиг не нужны. Понятно что как контр аргумент можно сказать что это ж можно зазубрить и пройти фильтр. Ну в целом можно но практика показывает что люди ленивы и таких зубрил по пальцам пересчитать можно к тому же если человек способен зазубрить то и в работе у него все будет хорошо.
А в чем собственно проблема вопросов по базе?
Проблема в том, что у лентяев ничего, кроме этих платиновых вопросов, в запасе нет.
Если человек действительно эксперт то легко ответит на них за 5 минут и дальше можно перейти к чему то более интересному
К тому, в чем разница между ArrayList и LinkedList? Или чем в спринге синглтон от прототайпа отличается? Было б смешно, если б не было так грустно. Я специально хожу по собесам как кандидат с целью найти интересные вопросы и темы для моих собственных собесов. Вдохновиться, так сказать. Так вот за последние полгода улов нулевой. Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"
Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"
Потенциальные работадатели, наверное, тоже переживают, что в очередной раз потратили полтора часа на чтобы подсказать интересные вопросы кандидату, который не собирался у них работать. Баланс ))
Все зависит от того зачем эти вопросы задаются, если человек не знает чем отличается связный список от массива это уже звоночек. Вы пойдете к врачу который не знает "базу" и умеет лечить только то что лечил на прошлом месте? Я думаю что нет, почему тогда в мире ИТ это норма?
если человек не знает чем отличается связный список от массива это уже звоночек
Для препода с универа может и звоночек, а для меня нет. Я считаю, что можно писать ПО и без этого. А звоночек для меня, это, например, когда сеньор-помидор декларирует знания трех фремворков и двух баз данных, а потом не может объяснить, чем эти продукты друг от друга отличаются, что для каких случаев лучше подходит, и за счет чего одно работает быстрее другого.
Вы пойдете к врачу который не знает "базу" и умеет лечить только то что лечил на прошлом месте?
Ок, берем врача ЛОРа педиатора. Лечит детям уши. Лечит хорошо. И тут мы ему вопрос по анатомии малого таза, а потом пусть все ферменты поджелудочной железы перечислит, а потом пусть вспомнит названия всех слоев мозга на латыни.
Меня смущает, когда такие вопросы начинают задавать миддлу на разгребание легаси, в котором сложившуюся архитектуру уже дёшево не поменять.
Особенно когда бенчмарки фреймворков и БД меняются от версии к версии.
ЛОР должен знать группы крови и как минимум должен смочь прочитать результаты анализа крови даже если не гематолог. Если вилку из глаза в живот то это не доктор.
Когда Вы идёте к ЛОРу за лечением проблем, которые лечит ЛОР, то Вы будете гораздо более счастливы, если он эксперт конкретно в своей области, который не тратит своё время на знания, которые для конкретно его работы помогают мало. Нужен специалист широкого профиля — идите к терапевту, он вероятно отправит к нужному доктору, но не всегда. И уж вряд ли вылечит что-то сложнее ОРЗ.
База необходима даже ЛОРу. Допустим он видит запредельное количество лейкоцитов в анализе крови. Он не спец по раку, но может послать человека к другому специалисту. Это как в программировании. Фронтэндщик может проигнорировать неправильный ответ от сервера, типа моё дело маленькое, не работает да и хрен с ним. А может подойти к бекендщику и грамотно рассказать о проблеме. Вся команда только выиграет от этого.
ИМХО, количество лейкоцитов в крови обычно терапевт смотрит. И только если видит, что надо к ЛОРу, то отправляет к ЛОРу.
Я, к сожалению, часто хожу по врачам. И пришел к выводу, что к любому врачу лучше идти с анализами. Да, они не всегда нужны, да не всегда их просят. Но я много раз нарывался на то, что даже ЛОР просит анализы. Более того, у меня несколько друзей врачи-стоматологи и все они умееют читать базовые анализы, кардиограмы и ти д. - курс базовой медицины преподают всем. Да, они не скажут по анализам что с вами не так, что за болезнь (это, к сожалению, даже специалисты не всегда скажут), но увидеть аномалию и отправить к врачу смогут.
Во-первых, никто не идет к лору чтобы тот посмотрел анализ крови, во-вторых, лор может это знать, но поскольку нормальные люди пойдут к нему не с анализом крови(возможно в каких-то конкретных случаях это играет роль, но в большинстве своем нет), а со своими проблемами касающихся лора, то он может знать как читать анализ крови, даже анализ кала и мочи может разобрать, но будь я лором, я бы точно был недоволен, если бы ко мне ходили чтобы я анализ мочи и кала разобрал, у меня задачи другие, это не моя ответственность и обязанность, так что даже если в твоем примере фронтэнд не пойдет рассказывать о проблеме, никто не имеет права его винить, это косяк бекэнда и тут роль человеческое отношение играет, не более
Врач любого профиля должен выловить любую экстренную патологию и оказать помощь, либо вызвать бригаду. По плановым патологиям та же история. Я могу не знать деталей диагностики сложной неврологии, но распознать гиперкинез и направить к неврологу должен.
Короче, врач по чужой области должен сработать как корректный маршрутизатор. В идеале - связать в цепочку со своей патологией, если применимо.
ЛОР должен знать группы крови и как минимум должен смочь прочитать результаты анализа крови даже если не гематолог. Если вилку из глаза в живот то это не доктор.
Группы крови может знать любой школьник. В базе их 4*2. А на самом деле их там сотни.
Что же касается "прочитать результаты анализа крови", то по анализу крови ЛОР никак не распознает что у пациента, например, подозрение на рак. Ибо изучал другие направления. И запредельное количество лейкоцитов может быть не только рак, а например простуда, воспаление, беременность, инфекция...
И вообще для рака может быть характерно не запредельное количество, а наличие слишком молодых лейкоцитов, которые по формуле далеко не каждый врач может нормально распознать.
Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.
Я к тому что нормальный программист, даже не разбираясь в технологии используемой в соседнем отделе, может бегло просмотреть код и указать на очевидные ошибки. Чем принесёт пользу общему делу. А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.
Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.
Если к нему пришли с больным ухом, то он должен лечить больное ухо. Вопрос скорее в том почему терапевт направил человека в таком состоянии только к ЛОРу.
Я к тому что нормальный программист, даже не разбираясь в технологии используемой в соседнем отделе, может бегло просмотреть код и указать на очевидные ошибки.
Если у человека грубо десятисантиметровые лимфоузлы, то ЛОР на это тоже сможет указать.
А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.
Нормальный программист тоже может придти в 9 и уйти в 5. Или там решить что дела другого отдела его не касаются.
а зачем нормальный программист должен лезть в чужую работу и почему он не может прийти в 9 и уйти в 5?
Если речь не идёт о госконторе то коммерческая фирма зарабатывает деньги. Если из-за косяка сервер упадёт или клиент разорвёт контракт фирма закроется и программисту придётся искать работу. И наоборот, если его наблюдательность или сознательность улучшит работу сервиса ему будут благодарны, фирма улучшит материальное положение и возможно выпишут бонус.
Знакомому в похожем случае оплатили поездку в США, он был доволен.
Так а зачем ему задерживаться? Пусть его наблюдательность и сознательность поможет ему сделать сервер перезапускаемым и готовым к нагрузкам, чтобы спокойно работать с 9 до 5 и ему, и всем остальным.
Коммерческая фирма так же будет довольна.
Программист не обязан брать ответственность за выполнение бизнес-целей и не обязан заниматься риск-менеджментом. Если фирма закроется - туда ей и дорога. А программист всегда нацдет новую работу поскольку - востребован.
Если речь не идёт о госконторе то коммерческая фирма зарабатывает деньги.
А сотрудник зарабатывает деньги выполняя свои должностные обязанности в рабочее время. Доход сотрудника в подавляющем большинстве случаев не привязан к доходу фирмы, а устанавливается рынком труда
Если из-за косяка сервер упадёт или клиент разорвёт контракт фирма закроется и программисту придётся искать работу
Тут вопросы к рабочим процессам: если сотрудник может сломать так, чтобы прод упал и понёс серьёзные убытки не подняв тревогу, то фирма когда-нибудь точно закроется )
ему будут благодарны, фирма улучшит материальное положение и возможно выпишут бонус.
Возможно. А может и не будут. Может просто по плечу похлопают и "спасибо" скажут. Где какие-нибудь гарантии?
то, что кого то где то как то отблагодарили - это повод работать в режиме 24/7/365 ? чем принципиально в этом отношение программист должен отличаться от строителя, водителя, дворника, сантехника? что за непонятные попытки доказать элитарность и незаменимость какой то конкретной профессии?
myvar=${#myvar} && myvar=${myvar,,}Я вот интуитивно подозреваю, что вы не очень разбираетесь в шелле. Подскажите очевидную ошибку в этом коде без гугления?
Вы же считаете себя нормальным программистом?
Это базис. Должен делать любой врач. Как минимум направлять на пересдачу анализа и к онкогематологу, если там НЁХ с анализами.
Ходил я к одному такому ЛОРу горло лечить, месяц потратил, потом поменял врача и за один прием выяснилось что это был рефлюкс. Вот что значит база.
Доктор вполне мог иметь аналогичный случай месяцем ранее. И у вас он просто увидел знакомый паттерн. Вы не можете 100% знать, что тут некая "база", а не обычный рабочий опыт.
Точно так же разраб может решить проблему перфоманса БД не потому, что он собаку съел на реляционной алгебре и внутреннем устройстве СУБД, а просто потому, что разбирал похожий кейс на прошлом месте.
Вот на этом предположении и держится вся ваша аргументация, это не врач профессионал потому что в институте хорошо учился и знает как одно от другого отличить, а просто это ему так повезло и он по приколу в прошлом месяце половину пациентов к гастроэнтерологу отправлял а потом статистику смотрел кого вылечили, а кого нет. Конечно в медицине все так и работает.
Моя аргументация держится на факте, что в дрочильных вопросах о "базе" я сам весьма плох. А в прикладной работе весьма хорош. Я экстраполирую этот факт на других людей и считаю, что дрочильные вопросы сами по себе, а способность думать и решать задачи сама по себе. И именно на этой способности я фокусируюсь во время интервью.
Скажите, вам правда кажется сложным вопрос про AL vs LL? Вопрос без подводных камней, мне действительно любопытно
Позвольте дополнить ваш тезис, коллега, подсократив множество не попадающих в вашу экстраполяцию вариантов: не могу припомнить специалиста по дорочильным вопросам, который хорошо решал бы прикладные задачи. Более того, я совершенно точно не встречал ни одного дрочилу, который решал бы такие задачи однозначно лучше или хотя бы сопоставимо относительно прикладных специалистов.
Если сэкстраполировать данный тезис консолидированно с вашим, то, боюсь, у нас вовсе не останется иного варианта, кроме как сделать статистически обоснованный вывод о том, что степень задрачивания базой В БОЛЬШИНСТВЕ СВОЕМ обратно пропорциональна прикладной полезности специалиста.
Который в общем то можно вывести аналитически, а не статистически: направление умственного ресурса на прикладные задачи освобождает эти ресурсы с поддержки "базы", ненужной для решения этих задач, и чем больше ресурсов будет выделено, тем лучше будут решаться эти задачи и, следовательно, тем меньше будет владение базой (по крайней мере, оперативное). И наоборот.
А уже отсюда, позвольте в силу профдеформации позанудствовать, можно сделать уже следующий вывод: наблюдаемый систематический рост такого подхода в найме свидетельствует как о наблюдаемой общей деградации ИТ-индустрии, как минимум, в стране, так и о неизбежном ускорении этой деградации в ближайшем будущем. Причина такого вывода очевидна: поскольку результат такого подхода в виде перебоев в разработке не приводит к его смене, значит топменеджмент такой подход и, следовательно, перебои, устраивает. Причем систематически, массово. А причиной этого, в свою очередь, может являться только одно: падает востребованность продукта индустрии в экономике. Высокие темы держатся на инерции но привод уже отключился. Далее инерция приведет к переизбытку предложения и случится кризис, если ситуация в идустрии не изменится.
Моя личная гипотеза причин подобного в том, что индустрия начала поедать сама себя, продукт начал создаваться ради продукта, цели начали выдумываться за неимением объективно стоящих, и под этим самокопирующемся шлаком хоронятся немногочисленные (на общем фоне) действительно востребованные решения. Так что, коллега, опасаюсь что эпоха когда программисты будут как бухгалтеры в начале 2000-х, уже не за горами.
Была как-то статья на хабре про специалиста которого попросили решить проблему с нагрузкой сервера. Посмотрел - там и докеры, и кластеры баз данных, и заббиксы, всё в точном соответствии с современными вакансиями. И сам сервис который тупо отдавал условно говоря решение квадратного уравнения.
Спец поднял другой сервер с крошечным скриптом на питоне и рестартом в случае чего, установил на распберри пи и уменьшил расходы фирмы на 500 баксов в месяц.
Наверное потому что базу знал.
Так наверное или нет?
Очень круто, что он подобрал такое решение, но ваш вывод про базу из этого не следует.
Тот специалист может:
- знать базу
- не знать базу
- знать базу но что-то другое помогло ему прийти к этому решению...
- не знать базу, пожалеть что именно ее нехватает, поучить и сделать как сделал.
- много других вариантов...
Кроме этого специалиста никто не скажет, как на самом деле было, помогло ли ему знание базы, было ли у него оно...
Но вы берете и подгоняете вывод под желаемое - это вам знание базы помогло?
Апелляция к личному опыту это не научный метод. У меня, например, другой опыт : люди которые уделяют внимание БАЗЕ (пытаются досконально разобраться как оно работает, в каких случаях что лучше применить и тд.) и в работе показывают лучше результаты. Можно ли именно мой опыт экстраполировать на других людей? Возможно, у техлида из статьи такой же опыт.
Рефлюкс почти у каждого второго. Раздражение горла от рефлюкса — настолько типичный случай, что уже нельзя ссылаться на узкую специализацию. То есть, возникают серьезные вопросы к компетентности.
А когда вы приходите к инфекционисту с ангиной, а он находит болезнь Грейвса только по дрожащим рукам, встречающуюся так редко.... База нужна всем, вопрос только в том, на каком уровне она нужна.
Базедова-Грейвса ни с чем не перепутать обычно) Глаза навыкате, блестят. Пациент часто моргает и выглядит как крысобелка под амфетамином. Это как раз любой врач должен определять.
Сейчас я это понимаю... А в то время меня останавливал каждый сотрудник ППС, т.к. мои глаза ему казались весьма странными. За несколько месяцев до инфекциониста, я посетил окулиста, т.к. сильно болели глаза. Она нашел аллергический конъюнктивит, быстренько его вылечил, а вот глядя на мои глаза к эндокринологу меня не отправил. И в момент посещения окулиста глаза выглядели не лучше, чем в период лечения у инфекциониста, Грейвс был лет 5 наверное как минимум, до начала лечения. Так что да, там может быть и все очевидно, но без знания базы и очевидные вещи не замечаются.
выглядит как крысобелка под амфетамином. Это как раз любой врач должен определять.
Крысобелку не всякий охотовед распознает — а Вы о врачах...
То есть для вас не звоночек что человек не знает структур данных, может выбрать кривую и просадить производительность на ровном месте буквально на порядки? Хотя может конечно у меня уже деформация от плюсов и перформанса, но для меня если человек не понимает структур данных в своём языке это неплохой такой звонок. А всякие новый фреймворки выучить это как раз уже не так страшно если будет нужно.
То есть для вас не звоночек что человек не знает структур данных
Не знать структуры данных, конечно, плохо. Но дело в том, что я не считаю, что отличные ответы по структурам на собесе эквиваленты хорошему их знанию на практике. На моей памяти самые четкие ответы на "как устроена хэшмапа" давали джуны - они же со спокойной душой засаживали в код алгоритмы O(n*n). Сеньор или мидл, наоборот, могут продолбаться на этом вопросе, но код их будет лучше.
Согласен что знать != применять, но не знать это уже скорее == не уметь применять. Но в общем то еще конечно зависит от области, для меня странно если плюсовик не знает как стэк, куча (которые не структуры данных, а память, хотя оно так называется потому что стэк организован как... стэк) работают, как кэши процессора работают и т.д. Хотя я то же самое спрашивал у знакомого пхпшника и он ничего не смог сказать (а я бы ничего не смог сказать про всякие вэб протоколы). В целом в плюсах люди могут сказать на собесах эти вещи (а потом себе ноги отстрелить какими-нибудь более изощренными штуками).
как устроена хэшмапа
Есть некоторая разница между:
- Могу сам написать хешмапу за 20 минут с тестами. Засекайте
- Понимаю как работает. Могу нарисовать, показать, рассказать.
- Я тут плыву, если честно, но знаю когда стоит применять, а когда не стоит.
- Ну это… не знаю что это. Я код из стековерфлоу обычно копирую.
Если человек не отличает связный список от массива, то это 4-й пункт. За таким нужен тщательный присмотр и менторинг.
У меня был персонаж с другим вариантом. Смотрю, там где можно по смыслу использовать мапу он использует массив. Спрашиваю про мапу, чтоб натолкнуть на мысль ее использования - рассказывает все, но он не понимает то, что рассказывает - зазубрено, определение не сопоставляется с реальностью. Попытался на пальцах вместе разобраться - ноль, т.к. практически вся база знаний, мышление так построены. Распрощались, хотя навязали как мидла.
К сожалению, подобное, когда знания не соотносятся с реальностью, а воспринимаются как что-то абстрактное довольно распространенное явление не только в программировании, а в любой сфере. Более того, неадекватное восприятие реальности было обозначено, как одна из трех наиболее значимых проблем современного человечества. Ну, и как тут жить прикажите?! Остановите Землю, я сойду ! :)
О, я такое встречала точь-в-точь на тему изучения английского языка. Пока училась в университете, местным студентам по условиям стипендии, помогала разговориться. Так как у них массовая проблема была - они сдают тесты на отлично, грамматика от зубов отлетает, даже сложная, словарный запас до небес, но говорить не могут.
Один даже пришёл и показал мне две общие тетради, исписанные в каждой клеточке фразами на английском, вопросы, утверждения, на разные темы, и он всё это зазубрил, и даже научился применять (что уже ого-го себе, он очень-очень постарался научиться говорить). Но при этом общаться на живом языке - нет.
Условно говоря, я спрашиваю его, есть ли у него кот дома - да. А какой? Он рассказывает про (например) кота, какого он размера, веса и цвета, и даже что он любит. И, если я задаю какие-то квадратно-гнездовые вопросы, он на них легко отвечает, почти без задержки. И тут я спрашиваю, а есть ли у кота (условное) белое пятнышко на хвосте? И всё, завис человек. При этом он грамматику вопроса знает отдельно, слова все ему знакомы. Но нестандартный вопрос вгоняет его в панику.
А я как бы даже не экзамен, я здесь просто поболтать, но любая беседа, выходящая за рамки учебника, просто не клеится. Потому что у многих не было вообще понимания языка как речи.
Это исключительно проблема преподавателя и методики. У меня есть с чем сравнивать. В школе за ошибку в грамматике ставили два и у нас никто не говорил. А вот как-то попался американский учебник для мигрантов и я в рамках эксперимента взял группу пенсионеров поднатаскать в английском с нуля. Учебник очень простой. Картинка, как произнести слово и диалог. Никакой грамматики, исключительно разговорная практика. И бабушки заговорили спустя пару месяцев. Да, зачастую с ошибками, но вполне уверенно.
Это работает для маленькой группы, как только вам нужно быстро проверить знания миллиона-другого человек, на сцену выходят стандартизированные тесты. Это же были вчерашние дети после школьного курса английского.
К тому же есть такая штука как языковой барьер, у них отдельная паника случалась, оттого, что они увидели настоящего живого иностранца. Это как раз с каждым человеком может случиться при самой лучшей методике, если, конечно, не выписывать настоящих иностранцев в качестве учителей (но это не всем по карману, вот в нашем универе как раз нас и выписали за кормёжку и обучение)
Суть всего спора в том, что существуют полностью осознанные знания, которые вытекают из понимания базы, то есть фундамента на чём всё строится и тупо функциональных зазубренных знаниях без самого понимания основ.
Вот взять кубик Рубика, можно пойти в утуб и быстренько посмотреть самый быстрый алгоритм сборки, а потом на глазах у знакомых его быстренько собирать, можно ещё всяким трюкам научится спидкуберским, тогда вообще огонь будет смотреться.
Только вот бездумно зазубрить рабочий алгоритм, это вообще не тоже самое, что самостоятельно крутя вертя кубик, найти те закономерности и те особенности которые помогут тебе добиваться какого-то результата где сам алгоритм уже вывели математики.
Мы все точно так же в школе зазубривали метод деления в столбик, не задаваясь вопросом, а почему этот метод возможен и на каких закономерностях он основан и как кто-то пришёл к этому методу, мы просто зазубрили функциональную часть, где этот метод даёт нам нужный ответ, попробовали его пару раз, проверили что он рабочий и всё, наша цель же была в том, чтобы верно решать примеры, чтобы нас похвалили и поставили 5.
С рубиком и столбиком оно работает одинаково, зазубренный рабочий метод это способности обезьянки, которая научилась повторять что-то, что вывел более осознанный субъект, который задавался куда более фундаментальными вопросами, как чёрт возьми оно устроено по своей сути, а не то, как получить нужный мне результат, чтобы козырять этим перед остальными.
Для каких-то прорывных вещей требуется знание базы, а просто ехать можно и на функциональных знаниях не понимая что лежит в их основе и как оно было выведено.
В идеале конечно лучше чтобы все в команде понимали всё с фундамента, но это вовсе не обязательно, нужно какое-то лишь достаточное количество ключевых людей, которые будут видеть архитектуру с нуля и проверять её, направляя людей.
Например автомобиль, как концепция состоит из разных функциональных элементов, где база, колёса, двигатель, объединяются в единое целое и только в таком виде, оно выполняет свой функционал, невозможно убрать что-то, оно сразу перестанет выполнять свои функции.
Так вот, чел который тут всех отбраковывает, требует полной универсальности, где каждый член был бы полностью автономен и в одно жало мог бы написать всю задачу с нуля. Но это не обязательно, нужно чтобы костяк спецов, понимал и следил за развитием инфраструктуры, а спецы без понимания базы не увели бы проект куда-то не туда, не понимая основных принципов.
Где в компании есть нехватка рабочих мощностей, что сказывается на конечном продукте, так как появляется перегрузка команды, недовольство командой, недовольство руководством и кадровой политикой.
Где требуется урезать требования к базе, но выставить жесткое разграничение для людей которые эту базу не знают, где они будут лишь как подмога, но не будут участвовать в проектировании фундаментальных структур, а будут лишь выполнять задания сверху.
что можно писать ПО и без этого
Это вообще как? Что это за ПО такое, что можно все массивы на связные списки поменять и всем плевать?! Я бы к вам не пошёл. Пишите такое ПО сами. И пользуйтесь тоже им сами.
24 плюса. Хабр, что с тобой? Я понимаю, если бы человек написал что ему человек со знанием эхо-корасиков не нужен. Но блин не отличать связный список от массива… Причём в Java… Что дальше? Кандидат путается в 3-х IF-ах? Ок, берём. Будем давать задачи с 2 IF-ами.
Во-первых, вы еще пойдите найдите кейс, где в современном джава-приложении ArrayList и LinkedList ведут себя драматически по-разному. Типовая обработка коллекций вся давно на функторах - а они разницу не видят. Сценарий, где мы зачем-то берем энный элемент списка и получаем ту самую разницу O(1) vs O(n) - это экзотика, которая встречается скорее на литкоде, а не на практике.
Во-вторых, если человек путается в этих нюансах, то это решается ровно 1 замечанием на код ревью.
В-третьих, LinkedList в джаве - предмет шуток даже для его автора. Why so serious?
Что-то не выходит драмы.
то это решается ровно 1 замечанием на код ревью.
Не решается. Если человек не знает этого, то он не знает почти ничего. Его придётся учить почти с нуля.
где мы зачем-то берем энный элемент списка
Т.е. вы используете массивы, но адрессная арифтметика вас не интересует. Какие-нибудь матрицы смежности это видимо high end технологии. Понял. А ну да. Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.
Что-то не выходит драмы
И правда. В вашей вселенной не выходит. Главное от неё держаться подальше.
Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.
Реальный код у каждого свой. Если вам какой-то аспект важнее других - я не против, если вы вокруг этого свое интервью будете строить. Просто смиритесь, что у каждого своя ситуация и далеко не каждому нужен выдроченный курс CS.
Главное от неё держаться подальше
Я рад, что искусство диагноза по аватарке все еще живо.
выдроченный курс CS… связный список
Ох. И это Java, которую всегда ставили в пример. А я думал у нас всё плохо.
В джаве в 99.(9)% случаев используют ArrayList. И вообще есть бест практис работать с листами как с интерфейсом List. А обрабатываются они через стримы (т.е. функторами). Обращаться к элементу по индексу - это реально редкость в энетрпрайзе. LinkedList лично я за 8 лет практики использовал только на литкоде, т.к. этот класс также реализует интерфейсы Queue и Stack.
Реальной проблемы в выборе реализации просто не стоИт. Поэтому вообще ноль проблем, если человек не знает разницу или подзабыл. На самом деле джуны+ и далее знают все прекрасно.
В чем именно ваша проблема? Почему вы продолжаете хамить даже не разобравшись в ситуации?
Да разобрался я вашей ситуации. Знаю я и про итераторы, и про кровавый ынтерпрайз. Грустно мне. За державу нашу отрасль обидно. Докатились, так сказать, до ручки.
Queue и Stack
Не-не. Никаких очередей и стеков. Долой литкодщину. Слишком сложно. Спринт горит!
P.S. я там выше скриншот добавил. У нас вроде тоже ынтерпрайз. И тоже итераторы.
В джаве в 99.(9)% случаев используют ArrayList.
Не сказал бы. У нас около 20% LinkedList, и есть даже над ним обвертки, для большей эффективности. Все зависит от задач.
Обращаться к элементу по индексу - это реально редкость в энетрпрайзе.
Скорее говнокод, даже не знаю где может понадобится. Или же в моей практике просто не встречалось.. Как у вас с LinkedList.
вообще ноль проблем, если человек не знает разницу
Если он работает у нас, то проблема. Если у Вас, то проблем нет, так как вы не используете.. В целом, если вернуться по стеку к статье, то скорее когда на собеседовании задают вопрос по LinkedList, то наверное используют и наверное им важно..
не придраться, но спросить:
20% случаев использования LinkedList(-) вместо Arr на Java(-). Мне хм... не то, чтобы сложно поверить - но кажется ваш случай действительно довольно специфичен.
Из всех вариантов когда List лучше Arr - у вас остался только случай специфической нагрузки (много удалений \ вставок) на достаточно длинные коллекции.
(real-time мимо из-за Java, lock-free мимо из-за List).
Судя по вашему скрину, у вас а) фронтенд б) что-то связанное с графикой
тут, пожалуй, индексы могут пригодится. но область уж очень узкая.
Открыл наш backend:
- 955 results in 293 files
- 3916 results in 654
Полистал. Часть, конечно, что-то левое. Но более чем достаточно кода где прямое обращение к элементу массива по индексу. Как и вызовов всяких splice, findIndex, slice.
Backend самый обыкновенный (ну кроме того что это high-load). Посмотрел по смыслу — всякие сопоставления коллекций, их merge-инг, валидация, группировка и т.д… Ну т.е. довольно рутиные операции. Не какие-нибудь графические вектора.
Покажите пожалуйста пару мест - очень интересно где вы обращаетесь по индексу.
Простите, но влезу в разговор ссылкой на код хромиума. Куча обращений по индексам. Где-то 80% найденного там — это действительно тупо итерация по контейнеру, объявления массивов и прочие комментарии: не считается, да. В оставшихся там есть обращения к подряд идущим элементам. Еще где-то индекс является ключем в колекции — это именно обращение по индексу, которое нетривиально заменить на что-то еще.
Выше кратко привёл вид задач. Включил поиск по проекту:
- Самый частый кейс это какая-нибудь реализация навигации стрелками с клавиатуры по списку.
- Какой-то кейс где у нас есть несколько уровней тарифных планов, которые поддерживают разный набор фич. И у них есть иерархия. Задача — выбрать ближайший в пределах иерархии план, содержащий нужную фичу, чтобы попросить юзера купить этот план.
- Какой-то мудрёный код в иерархическом контроле где всякие каталоги, подкаталоги. Я вижу там вообще полно индексов. Но это надо вникать в каждый конкретный метод.
- Merge-инг разнородных коллекций во что-то новое.
- Много кода со всяким парсингом строк. Тоже индекс на индексе.
- Ооочень много кода, где массивы используются в роли хеш-мап, но с числовыми ключами (которые и есть индексы в коллекции). Формально можно заменить на хешмапы с сохранением порядка и со случайной генерацией ID, но на кой чёрт? :)
- Куча какого-то кода с поиском. В том числе иерархическим.
Ну и прочие примеры. Там 513 кейсов даже по такой регулярке: \[(idx|index).
ArrayList это ресайзабл массив, а LinkedList связный список? К примеру в плюсах будет чаще перформанс хит не из-за алгоритмической сложности, а из-за того, что связные списки раскиданы по памяти и очень плохо ложатся на процессорный кэш и просадка из-за того, что "ой, а след элемент у нас не в кэше, пойдем за ним долго и упорно в след левелы, а если не повезет в оперативу". В жаве не так (мммм всё на хипе и в массиве все равно будут указатели на куда попало? но с примитивными типами должно работать все равно)?
мммм всё на хипе и в массиве все равно будут указатели на куда попало
Не, ну там же не полный хаос царит. Всё равно будут большие цельные блоки памяти в пределах которых всё работает быстро.
Ну утрированно. Понятно про система скорее всего вам пытаться будет целыми блоками давать и поближе, плюс процессор скорее всего умеет, скажем так, держать у себя в кэше данные с разных мест в памяти и может этого хватит (может в эмедед мире не так) и так далее, то есть на практике ну не так все плохо будет скорее всего, но в перформанс критичных приложениях лучше так не рисковать. Ну либо разворачивать свой лист на своей преаллоцированной арене, которая будет гарантированно одним большим постоянным блоком.
Ну в целом я согласен с коллегой что огромный пласт ПО можно писать без этого) Печалит в этой истории то что людям не только совершенно не любопытна теория по своей профессии, но они ещё и кичатся этим, поднимают на флаг. "Нам он и на* не нужон, хашмап ваш"(с)
Вот тут чуть мимо. Человек сложно устроен. Я однажды мучился с почками, ходил по врачам, пока однажды уролог не сказал: "Да у вас просто мышцы спины в гипертонусе" и отправил к совершенно другому специалисту
Смею заметить, что пример с врачом по моему мнению в корне некорректен: люди намного хуже стандартизованы в деталях функционирования конкретного организма нежели 90 процентов программных продуктов. А еще код можно читать, совсем как текст, а вот состояние человеческого организма прочитать, увы, не выйдет, его можно только оценить по огромному комплексу сложных, непостоянных и индивидуальных метрик. Если выкинуть совсем энциклопедические случаи - даже терапевту, чтобы лечить хорошо, действительно нужен кругозор и база. Чтобы написать рабочий, просто рабочий код требуется, ИМХО, на порядок меньший кругозор и пресловутая «база».
Возможно я Вас удивлю, но врачи тоже гуглят. А мировая практика показала, что даже очень опытные врачи сталкиваясь с редкими заболеваниями не могут их распознать.
Во первых гуглить тоже надо уметь, человек без нормальной базы на гугление потратит в 5 раз больше времени и не факт что вообще поймет что он там нагуглил.
И потом может тогда врачам тоже не стоит 5 лет учиться, пусть идут на трёхмесячные курсы от гикбрейнс и вперёд, все равно 90% больных у ЛОРа болеют вирусными заболеваниями которые сами пройдут за неделю, а остальные можно и нагуглить
может тогда врачам тоже не стоит 5 лет учиться, пусть идут на трёхмесячные курсы от гикбрейнс и вперёд, все равно 90% больных у ЛОРа болеют вирусными заболеваниями которые сами пройдут за неделю, а остальные можно и нагуглить
Тссс, не подсказывайте министру здравоохранения идеи оптимизации расходов на медицину для быдл электоральных масс
Недавно был эксперимент кто лучше и точнее диагностирует заболевания. Взяли врачей с минимальным опытом после обучения и опытных врачей с огромным стажем и узкой специализацией. Опытные врачи великолепно ставили диагнозы по своей специализации и проигрывали выпусникам в диагностике болезней не своей специализации. Выпускники неплохо диагностировали болезни по большинству специализаций и лучше по своей но гораздо хуже опытных врачей по их специализациям. То есть нужно брать только выпусников или людей с широкой специализацией.
А еще лучше опытных но не растерявших полученные в учебе знания.
FAANG в общем то так и делает, вот тебе секция алгоритмов и секция дизайна распределенных систем, пройдешь значит будут с тобой говорить, нет так нет. Но на хабре от этого у многих хорошенько так пригорает, как же так, мы же в вузе не учились зато прекрасно json'ы перекладываем, значит это не мы плохие, а интервью неправильные.
Я учился в ВУЗе (да ещё в доЭГЭшную эпоху), джонсоны не перекладываю. Но интервью, да, неправильные. Возможно лет 20 назад алгоритмы и правда могли выделить лучших инженеров из просто хороших. Но нынче эта система геймится и абьюзится просто в промышленных масштабах. Вплоть до состояния антипаттерна: видишь выходца из FAANG - считай абсолютно бесполезная в реальной разработке литкод-макака.
литкод-макака
Ироничненько (с)
Но, в общем и целом, согласен. Про другие фаанги ничего не скажу, но в Гугле народ слишком дофига занимается перформанс ревью друг друга и прочей хернёй. Алгоритмы, про которые они спрашивают на входе, 95% там в работе никакие не юзают.
видишь выходца из FAANG — считай абсолютно бесполезная в реальной разработке литкод-макака.
Опишите, пожалуйста (или ссылку на ваш старый коммент дайте, если уже писали), в чем конкретно они бесполезные в разработке?
Как говорится критикуя предлагай. Пока что никто толком не описал как правильно проводить интервью, однако жалоб вагон, обижают бедных сеньоров вопросами про хеш таблицы, ужас ужас.
Нет и не может быть никакого универсального интервью, как и не может быть таблетки от всех болезней. Джуны это одно, а сеньйоры это другое. Нет, они не лучше, они занимаются другими задачами. От фронтендера требуются одни качества, а от ембеддера совсем другие. Но поскольку никто ничего в этом направлении не делает и делать не собирается, я бы просто разыгрывал лотерею. Один фиг текущий процесс это лотеря. Хотя бы обоюдно время и силы сэкономим.
видишь выходца из FAANG
Работаю с выходцами из FAANG. Отличные спецы знающие своё дело. Имеющие превосходное представление о реальной разработке, причём часто с позиции business-а. Прекрасно понимают где и когда можно скосить углы, где будут perf-bottleneck-и, где можно писать код ногами, и куда подстелить соломку. Хорошо понимают роль логирования, умеют в продвинутый troubleshoot-инг и debug-инг. И обладают высокой инициативой. Хорошо доносят своё мнение. Умеют идти на компромисы. Обладают глубокими познаниями в используемых инструментах. Без проблем пишут свои решения, библиотеки. Прекрасно разбираются в чужом коде.
Вообще грех жаловаться. Что это вам за выходцы из FAANG-а попадались, что в разработку не умеют?
ИЧСХ далеко не все из них умеют в "литкод-макакинг".
видишь выходца из FAANG - считай абсолютно бесполезная в реальной разработке литкод-макака.
А вы много таких выходцев реально встречали/работали? Литкод в ФААНГЕ это может 10%-15% от всей серии интервью на позиции выше джунов, остальное как у всех - тех, опыт работы и всё вот это вот. Или у вас все операционные системы, иде и т.д. пишут исключительно литкод макаки и просто рэндомно выходят продукты которыми буквально пользуются миллионы/миллиарды?
Я думаю что нет, почему тогда в мире ИТ это норма?
Потому что мир ИТ совсем не похож на мир физиологии человека.
"База" анатомии довольно статична и не расширяется так, как "база" ИТ. Анатомию без специализаций выучить можно, а объять также сферу ИТ невозможно. Во фронте каждые 10 лет прикладные фреймворки меняются — вы представляете себе врача, у которого инструментарий каждые 10 лет абсолютно не похож на предыдущий?
Проблема то эта лежит вобщем-то в финансовой плоскости. Поддерживать эту разрастающуюся "базу", большая часть которой малоиспользуема, требует много затрат времени => такой специалист очень дорогой в обучении => очень дорогой в дальнейшей работе (ведь стоимость обучения перекладывается на работу). А бизнес почему-то не хочет платить за эти затраты. Бизнесу идеально как раз нанимать ровно "умеет лечить только то что лечил на прошлом месте" если области совпадают.
База ИТ ровно так же статична как и база анатомии, просто многие в этом посте не понимают что такое база в принципе и думают что это названия классов и методов в фреймворках которые они использует. Так вот нет, фреймворки это не база и никогда ею не были. Продублирую свой ответ из соседнего треда:
https://habr.com/en/articles/758838/comments/#comment_25932550
Вы пойдёте к такому врачу, так же как и я, и уже много-много раз ходили. Вы же каждого врача не интервьюируете?
Когда вы последний раз использовали связный список?
По крайней мере в гугле их используют постоянно. Писать их, конечно, с нуля почти не пишут, за очень редкими исключением, но на интервью иногда спрашивают, чтобы убедится, что кандидат таки поймет, когда использовать std::vector, когда std::list. Можно было бы просто спрашивать о свойствах списков, но все равно же надо выдавить из кандидата 5-10 строк осмысленного кода, почему бы не спросить что-то со списком написать?
Блин, разница между хорошим специалистом и плохим в том, что и тот и тот могут забыть\не знать каких то вещей, но первый может довольно быстро разобраться в вопросе. Я вот за годы своей карьеры позабывал кучу хитрых алгоритмов, которые хорошо знал лет 10 назад, сейчас спросите - не отвечу. Но со шпаргалкой разберусь и вспомню. Однако такой кейс на собеседовании красный флаг для большинства интервьюверов.
Какие такие хитрые алгоритмы спрашивают на интервью? Ни разу такого не видел. Обычно спрашивают про отличия в стандартных структурах данных по асимптоматике да и все, или вас по красно-черным деревьям гоняют?
Даже задачки с литкода обычно везде дают уровня easy, максимум medium, что бы их решить обычно ничего сложнее хеш таблицы и слияния двух массивов знать не требуется.
Всякое бывает. Коллегу одна немецкая контора попросила задачку на поиск оптимального пути в графе решить. Я хоть и решил таких штук 50 наверное сейчас вот так вот сходу и не решу. Всё выветрилось. Но там, справедливости ради, в самой вакансии было указано, что алгоритмы играют ключевую роль в позиции.
Я специально хожу по собесам как кандидат с целью найти интересные вопросы и темы для моих собственных собесов.
Т.е. лень самому придумать вопосы и темы, но не лень время тратить на пустые собеседования? Может это и есть ответ про других: им тоже лень думать и подстраиваться под каждого кандидата.
Т.е. лень самому придумать вопосы и темы
С потолка взяли? Невозможно придумать из головы все возможные интересные вопросы. В другой конторе могли иметь уникальный кейс, который потом превратился в вопрос для собеса. На это и расчет.
Цель: адекватно оценить и нанять кандидата на соответствующую роль, а не поупражняться в изяществе вопросов. Достаточно, "просто", подходить к каждому кандидату индивидуально. Перефразируйте вопросы, вплетите вопрос к другой контекст, чтоб он вытекал из задачи и не был академическим, чтоб выбить кандидата из привычной среды экзамена и не дать соотнести вопрос с ранее услышаной формулировкой и т.д. Да, проводить собеседование тоже искусство. Нужно тренироваться, учиться, овладевать психологическими практиками и иметь широкий кругозор.
Тут все зависит от того, как эти вопросы задавать и оценивать. Если все это в стиле квиза с попыткой подловить на незнании деталей - то это ад, конечно, с другой же стороны можно эти вопросы задавать просто с целью посмотреть на то, как человек будет отвечать. Если человек может четко и грамотно сформулировать, что он знает, и очертить круг того, что "вот это уже забыл", то и понятно сразу будет, что по факту он в вопросе разбирается.
По сути, это все просто такие универсальные темы для разговора.
Ну вот, например, после вопроса про устройство hashmap можно спросить - а можно ли в качестве ключа исользовать null? А что будет при постоянных коллизиях?
Проблема что это не всегда что-то из разряда фундаментального. Для той же системы .Net вы влет может огрести от разной реализации в mono и clr.
Для c++ реализация хэша в контейнерах может меняться от версии компилятора.
И т.д.
Для c++ реализация хэша в контейнерах может меняться от версии компилятора.
И в команде никто этого не знает и не знает где бывают эти проблемы в их проекте?
Ну имхо что такое хэшэйблы (всякие unordered_) и по какому принципу оно работает это как раз фундаментальное и это по хорошему надо знать, а как оно уже конкретно реализованно это детали. Хотя С++ страдает от того что все знают 5% языка и у всех эти 5% свои с небольшими пересечениями, а спрашивать "а зачем нужен виртуальный деструктор, а можно ли выбрасывать исключения в деструкторе" и так далее как-то не серьезно (да и отвечать на это тоже задалбливает)
Проблема вопросов по базе в том, что они могут не иметь отношения к реальным юз кейсам.
Не так давно собеседовался в компанию как Unreal Engine плюсовик. Обсуждали ромбовидное наследование что это, как правильно наследоваться и что будет в разных вариантах наследования. Всё что я мог сказать: "Да, я конечно читал про проблемы ромбовидного наследования. Лет 10 назад. Потому что на практике мы его нигде и никогда не используем из-за того что это проблемная штука, которой нужно избегать."
И вот получается - это база. И это база, которую я не знаю(вернее не помню, но это одно и тоже). Давайте меня браковать за это?
проблемы ромбовидного наследования
И это база, которую я не знаю(вернее не помню, но это одно и тоже).
Да, бросьте, в чём состоит проблема ромбовидного наследования нет проблем вывести через пол-минуты размышлений.
Вот вспомнить наизусть что означают какие буквы в SOLID и иногда даже CAP - это без освежения данных сложнее. Впрочем, на собеседованиях одно и то же спрашивают, после первого собеса в серии, это будет отлетать от зубов.
Для энтерпрайзных разрабов обычно нет проблем рассказать про солид во всех его проявлениях, связать di c юнит тестами, и c них перескочить на bdd с примерами из реальной жизни, рассказать про легаси, в котором пришлось это все править и проч. Рассказать про проблемы, которые приходилось решать, поиски боттлнеков и гейзенбагов. А вот вопросы по "БАЗЕ" - ну блин... Бывают такие дебильные. Но правда бывают и хорошие и можно глубоко по ним докопаться. Как повезет с интервьюером. Судя по статье везет не всем.
Да я не про рассказать. Я про буквы. Из этих букв я, обычно, только первую помню потому что она первая и L потому что она Бабра Лискофф :).
Рассказать потом не проблема, проблема вспомнить что какая буква означает.
И это база, которую я не знаю(вернее не помню, но это одно и тоже)
"Не дожидаясь отказа, свою кандидатуру я снимаю сам." (c) некто по фамилии Эйнштейн
если человек способен зазубрить то и в работе у него все будет хорошо
Как раз практика показывает, что если человек способен зазубрить, то он способен зазубрить и больше ничего. Обычно тупой зубрежкой как раз компенсируют неспособность самостоятельно решать задачи.
Не везде и не всегда. Есть правила наработанные практикой которая отличается от теории. Потому что последняя не учитывает пограничные случаи. Та же сортировка. Один алгоритм работает быстрее в случае почти отсортированных данных, другой незаменим если мало памяти и тд и тп. Новичок может не знать какие именно данные поступают из очереди и тогда ему проще заучить то что говорят более опытные коллеги.
Опять таки вопрос времени. Книжка Кнута размером в три тома замечательная и после неё ты точно будешь разбираться в теории и сможешь ответить на любой вопрос. Но есть ли у тебя время на Кнута? И сотни других книжек.
Я думаю что в чём-то конкретном программист должен разбираться досконально. В остальном можно зазубрить. Например, если он фронтендщик, ему не надо разбираться в node.js, достаточно запомнить пару команд как быстро поднять сервер локально, дальше пусть devops парится.
Не путайте "уметь пользоваться на уровне пользователя" и зубрежку. По факту, как в школе, выучить, значит и понять, нужно только "таблицу умножения". Остальное нужно уметь выводить путем логических размышлерий. А зубрежка, даже, так и называется, что отскакиевает от зубов минуя мозг и этап размышления.
Проблема базы в том, что база - это бесконечные знания. Базой можно назвать все, от простых функций до того, как работает компилятор и как работает GC под капотом. В общих чертах понимать, конечно, надо, но точно знать последовательности и точные названия каждого уровня языка и каждого этапа выполнения - просто нереально. Плюс к этому, знания чисто энциклопедические, в реальной жизни почти не используются. Поэтому забываются, а вспомнить все перед собеседованием - просто невозможно.
Я знаю базу языка Delphi, ты знаешь базу языка java, а собеседование на разработчика python. Если я буду тебя спрашивать свою базу ты на нее сможешь ответить?
Для начала стоит определиться что такое "база". В моем понимании это те вещи которые проходят на курсе CS в вузах. Туда входят структуры данных, алгоритмы, реляционные базы, распределенные системы. Что касается языков то некоторые компании вообще не проверяют знание конкретных языков и платформ, ну например тот же яндекс. Во вторых каждый язык использует какую то парадигму программирования(процедурная/функциональная/ооп и т д), возможно есть какие то нюансы в реализации но суть обычно одна и та же везде, вот эту базу и можно спрашивать.
А в чем собственно проблема вопросов по базе?
Как минимум проблема в том, что если я начну спрашивать свою "базу" у человека, который меня интевьюирует, он посыпется на первых же вопросах, потому что в отличии от него, я к собесу готовился) В итоге мы друг другу докажем, что оба идиоты. Ну и смысл?
вкатыши в айти которые знают только то с чем работали и нафиг не нужны
Я в айти уже считай 10 лет. И, удивительным образом, я знаю только то, с чем работал :) А то, с чем не работал - не знаю. Да и не стремлюсь особо. Знать всё невозможно и не нужно.
IMHO, основная проблема вопросов по базе, что многие путают низкоуровневые нюансы и базу.
Вместо того, чтобы задать общий вопрос по архитектуре на понимание принципов, задают по деталям реализации конкретной фичи в конкретном фреймворке/библиотеке.
Мало кто пытается на интервью выяснить что человек знает, чаще стараются что не знает.
Я провел сотни интервью, у меня треть интервью идет по разным вопросам касательно технологий указанных в резюме. Даже если я не знаком с какими-то технологиями, я могу позадавать общие вопросы, выяснить насколько глубоко человек их копал. Да и для себя полезное узнать.
а что за пренебрежение к тем кто хочет "вкатиться в IT" ? может если бы в нашей стране норм ЗП получали не только нефтяники и ITшники то может быть и вкатышей не было бы ?
А то странно ругать людей в стране скатывающейся в "темные века технологий" что кто то хочет вкаиться в IT
Или вы предлагает людям работать за 15 000 в пятерочке или медсестрой которая вам же будет вводить лекарства и желательно чтобы она была не уставшая чтобы не перепутать лекарство и раствор хлорида натрия
А как же тогда повыделываться знанием алгоритмов?
Мне кажется пара реальных сценариев из жизни может быть гораздо интереснее литкодинга. Начать например так - ты знаешь что такое рекурсия. Окей, а вот допустим у тебя есть рекурсивный алгоритм, но внезапно вылетает stackoverflow - а что это? А почему это - и как ты решишь эту проблему.? Оо, развернешь в стек или очередь, здорово. А слышал про хвостовую рекурсию? А в C# она есть? А где есть? Ооо, а ты использовал F# для реальных задач в проектах? Расскажи. А что ты еще знаешь про приемы функционального программирования, если мы пишем на C#? А что такое Result<T> и где он используется?
Вот я считаю что такая беседа была бы очень крута и сразу бы выявила сильного разработчика. В принципе клубок в любую сторону можно разматывать, и по многопоточности, и по вебу итд. По беседе вообще обычно сразу становится понятно.
Не могу не поддержать такой подход. Самый лучшие мои собесы были именно такого рода. Они же оставляли после себя самые приятные впечатления, независимо от успешности самого собеседования.
Это и собеседованием сложно назвать. Скорее обмен мнениями, диалог специалистов или что-то похожее.
Вооот. Вы рассказываете про индивидуальный грамотный подход человека, которому нужно найти кандидата в свой проект. Но, к сожалению, довольно часто применяется подход, когда собеседуют на абстрактную должность в абстрактный проект. И тут уже остается на совести интервьювера как относиться к собеседнику.
но внезапно вылетает stackoverflow - а что это?
Это сайт, с ответами на все вопросы)
Знание стандартного алгоритма освобождает от необходимости его применения в коде. Ну потому что потому что уже написано написано до нас, библиотека, модуль, пакет.
Нестандартный, специфический алгоритм придумать самому - это не нужно. Тимлиду не нужны какие-то изобретатели. Ему нужны 1) рабы. Разрабы. 2) Зерги, что тоже самое. Чтоб работали, делали, что скажут, а не изобретали. Тимлид (отечественный, с другими дела не имел) должен быть посредственностью, работающей на результат, на синицу здесь и сейчас, чтоб успеть к сроку. Для зерграша ему нужно много еще более дешевых юнитов, посредственных посредственностей, но, однако по-своему мотивированных.
Суперюнита или нескольких можно прикупить одного на полставки или там сдельно - под конкретную задачу. Это хорошо и правильно. Так можно закончить проект успешно и получить денег на новый. И остаться тимлидом.
Общался в среде литераторов - они конкурсы проводили, на которые писатели подавали свои рассказы. Повыделывался знанием сортировок.
Причем все по классике. Обсуждение пришло к тому, что не понятно как бить участников на группы в случае, если работ будет много (вернее можно бить так - но такая проблема, сяк - другая проблема). Было предложено решение бить на группы в зависимости от размера текста (критерий: дать членам жюри читать одинаковый размер чистого текста при разном количестве рассказов). Идея была одобрена. А потом все вспомнили, что тут в среде людей искусства есть еще и скромно молчащие айтишники...
Мораль - повыделываться алгоритмами можно вообще в отдельной от айти среде. И даже нужно. Но спрашивать алгоритмы, чтобы узнать про алгоритмы такое себе конечно.
В резюме надо вчитываться и корректировать свой пул вопросов под конкретного человека, продумывать тактику разговора.
Чаще всего в резюме написано что "работал работу", ещё может быть стек указан, но сразу на весь срок в компании на протяжении 5+ лет.
Во что тут вчитываться и что корректировать?
Резюме со ссылкой на Github я ещё не встречал.
Правда встречал со ссылкой на Stackoverflow, только там реальная активность была 5+ лет назад, а потом всё - ни вопросов ни ответов - что мне дал это профиль? В чём смысл оставления этой ссылки в резюме?
Чаще всего в резюме написано что "работал работу"
Ну если кандидат про все Х лет своего опыта поднатужился и выдавил только "работал работу", то не зовите такого кандидата, не вчитывайтесь и не корректируйте. И в целом я не согласен с "чаще всего". У нас сейчас на HR доске где-то 15 кандидатов висит. Почти в каждом резюме глаз за что-то цепляется.
И в целом я не согласен с "чаще всего".
У нас сейчас на HR доске где-то 15 кандидатов висит.
Почти в каждом резюме глаз за что-то цепляется.
Более 20-ти собесов с июня - подробности по проектам были хорошо если у 4-5 человек
Ссылок на GitHub ноль и, как я уже говорил, одна на заброшенный Stackoverflow.
Да, у некоторых есть за что зацепиться, но это именно исключение из правил.
У меня вот такая статистика.
Как-то странно. Если человек 15 лет отработал в ИТ, но давно забил на личные проекты, а в свободное время выращивает помидорки - он уже не кандидат?
ага. А если он работает по 8 часов в день с двумя выходными в неделю - видимо с ним уже вообще не о чем разговаривать :-)
Вы же даже не поняли о чем речь. Какие личные проекты вообще? Речь про людей, которые пишут что-то типа "работал в ООО Рога и Копыта с 2012 по 2019, правил баги, делал фичи" - и все, другой информации нет. На чем писал, чего достиг, какие проблемы порешал?
То есть кандидату лень нормально составить резюме, но я почему-то все равно должен его пригласить и потратить время на лишние распросы?
ну, иногда может быть такое, что кроме "правил баги, делал фичи" и написать то нечего. ну вот какая нибудь большая контора, огромный проект, всякая мелочь идёт непрерывным потоком, человек пашет не поднимая головы, задачи выполняет. А вспомнить и описать толком нечего
Да можно, стоит тлько поднапрячься. Наверняка среди багов были и супер важные, про которые и стоит расписать их важность и столько денег терялось пока я героически не починил. И не супер важные но интересные и редкие, про которые тоже есть что сказать.
Ну а про фичи и тем более - всегда можно найти и важную и уникальную.
p.s. попросите ЧатГПТ помочь, ставлю десятку он придумает что написать
можно. Если поднапрячься и выдать красивую картинку для удовлетворения чувства прекрасного интервьютера. Но реальная картина зачастую именно - быстро и качественно делал непрерывный поток разной мелочёвки. ну вот было у человека за несколько лет в этом потоке что то интересное. и потратил он на это неделю-две-три-месяц. Или даже не месяц - или даже потратил он час и выдал гениальное решение, от которого у всей конторы наступило щастье. А потом ещё несколько лет сидел в потоке разного. Что его больше характеризует - единичное озарение или способность устойчиво выдавать приемлемый результат?
Если поднапрячься и выдать красивую картинку для удовлетворения чувства прекрасного интервьютера
В общем лайфхак от капитана Очевидность: резюме как раз для того и пишут, чтобы сообщить о себе нанимающей стороне, показать себя в лучшем свете и пробить приглашение на собес. Это буквально единственное назначение данного документа. Если резюме такую функцию не выполняет, то зачем оно вообще?
Ого, я думала, что ссылка на GitHub должна быть в каждом резюме, если конечно у человека есть там что-нибудь за относительно недавнее время...
Моя личная статистика бытия собеседующим тимлидом говорит, что у человека 25+, имеющего несколько лет опыта работы и метящего в мидла или выше, вероятность встретить пет-проекты стремится к нулю.
Люди проводят время с семьей или с самим собой, крутят гайки в машине, путешествуют, катаются на лыжах, ходят в походы, танцуют, и свободное время используют для социализации. А если что и будет - в 99% это что-то, решившее проблему конкретного человека, и который сделал это для себя, возможно совершенно неоптимально, не покрыв тестами и т.д. Так сказать, as is.
К тому же, за крайне редким исключением, у всех компаний код под NDA, и как следствие - 8+ лет опыта у меня есть, гитхаб тоже, а показать есть говнокод 10-летней давности)
Ну зачем в каждом - у людей есть жизнь вне работы, а нормальный отдых залог хорошей работы. Кому-то стыдно выкладывать свой код в паблик и люди пишут пет проекты в приватных репах. У кого-то корпоративные политики запрещают выкладывать любой код в опенсорс так как считается что конфликт интересов (можно согласовать свой личный проект у юристов фирмы, пройти еще этапы согласований и вообще заморочится, проще уж ну его) и т.д. и т.п.
Подскажите мне, я вот почти 10 лет уже являюсь ETL-разработчиком (Oracle BI + Oracle Data Integrator). Я вот смотрю на свои огромные схемы ETL-процессов и не понимаю каким образом я это должен выложить на github? А еще у меня куча разработанных дашбордов в BI, скриншоты может мне выложить на github? или я просто не разработчик? Так пишите как будто сами вот только-только вкатились в айти
Я стараюсь везде давать ссылки на GitHub, StackOverflow, не только в резюме. Смысл этого в том, что я того же жду и от других. Категорически императив что ли.
Если готовиться нужно с обеих сторон то выходит такая ситуация что на собес приходят люди играть роли, роли тех кем на самом деле в "миру" не являются. Корчим из себя не пойми что в итоги и нанимаем не пойми что.
Структуры и Алгоритмы это не база, это всего-лишь одна из граней Компьютерных Наук. У нас даже предмет такой был, САОД назывался. И теперь, 25 лет спустя, я узнаю что это оказывается была "база" и без неё ты никто и звать тебя никак...
И да, 50% кандидатов заваливают простейшие вопросы по коллекциям - а это ведь основа.
Значит их сфера ответвенности лежала совсем в других областях программирования.
И теперь, 25 лет спустя, я узнаю что это оказывается была "база" и без неё ты никто и звать тебя никак...
Представляете какого людям, вроде меня, у которых вообще формального образования в CS нет. Все мои познания в "базе" - это обрывочная информация, которая поступала в мозг путём чтения случайных и не очень книг.
При этом это совершенно не мешает мне работать) Просто когда что-то нужно, я трачу день на то, чтобы разобраться) Понимаю, что в мире стартапов и вообще везде, где баги нужно фиксить мгновенно, мне делать нечего, но не одними стартапами едины. Есть и болотца попроще.
Сейчас вообще есть ChatGPT, который мне и подводные камни подскажет в случае чего, и примеры напишет и вообще распрашивай не хочу) Я согласен с тем, что в целом понимать архитектуру ЭВМ и "архитектуру" алгоритмов и структур данных бывает полезно, но только на уровне "могу порассуждать". Знания уровня даже Leet Code medium обычно не нужны никому.
как часто в работе над реальным проектом вам нужны знания тонкостей реализации коллекций? Насколько велика вероятность, что какой нибудь супер пупер сеньёр не менявший работу последние N лет и за это время поднявший какую нибудь большую систему сходу вспомнит эти тонкости?
Из десятков собеседований у меня было только одно, где проверяли не мою память, а мой навык рассуждать и уметь находить решения. Хотя, перед этим ознакомились с пет-проектами.
Интервьюер не заваливал вопросами, не пытался давить. Он просто рассказал про команду, задачи и описал общий процесс работы. После чего мы ненавязчиво перешли к собеседованию в стиле - а давай представим, что нам с тобой нужно реализовать приложение для учета горюче-смазочнвх материалов на АЗС (далее шло условное ТЗ) и мы начали думать (вдвоем!!!). Накидали диаграмму условной бизнес-логики, потом плавно перешли к реализации некоторых задач. Это было самое длинное, но самое шикарное интервью. Интервьюеру не были интересны мои академические знания или то, как я вызубрил мифическую базу. Он не пожалел времени, чтобы выяснить мой скилл поиска решений и информации. И, кстати, было видно, что ему и самому интересен такой процесс прощупывания соискателя. В итоге, я с околонулевыми знаниями зашел в команду и проработал там пару лет. Команда тоже оказалась офигенной, продуктивной и в какой-то мере фанатичной и тоже многие вошли так же, как и я - с околонулевыми знаниями и росли как спецы уже на проекте. Побольше бы таких вникающих и проницательных специалистов на собесах и тогда жить стало бы проще. Действительно тупые соискатели отсеивались бы автоматически, а люди с перспективами в недалеком будущем, но околонулевыми знаниями сейчас - спокойно заходили бы на позиции.
Вот и получается, что собеседования в России - чистой воды рандом
Согласен полностью! Хожу по собесам и первый вопрос: 'Что у вас с английским?'. Резюме моë состоит из 10 строк, а в 3й строке написано, что преподавал английский в университете 10 лет)) Сидишь и просто не знаешь, что ответить))
Может поделитесь опытом проведения интервью. О чем стоит спрашивать кандидатов? К примеру, я обычно спрашиваю о старом опыте, проектах, как устроено и почему. Бывает даю задачку на подумать, как человек реализовал ту или иную фичу, как декомпозировал фичу, какие компоненты бы реализовал.
Про то, что проходить собеседования - это отдельный скилл, отличный от решения реальных задач на работе, и его надо "качать", написано много. Теперь, вот так сюрприз, оказывается, что проводить собеседования - это тоже отдельный скилл, и его тоже надо "качать". Только вот у проходящих собеседование есть хорошая такая мотивация (кушац-то хочется) и скилл качать, и над обратной связью порефлексировать, а у проводящих эта мотивация не очень хорошая (особенно если на собес дёрнули погрязшего в срочно-важных тасках обычного разраба) и цикл обратной связи подлиннее (1-3 мес нанять, 1-3 мес понять что "тянет"/"не тянет"). Вот и имеем что имеем. Как только тимлиду/руководителю разработки припечёт - наймут первого подходящего.
Мне видимо дико везло - я всегда попадал на такие собеседования, где у нанимателей (Сбер, Точка, Альфа-Банк) каждый раз получалось меня искренне заинтересовать работой и стеком технологий. Большую часть времени они давали мне самому рассказать о своём опыте и уточняли некоторые моменты. При этом это было сделано максимально дружелюбно и не было ощущения, что пытаются на чём-то подловить.
Потом они рассказывали о том, чем надо будет заниматься и их интересовали мои знания этих продуктов или схожих. Из того что я не знаю RabbitMQ не делалось трагедии, они просто интересовались на каком уровне я вообще знаю работу брокеров, например. Но это были в основном люди 30-35+, уверенные в себе, которым ничего не надо себе доказывать и которым был нужен специалист.
Мне кажется интервью с кандидатом должно быть основано таким образом, чтобы понять что человек ЗНАЕТ. А не то, чего он НЕ ЗНАЕТ. Понять, насколько он мотивирован что-то узнать и выучить. Мотивирует ли его работа с новым стеком, или он хотел бы заниматься точно тем же, чем занимался раньше? Горят ли у него вообще глаза? Какие у него софт-скиллы - насколько он коммуникабелен, не стесняется ли спрашивать других людей для экономии своего времени. Можно спросить про подход к обучению новому стеку (как он это делает), это тоже о многом говорит.
Вопросы, на которых кандидат посыпался или долго думает можно отложить и вернуться к ним в конце интервью, чтобы кандидат не "закрылся". Я видел, как люди сильно "подтупливают" на каких-то вопросах в начале собеседования, но при повторном вопросе в конце собеса отвечают очень точно и чётко. Хорошее собеседование это когда был интересный для обоих сторон диалог и когда ты понял свои "слабые" места, но это у тебя не вызывает фрустрации и чувства никчёмности если тебя не приняли, а вызывает желание учиться.
а у вас были кандидаты, которых ваш сеньор с ролью техлида одобрил? может сперва с ним обсудить подход к отбору?
Да, были, но их уровень знаний и опыта был выше, чем финансовая часть, которую мы могли предложить, по этой причине были отказы уже со стороны кандидатов.
А ларчик просто открывался :) То есть кадры есть, просто нет на них денег. Тогда может с техлидом обсудить, что на "сеньоров" как он их видит, нет денег, есть на мидлов? Чтоб требования тоже были пониже.
Вот и ответ на все вопросы. Бизнесу не нужна звезда. Ему нужен человек работу работать за имеющийся бюджет.
А техлид хочет работать с крутыми специалистами.
Вывод: человек просто не на своем месте, так как не понимает потребности бизнеса. Все же техлид это не только про хард скилы.
Вот до этого комментария не хотел писать, что техлид дурак, но теперь напишу )
У вас одна проблема в команде
Может просто техлида поменять и дело пойдёт быстрее?
Хотя бы просто попробовать не пускать на собесы.
Как бы раньше тимлида не поменяли за то что тот не может "организовать работу" с командой. Походу там тупо личный конфликт между тех и тмлидом
ну тут вопрос, кого поменять проще. У меня знакомая hr в одной компании как то 10 месяцев не могла закрыть позицию. то одно техлиду не нравилось, то другое.. при этом сроки горели, баги лезли косяками, техлид героически превозмогал и показывал свою незаменимость работая до 10 вечера и по выходным. А кандидаты все какие то не такие были - ну вот никак не могли ответить на простейшие вопросы и показать знания элементарных алгоритмов. А потом техлида ушли. И позицию закрыли за неделю - просто взяли одного из ранее отвергнутых кандидатов. И работать он стал более менее по 8 часов. и со сроками и качеством стало получше.. только говорят периодически матерился на код ушедшего техлида..
Я не утверждаю, что тут та же ситуация, но почему то из опыта - когда сильно докапываются по формальным параметрам - обычно на проекте творится всякое.
А бывают случаи, когда разработчики не матерятся на код своих предшественников?
Дзэн левел называется, когда понимаешь что то что ты видишь такое себе, но ты не застал всей эволюции и не понимаешь почему оно стало тем, чем стало, что ну возьмешь и перепишешь даже, то может и получишь +- то же самое когда соберешь все грабли, может получится лучше, но все равно через годы ты, и те кто пришли после, будут смотреть на твой код и материться. Так что зачем тратить время и нервы на маты, просто пожимаешь плечами и пытаешься сделать то, что сейчас в твоих силах чтоб стало хоть немного лучше
Дзен левел это когда ты постиг "работает не трожь, а если трожь, то напиши сначала юнит тесты с полным покрытием".
Так что зачем тратить время и нервы на маты, просто пожимаешь плечами и пытаешься сделать то, что сейчас в твоих силах чтоб стало хоть немного лучше
А потом такой фидбек от хрюшки на интервью " у него нет интереса к продукту, глаза не горят"...
В принципе, у меня было даже наоборот однажды. Я пришёл в проект на чистом Си и такой: "вау, как всё круто и удобно сделано, буду делать теперь также" :) Я даже немножечко разлюбил С++, настолько был код хорош, прост, понятен и расширяем. Но там и сам проект - это была относительно небольшая библиотека, которая писалась без спешки и делала хорошо поддающийся декомпозиции функционал, который был отлично документирован.
Иногда чудеса случаются)
Ну, честно говоря, техлид, который заваливает кандидатов вопросами по "Базе" и тимлид, который в кризисной ситуации вместо того, чтобы обсудить проблему с техлидом и начальством побежал по собеседованиям в другие компании и винит теперь "Потерянную культуру рекрутинга" достойны друг друга, сладкая парочка.
Увы, вот такое как в статье поведение демонстрируют многие начинающие тимлиды, вчерашние разработчики - в проблемной ситуации делать то, что умеешь лучше всего - ходить по собеседованиям.
А вам не кажется что вполне логично походить по собесам в другие компании чтобы понять как можно улучшить собственный процесс найма в компании?
А разве в статье сказано, что проблема не обсуждалась с руководством? При этом как раз сказано, что пошел по собесам из любопытства как нынче проходит отбор в других компаниях
К сожалению, подобные обсуждения на практике редко приносят пользу, даже если состоятся.
Кроме того, автор нигде не упоминает, были ли "разборы полетов" с техлидом или начальством. Так что походы на собеседования хотя бы в ознакомительных целях (посмотреть как работают в других компаниях и узнать сколько сейчас стоишь на рынке) не считаю чем-то неверным. Скорее, даже наоборот.
Эта проблема уже обсуждается и уже не в первый раз. Если бы я был плохим тимлидом, то конфликт с техлидом был бы уже в рутинных задачах. Возможно открою секрет, но одним из важных факторов утвердить должность специалиста является авторитет самого специалиста в его области работы. Так же и здесь. Техлид является авторитетом для начальства как "технический гуру", по этой причине равный мне голос при выборе кандидата.
Я не начинающий тимлид и скажу, что один из основных навыков - это умение работать с разношерстными людьми и получать явный результат. Создать конфликт и бежать к начальству со словами "Меня обидел техлид, он не хочет дружить с теми, с кем хочу я", вот это поведение начинающего тимлида.
А на счёт решения, универсального нет, как в технических, так и в управленческих задачах. Нужно всегда учитывать много факторов, которые затрудняют решение, а в каждой команде в разных компаниях они разные. Да и статья не голден хаммер по решению вопроса найма разработчиков, а по большей части описание личного опыта и приход к проблемам, которые присуще найму айтишников в целом.
А у вас техлид не устал ли случайно до той степени, что у него сил нет на принятие решений, и он "нет" говорит просто потому что так легче? Может, ему в отпуск?
Эта проблема уже обсуждается и уже не в первый раз.
Супер. Первая часть алгоритма решения проблемы выполнена - поговорили . Хотелось бы перейти ко второй части - договориться о решении . Потом, понятно, претворить это решение в жизнь, ну и про четвертую часть, уверен вы тоже знаете.
>> Создать конфликт и бежать к начальству со словами "Меня обидел техлид, он не хочет дружить с теми, с кем хочу я", вот это поведение начинающего тимлида.
Именно. Последнее, что вам нужно - это создавать конфликт и жаловаться. Не надо так делать.
Судя по тому, что формат собеседования и критерии оценки со стороны техлида для вас раз за разом оказывались сюрпризом - вы с ним по делу не говорили, а между тем, вопрос "А почему он себя так ведет" у вас сейчас один из основных.
Вы уцепились за самый простой ответ "Он упырь и упрямый долбоящер, который понятия не имеет как проводить собеседования", а между тем все может быть совсем не так.
Может быть, у него годовая премия зависит от того, насколько теоретически подкованными будут нанятые кандидаты. Может быть его к вам приставили именно потому, что у начальства есть подозрения, что без няньки вы наймете слабых людей. Может быть, в целом у начальства есть сомнения в, так сказать, engineering excellence в организации и оно решает проблему таким способом - попросив техлида "Пожощще там спрашивать на собесах". Может быть, что-то похожее думает сам техлид. Можно сколько угодно гадать, но пока вы с ним продуктивно не поговорите, можно будет долго изучать "культуру рекрутинга" в других компаниях, пока у себя найм стоит.
Здесь мы, понятно, исходим из того, что техлид и сам хочет нанять лучших из возможных кандидатов в том смысле, в котором он это понимает. Если он саботажник, то дело другое, но это, конечно, маловероятно.
По переговорам с начальством у вас в статье упоминается, что на вас давят через техлида ( WAT?! ) и что задаются вопросы о медленно достигаемых результатов. А вы-то какие запросы к ним адресуете? Чего от них хотите, что предлагаете?
P.S. Нанять человека без обсуждения с техлидом, типа протащить, когда он будет в отпуске - это бомба замедленного действия, собственноручно подложенная под проект.
Просто тимлидировать и рекрутировать это две разные компетенции, не всегда сосуществующие в одном человеке. Поэтому что для компании важнее, той компетенции она и должна (в идеале) отдавать предпочтение. И не спрашивать по другой как по само собой разумеющейся.
Нет противника страшнее, чем союзник-идиот
На самом деле и сами специалисты, в том числе, перенапрягаясь чтобы их взяли в такие компании создают эту проблему.
Понятно, что сейчас, на самом деле, реальная проблема в рухнувшем объёме рынка, но то что устроиться не реально это следствие именно "тупости" самих разработчиков. Под "тупостью" я понимаю общий интеллект, т.е. и софт-скиллы, потому что умения написать гениальный алгоритм недостаточно чтобы быть в общем адекватным человеком.
Проблема так же и в том, что собесы эти сами айтишники эти и проводят, многие из которых вообще слабо одупляют даже в собственной профессии в общем, зато наизусть заучили ту самую базу.
Интересно как собесы будут через пять лет выглядеть.
Компании, имеющие адекватные стандарты собеседования и ищущие специалистов для решения задач либо ушли, либо уже имеют таких специалистов, а они в свою очередь знают, что сейчас на рынке, поэтому и не покидают свои места.
А ещё вакансии в адекватные компании долго не висят и закрываются мигом, т.к. никакого "дефицита специалистов" нынче нет даже близко и найти кого угодно сейчас можно с полпинка. Поэтому когда видишь такую которая висит месяцами, это явный сигнал что там хрень какая-то, и лучше не тратить на них своё время.
Одна контора вывешивала одну и ту же вакансию техлида трижды за год. Либо брали неподходящих на два-три месяца, либо не могут позволить себе подходящих. Но если вакансия не закрывается так долго, нужна ли она на самом деле...
Да, тут бесспорно. Хорошие места долго пустыми не будут, как и хорошие специалисты без работы. Но к сожалению, как мне кажется, не всегда хорошему специалисту такое место быстро находится, приходится перебрать и большое количество мусора, чтоб найти бриллиант.
Будут. Наблюдаю тут за одной компанией. Там сменился начальник и понеслось... Условно написано: кандидат должен знать такую-то базовую вещь и три надстройки над ней. На опыте моём я ни разу не видел человека, который знает все три. Максимум две. Штуки крайне специфичные. Вакансии год! Начальник рубит всех, потому что не знают люди все три. Хотя доучить человека дело полутора месяцев(я понимаю, о чем речь, так как стек мой, я тем же самым занимаюсь). И таких вакансий у них уже штуки 4.
Надо понимать что иногда нужно найти кандидата, а иногда нужно искать кандидата.
Начальник рубит всех, потому что не знают люди все три. Хотя доучить человека дело полутора месяцев
ЧТД: вакансия не такая уж и хорошая. С учётом как легко разменяли год на "полтора месяца обучения" - значит не очень-то кто и нужен. Нечего тратить на таких своё время.
Снова отказ от техлида по причине отсутствия пет-проектов и невозможности оценить практическую часть.
А можно было не отказывать, а сказать: "мы подумаем", а на следующий день попросить рекрутёра пригласить кандидата на второе интервью с лайв-кодингом (предупредив о нём).
Судя по всему, в конторе просто не нужен особо человек. Был бы нужен - студента бы наняли бы и научили бы. Тем более на микросервисы, когда зона твоей ответственности ограничивается контрактом, а задача разжёвана аналитиком и декомпозирована лидом.
Судя по всему, в конторе просто не нужен особо человек.
Видимо нужен - если написано было что людей не хватало. Тут другое. Такие как этот техлид это психически больные люди. И их болезнь, разумеется, распространяется не только на собесы. Наверняка на код-ревью докапывается до ерунды, и пофиг что вся разработка от этого стопорится. Видать из конторы все бегут от этого шизика, вот людей и не хватает.
Забава в том, что текущий техлид, это вчерашний сеньор, которому предложили место техлида в новом проекте за выслугу лет и опыт разработчика. Да и я лично не имел честь с ним работать до этого момента и только сейчас мы пересеклись как два специалиста на одном проекте. Благо начальство не глупое и видят проблему найма. К чему оно придёт, к сожалению, сказать не могу, но варианты решения уже предоставил.
Такие как этот техлид это психически больные люди.
...
Видать из конторы все бегут от этого шизика, вот людей и не хватает.
Встречал таких. Выглядит всё оч нелепо. Самое грустное, что заранее таких на чистую воду сложно вывести. А то и вовсе появляются на проекте по чьей-то воле.
У меня на одном собеседовании спросили, какой ассемблерный код сгенерирует компилятор Go для инкремента
Скажу так, я бы с удовольствием покинул IT, но слишком уже много времени и сил вложил в развитие себя в этой области (ещё со старших классов школы). И ничего другого я делать не умею
Ну, думаю, не стоит из-за одного собеседования с немного неадекватным интервьюером вешать нос) Я помню случаи когда и меня спрашивали, как будет выглядеть конечный автомат в async-await механизме в предкомпилированном коде c#. Но мне больше жалко людей, которые задают такие вопросы, так как все их знания и мир, как мне кажется, сконцентрированы на подобных вещах.
А по поводу того, чем бы заняться вместо it думаю любой выгоревший специалист думал. Даже я в какой-то момент подумывал просто скопить начальный капитал и заняться своим делом, достаточно банальным и без особых сложностей в процессах, но приносящих денег на уровне работы it-специалистом.
Да и не стоит думать, что другого не умеете) Я всегда был уверен, что большинство it-спецов умные ребята вне зависимости от сферы, но, к сожалению, не уверены в себе)
Ну, я бы предположил, что любой вменяемый компилятор для инкремента сгенерирует конструкцию на безе инструкции "inc", хотя... смотря для какой архитектуры - я только на x86, да Z-80 в ассемблер смотрел...
ничего другого я делать не умею
Газобетон класть всё умеют. Хрен ли там уметь? Верёвочку натянул, да клади :)
Ну не скажите. Видел я дома из газобетона с сантиметровыми швами которые сводят все преимущества материала в ноль. В идеале его вообще кладут на пену, но для этого нужен хороший завод с правильными допусками. Если человек не знает базу (теплопроводность газобетона) он положит как кирпич и будет глубоко не прав.
Видел я дома из газобетона с сантиметровыми швами которые сводят все преимущества материала в ноль
Ну, не то чтобы в ноль, свойства материала никуда не денутся, но режим подпортит, да.
В идеале его вообще кладут на пену
На сей счёт полного согласия среди специалистов пока что нет. Внутри помещений - да, никуда оно не денется, а лишнюю сырость разводить ни к чему. Дом строить на пене... я бы не стал.
Ну не скажите.... Если человек не знает базу...
Уточню. Любой ойтишнег (который ещё не достиг ожирения) может домики строить или там атамабили починять. Он же как привык: берём туториал и делаем по нему. А потом полирнём теорией. Ну или наоборот. А туториалов по стройке, причём очень хороших, в сети - завались! Поэтому да, любой освоит, было бы желание :)
Уже давно полное согласие специалистов в том, что класть удобнее на тонкий слой клей-раствора по горизонтали, и три-четыре полоски клей-пены по вертикали, дешевле просто на клей-раствор, и качественнее и надежней на клей-пену (при нормальных допусках геометрии блока). И да, строитель который боится клей-пены это человек, который не разобрался в вопросе и не хочет этого делать, что по сути профнепригодность и причина с таким не работать.
Не все хорошие техлиды - хорошие интервьюверы.
Все истории выглядят так, что техлид отбросил кандидатов по неадекватным причинам.
Я и сам таким был. Помню как гневался что приходится работать с людьми, которые не понимают почему float width = 1 / screenWidthPixelsCount; дает ноль.
Я бы таких на работу не взял!!!
Хорошо что я лидил, а не брал на работу. Потому что люди приходили, спрашивали почему не работает, получали ответ, исправляли и дальше просто делали свою работу.
А вы не имеете влияние на техлида? Если вы понимаете что техлид неправ, можно поговорить или попытаться отстранить его от собесов.
Потому что нужен Raft и Leader Election, а у вас консенсуса нет.
И в топку вашу базу, если вы не делаете HFT, embedded, web3, cryptography и паблик либы.
оффтоп, но расскажите, пожалуйста, как у вас получается "техлид нового проекта с опытом уровня senior"
Следующий уровень за senior у вас не lead, причём не technical lead?
Похоже что уровень lead над senior встречаю в вакансиях всего как несколько лет. Раньше это однозначно была роль. А уровней квалификации три.
И например teamleadом вполне мог быть middle+
По большей части имел в виду, что текущий техлид это бывший сеньор с большим опытом, получивший авторитет в глазах начальства. А оно, в свою очередь, предложило ему место техлида нового проекта. А тимлидом может стать любой разработчик, начиная с мидла, имеющий неплохие софт скилы и скилы менеджмента. Но, естественно, если есть необходимость в новом тимлиде.
"Крупные it-игроки ушли, с ними ушли стандарты, топовые специалисты и рабочие места. " - в первых же строках статьи автор дает ответ на все вопросы... И боюсь, что это только начало конца - госкомпаниям нет смысла переманивать разработчиков друг у друга бОльшими ЗП, а наоборот - проще сделать ЗП примерно одинаковыми, чтобы не переходили туда-сюда, да и прибыль от госконтракта не зависит от качества продукта (все равно купят), и, соответственно - от уровня разработчиков...
Тут двоякий момент. Если смотреть на уровень зп, то за 22-23 год темпов роста относительно одной и той же позиции почти нет. До этого год за годом зарплаты росли как на дрожжах, да и достаточно было пройти несколько собеседований чтоб получить оффер с +30% зп от текущего места. Сейчас таких чудес нет. А на счёт госпроектов сложно сказать однозначно. В основном реализация госзаказа прилетает частной конторе под пристальным взором или управлением свыше. Но it-шники тоже не дураки и работать за прайс ниже того, к чему они привыкли не всегда хотят. Из-за этого постоянно будет появляться конкуренция продуктов в тех или иных бизнес-доменах. Хотя есть один продукт-монополист в своей сфере в странах снг, 1с, но это частный случай.
распространенное заблуждение. Куча "новосозданных аккредитованных IT организаций", выделенных из штата, стали пилить свои продукты для широкого рынка, а не только для внутреннего заказчика. Соответственно и появляется конкуренция. Одних только альтернатив зуму и скайпу я уже десяток могу насчитать.
Либо проблема в техлиде либо автор чего-то не договаривает. Не хватает точки зрения второй стороны.
Прохождение интервью тренирует лишь скилл прохождения интервью. А по делу, обратный лайвкодинг не пробовали? Например, берём типовой алгоритм, делаем переменные неочевидными и под руководством кандидата рефакторим его на предмет нахождения имени алгоритма. Тут тебе и навыки чистого кода, и работа в паре, и реверс (программист он в первую очередь хороший читатель). Попутно про всякие биг-О можно поговорить и степень глубины знаний выяснить. Не стрессово, на полчаса времени, приближено к ежедневной рутине.
Это если рутина - копаться в легаси в попытке понять что там диды напридумывали внукам на головную боль.
Легаси это активы компании в которые вложены финансы, иногда очень серьёзные. Переписывать всё с нуля в угоду программистов это так себе вариант, особенно если бизнес привык считать деньги.
На почасовке без разницы сколько проектов поддерживать, на каком они стеке и насколько модны. Хехе, наверное я стар, если вижу в лигаси историю успеха компании. "Возвращаю тех.долги, дорого."
Кстати, мое самое лучшее собеседование примерно так и выглядело) Прошла его на ура и досрочно, получила оффер)
Хмм, интересно, не пробовал, стоит поразмыслить на счёт этого, спасибо)
Не за что. Собеседования кандидата сократились до двух звонков общей длительностью в полтора часа - 30 минут знакомство, 30 кодинг, 30 поведенческое финальное. Вы все равно не узнаете как сотрудничество пойдет через 3-6 месяцев. Кандидаты тоже занятые люди, и скажут спасибо за гуманное отношение. ФААНГ может позволить себе разбрасываться талантами, то набирая, то увольняя, а у маленьких лояльность это критический актив.
У меня было два лучших собеседования за последние 3 года (на самом деле значимых всего 4 за >20 лет, но пара из них не считается).
Исходно:
0) Удалёнка, Россия.
00) После пробивки HR (BTW, резюме читали, это уже плюс, но идиотские вопросы "почему ушёл" - сразу в минус, как и "почему к нам")
1) Тимлид: не будем тянуть кота за, вот два тестовых задания.
За второе даже не брался, после первого сразу оффер.
Расстались, увы.
2) Совсем недавно.
После первого созвона: "OK, дай мне минут 40"
???
"Посмотрел твой гитхаб, мне спрашивать нечего, давай начнём" (первый! за столько лет! не трахал мозги мусорными вопросами про коллективные ценности, и олимпиадными подколами, а посмотрел в реальный код)
Работаем :-)
А можно посмотреть твой гитхаб?
Да ничего интересного там нет. Так, какие-то ошмётки чего-то личного, да и то нерегулярно. Тут, скорее, сработало попадание в предметную область, конкретно вот эта мелочёвка - как затравка для более предметного разговора, безо всяких вступлений.
На этом моменте я усомнился в адекватности техлида.
то есть раньше таких сомнений не возникло ? 8-0
Можете написать, что у вас там была за задачка с литкода?
Я думаю правы оба, и техлид, и тимлид.
Без базы я бы не стал брать даже толкового программиста. Просто потому что есть риск в определённый момент нарваться на труднообнаруживаемые баги, которые принесут много неприятных часов в продакшине.
Расскажу пример. У нас закончился очередной проект и освободилось время. Мне дали задание поискать потенциальные проблемы в многопоточном C# коде проекта соседнего отдела. Код вполне рабочий, продажи идут. Через пару дней число заведённых мною багов перевалило за сотню и мне сказали "горшочек не вари". В основном потенциальные race conditions и незащищённые переменные которые могли изменяться одновременно несколькими потоками. С одной стороны пока не падало, с другой упадёт мало не покажется.
Но и вредничать особо тоже не стоит. Если в конторе культура кода и техлид покажет как и что делать - проблем не будет даже у тех кто плавает в базе. На то и техлид чтобы делиться знаниями и делать мир лучше. Если он социопат - пусть пишет КБ и делает код ревью.
Я вот как раз с последним случаем столкнулся - техлид не собеседует кандидатов. В итоге интервью проводили ребята из соседнего отдела и человек тупо не понял куда он попал, в итоге мучается, хотя мог бы выбрать другую компанию (было два оффера).
Совсем недавно было забавно, техинтервьювер думал подловить на вопросе чем отличается tas от ttas в спинлоке, а я совсем недавно эту тему копал немножко ну и выложил ему теорию и пять или шесть реализаций того и другого, еще и графиков нарисовал. Были круглые глаза и они с лидом полезли смотреть в гугль чем они реально отличаются, потом вопрос "А зачем тебе это?". Тут уже я сослался на митинг и ушел с созвона
Да, было то же самое на вступительном экзамене в ВУЗ когда я умудрился за день до этого прочитать книжку про гравитацию и получил билет по теории тяготения. Спустя полчаса оба экзаменатора просили меня остановиться.
Та же фигня :) В школе, выпускной экзамен по химии, мне досталась тема по полупроводникам (или конкретно про кремний, не помню). Экзамен устный, с подготовкой на доске. Я что-то быстро подготовился и, пока коллега отвечал, я начирикал на доске картинки из книжки Степаненко (учебник по микроэлектронике для ВУЗов), который как раз в то время листал, и заодно рассказал физику, как там орбитали устроены и как примеси влияют на тип проводимости.
Педагоги были слегка в ахере, но в целом довольны :)
Вот в этом и есть лоттерейность собеседований. База безгранична, всю не объять и не выучить, кандидат повторяет то, что считает нужным, а интервьюер базу по-другому определяет. Если совпадет, то хорошо, бинго) И неплохо бы, чтобы компании, раз уж из собеседования экзамен устраивают, выкладывали бы список вопросов, как в вузе за семестр. И пусть кандидат тянет билет, чтобы у него был шанс вытянуть единственно выученный счастливый билет))
В точку, как раз один из моих пунктов об этом) Если пазл представления о базе интервьюера сходится с базой кандидата, то происходит коннект)
А это кстати классная идея. Опубликуйте условных 100 вопросов (ну если так уж и хочется проверить "базу"), и если кандидат не подготовился по ним, то это уже говорит и про кандидата тоже. А с другой стороны, кандидат по "вменяемости" вопросов получит представление о интервьюерах.
Хожу на тех. собесы чтоб держать себя в тонусе и подтягивать скиллы.
Я тебе Google что ли, я забыл это уже давно. Отстань, у меня интеграция нереализованная.
Удручает ситуация, когда компании среднего уровня берут задачи для собеседования от Google и хотят чтоб кандидат решил их за ограниченно отведённое время (весь тех собес ~1ч 30м).
Что самое забавное, в этих компаниях работники занимаются перекладыванием json между микросервисами. И никаких тебе низкоуровневых, требующих реального знания алгоритмов, задач.
У Google и Яндекса такие собеседования из-за того что они ВСЁ реализуют сами. Остальные 95% пользуются готовыми решениями, и как правило лучшими, чем если бы вы написали их сами.
Но теперь очень мало компаний, умеющих расположить к себе. Очень мало компаний, которые сразу тебе скажут, на что ты подписываешься. Очень мало адекватных собеседующих и правильной культуры проведения собеседований.
У меня сложилось мнение, что таких компаний больше среди тех, у кого есть требование работы в офисе.
Из своего опыта - самое приятное собеседование было на должность руководителя довольно крупного подразделения. Отправил резюме, на следующий день прислали ссылку - с текстом с Вами хочет побеседовать директор департамента по направлению. Побеседовали с ним час, причем это был диалог а не экзамен. Вопросы были из серии а какие у вас масштабы, какие задачи, какие показатели, в какую сторону развиваетесь, какой проект был последний, с чем вы на этом проекте столкнулись и тд. Поделился каким-то своим опытом. В итоге меня не взяли, но впечатления остались самые лучшие и никакого ощущения зря потерянного времени
PS возможно, экзамен был бы следующим этапом :-D
Вспомнил как лет 20ть назад ходил на собес в Proctor and Gamble. Мне админ-бородач заранее прислал типичную задачку из его практики, мы поговорили в его каморке под лестницей, он говорит всё отлично, пошли к гендиректору. Поговорил с гендиректором. На следующий день отзвонилась HR. Вы нам не подходите. Я говорю почему? Вы в кедах пришли, а у нас компания серьёзная, директору не понравилось как вы одеваетесь.
Ну ОК.
И вас даже не заставили проходить психологическое (или это IQ тест?) тестирование с кружочками и фигурами?
лет 20ть назад? Простите, а как был одет админ-бородач?)
У меня был такой отказ. Эйчар сказала "а у вас обувь грязная, а у нас компания знаменитая - ну как так админ в грязной обуви будет?"
На минуточку, за окном было типа такого:
У меня про P&G тоже есть прикол. Мы делали для них небольшой заказ, не ИТ, но небольшую стоечку надо было собрать. Ну, приехали мы с товарищем... А они снимали целый этаж в БЦ, и в частности там было здоровенное помещение, которое они использовали под всякие нужды, нарезая его перегородками.
Так вот, сидим мы, крутим провода и подходит к нам девочка-менеджер, за нас ответственная и грит: "Ребята, сейчас у нас тут meeting, так что вы посидите тихонько за partition....". И мы такие: "Што? О_о". Просто дело было давно и так коверкать язык тогда было не принято. Сейчас бы, наверно, уже не обратили бы внимания.
База у каждого своя. В универе хотя бы был список всех вопросов перед экзаменом
В первом предложении вы пишете, что кандидатов очень много. А потом о том, что работать некому. К примеру у меня весь опыт на Upwork, но клиентами были в том числе небольшие компании. Образование - ф-т Компьютерных наук, АСУ. Но найти постоянную работу Front-end React я не могу - получаю отказы, не доходит даже до переписки. Хотя на Upwork брал проекты с приличным рейтом. Пока его не заблокировали. Есть что показать, но не получается дойти даже до собеседования.
Не проходите фильтр эйчаров... :(
Попробуйте напрямую через LinkedIn находить инженеров и писать им. Поищите советы, как улучшить резюме и сделайте, как говорят. Замените в резюме Upwork на название какого-нибудь аутсорсера в РФ. И т.п., не проходите фильтр HR, нужно понять, в чем причина. Взять консультацию у HR, которые правят резюме или карьерного консультанта, сейчас таких услуг очень много.
"Мы пустили всезнающего техлида к нам на собесы и он всех разогнал!"
Хз чё там в дот нете, проходил в том месяце собесы на java midle, я сам не откликался ни на одну вакансию. У меня ща пару недель было 6 тех собесов и это я ещё от части отказывался. 3 тех собеса были весьма хорошими, ещё 2 сносными, откровенно печальный был только один. Итог 3 оффера. На одном собесе я спросил прямо как сейчас рынок. Они мне сказали что жопа с кандидатами и они не могут закрыть штат. Коллеги у меня кто ходил по собесам тож без проблем получали оферы. Вилки предлагают хорошие. Так что как то ваши наблюдения не могу подтвердить.
Сегодня только на собеседовании спрашивали мол вот код использует асинхронное программирование мол найдите ошибку, ответил по коду мол что идёт и никакой ошибки не вижу. Потом через какое то время hr менеджер сообщает что само собой я не подхожу так как не нашёл ошибки и вообще меня всячески к ней подталкивали. Возникает закономерный вопрос, почему я должен искать ошибку по коду который при мне даже не удосужились запустить? Меня брали на работу по ASP NET Core или в качестве аналога VS чтобы я ошибки тупо по коду искал без компилятора и заменял им среду разработки?
К одним я уже устраивался на работу, мол тестовое задание было написать контролёры в формате REST API, требовались знания по ASP NET Core, а реально потом в работе пришлось ковырять монструозное BBOM на WPF которое напрямую цеплялась к базам своих клиентов. Хочется спросить, что с вами не так? Требуются одни, тестовое задание другое и не относится к тому чем реально придётся заниматься.
код использует асинхронное программирование мол найдите ошибку, ответил по коду мол что идёт и никакой ошибки не вижу
Вероятно проверка на знание синхронизации асинхронных функций. Например мьютексы.
Нет, если бы это было так то HR менеджер не сказал бы что меня не берут только потому что я не нашел ошибку симптомы которой мне не рассказали, значит им нужно чтобы я нашел ошибку не как программист, а как среда разработки или лексический и синтаксический анализатор, но я то шел на должность программиста, а не на должность среды разработки. А ну и напомню программисты никогда не ищут ошибки) Им выдает ошибку либо компилятор на стадии сборки или программа вылетает на стадии работы и тогда программист видя ошибку начинает ее решать, но никак не ищет)
Обычно race conditions и например stack/heap corruption выдает программа как "что-то в рандомном месте в рандомное время упало, good luck (особенно если на проде, часто локально даже не воспроизводится)". Кто в этом случае будет искать ошибку? Только вам даже упростили задачу сказав что вот кусок кода и там есть ошибка.
Не бывает так что в рандомном месте что то упало, всегда есть логи и всегда есть указание где произошла ошибка. А если что то упало и логов нет и ошибку не вывели то тут вопрос к тому программисту который такую убогую программу создал что нет ни логов, ни отлов ошибок при падении программы, ни краш репортов.
Не бывает так что в рандомном месте что то упало
А точно не бывает? А как хип или стэк корапшн проявляется например тогда? А рейсы? А дэдлоки? А что должно в логах быть? Вы логируете каждое обращение к каждому адресу памяти чтобы оттрейсить назад кто её испортил? И все это на проде в релиз конфиге?
Бывают ли в C# лавйлоки? Если да, то вот их на порядок сложнее искать, чем дедлоки и тд.
live-lock искать хоть в некотором смысле и труднее - но если они достаточно большие то попадут в логи.
А вот дэдлоки в логи не попадают и нужны специальные техники, которые не всегда удобно (не знаю как в C#) вклинить в живой проект.
Ну просто я на Go пишу, и заметить что дедлок существует куда проще, приложение просто падает, а вот в случае с лайвлоком можно долго не замечать, что приложение запущено, но полезной работы никакой не делает(Хотя есть косвенные признаки, когда на каком-то инстансе приложения сильно просел rps к примеру)
приложение просто падает,
Это, как я понимаю если дэдлок произошёл на Го-шевских примитивах синхронизации.
А если ты заблокировался на 2х блокируемых сисколлах (ну или примитив + сисколл) - ты же увидишь, дэдлок именно как "старый добрый дэдлок" - два процесса ушедших в системные вызовы и не просыпающихся.
Есть удаленное подключение к процессу, а в логах можно отслеживать где и что навернулось, когда что то навернется человек начинает выдавать словечки типа "выдало такую то ошибку" или "значение данное не верно" и т.д. А не тупо "Существует некая ошибка, в чем она выражается хз, все работает, но ошибка точно есть ищи".
Повторил специально для Гуру здесь сидящих тот же самый тестовый код, тут 3 ошибки на мой взгляд, если назовете 2 которые назвал я, то значит вы автоматом считаем провалили собеседование как и я. Если укажите на ту самую ошибку то видно я где то знания упускаю, а вас точно бы взяли. Результаты оглашу позже
А удаленно подключаться не всегда есть к чему. Допустим ваше приложение в лайве крутится и падает только у пользователей (например я себе приложение поставил ваше и оно крашится, я вам в принципе не дам подключаться к любому процессу на моем компе). И да с лайва у вас от пользователей будут просто крэшдампы. Если вы закараптили хип, или у вас два процесса пишут в одни данные вызывая рэйс, то в первом случае у вас все отвалится не когда вы хип испортили, а когда вы в следующий раз к ней обратитесь, то есть буквально в случайный момент зависящий от того как система вам память отдала и от фазы луны. В случае с рэйсом у вас это тоже отвалится сильно позже когда уже станет понятно что два потока в одни данные писали и написали какой-то трэш. Это случается в рандомные моменты и результат видно только сильно позже.
Да, только я на своем игровом движке тоже асинхронное программирование использовал и знаю какие моменты могут возникнуть если lock не поставить перед изменениями данных и там довольно тривиально такие вещи отслеживаются. Когда значение должно быть одно, а валяется там другое значение значит произошла перезапись из другого потока, следовательно смотрим где данная переменная используется и изменяется, и проверяем стоит ли lock чтобы данные корректно записались или нет. Так что даже "фазы луны" можно отследить.
Особенно в таких моментах помогает логирование где смотришь кто куда пишет и в какой последовательности, первым логированием определяешь в какой части приложения крашится, вторым логированием уточняешь в какой функции это происходит, и третьим этапом выводишь когда происходит перезапись значений и откуда идет в лог, таким не хитрым способом можно найти место краша и выяснить причины.
Свой движок это очень ограниченная область, про то и речь. Одно дело в своем движке, другое дело вы выпустили ААА игру с тоннами кода который писался десятками лет сотнями программистов, где там десятки трэдов работают с кучей данных. А ведь тогда еще и GPU появляется, когда любой gpu hang это просто отложенный краш через 2-3 кадра и в сис логах у вас "ой, вэйвфронт такой-то сдох". И вот у вас ничего не падает, у тестеров ничего не падает, а задеплоили игру в сторы и у пользователей просто валится в разных местах с одним общим - segmentation fault. Логи это конечно хорошо, но куда в таком случае их ставить? Всюду? Так они неплохо перфу выжирают и тайминги сбивают, не обрадуются пользователи просадке в два раза, потому что вы в лайве решили пологать, а оно может больше и не воспроизвестись. Такие вещи тривиально отслеживаются только в очень тепличных условиях на очень маленьких кодбазах.
Не ну если рассматривать не свой проект, который писался толпой программистов, а если еще и по антипаттерну BBOM то это уже совсем другая история, я говорю про проекты которые я либо полностью сам писал, либо проект достался от другого человека, но я его уже успел весь глянуть как свой личный. Со своим движком тоже было не все так просто чтобы через кадр краш был)) Там команды к видеокарте должны быть вызваны из основного потока, а сами данные обрабатываешь в другом потоке чтобы не нагружать основной поток, потом эти данные нужно синхронизировать, как и синхронизировать их удаление, так что удаление может произойти по факту сейчас, но сработать только через время и это может быть далеко не пару кадров. Да и кодовая база не сказал бы что вышла даже на сыром движке маленькая)
Да и не надо все логировать, логировать надо только ту часть в которой идет сомнение, тем более можно клиент обновить не всем пользователям для детального изучения, а только нужному у которого возникают проблемы. Логи нагружают систему? Так не выводи их все или делай через межпроцессорное взаимодействие проброс для отдельной программы которая не крашнется и лог сохранит и может выводить только то что надо, как и отправлять к тебе данные на твой сервер
Так не выводи их все
Так для этого и нужен программист, что падает рэндомно, но нужно понять что и где логать. Логи в любом случае тормозят систему (и лишние понатыканные кондишны), а обычно движки и так оптимизированы что там свободного места на GPU-CPU нет и люди буквально спускаются до LIKELY/UNLIKELY в условиях чтоб хоть немного выжать, а тут целые логи вставлять чтобы отдебажить на проде. Причем учитывая что в тот же пс или майковские сторы надо еще ревью по неделе проходить, то есть пользователи будут крашится - краши вспыли на проде + ревью билда с логами неделю + пофиксить + сабмит с фиксом. И если логи программист поставил не там и не те, то смело накидываем + 3 недели злых пользователей.
это может быть далеко не пару кадров
Если рассматривать чисто GPU, то ему все равно с какого потока идет сабмит в command lists и кто вообще эти команд листы в какую command queue сабмитит. Сам GPU сдохнет именно когда очередь дойдет до засабмиченных команд, а это зависит от того сингл-дабл-трипл и т.д. буфферинга, имедиат сабмишн или отложен до конца кадра и прочих занятных вещей. И то скорее всего сначала отвалится по вотчдогу.
или делай через межпроцессорное взаимодействие проброс для отдельной программы которая не крашнется
Что то мне подсказывает что Sony и MS спасибо не скажут если на их платформах рэндомно запускать случайные процессы. А если корапшн вызывает Kernel Panic? Я и такое видел.
Скажем так, за 10+ лет программинга ААА игр (на кастомных движках которые в разработке уже лет под 20), я повидал достаточно трэша и что-то отваливается рэндомно и не репрится ни у тестеров ни у девелоперов, к сожалению не редкая ситуация, так что для собеса показать кусочек кода и спросить где тут может быть проблема мне не кажется каким-то странным, такое возникает достаточно часто, это интереснее, чем спрашивать "а что такое дедлок (рейс, whatever)?".
Когда значение должно быть одно, а валяется там другое значение
Довольно часто это вызвает неправильное значение в чем-то другом, оно — в третьем, и потом, в каком-то другом потоке происходит крэш совсем далеко. При чем это последнее значение, которое неправильное, оно переписывается в десятке мест и между крешем и предыдущей записью с каким-то неправильным значением — мегабайты логов. Распутывать это бывает весьма и весьма муторно.
Потом, вот такое вот детальное логирование, когда пол минуты — это мегабайты логов, его у всех пользователей не включишь. Ибо они быстро "спасибо" скажут, что у них SSD от вашей программы с гигабайтными логами, во-первых, подыхает, а во-вторых закончился. Локально в debug билде это все писать можно, да, но у вас-то проблема не воспроизводится, а у случайных пользователей иногда крэшится.
Есть еще система) Логировать последовательность команд пользователя, куда нажал, что ввел и т.д. чтобы можно было отследить последовательность которая привела к ошибке, ну и как я и говорил логировать можно только нужных клиентов и логи за собой нужно чистить
Это далеко не везде применимая система из-за privacy. Скажем, если бы ваш браузер такое вытворял — то вы бы его удалили сразу же. Плюс, часто входные данные программы — далеко не только действия пользователя, это и всякая база данных клиентов и данные, пришедшие по сети. Опять же, куча всего, что пользователи не хотят давать разработчику.
И включать логи только у нужных пользователей не получится. Потому что когда такие стохастические баги есть, то они происходят у какого-то случайного пользователя. В целом баг репортов и жалоб полно, но каждый конкретный пользователь может его опять не встретить неделями.
Логировать последовательность команд пользователя, куда нажал, что ввел
Заодно можно и данные карты увести, чтобы два раза не вставить)
А в многопользовательских играх например логировать все движения всех пользователей, а потом дампать сотни мегабайтные файлы за каждую сессию (а логи тоже не бесплатные)? А как вам это поможет с тем, что если у пользователя вот так сложилось что запущены еще какие-то процессы и удачно сбивают тайминги? Или система так память отдала, что портится и у вас, и у пользователя, но у пользователя она портит то, к чему идет обращение, а у вас вот нет. А если тайминги рэйс создают который по цепочке портит данные и всплывает сильно позже, при этом не важно что ввел пользователь, просто при такой нагрузке и бэкграундых процессах на данной системе так в тайминг попали? А если ваши логи сбивают эти тайминги?
Логировать с умом надо и логировать я предлагаю не сайты, а программы десктопные, на сайтах не слышал чтобы были магические ошибки работающие от фазы луны) Логировать можно последовательность кликов мыши или вызов функций которые вызывались, не обязательно тащить какие либо данные конкретного пользователя, можно делать и обезличено это. Если у одного из тысячи пользователей чето крашиться и нельзя это решить то что нужно сделать? Положить болт как всегда это и делалось и кормить его стандартными отписками. Это что же за логи такие которые тайминги сбивают? Каждый шаг дамп памяти выводится чтоли?
Если у одного из тысячи пользователей чето крашиться и нельзя это решить то что нужно сделать?
Можно, посмотреть глазами код и подумать где рэйс может быть скорее всего, про что дискуссия и ведется. Вы можете хоть пол программы залогировать, но каждое обращение к памяти вы не прологгируете, у вас программа по перфе умрет. А проблема рэйсов и корапшнов что они не всегда напрямую зависят именно от инпута пользователя и вы просто даже зная инпут и логи не поймете что хип закараптился совсем в другом месте пол секунды назад, а сейчас только проявились последствия.
Это что же за логи такие которые тайминги сбивают?
Да фактически любые, вы же понимаете что на свехнагруженных местах буквально микросекунда может сбить тайминг и одно ядро может успеть/не успеть испортить данные в это время.
Так вот, возвращаясь к началу, вам дали кусок кода и сказали что тут проблема, вы сказали что вы не IDE и не компилятор
Логировать с умом надо
нельзя это решить то что нужно сделать
Вам как-то компилятор или IDE поможет с "логировать с умом" или с "решить что нужно сделать", вы как программист и должны знать как оно логировать с умом и что решать.
Если бы для вас придумали историю "вот с прода летят рэндомные краши, локально не можем воспроизвести, ваш коллега из всей код базы смог найти что вот в этом куске какая-то проблема, но ушел в отпуск/заболел/уволился/умер, вы можете пологировать здесь, но на сабмишн нужна неделя, потом собрать логи, починить, пересабмитить, итого у пользователей 2+ недели приложение крашится, или вы можете глазами посмотреть и найти проблему и у пользователей крашится все будет максимум неделю, что лучше чем 2+", вам бы как-то от этого легче стало или смысл задания от этого поменялся бы?
Тут проблема в том что мне не сказали что за симптомы у проблемы. Типо есть тут проблема - найди. В реальных приложениях как я писал такого нет, всегда вылетит ошибка или проблема это как то проявляется, а если ошибки не вылетает и проблема никак не проявляется то значит проблемы тупо нет
В реальных приложениях далеко не всегда вылетает осмысленная ошибка. Симптомы - крашится в рандомных местах с segmentation fault.
У меня такое было только 1 раз когда я ковырял cuda ядра для распараллеливания вычислений на видеокарте, там просто вылетала ошибка краша памяти через определенное время работы и то даже в этот момент я понимал что проблема была в коде который идет на видеокарте
Ну в коде на видеокарте вообще много что может быть, особенно если юзать асинк пайпы или gpu driven pipeline (или все вместе) - там могут сотни шейдеров крутиться и поди разберись что конкретно отвалилось и почему (самое мое любимое это гдет ошибиться с барьером). Я не думая один GPU hang обменяю на 5 сегфолтов на цпу.
Энивей, у меня и коллег в работе встречались такие случаи столько раз, что я и сосчитать не могу и по крайней мере в моей области это вполне себе обыденная ситуация. Конечно если у вас язык основной шарп, то этого будет поменьше, но все равно что-то мне подсказывает что в шарпе рейсы вызывать можно вполне себе легко.
Из моей практики:
TextView в программе периодически начинал глючить (нельзя было ничего выбрать, удалить или напечатать, даже каретка по тексту двигалась через раз). Баг не воспроизводился ни на одной из тестовых систем. Баг существовал у 4 пользователей из около 10000. Что было делать не понятно.
Нам повезло, что 1 и тех 4 тоже был разработчиком и ему самому стало интересно, что происходит. В итоге, он выяснил, что проблемы начинаются после установки специфического драйвера для CD привода. И каждый раз когда система дергала привод, у нас вешалось текстовое поле. После этого мы связались с остальными 3 и выяснили, что они пользуются точно такой же моделью привода.
В результате, даже после того как мы вязались с производителем привода, так и не удалось выяснить причину почему это вообще происходило. Все закончилось тем, что и мы и они повесили на сайтах warnings о возможных проблемах с совместимостью.
Тут не 3 ошибки, а целый сборник "как не надо делать"
Навскидку - не надо делать Thread.Sleep внутри async-а, не надо делать i++ без Interlocked внутри многопоточки, и не надо вызывать Count() у IEnumerable в цикле (тут даже не важно, многопоток или однопоток), это что глаз резануло за минуту смотрения на код.
Выделил бы следующие проблемы:
Строка 27: Модификатор доступа для Main -> public(для Framework, в .NET, на сколько помню, допускаются другие модификаторы)
Строка 27: Сделать Main асинхронным
Строка 29: Предполагаем, что db.GetOrders() - репозиторий, возвращающий IQueryable. Т.к. IEnumerable является базовым для IQueryable, то все последующие использования orders(из-за полиморфизма) приведут к обращению к источнику данных(например, БД). Думаю, что стоило привести к чему-то "материальному", типа ToListAsync()
Строка 34: Потенциальный Race Condition. Значение i будет не детерминировано. Необходимо использовать Interlocked.Increment, либо примитивы синхронизации
Строка 35: Переменная i будет захвачена и преобразована в отдельный объект, поэтому вывод значения i будет разниться - возможно напечататься только последнее значение либо будут повторы. Стоит завести отдельную переменную для передачи на вывод
Строка 35: Если предположить, что п.3 верен, то на каждой итерации будет запрос к источнику данных(БД)
Строка 38: Лучше использовать асинхронный WhenAll()
Строка 43: Также лучше использовать Task.Delay()
почему я должен искать ошибку по коду который при мне даже не удосужились запустить?
Потому что асинхронщина вещь такая - сто раз запустишь работает, на стопервом упадёт. Если человек не понимает что переменная может внезапно измениться между двумя строчками кода он напишет труднообнаруживаемый баг. Который потом придётся отлавливать саппорту у клиента, разбирая многотонные дампы.
Но есть нюанс, нет ни одного реального проекта где тебя или твоего коллегу внезапно осенит что в этом коде ошибка, но как она проявляется или выражается ты не знаешь, ну нет таких проектов. Тебе об ошибке либо компилятор сообщит, либо есть странное поведение которое ты заменил, но нет такого что ты знаешь что в этом куске кода ошибка, но не знаешь в чем она проявляется, хотя тут от меня требуют именно такого подхода.
От вас скорее всего потребовали не ошибку найти конкретную, а порассуждать что там может быть не так. И подсказку дали - асинхронный код. А дальше вслух проговариваете - вот эта строчка кода потокобезопасная, а вот тут читается переменная класса, дальше делаются вычисления на основе её значения и запускается функция. Переменная незащищённая, другой поток вполне может её поменять и функция вызовется неправильно.
То есть вы лучше знаете что от меня требовали на собеседовании на котором вас не было? На Хабре как я понимаю это распространённая практика делать выводы о том о чем понятия не имеешь, все же гуру. Так вот повторю в который раз мне HR менеджер сказал что я не нашел ошибку, так что никаких догадок или двойных толкований тут быть просто не может. А то что у них в вакансии про асинхронное программирование не было пунктика к требованию кандидату еще один звоночек.
То есть вы лучше знаете что от меня требовали на собеседовании на котором вас не было?
Потому что это стандартный вопрос, на стандартный код в эпоху многоядерных процессоров.
в вакансии про асинхронное программирование не было пунктика к требованию кандидату еще один звоночек
Это стандартное требование. Разработчики должны понимать что это и как работать с этим инструментом. Какие минусы и плюсы применения асинхронного кода. И какие есть риски.
но нет такого что ты знаешь что в этом куске кода ошибка, но не знаешь в чем она проявляется
Тут конечно да, такое редко, обычно в случае многопоточки/стэк/хип корапшн, ты не знаешь в каком куске кода ошибка и не знаешь толком в чем она проявляется (ну по какой-то причине когда доходит в рэндомное время в рэндомное место программа, она адресует уже испорченную память и крашится и это только в релиз конфигурации, а может и не только, кто его знает), а есть просто стэкдамп который уже особо и не поможет (а бывает что и символов уже нет) и призрачная надежда что может будет хоть иногда локально репродюситься. То что говорят что в определенном куске кода есть ошибка и она связанна именно с многопоточкой это прям уже помощь так помощь
Истину глаголишь, прикрепить бы это к резюме, заставить задуматься эти "компании" теоретиков.
Интересно как статьи про набор возбуждают народ) комменты - огонь.
А теперь по делу.
Я ожидал в конце статьи увидеть схему идеального собеседования от автора, который проделал такой огромный и сложный путь (и сам набирал, и сам ходил по собесам), но выводы как будто сделаны не для решения поставленной задачи, а просто - все у нас плохо и у них, и у всех в общем-то.
По поводу базы и алгоритмов - не спрашивать базу у специалистов уровня мидл и выше - глупость. Если вы как работодатель готовы тратить на обучение мидлов время и деньги, чтобы они стали реальными мидлами - берите джунов. Все "нормальные" работодатели, кстати, уровни джун и джун+ закрывают школьниками-олимпиадниками/студентами и магистрантами. И отгадайте кого там отбирают? О да - самых успевающих в учебе, обычно это математич., физич. факультеты, призеры олимпиад в основном по точным наукам. И, кстати, после года работы некоторые из них становятся мидлами. А брать мидла и потом его учить потому что он базу забыл - странное решение.
По поводу культуры собеседований - соглашусь, сам грешу этим. Оправдываю себя тем, что часто собеседник тратит не только свое и мое время, но и время 2-3 сеньоров (не важно, разработчиков, девопсов или СА). Поэтому приходится торопить, иногда даже перебивать - "фу таким быть".
Самое же интересное - эту тему затронули выше - то, что сейчас очень много контор и "групп" помогающих и натаскивающих соискателей на прохождение собесов уровня мидл и выше. И работает это как раз потому, что задачи и требования на собеседованиях - типовые. И уже базой, теорией и тестами не добьешься результата - возьмёшь мидла, а он вообще код не писал, а только зазубрил и научился решать типовые задачки с помощью друзей из "групп". Поэтому ситуация - две стороны одной монеты. И нужно понимать, что задачи соискателя и работодателя как ни странно - противоположные. Одному нужно взять хорошего специалиста, крутого, решающего сложные задачи, организованного и желательно не очень дорого. А у другого - найти работу, желательно без собеса (по результату разговора) с понятными задачами, не очень сложными и чтоб зп была побольше. Конечно же, это все обобщение :) Как и многое в этой статье.
Жаль, что автор не выдал лучшую схему набора) придется ходить по собесам и искать классные примеры :)
СПРАШИВАТЬ то, что вы считаете базой у специалистов мидл и выше - глупость. У зелёного джуна спрашивать смысл есть - он по определению ничего толком не умеет - так хотя бы теоретические знания проверить. И то - иногда лучше просто поговорить и что то обсудить
По поводу базы и алгоритмов - не спрашивать базу у специалистов уровня мидл и выше - глупость.
Кто даст гарантию что мидл это тот за кого он себя выдаёт? Может он 10 лет сидел формочки ваял, никак не развиваясь. Формально опыт есть, фактически ничего не знает и не хочет знать. Возьмёте его, а потом придётся увольнять через пару недель и всё по-новому.
База это гарантия того что человек как минимум знает основы. Остальному можно научить.
Так и есть, и в этом проблема. Программистов выпускается много, олимпиоников среди них единицы (в этом и смысл олимпиады, побеждает меньшинство). Всем нужны лучшие, но з/п по рынку как для средних. Конечно лучше взять джуна и заточить его под собственный стек технологий. И тут начинаются приколы, т.к. компании далеко не все железобетонные команды, работающие вечно и одним составом. Компании разоряются, кадры текут. А стеки у всех слишком разные. Вот и получается что большинство разработчиков как старые китайские автомобили, на вторичном рынке цены не имеют. Что толку идти в ИТ, если через 3-5-8 лет ты окажешься не нужен в своей компании а всем остальным ты не подходишь? Конечно есть звезды, как без них. Но чтобы звезды могли работать, им нужна покрывающая массовка рядовых кодеров. Т.е. система заранее выстроена так, что большинству гарантировано ничего.
А рынок труда это как раз большинство. И что характерно, большинству рядовых кодеров противостоит такое же большинство рядовых компаний. Которые почему-то считают себя уникальными (впрочем как и большинство рядовых кодеров). И тут случается взаимное несоответствие ожиданий реальности. Которое в текущей ситуации парализует рынок при наличии как спроса, так и предложения.
Когда ты тимлид, техлид, devops, архитектор и 2 твоих личности не смогли договориться.
Я работаю в одной компании уже давно и в принципе никуда уходить не собираюсь, кормят хорошо... но в жизни всё бывает. Как представишь, что надо будет проходить собеседования и с каким это связано стрессом, так и отбрасываешь любые мысли о смене места работы.
Это очень плохая тенденция, так как ограничивает свободу рынка труда. Конечно, программисты являются так сказать "избранной кастой" среди остальных, которые ожидают к себе отношения если не особого, то хотя бы внимательного. А когда происходит такое, как описано в этой статье, то получаешь огромный негатив в перемешку с чувством несправедливости.
Как всегда, зри в корень. Надо искать причину, а не лечить симптомы. Причина как всегда в людях. Некомпетентные собесы дают негативное представление о своей компании. В хорошей компании хорошо встречают. Так и в моём случае было в местом, где сейчас работаю, хорошая компания!
Надеюсь, эта статья даст свой вклад в общую ситуацию на рынке труда и хоть немного сдвинет с места проблему, которую мы имеем.
Что-то вспомнилось.
Proton (которые ProtonMail и прочее) уже лет точно 7 всем присылают одно и то же тестовое задание "на логику" перед основным процессом, оно за это время почти не изменилось.
Там вопросы в духе про разрезание пирога, как сварить яйца используя двое песочных часов, посчитайте количество треугольников на картинке, ну и прочий бред. Я не знаю кого они хотят отсеять этим.
После этого тебе выдают уже домашнее задание на кодинг, более адекватное, ещё мучают тебя штук 5 собеседований и предлагают грустный оффер, где 20% дохода это их акции, которые *нигде не торгуются* т.е. продать ты их не можешь :)
Поразительные ребята.
Нам тут недавно самим довелось проводить собеседования двух джунов. Пришли люди взрослые (~40 лет), из профильного образования за плечами только курсы. На практике это выглядело как уровень студента-первокурсника в первом семестре. И меня еще угораздило взять с Литкода задачку и ее задать. При этом я не ставила цели вытащить из кандидата оптимальный код. Мне просто хотелось проверить, пишет ли он код в принципе. Нарочно взяла задачку из первого десятка Литкода в надежде, что человек, ищущий работу в IT, прорешал хотя бы самое начало списка. В итоге получила проект решения на словах, без кода, с квадратичной сложностью и массу претензий.
Там в первой десятке 2 easy, 2 hard и 8 medium. Вы которую из них дали? =)
И спасибо за идею решать из начала списка. Я сам примерно такой же, только чуть помоложе, и решал задачки через peak one или study plan, а они там случайно надёрганы. Надо будет пойти по порядку.
Какую-то из медиум. Правильно-то, конечно, по темам решать...
Вы которую из них дали?
Судя по всему, номер 3
О, это, наверное, я был. Описание совпадает, и тоже сразу решение не придумал. А на словах, потому что зачем для явно кривого решения писать код. Так что если бы я пошел на собеседование, то так бы оно и было. Пойду сочинять хорошее решение.
Вообще, мне интересно, как эту задачу можно решить за квадрат. Даже самое тупое решение - линейное..
Задаться левой и правой границей подстроки.
Двигать правую границу подстроки.
Проверять, что новый символ не входит в подстроку путем последовательного перебора.
Квадратичная сложность готова.
В задаче фиксированный алфавит из где-то 70 символов, и строка длины N. Соответственно расстояние между left и right не более 70 - если больше, то заведомо есть повторы. Таких подстрок всего O(N), проверка каждой подстроки O(1). Итого линия. Просто с большой константой.
Очевидно же что про размер алфавита надо уточнять, иначе задача решена наверно.
По тоьйлогике по которой вы оцениваете указанное решенин вообще дает ответ за константу. Как и практически любое другое.
Почему за константу?
Строки там тоже ограничены сверху. По идее и вашу оценку надо расширять и считать от n и k — длина строки и размер алфавита. И там не линия будет, а что-то вроде O(nk), но как вы выкинули k, так же можно выкинуть и n.
Ниже ответили - в этой задаче (как и практически во всех литкодовских задачках) все параметры ограничены сверху, так что если мы берем максимальный размер словаря, то можно так же взять и максимальный размер строки)
Так что похорошему надо всегда уточнять, а относительно чего сложность считаем. Ведь по факту сложность нам важна как некая мера роста затрат на вычисления относительно изменения конкретных параметров - а не просто сложность в вакууме. Ну и какие операции считаются константой еще важно. Потому что какие-нибудь инты за константу сложить можно, а бигинты в общем случае - уже нет)
Ха! Можно хоть четвертую степень придумать запросто: Перебираем все подстроки, через substr их выделям, потом сравниваем каждую пару символов.
Да блин задача очень неприятная (написал выше почему). Не сложная, а именно неприятная в которой очень легко вообще не написать решение.
И давать такую джуну можно только если "решение это +"; "не решение минусом не является".
Ну и всегда остаётся вариант "дали гроб потому, что....".
Почему кто-то вообще в принципе должен задротить LeetCode?
вроде дроч на литкод это прерогатива крупных компаний. Когда у них 1000 человек на место и им сложно выбрать. Ставят высокие барьеры
Если задача в комментах та, что вы дали - то для джуна это не задача, а гроб какой-то. Скорее похоже на попытку завалить джуна - я бы её отнёс ближе к началу hard (ну что-то с не совсем тривиальным динамическим программированием).
Почему?
- сразу очевидно, что решение в лоб не оптимальное (и автоматом хочется сделать "правильно").
- решение с линейной сложность (скажем поддерживая HashSet для текущей подстроки) заставляет поддерживать сразу несколько инвариантов состояния, и жонглирвоать ими в уме. Его просто технически не очень приятно писать потому, что в каждой строчке кода тебя поджидаем "а всё ли я проверил".
ПС
Надо ещё прикинуть может быть есть какой-то трюк позволяющий написать более простое решение - с ходу его не вижу.
Там требуется только длина подстроки, и можно написать решение проще некуда. Полагаю, это не должно доставить сильных страданий кандидату.
Не угадали, я дала совсем другую задачку. И, повторяю, цель была получить не оптимальное решение, а просто проверить способность писать хоть какой-нибудь код (пусть даже неоптимальный и вообще нерабочий).
Решение: уволить техлида и монополизировать проведение интервью, набирая кандидатов, которые устроили вас.
Плюсы: комфортный вам состав команды, выросший из этой команды техлид может быть уволен как только начнет заваливать "ваших" кандидатов. И так по кругу...
Минусы: на каком-то повороте или этапе круга могут уволить вас.
Спасибо за интересное повествование - это очень полезно, особенно для джунов. Если понятно, что не будете работать в компании, куда проходите собес, то ради интереса можно задушить душнилу в ответ, чтобы спустить с небес.
Например, в секции по машинному обучению очень любят душить вопросом про бустинги и если интервьюер явно гнёт палку, то можно спросить в ответ как в adaboost.R2 реализовано предсказание с помощью взвешенной медианы - самооценка душнилы сразу распадётся на атомы).
Ну а если серьёзно, как мне кажется, в компании автора лучше проводить собесы для нового техлида и проблема с наймом исчезнет)).
Было бы интересно дополнить примеры вакансий ЗП, с сравнением её с средней по больнице.
Аналогом лайвкодинга может быть задачка которую соискатель решает на своём компе и скидывает решение в чат. Недавно на собеседовании с таким столкнулся, задали потом несколько вопросов по написанному коду, и из ответов надеюсь стало понятно, что действителтно есть понимание, и можно обойтись без chatgpt, если дать больше времени). Ну или как в западных компаниях, дают задание на дом, почему нет? Ведь уточняющие вопросы выведут на чистую воду в любом случае, если даже соискатель писал код не самостоятельно. А лайвкодинг и интервью с видео такое себе, по крайней мере для меня, как для соискателя, из-за этого только сильнее переживаешь. И да, техлид с завышенным ЧСВ у вас что ли?)
Я думаю кандидатам очень сильно повезло, что они не попали к вам, и тем более, к вашему техлиду. Не забываем, что процесс интервью это двусторонний процесс, не только вы присматриваетесь к кандидату, но и кандидат к вам.
все интервью с кандидатами(не джуны, с джунами не сталкивался) прохожу по стандартной для себя схеме.
читаю, что там про себя написал кандидат, выделяю технологии, которые прям сейчас сам хорошо знаю, с чем не сталкивался, сам гуглю, зачем они вообще - потому что иногда встречаются специфические вещи, на всё 20 - 30 мин.
если есть github - обязательно иду и смотрю, ну минут 30, если есть на что смотреть.
На самой встрече:
прошу рассказать, чем человек занимался на предыдущей(текущей) работе, без раскрытия всяких тайн, проекты, для чего они вообще кому-то нужны, используемые технологии и именно человек делает(делал) в проекте. Почему так или иначе делает, как можно лучше, с его точки зрения и попутно спрашиваю про технологии из его описания себя и, если есть пересечения, их назначение в проекте. Пытаюсь определить глубину текущих знаний, о которых человек сам указывает.
Потому непосредственно про разработку (python). Ничего особенного, иногда задаю вопросы типа используют ли functools, как организовать работу со множеством корутин, получить результаты от них, при разных условиях, всякое разное в общем, в основном цель - "раскачать" кандидата, оценить широту кругозора по языку скорее. Никаких вопросов про Django, никаких Flask-ов и ORM. Часто встречались джанго программисты, которые язык не знают, но уверенные джанго-разрабы.
Если "чую", что-то не устраивает, иногда, можем дать задание на "дом", без всяких алгоритмических изысков.
Откликался тут на аналитика в Playrix - их hr (Ирина Воронина) открыла в себе экстросенсорные способности и без созвона в принципе мне вот что ответила на отклик:
Отказ
Здравствуйте, Александр!
Большое спасибо за интерес, проявленный к вакансии "Senior Data Analyst" и отдельно за сопроводительное письмо с комментариями. К сожалению, в настоящий момент мы не готовы пригласить вас на дальнейшее интервью по этой вакансии. На текущей позиции помимо хард-скилов - которые у вас как раз очень ярко проиллюстрированы и в резюме, и в письме - очень важен опыт плотной работы с продуктом, сейчас кажется что уклон в вашем опыте больше на инженерные задачи - ближе к Data Engineering/BI Analysis - у нас периодически появляются и эти позиции - возможно они так же будут вам интересны? Мы не хотели бы прощаться совсем, поэтому в случае если наше видение изменится - то будем рады вернуться. Успехов вам в поиске новой работы!
Т.е. сама признаёт, что хард скилов на вакансию хватает - но говорит, что не хватает софт скилов - вообще без каког-либо общения. При том, что и в резюме у меня помечено, и hr-ам я всем тоже говорю - что с заказчиками и составлением ТЗ я тоже нормально работаю - в плоть до постановок задач напрямую от генерального директора.
Вообще примерно треть hr-ов наглухо отбитые (примерно как в этом кейсе - что-то придумали себе - и отказ без причины) - и чаще это встречается в больших фирмах - где hr-у за такую фигню ничего не будет.
Сейчас если смотреть не в РФ, а на международном рынке - конверсия в тех собес резюме Senior уровня 100% подходящее под вакансию - на уровне 3-5%.
А на рынке РФ - наоборот, сами пишут.
Если в принципе убрать прослойку в виде hr-ов - лично мне гораздо лучше было бы.
Треть? Да что вы, ИМХО у 9 из 10 hr плоховато с головой!
Вы написали - "Если в принципе убрать прослойку в виде hr-ов - лично мне гораздо лучше было бы." Полностью с вами согласен!!!!!!!!!!!!
Считаю, что объем hr сильно раздут и если не полностью убирать, то в любом случае необходимо сильно сокращать.
hh.ru вообще бесполезный сайт, ни одной попытки трудоустройства, лет наверное за 10, не привели к удачному результату
А где всем этим людям работать? Всем москвоским студенткам после мгимо? Не к нам же в нефтяночку вахтой на Сахалин подаваться. Ещё бы знали где это.
А что посоветуете взамен hh.ru?
HR это как автоматизированная система управления производством. Нужная вещь которая позволяет работать производству на совсем другом уровне. Но если она неадекватно настроена, то производству кранты.
когда из 100500 необходимых для должности технологий, ты не знаешь буквально одну
Я перед собесом читаю описание вакансии и если вижу что не знаю буквально одну, а вакансия вкусная - мне ничто не мешает загуглить, поставить софт в виртуалку, поиграться часа три и посмотреть типичные вопросы. Не вижу тут особой проблемы.
Ну и что это поменяет? Это ни сколько не добавит вам опыта эксплуатации этой технологии. С таким подходом вы ничем не лучше скилбоксера или любого курсанта. Ну вот, к примеру, поднимите вы кафку в докере, кинете пару событий, считаете. Всё? Готовы к эксплуатации распределенной промышленной системы? Заешь - знаешь, не знаешь - не знаешь. Работал - работал, не работал - не работал. Надо говорить как есть
Задача интервьюера прикинуть хватит ли у вас способностей освоить ту или иную вещь и на сколько быстро, исходя из вашего опыта.
Я сомневаюсь что новичку доверят писать критически важные куски кода. А за время испытательного срока можно поглядеть как люди до тебя это реализовывали и сделать так же. Раз ищут специалиста широкого профиля - то и нет необходимости знать конкретную технологию досконально.
Вот если конкретно скажем flutter то тут да, нужны глубокие знания.
Вы не поверите, но с переводческой деятельностью ситуация абсолютно такая же.
Как вы очень точно выразились, сейчас в сфере перевода, в основном на собеседованиях "идиоты ищут идиотов".
Перевел 7 книг в достаточно сложной тематике (медицина/спорт), плюют на мой опыт вообще и либо закатывают 7-этажную проверку теоретических знаний, либо предлагают переводить по книге в день за хлебные крошки.
Кстати, 7-ю книгу перевел с помощью нейросети ChatGPT, делюсь опытом в своей статье на Хабре тут:
https://habr.com/ru/articles/758406/
Первый случай
охх, у меня однажды нечто подобное было и про отношение и про стиль вопросов. Ну и потом получил отзыв, что я не могу ответить на простые вопросы. После отзыва специально по разному искал в гугле, и действительно ответы будут зависеть от входных условий причём они могут быть диаметрально противоположными.
Когда я собеседовал людей, то брал пару ситуаций из опыта. Одну стандартную, что на автомате анализируешь и делаешь выводы, а одну нестандартную, чтоб увидеть как человек мыслит. И уже при диалоге всплывают какие-то дополнительные вопросы, которые нужно знать (или нужно хотя бы понимать что ты будешь гуглить).
Компании, имеющие адекватные стандарты собеседования и ищущие специалистов для решения задач либо ушли, либо уже имеют таких специалистов, а они в свою очередь знают, что сейчас на рынке, поэтому и не покидают свои места
Да, полностью согласен с вами.
Тестовые задания мы не рассматриваем, так как я стараюсь уважать личное время кандидатов, да и на данный момент тестовое уже моветон
Написание кода немного, скажем так, интимная штука. Любой программист пишет код в одиночестве в состоянии сосредоточенности. А тут неестественные условия для него, как будто пишешь домашнее задание под пристальным взором строгого отца, который за любую ошибку даёт подзатыльник.
Вас ничего не смущает?
Техлид против, так как нет опыта в технологиях.
Техлид против со словами "Плохо знает базу".
Для понимания, что это были за вопросы, заданные техлидом. "Ты
знаешь о многопоточности и синхронизации, тогда опиши углублённо работу
класса Thread", "Опиши принцип работы DLR и поколения объектов в GC".Снова отказ от техлида по причине отсутствия пет-проектов
Поборов своё волнение, кандидат написал рабочий алгоритм и достаточно
неплохо. Но техлид снова его забраковал. В этот раз по двум причинам.
Снова "База хромает", так ещё и впридачу "Алгоритм медленно работает". Очередной отказ.На этом моменте я усомнился в адекватности техлида.
Только "на этом моменте"? А раньше непонятно было?
Рецепт счастья прост - уволить и гнать в шею этого "техлида". Как он сам вообще эту должность получил?
После ещё пары десятков таких собеседований я понял, что рынок не
изменился ни разу, но при этом вообще не похож на то, что было буквально
2-3 года назад.
Подождите, вот этой фразы не понял... Так не изменился ни разу, или всё-таки изменился? Как он может быть вообще не похож, если не изменился?
Алгоритмы и leetcode больше прерогатива крупных к-омпании а-ля Яндекс,
где для этого выведен отдельный этап тех. собеседования. И там это можно
оправдать реальным использованием в их практике.
Это заблуждение. То есть конкретно про Яндекс не скажу, не знаю, как там. Но про "крупные компании, которые любят leetcode" - какие бы хитрые вопросы на алгоритмы не придумывали, на практике мало что из этого применяется, >80% разработчиков в таких компаниях занимаются формошлёпством.
Из похождений (иначе не назовёшь) в прошлом по собеседованиям, уяснил только одно. Если человек очень нужен и резюме подходит - пара вопросов и берут сразу. В конце концов, при опыте работы в несколько лет технологии и фреймворки особо не имеют разницы. Почитать недельку мануалы и можно работать. Чтобы изначально звезды, то есть технологии, сошлись, надо рекрутерам очень постараться. Другое дело, что недели этой нет, нет мероприятий введения в должность, в общем сразу надо задачи делать, это настораживать должно, скорее галера, текучка или головотяпство верхов. В противном случае, все эти этапы собеседований и тд, на самом деле означают, что и так штат раздут или сами не знают, нужен или не нужен человек. Иногда подозреваю, что такое входит в задачу повышения кругозора собеседующих, кто как на этих технологиях работает в других компаниях.
В чём-то соглашусь. Два раза собеседовался в Jetbrains на релевантную опыту позицию, оба раза не прошёл дальше HR. С какими-то совершенно левыми отписками, типа я не вижу у вас необходимой мотивации или команде не понравилось ваше резюме. Если сотрудник нужен думаю вопрос нравится-не нравится не стоял бы. Взяли бы с потрохами.
Соглашусь и даже дополню в плане опыта. Опыт разработчика - это вещь, которая показывает не его обширный кругозор всех библиотек, фреймворков, паттернов и других сложных конструкций. Это понимание логики работы, что позволяет очень быстро освоить незнакомые разработчику механизмы. Я в своей практике даже не недельку убивал на изучение чего-то нового, а буквально часы. А потом сразу же и применял.
Что-то я уже передумал входить в айти после такого. Весёлого там вообще ничего нет, похоже. Ещё всякие с ЧСВ завышенным будут глумиться. Ладно бы 20 лет ещё было.
Правильно, не надо
Нечего тут ловить сегодня.
В 2008 году я вошел в it на 1500$, с пары собеседований, позанимавшись пол года htm/css/версткой/photoshop/продвижением своих любительских сайтов.
Сейчас, чтобы получать те же 1500$ нужно знать намного больше, и проходить десятки собеседований.
Весёлого там вообще ничего нет
А никакая работа не цирк. Я не знаю, откуда родилось представление, что ИТ - это сплошная ржака про костыли, велосипеды и бородатых чуваков в свитерах. Обычный труд, только не лопатой машешь, а не пятой точке видишь.
Только хотела написать про чсвшников,в начале карьеры пришлось столкнуться с несколькими такими компаниями,где взрослые тетки и мужики глумились и ржали в открытую
Может я что не понял но техлиду дать люлей с порога что бы не выделывался и брал что дают, и никаких "мучительных месяцев".
+++
Да, но может быть несколько подводных камней из-за которых это перестает выглядеть так просто:
1. Техлид имеет больший авторитет в компании, чем автор статьи.
2. Техлид долго в компании, в коде много легаси, проект держится только на нем
Ко всему прочему для руководства это может выглядеть иначе:
1. Как это выглядит для нас - тимлид собеседовал вполне толковых людей, но техлид их забраковал из-за чего не получилось закрыть вакансии
2. Как это может выглядеть для руководства - тимлид несколько месяцев не может найти толковых людей, а техлид старается не допустить плохих специалистов в компанию. Ко всему прочему из-за того, что тимлид не закрывает вакансии горит какой-то проект уже
Соответственно для руководства кредит доверия тимлиду может быть сильно меньше, чем техлиду. Я не говорю, что стоит ничего не делать и просто закрывать глаза, но и делать вид, что это исправляется по щелчку пальца тоже не стоит. К сожалению такие ситуации обычно куда сложнее.
По ощущениям, это собеседования офисного планктона. Сразу сходу давать отказ. По хорошему нужно поспрашивать несколько кандидатов, сделать таблицу в которой провести сравнительный анализ кандидатов, кто из них получше, а кто по хуже и отправить это наверх начальству. А так особо не нужно воспринимать эти собеседования всерьёз. :-)
Меня всегда забавляли моменты копошения в пикселях (что будет если 1 - "1"), вместо осознания кругозора человека, уровней его абстракций, построения сложных систем, процессов, выбор технологий и .тд. )))
Согласен с выводами автора, нанимают не понятно кто и не понятно кого и вопросы часто задают на собесе про то, что сами знают, а не про то что требуется. И конечно удивляют эти часовые экзамены на знание мало известных и редко используемых технологий и настроек.Зачем мне помнить то, что редко используется есть же документация. Я пришел на собес, а не сдавать экзамен VCP 🙂.
Проведите собесы, когда техлид заболеет или будет в отпуске, и будет вам счастье )
А если серьезно, то база базе рознь. Иногда и правда люди слишком увлекаются. Сам на собесах в роли интервьюера тоже не прощаю незнание элементарщины, хотя едва ли отношу к этому middle-задачки с литкода, хотя большинство там решается не очень-то и сложно. Но про сборщик мусора и многопоточность знать точно нужно.
Это да. Техлид отвечает за код. Если у него был негативный опыт исправления банальных ошибок не владеющих базой программистов - не нужно тимлиду лезть туда чего он сам не понимает. Даже если кандидат кажется нормальным, но не в состоянии решить типичную задачу в рамках техзаданий - дешевле поискать другого чем потом огрести проблем.
Ну и да, нужно заранее оговорить с техлидом критерии, желательно с конкретными багами из трекера и примерами кода - чтобы и тим-лид понимал что нужно от кандидата.
Меня автоматически браковали из-за отсутствия вышки (которой, к слову, до сих пор и нет). Но меня дико раздражает, что берут часто глупых, но с вышкой. На собеседования даже не зовут, когда видят "нет высшего", сразу отказ даже в разговоре с HR. Они даже не интересуются, что ты умеешь и что знаешь, а я хочу развиваться, писать красивый и лаконичный код, заниматься архитектурой приложений, но закрывают двери из-за вышки, после которой люди даже не поймут и 10% моего кода, который я на данный момент пишу (в данный момент работаю, 1 компания в меня поверила и взяла без "вышки").
HR, вопросы к вам, как моя ценность, как сотрудника, вырастет, если я получу "вышку"? Меня научат в универе разрабатывать микросервисы, расскажут зачем нужен EntityFramework, DTO модели, AutoMapper и прочие вещи? Очень сомневаюсь.
Накипело, извините :(
Ооо, с вышкой уже отдельная тема) Как ни странно, у нас в команде, откуда я вышел из разработчика в тимлида вышку имели от силы половина ребят. Сейчас вышку просят не часто, насколько я могу заметить, но это зависит уже от языка и технологий. В том же фронте людей с вышкой и то меньше, так как добрая треть, а то и половина ребят выходцы всяких курсов.
Язык как и в посте - C#. Надеюсь, что позже будут приглашать уже из-за опыта, а не из-за того, что у меня, например, есть вышка, а у другого её нет.
А почему "из-за опыта", а не скажем "из-за умений"? Опыт он сам по себе ничего не гарантирует и в этом плане ничем не отличается от наличия вышки.
Почему? Он показывает, что некому Васе платили (в некоторых местах можно даже узнать сколько) на протяжение N-го срока и он что-то делал и им были удовлетворены.
Тут возникает лишь вопрос, сможет ли он делать задачи нового работодателя, но существующий опыт показывает, что старые задачи он делал как минимум на тройку.
Грубо говоря, если вы видите человека, который работал маляром в условном домостроительном комбинате номер 7 10 лет, то очевидно, что красить человек умеет. Как хорошо - уже другой вопрос, но вопрос умеет или нет уже не стоит на повестке дня.
Тут только проблема, что айтишечка сложнее (глубже, шире) покрасочных работ, ну и коллективы с "традициями" тоже разные. В некоторые можно и не вписаться.
Почему? Он показывает, что некому Васе платили (в некоторых местах можно даже узнать сколько) на протяжение N-го срока и он что-то делал и им были удовлетворены.
Ну так а ВО точно так же показывает что человек смог сдать какие-то экзамены или пройти практику и так далее и тому подобное. И обладает какими-то там знаниями.
А что там кому-то платили, причём ещё и неизвестно сколько, оно точно так же не особо о чём говорит. Может это "вечный джун" какой-нибудь.
То есть и то и другое это просто какие-то "косвенные данные", которые обычно коррелируют с полезными умениями. Не больше и не меньше.
Потому что сначала смотрят на опыт в резюме, а потом на собеседовании уже смотрят на умения :)
Так получите уже эту вышку, что вы. Заочка и через 3,5 года будут корочки.
HR, вопросы к вам, как моя ценность, как сотрудника, вырастет, если я получу "вышку"?
Это скорее софт-скилы. Если человек смог закончить ВУЗ он как минимум упорный и умеет решать поставленные задачи. Опять таки стрессоустойчивый (сессия) и способен грамотно излагать свои мысли. Это всё может присутствовать и у вас, но придётся проводить дополнительное тестирование. Опять таки в нынешней ситуации программиста без вышки могут забрать на СВО, а с вышкой попадёт под бронь.
А в чём проблема добавить зависимость премии (или вообще большей части компенсации) техлида от успеха проекта? Не хочет нанимать предложенных? - Пусть сам до ночи сидит и кодит. Хочет нанимать только гениев? - Ну пусть подкарауливает их возле НИИ, РАН или бауманки, или где там гении обитают.
Может в данном случае техлид и старается для успеха проекта. Потому что предыдущие уволенные программисты накосячили и пришлось переделывать, что задержало проект. Лучше день потерять и потом за 5 минут долететь (с)
Вот у нас был пример когда мы несколько раз в месяц напарывались на ошибку записи на диск в ядре линукса. Понятно что всего предусмотреть невозможно и у нас высоконагруженное приложение со скоростями порядка терабит в секунду. Но кто-то из авторов ядра накосячил и нам пришлось делать принудительный сброс очереди на диск, что существенно ухудшило производительность. Если бы сразу сделали нормально, не пришлось бы приставлять костыли.
По первому пункту - вполне такое может быть. Нужно посадить техлида перед собой и сказать: "Смотри, есть такая вот проблема". И дальше уже обсудить способы её решения, а не писать оченедной пост на хабр по теме "процесс собеседований поломан". Второй пункт не очень понял. Если изначально писать ПО без ошибок, то можно закончить проект быстро и заработать кучу денег, только вот такой методологии ещё не придумали. Вполне возможно, что автор кода с ошибкой в ядре высококлассный специалист, но в тот день у него болела голова или настроение было плохое.
Если программист владеет базой то шансы написать глючный код уменшаются экспотенциально. Особенно если он досконально разбирается в механизмах многопоточности. Конечно, современные библиотеки берут на себя почти все низкоуровневые детали типа мьютексов и критических секций, но замечать дурно пахнущий код интервьюируемый обязан. Тем более миддл или сеньор.
Несколько раз мне приходилось собеседовать кандидатов, которые приходили к нам устраиваться. Я никогда не понимал смысла вот этих экзаменов по часу-два.
Я всегда на собеседовании держал в голове, что мне нужно заркыть позицию в штате толковым сотрудником. Собеседование - это не то место, где нужно доказать, что ты умнее кандидата.
Пару вопросов по "базе", sql, фреймворку, небольшой лайвкодинг, обсуждение реальной проблемы из нашего проекта и как её можно решить.
Зачем мне спрашивать про алгоритмы, которые мы не используем в работе?
В целом после 15 минут диалога, я уже понимал подходит нам кандидат или нет.
Недавно месяц искала работу с хождениями по собеседованиями. Работаю системным аналитиком 13 лет, финансовый сектор, много крупных компаний в резюме, образование профильное МИФИ. И второе- карьерное консультирование, поэтому вполне уверено чувствую на собесах.
Рассматривала в основном банки. Почти у всех вопросы под копирку. Столкнулась со следующими пунктиками:
БАЗА... Конечно, я не зубрю статьи из вики, мне проще рассказать пример из реализованных задач. Где-то вопросы еще норм, а где-то прям дайте определение. Один банк из 10-ки топ после собеса вернул ответ, что мой уровень джун. Я была удивлена, но посмеялась. Ибо с тем, кому вики важнее практики, мне не по пути.
Вопросы о технологиях, которых нет на проекте. Причём, с просьбой и пример написать. Один из таких БД. Поговорили про то, какие бывают, чем отличаются, дошли до SQL. Написала простой запрос, сложными не владею, что и указано в резюме. Плюс я не готова больше 10% времени сидеть в БД, т.к со своим опытом я уже могу выбирать чем хочу заниматься, чем нет. Я могу, если надо команде, но на постоянке мне скучно. В итоге, задаю вопрос, как часто у них писать запросы. В ответ улыбка, ой, ну мы раз в два месяца что-то можем посмотреть, мы так спрашиваем, чтобы выявить уровень аналитика.
Был банк, который презентовал проект, где они делают процесс один-в-один, как я делала в банке топ-3. Менеджер был счастлив. Там же рассказывают условия, мол надо будет и тестировать немного, и дизайн рисовать, и где-то самому менеджером быть, и график ненормированный, т.к. коллеги в разных часовых поясах. Подумав, что я все равно из дома и в большинстве случаев не проблема, ок. И тут пригласили тех лида. Он зажал два вопроса про технологии, которые они поанируют использовали, но в моем резюме их нет. Логично, что я их не знаю. И всё, отказ. Ребят... серьезно?))) Посмотрите на разный опыт и технологии, вы думаете что я не освою это за неделю-две? При этом вы отказываетесь от человека с идентичным опытом? Удачи))
Было много предложений, которые не отвечают запросу в резюме. Написано черным по белому: удаленка. Ладно гибридные пишуи, но есть и те, кто пишет мол вэлкам в офис... И почему должна вдруг ради них передумать?
Банк с известными 5-этапными .. или больше собесами вообще вначале отказывал на входе. Типа нет и всё, хотя общались мы с ними лет 7 назад на собеседовании... и стекла в аквариуме их я не била, вполне все адекватно прошло. В итоге, зашли туда через консалтинг. Прошла все этапы. Финальный - общение с командой. Неделя тишины. Выяснилось, что под мой стек у них нет сейчас команды. Типа всем нужна БД 90%. А какого вы вообще мое время тратили?
И был случай, который меня крайне возмутил. Это был второй банк, который решил, что я не знаю теорию, то типа я джун. Увидев от hr в ответе в первых строчках, я продолжила спать утром дальше. А потом я прочитала, в чем конкретно джун. Оказалось, что я не умею описывать процессы.... (интересно, за что я 13 лет получала зп?) И не знаю UML (это моя любимая нотация и я в ней как рыба в воде. Рисовать схему не просили на собесе, вопросы какие-то там особо и не задашь из теории). В итоге, я написала в ответ hr, в котором под каждую цитату привела аргумент против, а также спросила, почему они не попросили им в моменте нарисовать схему, написать запрос, хотя бы прислать пример документации. И главное, тот самый sql, которые они используют раз в 2 месяца, они почему-то не указали как слабые навыки, от чего я не отказываюсь. Не указали, потому что сами не сильны. В итоге hr извинилась, мол это были аналитики, которые обычно не собеседуют, просто техлид команды не смог. Договорились на повторное собеседование в др команду. Шла туда ради принципа обелить свою репутацию. Обелила. Оффер.
По итогу месяца собеседований скажу, что я зазубрила теорию ровно настолько, чтобы проходить этот этап на собеседование. Сейчас это мне снова не требуется в работе, знания потихоньку забываются. Вспомнила все вещи, которые умею... потренировалась на практике. Аналогично, что не используется отложено в долгий ящик. И создала себе черный список работодателей, кого не рекомендую своим друзьями -коллегам. Остается вопрос... я вот сама набирала аналитиков в команду свою, когда была менеджером. Я всегда скептически отношусь к цитатам из вики, стараясь сразу спросить, где на практике использовал. Один товарищ был с крутым резюме, но три менеджера так и не добились примера из практики. Он психанул, поняв, что одной болтавней и вики нас не купишь, и заявил, что вообще не ищет работу) И второй кандидат - скромный, мало опыта, но рассказывать как и что применял увлеченно, с техническими моментами... конечно да! Лучше такого дорастить, ведь там виден сразу потенциал. Это мое видение.... но у всех взгляд разный. Главное найти своих людей, с кем на одной волне.
Банк с известными 5-этапными… или больше собесами вообще вначале отказывал на входе. Типа нет и всё, хотя общались мы с ними лет 7 назад на собеседовании… и стекла в аквариуме их я не била, вполне все адекватно прошло. В итоге, зашли туда через консалтинг. Прошла все этапы. Финальный — общение с командой. Неделя тишины. Выяснилось, что под мой стек у них нет сейчас команды. Типа всем нужна БД 90%. А какого вы вообще мое время тратили?
т.е. вы туда ломились, они вам отказывали, а когда вы зашли окольным путём и они вам опять отказали из-за нерелевантных технологий — это они тратили ваше время, а не наоборот?
Банки это как раз те организации где требуется чёткое знание определений. У них строгая отчётность перед государством, аудиторами, да и протоколы межбансковкого взаимодействия требуют строгого следования правилам. Из моего опыта работы в банке там придирались к каждой букве ответа и общий совет был такой - если не можешь ответить точно, не отвечай, иначе будут проблемы.
Зачастую ответы в надзор писали как казаки турецкому султану - всем отделом. Тщательно выверяя каждую фразу. И перед отправкой показывали юристу.
вопросы под копирку
Хорошо. Легко выучить :)
Уже два года активно подбираю разработчиков в команду. Примерно процентов 30 пишут в части навыков, тоо чем только читали и их это не смущает. Так что вчитаватьсч в резюме нужно и при этом нужно отсеивать.
Лайвкодинг проводим без привязки к нашему решению, цель Лайвкодинг - оценить рассуждения и логичность кандидата.
Отчасти оффтоп, что в целом понимают под "БАЗОЙ", какой список вопросов ожидают услышать интервьюеры по .NET? И что за Пет проекты ожидают?
На счёт БАЗЫ как уже говорил всё индивидуально от специалиста, который собеседует. Может быть банальные вопросы из серии "Чем отличаются ссылочный и значимый тип? Чем отличаются IEnumirable от IQueriable". Может быть для спеца база "Что будет, если я создам массив таксков в каждом из которых вложены ещё таски, запущу этот массив асинхронно WhenAll и захочу вывести все значения всех тасков как из массива, так и вложенных". Тут на какого идиота напоритесь. С пет проектами та же история, кто-то ожидает несколько микросервисов с апишками, работой с ОРМкой и некой работой продюссера-консьюмера, и всё это упаковано в контейнер. А кто-то ожидает личных библиотек, которые используют миллионы людей, реализующие некие паттерны и решающие простые задачи гениальными методами.
Во всем выше описанном есть противоположная сторона: упор на так называемую "базу" дает возможность кандидатам зазубривать предполагаемые вопросы. Когда-то за собой подобное заметил, что после нескольких собеседований у меня не столько добавились навыки, сколько появился навык проходить интервью: на повторяющиеся вопросы отвечаешь не потому знаешь и/или применяешь на практике ежедневно, а потому что неделю назад проходил интервью и там был такой вопрос
Я не знаком с текстами как же работают джуны и стажёры в "программистских конторах", те кто: пришел с универа, с курсов, закончили вуз более 15 лет назад и вспомнил что у него диплом в котором написано "Вычислительные машины, комплексы, системы и сети". Есть что посмотреть? Как вообще входят в работу? На других работах все ясно, тебе платят авансом и ты в течении какого то срока втягиваешься в работу, отрабатывая аванс и рассчитывая на повышение з/п.
мимо .net джуняра
С описанным в посте не сталкивался, видимо опыта собеседований не достает пока, но вот пара кейсов.
Кейс 1.
Закидывали вопросами по "БАЗЕ" только единожды (в целом по теме, но со своими особенностями). По итогу махнули рукой на мои ошибки при ответах, мол, нормально, опыта наберешься, а у нас все равно на этот проект человек нет. Оффер.
Кейс 2.
В одной компании сказали "У тебя офигенный профиль на GitHub, готов прямо сейчас с руками отрывать... только техлид хочет, чтобы все кандидаты тестовое делали". Пообщались еще по теории, пара формальных вопросов - всё всех устроило. Дали тестовое на неделю, я его сделал. Выясняется, что ответ дадут через две недели... Ладно, дождался-таки. Отказ.
Кейс N.
В основном, если не отказывают на этапе великого фильтра HR, все просят сделать им сразу тестовое задание, на которое выдаётся 7-10 дней. Без предварительного общения с HR хотя бы. Нужно ли говорить, что после этого следует закономерный отказ... если вообще ответят. И таких немало. Это очень сильно замедляет поиск и получение обратной связи.
Вообще, ощущение такое, что работу можно получить чистой удачей. Прибило волной в компанию, где готовы рассмотреть джуна - вцепляйся как клещ и не отпускай, иначе в этом году работу ты не найдешь
Подумалось, пора начать продавать услуги собеседования. Я прихожу к вам, получаю расклад: кого ожидаете, какая культура в коллективе, оргструктура. Дальше провожу собеседования не как просто хрюша, а как ваш коллега с техбэкграундом. Короче, IT-сваха
Далее интереса ради я решил понять, а что сейчас на рынке творится, и что же мы делаем в найме не так
и что же мы делаем в найме не так
не пнули техлида под жеппу подальше от процесса найма, например, это прям базовая база которой, скорее всего, будет достаточно для спокойного укомплектования команды
После ещё пары десятков таких собеседований я понял, что рынок не изменился ни разу, но при этом вообще не похож на то, что было буквально 2-3 года назад.
Не могу сказать, что прям весь такой ИТ аксакал и больше всех повидал на своём веку, только повспоминав своих и знакомых историй, могу сказать, что 8-10 лет назад было такое же положение дел. Ну разве что рекрутеры звонили на телефон или писал на электронную почту, а не как сейчас в мессенжеры и профили социальных сетей.
После этого забавно слышать от комьюнити-рекрутеров, что на рынке дефицит специалистов, не могут найти хорошего мидла-сеньора месяцами, при этом под их порогом орава толковых и не очень ребят, которые жаждут работать на галерах
С ними иногда бывает крайне забавно. Доходило до того, что напрямую у бизнеса спрашивал, знают ли те, что творят при поиске их сотрудники? А именно:
- резюме без фотографии? сразу в корзину
- на фотографии к резюме слишком фривольно выглядит (присутствует вейп, кальян или вызывающего вида майка) сразу в корзину
- в письме от кандидата только ФИО, название вакансии и приаттаченное во вложении резюме ? Без небольшого описания самого себя или самопрезентации в теле письма? сразу в корзину
И это не мои сказки, это из их жалоб на Linkedin, как им трудно приходится искать кандидатов.
вы знаете что такое NDA?
Знакомый практикующий юрист и владелец небольшой юридической компании по совместительству, решил себе сделать сайт и обратился в соответствующие компании, которые занимаются изготовлением сайтов. И вот когда вопрос дошёл до юридической стороны сделки непередаваемому веселью юриста не было предела. Поэтому не стоит надеяться, что в наших Палестинах NDA или его подобие имеет особую силу.
старшему разработчику в другой команде парочку таких каверзных вопросов и был послан с фразой
Да, всё так. Иногда даже не от каверзных вопросов, но фундаментальных на собеседовании можно сразу словить минусов в карму.
По итогу сейчас мы имеем:
Дикую нехватку рабочих рук в команде.
Постоянно не укладываемся в очередные дедлайны.
Вопросы со стороны начальства о большой загрузке и медленно достигаемых результатах.
"Всезнающего" техлида, на которого давит начальство, который давит на меня.
Мы имеем дефицит высококвалифицированных (с той самй БАЗОЙ) и ответственных и опытных, но низкооплачиваемых специалистов.
NDA у нас - это скорее хороший тон.
Я не буду показывать код с моих старых проектов не потому, что это понесёт какие то юридические последствия, а ввиду собственных моральных принципов.
Тут полностью согласен. Учитывая, что при решении схожих задач, но на разных местах работы, программист скорее всего возьмет решение, которое уже когда-то использовал(скоре всего даже не осознавая это). Правда это не касается каких-то специфичных алгоритмов, которые были придуманы для конкретной компании, вот их повторное использование точно будет осознано, ну и вполне могут быть юридические последствия.
Я за кандидата, знает и понимает что делает, умеет реализовывать поставленные задачи. Но с немного урезанной вилкой зп по причине отсутствия опыта в применяемых нами технологиях
Т.е. вы кандидату демпингуете предложение только из-за того, что он не имеет опыта в технологиях, которые вы используете. Тут возникает вопрос: а зачем вы его тогда позвали на собеседование?
Со стороны соискателя это выглядит оскорбительно, когда кандидату просто режут косты после нескольких этапов.
Так и рождается ненависть к работодателям, которые ввиду своей внутренней бюрократии и отсутствием коммуникации между подразделениями предлагают нищенские по отношению к запросу кандидата оферы.
Не могу похвастать такой экспертизой как у автора, но он опустил такой важный момент, когда готовы брать без собеса, с улицы можно сказать, а потом удивляться почему он за неделю не выучил стек, который первый раз в жизни увидел на их месте работы
Какое счастье, что уже больше 5 лет не участвую в этих крысиных гонках, работая над своими проектами и имея пассивный доход, бОльший, чем я имел работая на дядю вплоть до CTO(в промежутке еще был и тимлид, и принципал эксперт). Иногда зовут на собеседования по моим старым CV, дежурно пишу отказ. Зарекся работать на кого-то, чего и всем желаю :)
Собесился в одну рф компанию, которая известна своим поисковиком и не только. Говорили о том что ищут ребят с небольшим опытом, но стремлением к обучению и развитию, следовательно куча этапов интервью будет пропущена и разговор состоится с техлидом. Так получилось что за несколько дней до собеса я получил более крутой на мой взгляд оффер, однако решил все же пойти на собес так как было бы интересно (все-таки «лидер индустрии»). Прогнал так называемую по сетям, контейнеризации, виртуализации, освежил прошлый опыт и был готов к интересному диалогу. Спустя 2 минуты после подключения техлид скинул ссылку на решение алгоритмов, впав в ступор и переволновавшись нарешал какую-то ерунду. Пытался как-то свести диалог в сторону самой вакансии и стека технологий, но толковых ответов не получил. Хотелось бы в целом узнать отношение людей в комментах к алгоритмам и алгоритмам в девопс в частности (джун+/миддл лвл).
Алгоритмы не имеют никакого отношения к девопсу.
Балуются ими в фаанг, а в РФ - те, кто думает, что они фаанг (Тиньков, Яндекс).
Согласен, это просто часть найма, которую взяли из FAANG, типа «мы it компания, и мы все программисты». То же самое с system design, на интервью просят нарисовать facebook на минималках, или twitter, а потом в команду попадаешь, смотришь на какие то убогие полураспиленные монолиты и костыли, думаешь: «а собственно зачем там был system design?»
Вангую, что на собесе в разработке примерно так же: всякие сложные сортировки, поисковые алгоритмы, деревья в глубину, ширину, а потом на фактической работе json туда сюда перекладываешь
По поводу конфликта с техлидом - я бы протестировал своих топовых сотрудников на знание этой самой базы. Если они плавают в этой базе, но при этом прекрасной перформят, то это повод тех лиду задуматься об адекватности своего опросника.
По поводу собесов - я бы отталкивался от опыта кандидата. Расспросил бы, в каких проектах он участвовал, какие задачи решал. Выбрал бы пару топиков, максимально релевантных задачам проекта, и уже по ним подробно бы побеседовал - какие проблемы возникли, какие были приняты решения и почему. Такая беседа даёт лучшее представление о кандидате чем прогон по опроснику
Кстати, мы так делали в своё время, когда внедряли стандарт для собеседований.
Была проблема — у фирмы 4 офиса в разных странах и на разных континентах (Европа и США). В каждом офисе стандарты собеседования свои, хотя по факту все работали над одними и теми же проектами. И получалось, что в некоторых локациях иногда просачивались ребята по уровню чуть выше нуля...
Предложили решение — внедрить общий формат собеседования, с более-менее стандартным опросником. И обязательно на собеседовании должен присутствовать сотрудник "с другого континента", хотя бы в формате молчаливого слушателя.
Ну и в итоге опросник погоняли на своих же сотрудниках, примерно человек 20 проверили. По итогу от некоторых вопросов действительно пришлось отказаться, чаще всего из-за того, что слишком неоднозначно вопрос сформулирован.
я бы протестировал своих топовых сотрудников
Интересно, как сотрудники отнесутся к такой инициативе начальства :)
Пост выглядит как нытье на техлида, который запарывает кандидатов, а вы, тс, как бравый рыцарь не можете его найти. Потом всецело вините в уходе западных компаний.
Я за последний ровно год провел порядка 100 собеседований и сделал 6 офферов, вот и считай конверсию. Это были аналитики и разработчики. Аналитика толкового найти очень тяжело, а разработчика, даже который имеет потенциал, но при этом всего год опыта работа за 300-400к я брать ну никак не вижу смысла. Вылью за эту цену он принисет сильно позже.
Закончил курсы по профессиональной переподготовке на QA инженера. Около 6-7 месяцев откликался буквально на все вакансии на всех возможных площадках. Опыт имелся на момент поиска работы, но небольшой (мелкая подработка). Могу сказать что будь ты хоть трижды знающим, дважды умным и вообще классный по всем фронтам - работы ты не получишь потому что ты джун, а их никто не любит. Около 30% откликов остались висеть мертвым грузом, вакансии переносились в архив, открывались вновь, публиковались по 10 раз в день, но тишина. Еще 50% это обычные отказы где "не готовы пригласить и бла-бла" и что самое забавное, такие отказы летели по вакансиям где не нужен опыт и набирают просто на стажировку с окладом в 15-20 в месяц (какой-то bread, не правда ли?). Еще 18% это с ноги тестовое задание которое просят выполнить (и тестирование каки-то сайтов-визиток и боевые сайты, что скорее всего бесплатный труд на благо, чего только не было), из этих 18% убираем около 15% выполненных тестовых которые остались без ответа, и еще 3% это отказы потому что "мы хотели не так" (а в сопроводе писали "делайте как вам удобно") штош. И у нас остаются 2% по которым предложили собеседование (я откликнулся более чем на 600 вакансий и реально приглашения приходили по 2 из 100 в среднем). Собесы были разные, где-то гоняли по базе которую я еще хорошо помню с курсов, где-то задавали конкретные вопросы связанные с работой команды в которую я собеседуюсь, где-то спрашивали почему я ухожу с нынешнего места работы, кто-то назначал собес и за 5 минут до его начала говорил, что начальство отменило поиск/нашли кандидата лучше/мы передумали (нужное подчеркнуть). И вот я пришел на собес в своем городе. Буквально 40 минут общения с HR, ПМ и бывшим тестировщиком (на место которого меня и искали) и я вышел с четким понмианием что это место в котором хочется работать. Вопросы по делу, приятная обстановка, по теории как на экзамене не гоняли, но некоторые все же позадавали. Сейчас работаю в этой команде и могу сказать, что лучше одно очное собеседование чем 10 по зуму/скайпу/тг и тд.
Сейчас работаю в этой команде и могу сказать, что лучше одно очное собеседование чем 10 по зуму/скайпу/тг и тд.
Вообще никак не зависит.
Общались как-то с человеком, которому нужен был напарник. Погонял простыми вопросами, дал кейсы, опредилил знаю-не знаю. Вроде ок. Как раз по зуму.
Его рук попросил на собес приехать в офис (прилететь). Неохотно прилетел, но ок, это же я работу ищу.
1) рук не читал моё резюме, и читал его прямо на собесе
2) у него было несколько триггеров по моментам, которые ему не понравились. Заранее можно было уточнить, но не уточнили, потому что п.1
3) в общем, у обоих осталось впечатление зря потраченного времени, а у меня еще и осадочек от испорченного отпуска =\
10 минут чтения резюме перед приглашением "на финал" могло сохранить час его времени, час моего времени, час времени этого задолбанного чувака, а так же мой отпуск. Never happened.
возможно и так, но я сужу из личного опыта. на двух собесах по зуму не подключились те кто должны были и меня собеседовали черт пойми кто с вопросами из разряда "кто вы по гороскопу", один собес назначили пока я был в отпуске на море, я подготовился, расписал свой график отдыха что бы быть на связи в нужный момент и тут за 5 минут до мне пишут что ничего не получится =(
Спасибо за статью. Я 7 месяцев гонял по собесам плотно. Во-первых я подтверждаю то что Вам попадалось. Во-вторых есть еще один вид собесов.
Ты проходишь все три этапа, а то и 4 - и прилетает отказ. Просто без комментов.
Увы, но для себя давно придумал термин "работадальческий терроризм". Всё эти "15 лет работы, но быть не старше 20 лет", техсобесы по "базе", которая нафиг не нужна на проекте... Собеседующие, которые вообще не понимают материала и ведущие опрос с листа... При таком отборе ещё и хотят "гравик 23/7/365. Всё оборудование ваше + совмещение ещё 12 профессий. Зарплата? Ах да! Плошка риса в месяц и Пластиковая вилка как годовая премия"
Ваш спец, что проводил техсобесы, просто очередной чсв-сычара. Моё мнение такое - хотите нормальные собес проводить - совставте совместный список и подием для вопросов, с обоснование" почему этот пункт мы должны спрашивать у собеседуемого и как этот пункт используется в нашей организации" с последующим вищированикм его у вышестоящего руководства. Всё! Закончится его произвол с "базой" и прочим бессмысленным выкручиванием рук и самоутверждением.
Нет, я не связан с it(хотя данная тема мне всегда была интересна, потому сейчас ковыряю доку по Swift) Просто исхожу из личного опыта проведения совместных собесов и последующим обсуждением собеса. Я даже больше скажу - несколько раз проводил собес, с обоими соучами, менеджеров на розницу и курьеров. Так вот по прошествии парочки из них я понял простую истину(для той конкретной организации) - они сами вообще не имеют понятия что им необходимо было от соискателей. Может ваш тезпид из этой-же песочницы?
Надеюсь я понятно выразил свою мысль. Ничего не хотел обидеть, но если кто-то обидится - значит я был близок к истине.
Весь текст - это сугубо моё мнение основанное на личном опыте.
"Но "всезнающий" техлид посчитал, что это и есть база, и её должны знать все. Отказ, снова потерян хороший кандидат." - да у всех комплекс бога у кого есть комплексы которые приаили им неадекватные родители алкоголики, вот такие же и метят в руководство чтобы вместить свои психические проблемы в проявление власти. И это всегда неадекватно. Рациональных людей раз два и обчелся, остальные просто обезьяны очелоченные.
Я вообще не работаю больше, отдыхаю и развиваю свои хобби уже 2й год, хватило мне этого. Даже искать не хочу пробовать что-то. Не интересно.
А поговорить с техлидом? Я проблему услышал как "есть потенциал, но не хватает базы" -- может обсудить когда потенциал важнее имеющихся знаний?
Ну и база, конечно, должна быть релевантна задачам, по моей практике задачи на работе однотипны, тут скорее надо гонять по логике/алгоритмам + используемым технологиям, чем по всему подряд -- до этого тоже надо договориться с ТЛ
Спасибо за статью, во многом разделяю мнение автора, хотя не ясно почему нет кворума в принятии решения по кандидату. У нас в небольшой ИТ компании обслуживающей большой бизнес основным критерием являются бабки. Чем меньше кандидат попросил денег, показав при этом высокий (относительно других кандидатов) набор скиллов, тем выше его шансы на оффер. При этом уровень знаний оценивается не в абсолютных значениях, а относительно других кандидатов. Похожий подтекст наблюдал в других компаниях. Похоже ИТ зарплаты привлекли слишком много людей и рынок порешал. Думаю, что как только кандидаты начнут снижать цену, сразу начнут получать офферы. Но конечно же этого никто не хочет делать. Очень интересно что будет дальше.
Совсем недавно решил таки пографоманить и написал статью по этому поводу. Классических ошибок тут две:
Убираем hr из найма, да вам труднее, но сколько вы команду набираете? Сколько проектов повисло?
Техлид - вот тут трабла. Он повис на "базе" потому что использует ее постоянно, 99% если он сам пойдет проходить собеседование и попадет на чуть другой даже не стек а упор в технологиях, его самого завалят с той же формулировкой. Поднимайте вопрос кейсов на собеседованиях. Минимум 40% ваших отказников через неделю-две будут в стоке и задавать темп. Ваш техлид явная проблема. Вам надо решать её.
Тут, к сожалению, в статье не затронули тему того, что разговоры и беседы рекрутеров никак не контролируются и частая история, что рекрутер может забыть и забить на твое резюме, хотя в разговоре уже договорились о зум-встрече. Рекрутеры ведут себя как хотят и делают, что хотят по сути и работают как на конвейерной линии.
Так же рекрутеры очень часто интерпретируют ТЗ по-своему, что уже отсеивает крутых специалистов
Если честно, есть сомнения, что автор реально проходил 20-30+- собеседований. Скорей всего, сам напридумывал после пары собесов. Я проходил недавно много собеседований и ничего из того, что автор написал не встречал.
Да, были недостатки, но другие, чаще всего, это чсвешные и высокомерные эйчары, которые возомнили себя вершителями судеб. Но ничего такого, что автор описывает, типа опоздания, каких грубостей серьезных или неадекватных разговоров, эйчар всегда рассказывал про свою контору, что уже даже надоедало это слушать. Отвечали на вопросы и т.д. Про nda, показать код все с пониманием относились. Пытались найти как-то компромисс обычно.
Единственное, думаю, что автор проводил собеседования и то, что он отметал потенциально хороших спецов из-за недостатка опыта или знаний, в это верю. Такой есть недостаток к сожалению.
Отличная статья, во всем согласен с автором, тоже будучи с 2019 года C# разработчиком с частичным опытом руководства
Как выглядят собеседования сейчас