Комментарии 354
В вышеописанных случаях техлиды (или кто там собеседовал) не заинтересованы были в расширении команды. Почему? Ну, это у них и надо спросить. Возможно, вцепились в свой монолитный коллектив и не хотят его менять. Свои ж, родные, а щас придёт какой-то хрен пойми кто, учить его пол года, время тратить...
Возможно, просто задолбались проводить по 10 собесов на неделе вместо того чтобы заниматься своей работой и заранее относятся к кандидатам негативно.
Возможно ещё какие-то тараканы в голове.
Так что либо эти люди не такие уж нормальные и зря вы их на собеседования ставите, либо сам процесс проведения собесов выстроен плохо и изматывает ответственных работников.
В любом случае обучать проводить собесы нужно не только HRов, но и тех кто технические интервью проводит. И следить за ними тоже нужно, чтобы почём зря не валили людей. Это в интересах комании набирать качественных специалистов, не стоит пускать всё на самотёк.
В вышеописанных случаях техлиды (или кто там собеседовал) не заинтересованы были в расширении команды. Почему?
Например, потому что у них уже есть «свой кандидат» наготове и они просто автоматически отсеивают всех дабы он в итоге получил место. Такого вагон и тележка когда речь идёт про выбор контракторов, поэтому и с обычными позициями явно хватает.
Зачастую приведенные ситуации - это не злая воля, а просто автоматическая реакция. Собеседующий, в первую очередь, должен уметь абстрагироваться от своих личных переживаний и опыта и смотреть на кандидата с точки зрения решаемой задачи.
Сможет ли этот человек делать то, что от него требуется? Сколько ресурсов нужно будет потратить на его (человека) "доработку"? И всегда помнить, что испытательный срок (в РФ) - 3 месяца и он позволяет уволить любого без особых сложностей (кроме женщин ушедших в декрет в этот период).
Я, когда нанимал людей (инженеров на завод), задавал технические вопросы только с целью отсеять тех, кто вообще не шарит. Для меня важнее было то, как человек умеет общаться, что он делал до этого и почему ушел с прошлого места работы. Всем кандидатам говорил, что испытательный срок 3 месяца, описывал свои ожидания по его окончании, что должен делать, уметь и т.д.
И тех, кто производил хорошее впечатление - котелок варит, общаться с людьми умеет, умеет решать сложные задачи (не сдается) - брал на испыталку и смотрел выхлоп. Слабый выхлоп или много геммороя - обсуждаем отчего, почему, чем помочь. Если по итогу 2 месяцев и 3х недель меня что-то сильно не устраивает и я не вижу возможности это исправить - жаль, но ставочка не сыграла, "наша компания вам не подходит, всех благ!"
Очень умно. Подбор персонала это в некоторой степени рулетка - никогда не узнаете какое число выигрышное и единственный способ это перебор. И на этот перебор намного выгоднее закладывать бюджет, чем на оплату года работы кадровика, пусть этот бюджет и выше. Ведь на выходе будет решение проблемы через три-четыре месяца, а не понимание того, что год потратили, а толку нет - весь год дело стояло и не приносило компании денег.
Да и сейчас инженеров, технологов и проектировщиков на заводы так и принимают. Это в IT искусственно странную моду создали, когда есть куча вакансий и они не закрываются при куче кандидатов.
Это в IT искусственно странную моду создали, когда есть куча вакансий и они не закрываются при куче кандидатов.
одно дело взять программиста на ЗП 200к, и уволить через два месяца (минус 500тыс ФОТ + затраты на поиск) и другое инженера-технолога на 40-100тыр который с бОльшей вероятностью потянет
если брать на полгода человека за копейки код писать, то ничерта не получится
задачи будут годами тянуться и на выходе будет продукт просто адового качества.
нельзя создать контору разработки где будут одни джуны. Только совсем безумный сеньор пойдет туда управлять разработкой…
Много людей написало в TG подискутировать?
Помимо фильтрующей функции, технические вопросы нужны для того, чтобы понять насколько адекватны зарплатные ожидания кандидата, или сколько компания готова предложить за его уровень.
Очень нехорошо оказаться через 3 месяца в ситуации "вроде парень хороший, но что-то мы ему много платим относительно его компетенций". По ТК РФ понизить оплату очень проблематично, поэтому приходится расставаться. Хотя могли бы работать и расти вместе.
есть очень простое объяснение почему собеседующие не заинтересованы (потенциально в любом) кандидате: они рассматривают его как потенциального конкурента, в лучшем случае того с кем придется делиться доступными материальными благами.
Отсюда и агрессия и все остальное.
Как вы проверяете что собеседующие заинтересованы в расширении команды? Они вас об этом просили? А может когда они вам говорили что не хватает еще кого-то они имели ввиду что работают за двойх и не мешало бы им повысить зарплату, а вместо этого их на собеседования таскают!
ну вы то конечно не такой, как они, вы особенный, вы не допускаете ошибок. Непогрешимый человек идеал)
Но это не значит что это всё делается агрессивно — наоборт, максимально дружелюбно и с лёгким юмором (если человек его понимает). Это нормально — не знать, даже по своей теме. Я больше смотрю как кандидат реагирует на стресс (идёт на конфликт или гасит), насколько целеустремлён, любопытен и т.д. и т.п.
Помню случай, когда кандидат так и не сумел ответить на сравнительно простой вопрос, но потом прямо на собеседовании всё равно докопался и до нас и до гугла и ответ нашёл. Взяли — не жалеем.
Так что дело не в вопросах. Дело в общении и установлении контакта. А знает, не знает — это видно больше по тому как он отвечает, а не что.
А формальное HR-вское собеседование — это не то что зло, это просто лишнее. Это можно всё и через анкету провести.
когда кандидат так и не сумел ответить на сравнительно простой вопрос, но потом
Потом - это когда? Кандидат заваливает первичный отбор = кандидат дальше не проходит.
"Это нормально — не знать, даже по своей теме"
Более того - это ненормально утверждать что знаешь все. Каждый раз когда я слышу от человека "я не уверен, это не моя область" - мое мнение об этом человеке улучшается.
У меня были не раз несколько обратные ситуации, когда собеседующие сразу говорили что они сами не знают правильный ответ на вопрос и им всего лишь интересно в камо направлении я буду по этому вопросу рассуждать - по-моему вполне даже нормально, и уж всяко лучше чем у чела с 15+ лет опыта в C# в девятисотый раз спрашивать: "Чем абстрактный класс отличается от интерфейса".
"We're all someone's 'noob'.
I think we programmers have created a culture where you're supposed to know everything, and asking the wrong question might make you look stupid.
As a result we ask less questions, and spend too much energy trying to look knowledgeable instead of learning from each other.
The best programmers I know says 'I don't know' all the time"
Solomon Hykes, Founder and CTO at Docker
Ох уж эти анкеты... Сначала отправляешь свою, потом у работодателя заполняешь от руки. А интервьюер, даже не читая, пытается задавать те же вопросы по третьему разу.
Многие программисты чувствуют себя эдакими Гэндальфами, сдерживающими тьму
Подтверждаю, сам прошел через этап, когда на собесе был азарт задать настолько тяжелый вопрос, чтобы у кандидата позвоночник в трусы высыпался. К счастью, дурь в голове недолго продержалась. Тут же все как в жизни: завести друзей проще, если ты приятный и интересный человек, а не конченый жопошник.
Чего кандидату удалось добиться, пока он работал в прошлой команде? Какой вклад он вносил?
Вот от таких вопросов действительно звереешь. Да работу, *ять, свою делал - вот весь мой вклад и достижение :-D
Но, статья хорошая - сам хорошо помню каким на самом деле был удаком когда по-молодости собеседовал других людей. :-D
Ну так и расскажи, что делал. Будет за что зацепиться интервьюеру, развить разговор.
А то вот приходит такой:
- Расскажи, что делал?
- Работу работал!
- Эм.... Ну ок, давай, я хз, про обход дерева тогда чтоли...
Данные из DTO в DTO перекладывал и легаси говнокод еще больше заговнокоживал, охренеть достижение, это если по честному, без всей этой успехо-успешной тряхомудии, не прикольно, но нужно было. И что, скажешь так, и тебя нахрен пошлют - кому нужен такой специалист.
А с чего он взял, что умеет что-то ещё, если больше ничем не занимался. Если ищут сеньора, а пришел вот такой перекладчик ДТОшек, то зачем мучить и его и команду окуная в задачи, с которыми он не сталкивался и близко? А впрочем даже это перекладывание можно подать по разному, мол поэтому и ухожу, что чувствую, что перерос эти задачи.
Ага, видал я такие команды, на собесе понтов полно, вопросы все про солид и всякие там суперпрактики, а потом в код посмотришь - а там методы по пять тысяч строк, перекладывание дто, и концентрированная боль, вперемешку с лютыми багами. Но на собесе прямо - парни делают будущее с успешным успехом!
Ага, причем такое ощущение, что есть корреляция - чем больше тебе на собеседовании задают хитровывернутых (и имеющих, обычно, очень малую практическую ценность) вопросов типа: "Как поменять символ в строке не содавая новую строку", тем больше DTOшек по пять тысяч строк каждая потом придется перекладывать.
коллега рассказывал что у него на предыдущем месте работы был апофеоз такого подхода: на собесе долго гоняли по С и многопоточности, да многопроцессорности, плюс кешам процессора и как писать код, чтобы использовать эти все тонкости.
А потом после найма - он месяц сидел и запускал билды (ему сказали "ну, тут пока тасок нет, пойди посмотри что там с билдами") при помощи bat файлов, доставшихся в наследство (он с горя даже начал их рефакторить, но довольно быстро понял - что там к чему и уволилися)
У меня было - нанялся в один известный банк. На собесе тоже всякое хитрое спрашивали, и про многопоточность и про паттерны и много чего еще. Начал работать - даже вроде пилим новый проект, легаси ноль, должно вроде было-бы хорошо быть, но на проект набрали массу джунов чуть выше нуля (самая ядреная хрень, как по мне - человек уже почувствовал Силу, но правильно применять ее не умеет) и такая-же околонулевая организация процесса, кодревью по факту только в нашей команде и был, только у нас и джунов не было..
В итоге код проекта был - мама дорогая.. кровь из глаз, и вполне ожидаемо все сроки продолбали, проект в итоге прикрыли. Успешные рукамиводители успешно катапультировались достигать новых высот на других проектах, в провале обвинив тупых и ленивых разрабов, а программеры - кто уволился, кто потянулся говнокодить дальше, в других проектах.
кодревью по факту только в нашей команде и был, только у нас и джунов не было.
Прикольная, наверное тема - синьоры ревьюят код друг друга, а джуны коммитят вообще без ревью :))
вот там вообще ад и израйль был, один департамент и кодревью и архитектурный комитет и согласование с владельцами проекта… а другой департамент в ту же репу льет без ревью и деплоит в прод сразу… ну типа норм… там такое в коде встречалось… мамадорогая…
хотя оглядываясь назад понимаю что их спасало то что 95% персонала у них — сеньоры, хотя мешанину в репах за свои 10+ лет жизни они наплодили капец
Да уж, "прикольно", особенно когда твой может и не идеальный код, потом какой-либо джун без всякого ревью раздербанит как бог черепаху, и все ломается :)
ЗЫ помню, когда мы пытались донести до рукамиводителей мысль что как-то это не правильно, что все фигачат код без ревью, он послал нас практически буквально сказав - "Кончайте страдать херней со своими ревью, у нас проект в срок не укладывается, еб..те как все, да побыстрее"
и РП и руководитель департамента меня буквально убить хотели за срыв срока на две недели… представляете ПОСМЕЛ задержать релиз по причине того что отправил на согласование очень спорного mr безопасникам (которые его завернули кстати на доработку)… охренеть, во я смеялся тогда
Кончайте страдать херней со своими ревью
Я так думаю, после такого стоит сдуть пыль с резюме :)
У меня примерно следующий стандартный список вопросов по коду когда я собеседуюсь:
Как относятся к warning-ам в коде?
Используют ли автоматизированный CA/SA (анализ кода и стиля)?
Пишут ли юнит-тесты, и делается ли анализ покрытия для них?
Как работают с ветками Git, есть ли код-ревью?
Как работают с СI/CD?
У меня была история что на одном из собесов для очень серьёзного заказчика (как его тогда описали) спрашивали про парсеры и грамматики, свой язык для каких-то там запросов куча связанного с этим добра и терминологии, которую я старался изучал, даже для себя написал небольшой проект. А что по итогу: сидели почти целый год переносили старый легаси на новые рельсы(c С++98 и старше на С++14) в облако плюс переписывали билд с Make+Bash на CMake.
ну так потому и спрашивают про солид и суперпраактики - потому что сами не умеют и нужен кто-то, кто умеет)
Hidden text
Источник: https://t.me/tribecorporation/
А что такого особого в энтерпрайзе разрабатывает сеньор? На деле, джун просто перекладывает DTOшки, мидл может это делать без стороннего надзора, а синьор еще сам при этом знает какую DTOшку куда переложить. Вот и вся разница :)
Синьор научился работать с каким-либо фреймворком - который большую часть работы по перекладыванию берет на себя, и умеет пинать этот фреймворк в правильные места, если там что-то засбоило. Этим умением он страшно гордится, и демонстрирует его на всех собесах, топя соискателей, которые по какой-то причине так глубоко в эту тему не погружались. :)))
кажется что это как раз тики еще мидл
Ну, так-то стандарта устоявшегося не существует, кого миддлом считать, а кого синьором, что и приводит к тому, что и не такие чудесные "синьоры-помидоры" встречаются, опять таки - Даунинга, с его другом Крюгером никто не отменял, чел сам может себя вполне искренне считать крутым спецом, хотя и на миддла еле-еле тянет.
А что такого особого в энтерпрайзе разрабатывает сеньор?
сеньор нужен в ентерпрайзе чтобы суметь филигранно воткнуть костыль в антиквартный монолит чтобы он не развалился и новая фича заработала. у джунов с миддлами может просто квалификации не хватить сделать такое когда кодовая база тянется из 80х годов.
Золотые слова. По идее все вопросы на собеседовании с алгоритмами и прочим подходят для стартапа, где нужно писать много, эффективно и с архитектурой с нуля. Когда проекту уже года два, все это резко заканчивается и начинаются задачи вида: хотим, чтобы пользователь ещё передавал в форме вот это поле, а если поле принимает вот такие значения, то тогда хотим, чтобы произошло вот это и куда-то отправился email. При этом обычно уже и отправка написана, и фрэймворк рулей и правил какой-то сделан. Обычно новым if else, или дополнительным subscriber все решается. Удача, если за год что-нибудь рекурсивное приходится написать или начать новую иерархию классов. Конечно, можно ещё рефакторить, но зачастую это может требовать много тестирования, а на это могут и не давать ресурсов. Поэтому единственный вариант всегда уметь эти знания применять - ходить по стартапам, начинать там все, а как идёт рутина - валить в новый стартап. Ну либо параллельно с работой делать пет-проекты
Кстати да, и у такого синьора обычно как раз самые сложности с ответом на вопрос "что особо запоминающееся и крутое вы делали на прошлом проекте". Ну не скажешь же на полном серьезе что самая крутизна - это раскрашивание поля в интерфейсе, выводимом через легаси фреймворк, кривой и глючный, который не поддерживает такую фишку без разных хитромудрых хаков (реальный случай из практики). Оно может и было реально очень сложно и даже интересно - нагнуть кривой фреймворк что-бы он таки сделал то что нужно, но человеку со стороны это сложно понять, потому что звучит это как какая-то примитивная задачка для джуна, если не знаешь всего контекста.
Хмм… тут, скорее, не абстрактный сеньор нужен, а человек, знающий проект как токарь свои три пальца. В смысле, пару раз успешно обфакапившийся, и знающий не только куда и как можно тыкать, а еще и куда и как тыкать не нужно.
Удовлетворяющий этим требованиям автоматически будет сеньором, просто в силу того, что ведет этот монолит значительную его (монолита) часть жизни.
Но это будет не тот сеньор, который придет на собеседование.
Хмм… тут, скорее, не абстрактный сеньор нужен, а человек, знающий проект как токарь свои три пальца
И где вы такого найдете в проекте которому 30+ лет? причем в кровавом ентерпрайзе?
если взять миддла с рынка труда, он все завалит или будет очень сильно тупить.
Я на самом деле это довольно недавно осознал на своем опыте. поработав в одной штатовской конторе, там кодовой базе лет 12 было, но несколько раз довольно сильно менялась команда.
И приходя туда сталкиваешся с сотней микросервисов и огромным монолитом, и никто не знает полностью как оно работает и никто не напишет ТЗ и документация если и есть то устарела… и приходится самому изучать огромные flow бизнеспроцессов вместо того чтобы «просто код писать»
там практически все разработчики были сеньорами, а если попадались миддлы, мне приходилось самому разбираться как работает, дополнять им ТЗ и искать людей которые подскажут. потому что они откровенно не тянули такое.
сейчас я вот попал в контору где персонал в основном миддлы, и мне приходится прямо разжевывать задачи чтобы они могли чтото делать, тут сервисы не на столько старые и большие но я начал очень отчетливо осознавать разницу миддл-сеньор
легаси говнокод еще больше заговнокоживал
На самом деле есть такие проекты, где прям такие люди и нужны, а не вот это всё микросервисное смузи :)
Ну так если на новой работе тоже DTO-шки надо перекладывать, почему не рассказать подробнее, как умело их перекладывал на прошлой?
Ну в идеале этот вопрос спрашивается не для того чтобы ты выделывался, а для того чтобы найти о чем с тобой поговорить. Чтобы избежать как раз того что собеседующий спрашивает про свой проект про который ты не слышал ни разу.
А если этот вопрос используют чтобы ты условный "баллов крутости" набрал, то может и хрен с ними, с конторой такой
Вот да. Всегда непонятно, что тут можно ответить
создал приложение для того-то и сего-то
пофиксил 100500 багов
оптимизировал что-то эдакое
Вообще-то "создал-пофиксил-оптимизировал" — это как бы работа каждого первого программиста.
А рассказать, что конкретно создал-пофиксил-оптимизировал — обычно NDA не велит.
Создал - рилтайм обмен страницы с сервером через ws. Поднял socket.io и т.д. Оптимизировал этот обмен. Уперся в производительность socket.io, переделал на какую-нить центрифугу, вынес логику в отдельные воркеры и т.д.
И nda не нарушил и вроде рассказал чем занимался, а интервьювер прикинул примерный бэкграунд сопутствующих этому задач, сделал выводу, спросил про какие-либо моменты.
Как по-вашему, можно какой-то вывод об опыте кандидата по такому рассказу понять? И сколько пунктов НДА могло бы тут быть нарушено?
Я обычно отвечаю, чем именно я занимался. Всегда непонятно, почему у людей, которые реально что-то делали, а не самозванцы, возникают проблемы с этим одним из самых простых вопросов на собесах.
Ну, закончили проект, запустили в серию. Ну, я тоже там неплохо потрудился. Но где здесь эти самые "достижения", откуда я их возьму?
Потому что проекты приходят и уходят. Сделал, выкинул из головы, думаешь о новом, и так сотни раз, и это всё превращается в поток, о котором сильно не задумываешься. Рассказать в относительных подробностях получается только о том, что делаешь прямо сейчас. Но если прямо сейчас ты ищешь работу, возникает некоторая проблема. И сама постановка вопроса 'чего удалось добиться' довольно странная. Дали задачу - сделал задачу, чего добился? Выполнения задачи?
и так сотни
Фигасе у вас карьера. Я за 20+ лет менее чем в 10 проектах поучаствовал и в каждом помню, чем занимался, даже в тех, что делал 20 лет назад. Расскажите тогда про эти сотни, это же реально интересно послушать.
Для фрилансера 10 проектов за 20 лет было бы катастрофой. Да и для постоянной работы это очень мало, как мне кажется - за 20 лет у меня определённо было на порядок больше 10 проектов (игры, системные тулзы, медиа, интеграции платёжных систем, драйверы, железки, саундтреки, всякая фигня). И как бы, вы просите рассказать в ответ на обоснование, почему рассказать сложно.
Мы тут вроде про наемного работника, а не про фрилансера. И о последних 2-3 проектах (или о любых запомнившихся) рассказать можно, как по мне. Если человек говорит, что он сделал сотни проектов, но не может рассказать ни об одном, это очень странно, как по мне. Конечно, я, как положено джентельменам, поверю ему на слово, но потом обязательно дам ему пару задач, чтобы у нас было, что обсудить предметно.
Наёмные работники и фрилансеры - это одни и те же люди. Кто-то уходит с постоянной работы, кто-то приходит к ней, кто-то всегда совмещает (мой вариант).
(очень интересно оказалось не очень интересно, удалено)
А сколько людей вы отсобеседовали, какой процент наняли и сколько из нанятых прошли испытательный срок?
люди видели мои прошлые работы в требуемой им узкой области
Ну мы тут вроде не про вас, а про индустрию в целом. Никто не идет на гитхаб смотреть кто там чего понаделал, когда ему надо мидла нанять в команду джейсоны перекладывать.
Сегодня вечер странных вопросов? Ну каким боком релевантен мой личный опыт найма, и что вообще подразумевает, что я кого-то нанимаю? 'Собеседовал' я человек 30 (в основном смотрел портфолио и задавал по нему вопросы), нанял человек 5-7, никаких испытательных сроков - заранее было известно, на что человек способен.
Я вам говорю, что таки идут, а вы говорите - никто не идёт. Ну, видимо вам виднее за индустрию.
может 10 проектов за год?
Оно, наверно, зависит от того, сколько времени каждый проект.
Похоже что у фулл-тайм работников и у фрилансеров несколько разные полнимание проекта:
"400 проектов за 20 лет" это "20 проектов в год" это почти "2 проекта в месяц"
у меня "проект" легко может занимать год, а чаще больше - с учётом развития после внедрения и прочего
Дело не в фуллтайме. Проекты бывают разного калибра. Сделать интеграцию систем, вот API, срок месяц - типичная задача, это проект, с началом и концом. И в рабочем порядке таких несколько в год.
Обычно есть некоторые запоминающиеся моменты в любой карьере. А то получается, проработал 20 лет программистом не приходя в сознание, от момента посадки за монитор до вставания за покушать вечером темный экран, с перерывами на почитать хабр)
Дело к тому что называть "проектом".
У меня не бывает "проектов" вида "интегрируем X с Y" - это именно задача в рамках работы на проекте и, конечно, у задачи будет начало и конец.
И таких задач будет много и длительность у них будет находится в промежутке от "день" до "пара спринтов", но все они - в рамках одного проекта.
Если все такие "задачи" интепретировать как "проекты", то придётся всю джиру перелопачивать и тогда тоже будут "сотни проектов в год".
Но так как у меня есть именно проект и время жизни у него исчисляется в месяцах, то именно его я и буду описывать в резюме.
А вот на фрилансе ситуация с множеством задач в рамках одного длительного проекта это скорее исключение чем правило - что-то подкрутили "там", потом повертели "тут" и назвать это одним "проектом" нельзя вот и получаются большие цифры.
Заказчик у 'работы' разный, содержание её разное, условия разные, работа с командами зазкачика - люди разные, продукт для интеграции один из нескольких разных, которые разрабатывают внутри компании также разные люди. Все признаки проекта, и именно так оно и проходит по организации работ. Трудновато назвать 'проектом' всю деятельность компании на протяжении 20+ лет.
Трудновато назвать 'проектом' всю деятельность компании на протяжении 20+ лет.
Отчего же, если компания, например, пилит какой-нибудь продукт?
Условный, JetBrains с их IntelliJ IDEA
Продукт - это продукт. Проект - это проект. Компания - это компания.
В случае господина shiru8bit, если происходит «работа с командами заказчика», то у каждой такой команды в каждый момент времени должен быть какой-то проект, но он с нами этой информацией не делится.
Аналогично. Я могу быстро припомнить детели всех своих проекты, но их за 20+ больше 30 наверно и не наберётся. Но всё зависит от того чем человек занимается. Но если как фрилансер решаешь мелкие задачи или сидишь на аутсорте в узкой нише... Работа превращается в текучку.
В этом случае логично было бы рассказывать уже о типичных решаемых задачах.
Для этого можно просто обновлять CV по ходу - сделал реально интересную сложную задачу, сразу записал в резюме. Потом как только понадобилось реальное CV, посмотрел, вспомнил все что делал (даже интересные задачи имеют свойство забываться когда нужно их вспомнить), оформил в CV и перед собеседованием напряг память и подумал какие проблемы возникали и как решал.
Такое наверное бывает если предыдущий работодатель настолько сковал NDA что по нему просто не можешь ответить чтобы не раскрыть какой-то внутренней информации, если такой проблемы нет, то обсуждение предыдущего опыта считаю самой интересной частью интервью будучи как и интервьювером, так и тем, кого интервьювят.
Кандидату самому неинтересно рассказывать, чем он занимался. Он занимался рутиной в проекте с сомнительной пользой, использовал костыли, плодились баги, фиксил баги другими костылями.
Да работу,
*ять, свою делал - вот весь мой вклад и достижение :-D
Ну может они пилили онлайн-казино, работали в криптостартапе, в разработке сайта для взрослых или игры Raid:Shadow Legends и не хотят об этом говорить, не зная как собеседующий отнесется к такому опыту.
Почему звереешь? Если человек вообще никак не рефлексирует свой опыт, это тоже о многом говорит
В моей практике был случай, когда кандидат озверел от простого вопроса: "что это за собеседование на миддла, где задают ТАКИЕ вопросы?" И.. отказался на данный вопрос отвечать. А потом ещё негативный отзыв написал на сайте для отзывов на компанию, где с ним общались.
Представляю собеседование на должность хирурга:
- У меня стаж работы хирургом в больнице более 10 лет, также работал военным врачом в Ираке, где приходилось оперировать без подручных средств и без анестезии, и почти все пациенты выжили...
- Хорошо-хорошо, вот вам тестовое задание, удалите-ка аппендицит вот тому дяденьке. И пожалуйста комментируйте каждый ваш шаг.
Но почему-то хирургов так на работу не берут, не правда ли? Моё имхо - технические собеседования на уровень мидл+ не нужны от слова совсем.
Когда будут тысячи псевдохирургов, которые обивают пороги больниц с офигенным но выдуманными резюме - будут брать на работу именно так.
Но почему-то хирургов так на работу не берут, не правда ли? Моё имхо — технические собеседования на уровень мидл+ не нужны от слова совсем.
Есть огромная разница между программистом и практикующим врачом. Хотя бы в том, если хирург успешно работал хирургом, значит, это само по себе некая гарантия его профессионализма, не говоря уже про аттестации, лицензии и так далее. И то, далеко не всегда, врачей-шарлатанов тоже немало. Если программист работал успешно программистом… ну, по всякому бывает. Нередко на поверку оказывается, что он много чего не умеет из того, что вам требуется. И даже из того, что он написал в своём резюме.
Ну то есть так и получается, что-то типа "большинство программистов не умеет программировать. Иными словами, все, кто ищет работу – круглые дураки, а наша задача – уличить их, преподать им урок, унизить так, чтоб неповадно было."
К слову о хирургах:
Сюда же - https://lenta.ru/articles/2018/10/12/konoval/
Про доктора сняли минисериал - https://www.kinopoisk.ru/series/1309543/
Позвольте немного детализировать как выглядел бы технический раунд хирурга в стиле разработчика:
"Вот вам игрушечный набор "Юный доктор", удалите аппендицит у этого плюшевого медведя, и рассуждайте вслух."
Хирурга можно попросить заштопать курицу или виноградинку если уж проверять.
Так оно ближе к тому, что просят как «тестовое».
Живую курицу и без анестезии и фиксации
...за три минуты, и на бегу!
В условиях есть чтобы курица осталась жива после операции?
Условия, не оговорённые при постановке задания, традиционно оставлены на усмотрение исполнителя!
технические собеседования на уровень мидл+ не нужны от слова совсем
Позвольте, не соглашусь. В своё время провёл огромное количество собеседований. Приходят люди с фантастическим резюме, неплохо рассказывают про проекты, над которыми работали, их архитектуру. А когда дело доходит до кода, не в состоянии решить элементарную задачу. Причём, правда, элементарную: никаких алгоритмов, никаких структур, никаких специфический особенностей языка, никаких требований "идеального" решения. Просто банальная рутинная задачка уровня junior, чтобы посмотреть, как человек думает, но некоторые "синьоры" со звёздным резюме не могут решить. Пытаются, но правда не могут. Попробуйте ради интереса побыть интервьюером на мидл+: думаю, вскоре посмотрите на процесс собеседования сильно по-другому.
А можно пример задачи? А то бывают вроде простые, но в стрессе и без опыта прохождения можно хорошо так затупить или уйти не в ту сторону.
Могу предложить шутливую задачку
"закомментируйте" (исключите выполнение) кусок кода не используя символы выделенные языком программирования для оформления комментариев
Что-то в стиле if 1=2?
Ну что-то такое, да. Интересен ход мыслей.
Видите, нашлось о чем поговорить на собеседовании.
продолжаем разговор) "напишите функцию сложения трех целых чисел."
А в чем прикол (про ф-ию сложения)? :))
Переполнение
1) Таки как будем проверять аргументы? 2) А если нам нельзя кидать эксепшен и надо все же сложить и отдать хоть как то результат?
А, ну в шарпе переполнения не будет (по умолчанию). Правда и результат будет странноватый. Тут уже надо уточнять требования к ф-ии - должна ли она кидать исключение, возвращать странный результат, или поступать еще как-нибудь.
Переполнения не может не случиться при соответствующих исходных данных. Есть лишь варианты что в случае переполнения делать — кидать исключение или возвращать "странный результат".
Да, но это уже и есть "уточнение требований", потому что делать сразу и то и другое не получится. Кроме того можно еще вообще слегка поменять API и реализовать например так:
// Результат всегда будет без исключения и точный
// а там вызывающий пускай сам решает что с ним делать.
public long Sum(int x, int y, int z) => (long)x + y + z;
Или так:
// Пускай вызывающий сразу решает устраивает ли его исключение
// или он хочет всегда результат, хоть и "чудесатый"
public int Sum(int x, int y, int z, bool throwOnOverflow)
{
if(throwOnOverflow)
{
checked
{
return x + y + z;
}
}
return x + y + z;
}
Вот и не прошли бы вы у нас коде-ревью! :)
З.Ы. булевы параметры — правда зло, лучше вместо них enum'ы использовать. Или метод перегружать (SumWithOverflowCheck — простите, я в душе джавист). Иначе часто при вызове метода вообще не понятно что они значат. Не всегда смотришь код с линтером.
Иначе часто при вызове метода вообще не понятно что они значат.
Ну в шарпе с этим проблем нет, потому что можно просто писать так:
var result = calc.Sum(1, 2, 3, throwIfOwerflow: true);
Лично я так всегда и делаю, и не только для bool, а вообще всегда когда просто по литеральному значению параметра сложно предположить его смысл.
лучше вместо них enum'ы
Инамы - зло (я не знаю как в Жаве, но, по крайней мере так как они сделаны в Шарпе).
Чтобы этого избежать, можно в вызов подставлять название переменной:Sum(1,2,3,/*throwOnOverflow=*/ true)Плодить по сущности на каждый чих - и правда очень по-джавистски =)
В шарпе enum-ы это по сути всего лишь глобальные целочисленные константы с небольшим "сахарком". Совершенно не объектно-ориентированная и не расширяемая штука, которая, к тому же, если где-то сохраняется или передается как число (что обычно по умолчанию), то чревата runtime ошибками. Кошерная ОО-альтернатива enum-ам это предопределенный набор полиморфных объектов и использование паттернов типа "стратегия" или "состояние". Например, в случае нашего складывателя чисел могло бы выглядеть примерно так:
public abstract class CalcStrategy
{
public readonly CalcStrategy Checked = new CheckedCalcStrategy();
public readonly CalcStrategy Unchecked = new UncheckedCalcStrategy();
public abstract int Sum(int x, int y, int z);
}
public class CheckedCalcStrategy: CalcStrategy
{
public override int Sum(int x, int y, int z) => checked(x + y + z);
}
public class UncheckedCalcStrategy: CalcStrategy
{
public override int Sum(int x, int y, int z) => unchecked(x + y + z);
}
public class Calc
{
public int Sum(int x, int y, int z, CalcStrategy calcStrategy) =>
calcStrategy.Sum(x, y, z);
}
Вот именно, это набор констант в своём особом пространстве имён, который без дополнительных приседаний нельзя перепутать с другим таким же набором.
Ровно то, что требуется чтобы заменить булев параметр, выиграв в самодокументируемости и не проиграв при этом в производительности.
А всяческие стратегии складывания чисел как раз лютый говонокод. Мало того, что это тупо медленно — так ещё и возможность расширения тут нафиг не нужна. Возможных способов обработать переполнение есть ровно три штуки (заворачивание, насыщение и исключение), что заметно меньше общего числа возможных арифметических операций. Не говоря уже о том, что вы умудрились вынести из метода во внешнюю стратегию абсолютно всю логику.
который без дополнительных приседаний нельзя перепутать с другим таким же набором.
Достаточно всего лишь явного приведения типа, и, о, сюрпрайз, - в переменную enum типа, оказывается, можно записать вообще любое самое бредовое значение безо всяких проверок.
возможность расширения тут нафиг не нужна.
Да, но во первых это приведено как пример, во вторых с KISS никогда не стоит скатываться в "нам это пока что не надо, поэтому сделаем все одним статическим методом Main()" - потом для "надо" потом может быть поздно и надо будет вообще все переделывать (на что обычно никогда нет ни денег ни времени, и говнокод отправляется в бесконечное свободное плаванье "Летучего Голландца").
Ровно то, что требуется чтобы заменить булев параметр, выиграв в самодокументируемости и не проиграв при этом в производительности.
Предлагаю тогда вообще отказаться от типа bool, заменив его везде на
public enum Bool
{
Yes,
No
}
Вот уж это будет жесть. Можно сразу на The Daily WTF c этим идти :)
умудрились вынести из метода во внешнюю стратегию абсолютно всю логику.
"Стратегия" это и есть логика выбираемая во время выполнения приложения.
Стратегия (англ. Strategy) — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
Просто из личного опыта - везде где enum-ы там, в итоге, хоть сколь-нибудь сложный код превращается в чудовищную лапшу из ветвлений.
Предлагаю тогда вообще отказаться от типа bool, заменив его везде на [...]
Тип-перечисление Bool имеет все недостатки "голого" булева типа — отсутствие семантики.
"Стратегия" это и есть логика выбираемая во время выполнения приложения.
Ага, только требовалось-то выбирать логику обработки переполнения, а не логику сложения трёх чисел...
Просто из личного опыта — везде где enum-ы там, в итоге, хоть сколь-нибудь сложный код превращается в чудовищную лапшу из ветвлений.
Код сложения трёх чисел никогда не станет сложным.
Тип-перечисление Bool имеет все недостатки "голого" булева типа — отсутствие семантики.
В том и дело, что любой enum имеет тот же самый недостаток.
Код сложения трёх чисел никогда не станет сложным.
Код сложения трёх чисел приведен просто как пример замены enum-а c ветвлениями паттерном "стратегия". Если бы это, скажем (из моей реальной практики) был код для интеграции с полутора десятками совершенно разных сторонних сервисов, где у каждого свой АПИ и форматы входных/выходных данных), то это бы воспринималось уже по-другому.
В том и дело, что любой enum имеет тот же самый недостаток.
Неа, не любой. Смотрите фокус:
enum OverflowHandling {
Wrapping,
Exception,
//Saturation,
}Оба значения имеют свою семантику, вы никогда не перепутаете какое значение какой режим означает. В отличии от перечисления Yes/No.
Если бы это, скажем (из моей реальной практики) был код для интеграции с полутора десятками совершенно разных сторонних сервисов, где у каждого свой АПИ и форматы входных/выходных данных), то это бы воспринималось уже по-другому.
Ага, но тут требуется сложить три числа. И потому воспринимается оно именно так как воспринимается.
А мы напишем на голом пихутоне, какие еще переполнения?
Или goto
У меня обычно первый вопрос, который возникает при озвучивании таких задачек на собесе - нахрена! Вам нужен специалист, который будет работать на необитаемом острове, куда слеши со звездочками привозят раз в год вертолетом, и их там жуткий дефицит?
сортировка вам тоже доступна по .sort() , однако просят написать свою сортировку через раз.
Так я и насчет сортировок такого-же мнения придерживаюсь, после нескольких лет работы уже хрен вспомнишь этот алгоритм, если ты, конечно, не разработчик библиотек сортировки. Какой полезный навык тут проверяется? Умение в стрессовой ситуации вспомнить сортировку пузырьком? Или, опять-же, у них там строгий запрет на использование сортировок из сторонних библиотек?
Это вопрос на алгоритмы. Но получается так, что задают вопрос на знание существующих алгоритмов, кандидату не нравится. Вопросы на создание алгоритма, тоже не нравится. Тестовое, не нравится. Может вообще не проверять алгоритмы или у вас есть универсальный способ?
PS ИМХО, сортировку пузырьком пора бы выучить и зазубрить всем программистам, ищущим работу.
Я про то, что алгоритмы - это очень кривой фильтр с недопустимо высоким уровнем ложных срабатываний. Подавляющее большинство вполне себе ценных и справляющихся со своей работой специалистов его провалят без долгой предварительной подготовки, просто по причине того что сами алгоритмы забываются за ненадобностью. Из-за этого и получаются, что отсеивают человека, который через пару-другую дней может въехать в суть рабочего процесса и начать решать насущные задачи на серьезном уровне, а вместо него берут решальщика алгоритмических задачек из учебников, который назубок знает десяток алгоритмов сортировки, но при этом не может простейший сервис рест с крудом и авторизацией накидать, и которого еще учить и учить что-бы он начал делать что-то полезное на проекте.
С сортировкой можно тоже более-менее интересные вещи придумать. Например, написать сортировку ну очень большой (допустим, даже не влезающей в память) последовательности целых чисел, если известно, что все они лежат в диапазоне от 0 до 99, или та же самая ситуация, но известно что среди этих чисел много одинаковых (скажем, для конкретики, среди них не более 10^3 уникальных значений).
А можно дать соискателю шахматные задачки порешать, примерно такая-же польза, задача абсолютно оторванная от реальных задач, которые придется решать на проекте, типа на остроту мозга.. А еще можно задачки на аналитическую геометрию, или загадки позагадывать, типа "зимой и летом - одним цветом".
Но уже давно перестали, а у нас нет-нет да и спросят, зачем люки круглые.. :))
Я всегда думал, что крышки для люков круглые, потому, что сами люки круглые и было странно закрывать круглые люки квадратной крышкой :)
У меня самая дичь была, когда меня на собесе в самом конце, после прохождения всех технических этапов (было два собеса), послали нахрен после того как я прорешал кучу таких вот "круглолюковых" задачек и меня попросили нарисовать домик, я нарисовал, после чего начали доскребываться почему именно такой, почему с трубой.. честно говоря меня к тому моменту все это вконец уже задрало, и видимо я сказал что-то не по скрипту..
меня попросили нарисовать домик, я нарисовал, после чего начали
доскребываться почему именно такой, почему с трубой.
Надо было сделать морду кирпичом и сказать — "потому что стандарт, ёктель — вы что U+1F3E0 никогда не видели?!"
Но по ссылке открывается домик без трубы...
Убунту,
Фаерфокс (вверху), Хром (внизу)
У меня в firefox на винде ровно то же, что у коллеги на убунте.
Вообще, по-моему, Спольски как раз про домик писал. А его вряд ли можно записать в собеседователи-неадекваты. Суть в том, что кандидата просят нарисовать домик, он кидается сразу же его рисовать (с трубой или без), а ему говорят: "Чозанах, нам ведь нужен был домик для многодетной семьи жирафов". Вопрос не на то как кандидат умеет рисовать домики и трубы, а как он подходит к анализу и уточнению требований задачи - бросается, очертя голову, её делать, или станет уточнять нужные детали.
Суть в том, что кандидата просят нарисовать домик, он кидается сразу же его рисовать (с трубой или без), а ему говорят: "Чозанах, нам ведь нужен был домик для многодетной семьи жирафов". Вопрос не на то как кандидат умеет рисовать домики и трубы, а как он подходит к анализу и уточнению требований задачи - бросается, очертя голову, её делать, или станет уточнять нужные детали.
Аааа, вот оно что.. ну молодцы они, уделали, победили человека, которому перед этим час выедали мозг загадками стыренными у всевозможных спольских.
Ключевая проблема всяких подобных тестов, в том, что человека ставят в условия экзамена, в котором он по умолчанию ожидает поток оторванных от реальности задачек, и пытаться подловить при этом человека на том, что он не задает дополнительные уточняющие вопросы - ну такое, это уже какие-то взаимоисключающие требования. И другая проблема - если кто-то прочитал о всех этих иезуитских практиках и знает что когда тебя просят рисовать дом, то ты должен доколупаться до вопрошающего со своими вопросами - этот кто-то всегда будет проходить тест, но вовсе не по причине своей дотошности, просто он знает как его проходить.
как он подходит к анализу и уточнению требований задачи - бросается, очертя голову, её делать, или станет уточнять нужные детали.
Осторожнее, нарвётесь когда-нибудь!
Так без ТЗ результат — ХЗ.
Просили домик — получили домик.
А то эта игра прекрасно реверсируется.
Приезжайте в Ростов, Санкт-Петербург, Череповец. Покажу вам квадратные колодезные люки.
При чем тут шахматные задачки. Это элементарнейшие задачи на алгоритм карманной сортировки. Я конечно очень даже за то чтобы ИТшники получали много-много денег, но просить 4К евро (300К рублей) на руки и про неё (сортировку карманами) не знать это уже я вообще не знаю что. Скоро наверное начнут приходить люди не отличающие компилятор от интерпретатора со словами что "это оторвано от реальных задач".
А в чем проблема с "получением 300 на руки и не знанием карманов"? Фирма платит мне за проделанную работу, а не за доскональное знание алгоритмов из толстых книжек. Зарплата это всегда про деньги, бизнесу не интересно какие мудреные алгоритмы вы натренировались реализовывать по толстым книжкам, ему надо что-бы нанятый специалист умел решать насущные и вполне себе приземленные задачи, приносящие ему прибыль. А там у себя дома, вы хоть шахматные задачи решайте, хоть мудреные алгоритмы сортировок изобретайте, это лично ваше развлечение.
Я не против саморазвития, задачки на поддержание мозга в бодром состоянии это хорошо, решать головоломки, реализовывать зубодробительные алгоритмы для развлечения, по фану, это круто. Но отсеивать специалистов по умению раскалывать загадки и по признаку (этот дурак не слышал про сортировку карманами), это как-то мягко говоря странно.
Скажем когда я учился в ВУЗе (ох, блин, как-же это уже давно было :( ), я мог без особых проблем раскалывать довольно замысловатые задачки по комбинаторике. Сейчас попроси меня решить самую простую - я буду день тупить пока не вспомню, потому что в практике оно не надо было и все эти знания ушли куда-то в самые дальние хранилища памяти, и вытащить их оттуда, задача нетривиальная. И если мне на собеседовании зададут такой вопрос, то я со стопроцентной вероятностью ничего толкового не отвечу. Значит ли это что я непригоден к работе программистом? Даже если работа будет заключаться в решении подобных задач - я без особых проблем все вспомню и буду их решать, но проверкой на содержимое оперативной памяти меня отсеют с гарантией.
обернуть в if (flag) { }
по умолчанию flag = False, ну и считывать это из окружения.
фичефлаги, тогглы так и делаются.
Это было бы моё решение.
Рабочий варинт в АСУТПшном программировании - реально видел такой случай. Суть в том, что одна часть системы была не построенна и логика защит была одна. Как только достроили нужную часть - в коде просто флаг в True возвели и пошла выполняться уже другая логика.
В С для этого вроде есть - #ifdef FLAG ... #endif
так и понятнее и компилятору проще разобраться что к чему
Но нет в ST (я имел в виду язык МЭК https://ru.m.wikipedia.org/wiki/IEC_61131-3)
Никогда не понимал таких вопросов. Больше 10 лет опыта ынтерпрайз разработки, сходу не придумал ни одного варианта, просто потому что мозг заточен под совсем другое и все 30 секунд, что я пытался думать над ответом, единственной мыслью в голове было: "нафига это надо?!"
Ну, в питоне интроспекция позволяет получить сходу частичное решение.
Могу предложить другую шутливую задачку. Создайте класс, который принципиально невозможно наследовать.
В питоне можно наследовать класс от функции, значит любой объект можно расколдовать для наследования. На все способы найдётся контр способ.
Явный способ попросить не использовать.
class Foo:
def __new__(cls):
if cls != Foo:
raise TypeError(f"Inheritance is forbidden, including: {cls.__name__}")
return super().__new__(cls)
class Boo(Foo):
pass
Foo()
try:
Boo()
except TypeError as e:
print(e)
# Inheritance is forbidden, including: Boo
Объявляем строковую переменную и кавычим кусок кода в качестве значения переменной, например?
Задача на питоне, реализовать декоратор, который кеширует возвращаемое значение обёрнутой функции на время:
def cache_result(seconds):
# TODO реализовать кеширование обёрнутой функции на время
@cache_result(seconds=5)
def expensive_function():
# Возвращает результат, который мы хотим закешировать
return datetime.now()
Предполагается, что человек, который собеседуется на синьора питониста в состоянии написать декоратор с параметром. Спойлер — половина не в состоянии. Не в состоянии даже написать декоратор без параметра.
Ну да бог с ним, если видно, что кандидат не может написать декоратор, мы пишем декоратор за него и просим продолжить. :
def cache_result(seconds):
def wrapper1(func):
def wrapper2(*args, **kwargs):
# TODO закешировать результат вызова func на время seconds
return func(*args, **kwargs)
return wrapper2
return wrapper1
Здесь уже нет особенностей языка. Просто напиши минимальную логику, которая кладёт результат и время его получения в словарь, если там пусто или с предыдущего результата прошло больше, чем seconds, и возвращает результат из словаря.
Опять же, даже знать как получить время не нужно. Хотя бы напиши псевдокодом, что должно происходить. Многие не могут.
Часть "со звёздочкой" - это порассуждать, что должно быть ключом словаря при кешировании. Просто хочется услышать, что для разных *args, **kwargs закешированое значение должно отличаться (и рассуждения "а что если аргументы не кешируемые, как их превратить в ключ словаря"), но опять же, многие этого не говорят.
Спойлер — половина не в состоянии. Не в состоянии даже написать декоратор без параметра.
кек… я какоето время назад гуглил шаблон декоратора, потому что хоть убей не мог сходу запомнить как его написать, потому что у нас очень редко они использовались (почему — отдельный вопрос и не ко мне) и только через время я таки запомнил ;))
а подобные 'странные затруднения' — вытекают из того что собеседуемые вам пишут код на салфетке или в блокноте (бубнение о том что настонящий погромист должен писать код в тетрадке по памяти и помнить весь синтаксис наизусть, без этихваших новомодных ide и в условиях когда все либы и системные ф-ции языка недоступны по странным причинам) и ведь пользоваться гуглом — страшный зашквар же да? вы так на работе не делаете же? :)
Э-э-э, а что там вообще запоминать-то? Есть требования к декоратору — исходя из них пишется реализация. Всё.
Что такое декоратор для функции? Это функция которая принимает функцию и возвращает функцию, function -> function.
Как передать декоратору дополнительные параметры, если он принимает только 1 функцию? Каррировать его, обернув во внешнюю функцию с параметрами.
Откуда взять ту функцию, которую надо вернуть? Можно делать по-разному, но самое простое — объявить её внутри. Отсюда и третья функция.
Всё, структура декоратора закончена, осталось разобраться что писать в реализации этой возвращаемой функции.
Повторюсь, если человек не в состоянии написать декоратор с параметром, крест на нём никто не ставит: пишем ему шаблон декоратора и просим продолжить. Хотите верьте, хотите нет, но люди, которые не могут написать декоратор, как правило, не справляются с кодом дальше. Корреляция, конечно, не абсолютная, но близкая к ней.
Я понимаю ваш скепсис про "не пользоваться гуглом" и отчасти его разделяю сам. Но посмотрите на ситуацию с другой стороны: если человек будет пользоваться гуглом, он наверняка просто нагуглит готовое решение тестовой задачки. Просто потому что собеседований много, люди решают задачки и выкладывают их в интернет, а придумывать новую задачку после каждого собеседования никто не будет: время интервьюеров тоже денег стоит.
Если же дать человеку что-то комплексное, что готовым в гугле не найдёшь (разрешив при этом пользоваться гуглом), и надо именно написать, здесь уже упрёмся в длительность собеседования: мало кто захочет писать код больше 30-60 минут.
Впрочем, я лишь рассказываю, как было у нас. Это ответ на комментарий выше, где говорилось "техническая часть вообще не нужна". Если кто-то придумает задачку, которую можно с гуглом решить за разумное время, при этом без вероятности нагуглить полностью готовое решение, лично я совершенно не против.
Повторюсь, если человек не в состоянии написать декоратор с параметром, крест на нём никто не ставит: пишем ему шаблон декоратора и просим продолжить. Хотите верьте, хотите нет, но люди, которые не могут написать декоратор, как правило, не справляются с кодом дальше. Корреляция, конечно, не абсолютная, но близкая к ней.
почему я придрался, потому что был на собесе (на тот момент на грейд миддла) и у меня была проблема с декоратором именно по этой причине что я тупо не помнил синтаксис.
и кстати писал именно кеширование и интервьюверу в итоге понравилось
но отношение интервьювера что 'ну ты ваще лох, ничерта по памяти не помнишь' — очень покоробило
если человек будет пользоваться гуглом, он наверняка просто нагуглит готовое решение тестовой задачки.
а для этого надо спрашивать словами, как он её сделал, если он скопипастит задачку он не сможет её объяснить.
я когда собеседую людей смотрю на то как они мыслят, а не тупо пишут зазубренный код. мне бывает достаточно на словах объяснить как человек сделает задачу без написания кода на бумажке
потому что конкретная реализация где запятые ставить и как объявлять переменные (был у меня такой коллега, валил всех на ревью именно придираясь к синтаксису) это всё вкусовщина, важен принцип выбранного решения и потенциальные подводные камни и что человек их понимает.
Я давал на мидла: Посчитайте количество букв в слове на Питоне. Мидл имел опыт написания ORM запросов в Django. В то что там под капотом он не вникал, в особенности Питона тоже. Решить не смог.
Когда я в ту контору собеседовался на синьёра, то там меня попросили что-то простое типа декоратора и обхода графа с рекурсией и без. В общем суммарно кода строк на 20-30. У меня сложилось впечатсление, что интервьювер заложил на это более получаса и не ожидал, что я минут за 10 справлюсь вместе со всему разговоромаи и уточнениями. В общем на второй трети интервью у него кончились вопросы.
Вот это прямо я. Опыта дохрена, резюме неплохо выглядит, везде где работал вроде бы не было каких-то серьезных претензий к моей работе. А когда дают на собесе решить "элементарную задачу" начинаю тупить и нести какую-то хрень. Ну не работается мне в такой обстановке, это для меня как сексом на площади заниматься, вроде "а чё такого, многим даже нравится", но не мое это и не получается и все тут.
В стрессовой ситуации вы спускаетесь со своих теоритических навыков до своих практических. Иными словами если вы понимаете декораторы, но не пишите их каждый день, то на собеседовании может случится ступор.
но не мое это и не получается и все тут
Это навык. Если есть желание и время его можно развить.
Это навык. Если есть желание и время его можно развить.
А зачем его развивать? В работе он не нужен, как и навык езды на одноколесном велосипеде
Я практически каждый день пишу код, но на таких собеседованиях иногда клинит и я просто не могу вспомнить где надо угловые скобки в дженерике ставить, хотя в обычной работе делаю это на автомате, не задумываясь. Тут как в анекдоте про бороду - пока человек не задумывается куда он ее кладет - под одеяло или над ним, все идет хорошо..
Плюс, еще я думаю проблема в довольно жестком временном лимите, собесы обычно не дольше часа длятся, и учитывая что они не только из кодирования состоят, то на эти задачки времени отводится очень немного, не все люди хорошо работают в таких стрессовых условиях.
Это навык. Если есть желание и время его можно развить.
Каким образом - просить кого-то наблюдать за тем как я работаю? Так все равно это не то, стресс не тот.
Каким образом - просить кого-то наблюдать за тем как я работаю? Так все равно это не то, стресс не тот.
Тут несколько факторов работающих вместе, навыки, знания и стрессоустойчивость.
Подумать и вспомнить, это разные действия и занимают разное время.
Начать делать что-то знакомое, это хороший способ себя успокоить.
То есть просто решая задачки в спокойной обстановки вы можете сильно улучшить ситуацию.
Про стрессоустойчивость могу мало что сказать. Можно попробовать делать доклады на работе, на уровне команды или отдела. В общем любое общение которое заставляет вас выйти из зоны комфорта.
Хорошо-хорошо, вот вам тестовое задание, удалите-ка аппендицит вот тому дяденьке. И пожалуйста комментируйте каждый ваш шаг.
Опустим вопрос, где взять одноразового дяденьку. Но чем плох вопрос "описать ход операции такой-то"? Если хирург общей практики гонит "Да я! Да у меня диплом! Да у меня сертификаты!", но не может описать в деталях простой паттерн, то на кой он нужен-то? В суд потом диплом с сертификатами пойдут или главврач?
Хорошо-хорошо, вот вам тестовое задание, удалите-ка аппендицит вот тому дяденьке.
Расскажите в деталях, как вы будете удалять аппендикс (аппендицит — это болезнь, ее нельзя удалить), что вы будете делать в первую очередь, что потом, опишите по шагам, как вы достигните результата, сколько времени потратите.
Далее хирург расспрашивает о доп вводных (чтобы понять, есть ли перитонит и т.д.) и рассказывет о ходе операции.
Хм, постойте-ка, так у нас обычный технический собес получился, если заменить хирурга на программиста, а операцию на, например, микросервис какой-нибудь.
Моё имхо — технические собеседования на уровень мидл+ не нужны от слова совсем.
Много кандидатов на такие вакансии отсобесили? Какой процент из нанятых прошли испытательный срок?
Хм, постойте-ка, так у нас обычный технический собес получилсяНе, это у вас хороший собес получается.
«Обычный технический собес» будет если сказать хирургу-кандидату перечислить названия всех хирургических инструментов по списку из гугла (часть из которых редко используемы, типа ветеринарных, часть — устарели, а часть просто вылетели из головы, так же, как вы сейчас не сможете быстро вспомнить все части речи русского языка), потом погонять его по знанию англоязычных аббревиатур (или, латыни, раз уж разговор про хирурга), а потом дать провести «простую операцию» без инструментов и вводных.
Думаю, если у программиста попросить перечислить названия ассемблерных команд какого-нибудь z-80 или msp-430 (ну а что? Онжпрограммист!) - результат будет похожим. У хирурга, в отличие от программиста, цена ошибки может оказаться гораздо выше. Но и сам объект приложения знаний при этом гораздо меньше меняется с годами.
Не уверен, что хирург из поликлиники вспомнит все эти подробности...
Вы видимо работу хирурга по фильму др.Хаус представляете. Ну там и «пробное задание» можно представить. Но вот только программиста такого уровня тоже нанимают без собеседования, потому что Вы уже знаете, что он умеет.
Нормальные хирурги удаляют сотню по сути одинаковых аппендицитов в год. Уровня джуниора и мидла вообще ничего кроме этого, потому кроме диплома для найма ничего и не нужно. И KPI там вполне понятен. Работу программиста так формализовать совсем не получается.
Нормальные хирурги удаляют сотню по сути одинаковых аппендицитов в год.
Ну вот именно, а потом он куда-нибудь приходит, а ему : "Расскажите про ваши достижения на прошлом месте". "За год вырезал 237 аппедицитов." :D У обычного разработчика 99%, и хорошо если не все 100 работы это как раз вот такое вот "вырезание аппендицитов". А вопрос (про достижения) задают так, что можно подумать, что все на работу ходят разрабатывать собственные компиляторы, СУБД, и операционные системы. "На прошлой работе за год разработал 73 контроллера WebAPI, 49 репозиториев к БД, и 63 класса DTO." :-D
На прошлой работе за год разработал 73 контроллера WebAPI, 49 репозиториев к БД, и 63 класса DTO
Понимаете ли, тут можно юморить и ёрничать, а можно поработать над техникой самопрезентации. Вы же предлагаете людям платить немалые деньги за ваш труд. Но не хотите говорить, а чем ваш труд хорош, кроме количественных показателей.
Ваш труд же привел к чему-то. Например, снизили потребление памяти, упростили сложный протокол, написали киллер-фичу, которая привела новых клиентов. Вот на это и должен быть фокус.
На прошлой работе за год разработал 73 контроллера WebAPI, 49 репозиториев к БД, и 63 класса DTO
Ну если вас все устраивает, то может и норм? Просто каждый день сидите и пилите DTO. Без работы, видимо, не сидите, значит процесс собесов работает. А если бы хотели разрабатывать собственные компиляторы, то наверно и в типичном классе DTO чтонибудь необычное бы нашли, о чем можно было бы рассказать на собесе.
Например, на одной из прошлых работ у меня тоже был недолгий период "перекладывания json-ов". Но я решил сделать это "быстро" (в смысле процессорного времени) и упоролся по профайлерам, изучил различные места в коде и библиотеках, которые работают быстрее/медленнее чем нужно, узнал, что существует 2 разных типа парсера json-а (DOM vs SAX) и т.п.
Просто каждый день сидите и пилите DTO.
Так других задач просто нету.
А если бы хотели разрабатывать собственные компиляторы, то наверно и в типичном классе DTO чтонибудь необычное бы нашли, о чем можно было бы рассказать на собесе.
И мне бы на ревью сразу голову оторвали за такое. Потому что я бы и сам то же самое сделал тому, кто для перекладки DTO попытался бы впилить в проект свой собственный компилятор :))
Если по достижениями вы подразумеваете событие не меньше "придумал nginx" то тогда вопрос скорее к вам. Достижение вопрос относительный, для джуна писать год код и не иметь больших претензий на пуллреквестах это достижение. Для мидла оптимизировать какой-нибудь сервис-узкое место на 30% и сэкономить 10к баксов на инфру ежемесячно — достижение. И так далее.
У обычного разработчика 99%, и хорошо если не все 100 работы это как раз вот такое вот "вырезание аппендицитов". ... "На прошлой работе за год разработал 73 контроллера WebAPI, 49 репозиториев к БД, и 63 класса DTO."
И чем он это может подвердить? И сколько багов там нашли, и чем может подтвердить?
Если в больницу придёт хирург кандидат с дипломом "прослушал теорию вырезания аппендикса", резюме "Вырезал аппендиксы. Много. Все выжили.", на словах "подтвердить не могу, NDA", и "мамой клянусь, умею" - ну да, придётся ему экзамен устраивать чтобы понять, умеет ли он скальпель держать. На самом деле нет, просто нанять того, который с документами придёт.
В том и дело, что хирург уже сдает экзамен в медвузе, а потом может подтвердить опыт документально, и этим бумажкам можно доверять... а иначе его можно посадить в тюрьму.
Потому повторю:
Работу программиста так формализовать совсем не получается.
Если думаете что можно, найдите мне описание должностных обязанностей, строго по которым можно уволить программиста (но чтобы и наоборот, не требовало уволить хороших программистов).
Например по бизнес логике в каждую DTO нужно вставлять имя пользователя и время когда пришло изменение. Делать это лениво поэтому я написал интерцептор, который берет нужные данные из контекста запроса и делает это для всех DTO с нужным интерфейсом.
Не знаю, что у вас за платформа, но у меня это есть готовое в Automapper - достаточно в его конфигурацию добавить несколько строк.
Я ещё помню автомаппер, когда он был статический. Из статического маппинга добраться до логина пользователя который запустил операцию нужно уметь.
Но даже если сейчас он умеет в одну строку важен подход: я увидел возможность улучшить эффективность банальной операции. Это секономит х строчек кода мне и комманде.
Автомаппер еще даже в статические времена уже поддерживал DI. Пишешь кастомный ValueResolver и инжектишь в него то что хочешь. Для описанного случая это тоже от силы пару дюжин строчек кода.
ValueResolver будет создан в статическом контексте, а нужно брать ид пользователя из контекста авторизации, который PerScope. Для этого есть средсва, но нужно про них знать. Еще я не хочу для каждого нового класса прописывать вручную использование резолвера. Я хочу чтоб как только классу добавлен нужный интерфейс все работало из коробки.
Суть не в конкретном решении, а в том как отличить мартышек от инженеров. Если человек бездумно перекладывает значения из модели в модель и не разу не остановился подумать как сделать это эффективней, то неважно как хорошо он цитирует определения SOLID и KISS.
Строго говоря, я бы все-таки не делал это в меппинге вообще. Это часть логики, а ей там не место. Я бы сделал кастомный binder для записи этих значений в модель запроса Web API, а в DTO меппил бы оттуда уже готовые значения. Немного больше кода, но идеологически намного правильней.
Нормальные хирурги удаляют сотню по сути одинаковых аппендицитов в годЧаще всего резать аппендюки и жировики — дают вообще ординаторам, чтобы хирурги не отвлекались на всякую ерунду
Чаще всего резать аппендюки и жировики — дают вообще ординаторам, чтобы хирурги не отвлекались на всякую ерунду
Про аппендиксы сомневаюсь, но не суть - подставьте в исходное сообщение "язву" и всё так же получаем формализуемую повторяющуюся работу хирурга.
Проблема не в типе операции, а в том — что получился котенок с дверцей.
А кстати можно спросить у директора "Белой Радуги" как они хирургов нанимают на работу.
/summon Белая Радуга
кстати, примерно так и берут. На тренажере (есть такие для хирургов специальные)
А как по вашему берут? Хирурги с которыми я общался, недавние операции, особенно экстренные помнят по секундам.
Хирургом можно стать только совершенно определённым образом: специальный, а не абы какой медвуз, потом ординатура.
А программисты через одного самоучки
Это могло бы быть правдой, если бы понятие "уровень" было одинаковое во всех компаниях, как минимум. Скилы очень полезные в одной компании, позволяющие ей считать дева мидлом, т.к. хорошо и быстро справляется с задачами, могут быть не востребованы в другой.
Например, человек 3 года работал плюсовиком, пилил себе фичи какие-то. В компании он мидл. Идет в другое место, где больше важна оптимизация - а он в этом слаб, да и в принципе, оказывается, плюсы знает поверхностно.
На месте второй компании, вы бы хотели взять такого человека без собеза?
При собеседовании я всегда держу цель собеседования: "необходимо найти человека, который будет справляться с задачами команды, в которой он будет работать", поэтому я начинаю всегда с абстрактных вопросов: например, "расскажите про опыт, когда вы столкнулись с трудностями использования X", так и кандидат привыкает к интервью, так и я могу приблизиться к цели.
В конце, мы оба решаем задачку из серии "а давай сейчас вместе сделаем простую форму логина, без всяких лишних вещей" или "напишем сервис авторизации на минималках", пользоваться разрешено всем.
Возможно у этого подхода есть, конечно, минус, что собеседование простое, но с другой стороны нет цели сделать его невыносимо трудным
P.S у меня был опыт, когда я отсеял разработчика (за счёт вопросов "Расскажите про прототипное наследование"), но начальство тогда спросило, готов ли я дать шанс разработчику на роль джуна и я тогда согласился на такой эксперимент, поэтому мы наняли отсеянного разраба, в итоге он вырос в архитектора
P.S.2 у меня не было опыта, когда я или команда, в которую нанимался человек, жалели о взятом человеке (возможно просто повезло)
пользоваться разрешено всем
Кандидат открывает chatGPT, до этого он работал грузчиком
Кандидат открывает chatGPT
А chatGPT лежит из-за нагрузки :)
У меня, к примеру, не получилося этим пользоваться нормально.
А chatGPT закрыт для вашей территории. И вчерашний грузчик вдруг легко поднимает туннель и таки открывает его... Тоже показатель!
Код chatgpt не всегда хорош, я проверял )
По крайней мере, сейчас
Код потом работает?
Если да - значит возьмем его постановщиком задач для chatGPT, а джуны более в таких количествах станут без надобности. Ура!
Правильно поставить задачу чату - это уже синьёрский навык.
Такой кандидат, похоже, вполне может обойти других.
Так же и кандидат который за деньги отдал написание резюме проффесионалам может обойти других. До чата тоже можно было воспрользоваться чужими знаниями в разной степени.
Все эти асинхронные взаимодействия (резюме, тестовое задание) это фильтр. Тут цель не сделать хорошо, а пройти его. Как бы в не хитрили живое общение расставит всё по местам.
С другой стороны тоже играют не особо хорошо.
Ваше резюме могут просто потерять, даже если вы подавались через знакомого.
Созваниваемся с рекрутёром, он мне говорит: "Мне три для назад прислали Ваше резюме." Я не стал уточнять где оно было предыдущие 20 дней.
Когда утсраивался на первую работу, на Питон, к своему научному руководителю, на живом собеседовании сначала говорил с рекрутёром. Потом она дала мне тестовое на бумажке и сказала, что технический интервьювер будет через 20 минут. Вопросы были по С++ и на абстрактную логику. Пришёл руководитель и выкинул эти листы в помойку не глядя.
> Возможно у этого подхода есть, конечно, минус, что собеседование простое, но с другой стороны нет цели сделать его невыносимо трудным
минуса не вижу, типа четко понимаете что делаете, когда интервьюировал людей примерно также, это на основе опыта, консервативно >300 проведенных интервью, людей c таким пониманием охотно взял бы в команду, хотя это уже в прошлом (30+ лет работы в us)
Как раз недавно читал про то, как евреев валили на экзаменах в мехмат МГУ =3
В крупных компаниях обычно выстроен формат собеседования и самодеятельность интервьюеров не приветствуется. Там, где формат зависел от меня, я пришел примерно к следующим элементам:
Начать с вежливых формальностей, представиться, объяснить, как будет проходить собеседование. Объяснить, что мы будем писать код без IDE, но нам не нужно чтобы код был сразу компилируемым, по сути, подойдёт и псевдокод, лишь бы была ясна общая структура и алгоритм. На это нужно буквально пару минут.
Спросить, какие проекты ему запомнились, и что интересного или забавного он может припомнить из своей практики. На этом этапе кандидат может немного успокоиться, а я могу посмотреть, рефлексирует ли он над своей работой, испытывает ли интерес к программированию, и как вообще формулирует свои мысли. Этот этап занимает минут 10, максимум 15.
Дать элементарную задачу, например, найти дубликаты в массиве, и уверить кандидата, что нет никакого подвоха. Тут я смотрю, насколько быстро задача будет решена (по-хорошему, кандидат просто тут же за несколько минут пишет решение), и что человек в принципе способен написать код. 5 - 10 минут.
Практически все оставшееся время, около 40 минут, отводится на более трудную задачу. Тут я смотрю, как кандидат уточняет условия, как проектирует решение, и как пишет реализацию. Для меня важно, чтобы в итоге человек хоть что-то написал, ведь ему придется это делать на работе. Неплохой подход, с моей точки зрения, это сделать простое решение и потом улучшать.
В оставшееся время я отвечаю на любые вопросы, которые есть у собеседуемого.
Если есть дополнительные этапы, то, на мой взгляд, хорошие приёмы это отладка программы со специально созданной ошибкой, тут видим, как кандидат пользуется инструментами. Естественно, об этом предупреждаем заранее, и просим подготовить рабочее окружение. Читал, что кто-то просит кандидатов сделать рефакторинг - тоже неплохо.
Еще один интересный подход - попросить кандидата заранее сделать короткую презентацию на любую интересную ему техническую или околотехническую тему.
что забавного он может припомнить из своей практики
Вот это, имхо, самый так себе вопрос в любом интервью, кого угодно для каких угодно целей. Забавное - это всегда что-то внутри контекста, и умение понятно изложить этот контекст и саму историю - задача для стендапера, но едва ли для технического специалиста. Когда надо делать то, что не умеешь, понимая, что в результате скорее всего тебя не поймут и ты будешь выглядеть нелепо - это так себе путь к спокойствию.
согласен с большинством Ваших комментариев по теме, в том числе о большом количестве проектов, невозможности все помнить и т.д., поэтому добавлю такое наблюдение - чем более профессионально ведет человек интервью, тем легче найти с ним общий язык, от глупых вопросов типа " что забавного можно припомнить ... " можно избавиться, если не ходить на интервью по-холодному, т.е. когда вас не знают, networking именно для этого и нужен
Много раз видел что предлагают писать код без IDE в качестве проверки. В чём сакральный смысл, это же выходит копание ямы без лопаты?
Да и мне не так уж редко (чаще, чем хотелось бы :) ) приходилось программировать Java, С# и Python (не говоря уже о всяких bash' ах) в nano или vi (без m).
Я вполне нормально, если мне надо просто подправить пару строчек в коде, то открываю его всегда в консольном vi(m) делаю то что надо, потом проверяю сборку с командной строки. Ради этого запускать IDE это как на самосвале в ларек за пивом ехать.
Мне кажется нет смысла.
Последнее время все задачки у меня были на сревисах для совместного кодирования, с подстветкой синтаксиса и даже автодополнением.
Пандемия поколебала позиции кодирования на доске и в блокноте.
Так уж сложилось что в прошлом году прошел где-то... ну 50 собесов точно. У меня после этого опыта есть две претензии к собеседующим:
1) Всем сторонам было бы проще и понятнее если бы на собеседующей стороне потратили 10 минут, зашли в гитхаб, указанный в моем резюме, и почитали бы мой код в репозитории с 400+ звездами. Тогда сразу отпали бы 90% вопросов и не надо было бы, извиняюсь, дрочить мой мозг тупыми вопросами, ответы на котрые у любого программиста сидят в подсознании и которые достать оттуда на собеседовании не всегда получается.
2) По моему субъективному мнению действительно обоснованных отказов было в лучшем случае четверть. Все остальное, по личным ощущениям, это отказы в стиле "ты нам не подошел потому что твой стек совпадает с нашим только на 90%" и прочий бред. Зажрались короче и/или сами не понимают кого они ищут.
Вы же не всегда видите, в чем проблема. Может, вас бы взяли за совпадении и в 20%, но не за те деньги. Либо вы шутите в стиле, неприемлимом для команды(очень серйозный косяк на самом деле при приеме на работу).
Фигня в том, что 99% претендующих не имеют гитхаба со звездами. Ну так сложилося в индустрии. Менять что-то под вас контр-продуктивно.
Ну так наоборот же - когда чувак с гитхабом 1 на сотню за это наоборот должен глаз цепляться. А если не цепляется - а может не так уж и сильно и нужен хороший специалист на это место и подход в стиле "накидаем кучу всего на стену, авось что прилипнет"? Какие-либо серьезные отклонения в процессы и затрачиваемое время такая ситуация не вносит.
Вы же не всегда видите, в чем проблема. Может, вас бы взяли за совпадении и в 20%, но не за те деньги. Либо вы шутите в стиле, неприемлимом для команды(очень серйозный косяк на самом деле при приеме на работу).
Ну денежный момент в какой-то момент отпал когда я понял насколько все на рынке плохо. Плюс я почти всегда уточнял что та сумма, которую я называю, не является минимальной на которую я соглашусь. Насчет шуток - в какой-то момент специально просил сторонних наблюдателей посмотреть на собес со стороны, никаких красных флагов не заметили. Ну и я вообще стараюсь шутить на собесе редко и максимально обтекаемо.
К тому же, есть понятие Overqualification.
Шутки и красные флаги могут существовать только для этой команды. Это просто пример.
У для-галочников обычно нет 400 звезд. А если и есть накрутки (лайкают друг другу репы по кругу), то там либо пустые репы, либо сплошные форки, либо дичайший г-код. Во всяком случае пока не встречал лайкльщиков, которые додумались бы стырить хороший репо и налайкать друг другу, а не форкать.
И звезды — не увидите.
Я пытаюсь вам это донести, но, похоже, никак.
Даже у моего ребенка на втором курсе у всех «есть гитхабы». Может у кого-то из них есть гитхаб чего-то, что люди используют — но я ж ну буду это проверять, да?
Согласен.
Стоит посоветовать @Alexsey указать в своем резюме, что он меинтейнер проекта с 400 звездами.
Сильно всматриваться в рандомные гитхабы мало кто будет.
Во всяком случае пока не встречал лайкльщиков, которые додумались бы стырить хороший репо и налайкать друг другу, а не форкать.
У таких товарищей другая нынче фишка - они делают какой-нибудь незначительный PR по типу правок в readme или какую-нибудь документацию в надежде на то что PR примут и они влетят в список contributors. Я одного так аппрувнул, потом с саппортом гитхаба несколько дней не могли его вычистить из всех их кэшей чтобы он из этого списка исчез.
Сейчас норма что резюме не читают от слова совсем. И собеседующий видит твое резюме, хорошо если не за 15 минут до собеседования. Ну то есть дурацкая ситуация получается - а может ты там вообще не нужен такой с таким твоим опытом. И вообще "этим людям" не нужен. Чего тут не звереть.
Вскоре собеседование превратилось в викторину на тему, с которой программисты работали в тот день.
Обожаю, конечно, когда попадаются такие собеседования.
"Вот вам кусок кода. Перечислите все ошибки, которые найдёте"
- Называю с десяток ошибок. Рассказываю, как сделал бы сам.
"Всё понятно. До свидания."
Через 15 минут:
"Вы нам не подходите из-за низких технических навыков"
А потом сидишь и гадаешь, что это вообще было...
У меня есть опыт с другой стороны: при проведении собеседования я прошу назвать проблемы в коде на 28 строк (включая импорты и пустые строки) и чаще всего в нём проблем не видят совсем тогда как там есть и проблемы с многопоточностью и с читаемостью и с закрытием ресурсов и т.д.
После того как кандидат всё озвучивает что посчитает важным - я рассказываю что там есть ещё.
Всё открыто.
Я не против обсудить код. Я имел в виду немного другое, что иногда попадаются особые странные собеседования.
Один раз интервьюер сам целый час писал код в редакторе и периодически уточнял у меня, правильно ли он делает или нет. Потом так-же пришёл отказ без объяснения причины.
На таких интервью нужно попытаться угадать, что именно задумал собеседующий и назвать правильный ответ. Если не угадал, то у тебя "низкий технический навык".
На таких интервью нужно попытаться угадать, что именно задумал собеседующий
Просто спросить у него? Умение что-либо уточнять это тоже как бы нужный навык. Я из-за этого давно принципиально не делаю тестовые задания, потому что в них уж точно никогда не выяснишь что от тебя хотят.
Просто спросить у него?
В ответ будет "Подумайте сами. Я хочу увидеть как вы мыслите.".
Ещё раз уточную, что трешовые собеседования происходят довольно редко. И обычно во время собеседования ты уже сам понимаешь, что не пойдёшь в эту компанию.
Однажды я сделал ошибку. Было собеседование, где мне полтора часа два программиста рассказывали, какими плохими были их предыдущие работники, что всё сломали и как сложно было с ними работать. Ну, я и согласился по дурости. Оклад обещали вполне приличный.
Как вы уже могли догадаться, теперь на их собеседованиях в этом списке ещё и я значусь.
В ответ будет "Подумайте сами. Я хочу увидеть как вы мыслите.".
Ну тут уж только пожелать ему попасть к product-owner-у который ему скажет то же самое. Хотя, с другой стороны, "assumptions" (допущения) это вполне штатная часть любых требований/ТЗ, поэтому с ними тоже надо уметь работать.
Было собеседование, где мне полтора часа два программиста рассказывали, какими плохими были их предыдущие работники
Cчитается, что говорить на собесе плохо о прошлом работодателе это сразу чорная метка. Применяя к этому математически симметричность отношения можно сразу сделать выводы.
Cчитается, что говорить на собесе плохо о прошлом работодателе это сразу чорная метка.
смотря что и как говорить
Я без проблем всегда описывал проблемы с которыми сталкивался у прошлых работодателей и токсичных описывал и проблемы в организации и описывал как я предлагал их решать.
Нельзя обвинять в стиле 'они козлы я от них ушел', можно говорить плохо только если описываешь как ты пытался с этим справится и почему не получалось и почему в итоге ушел… и спросить, а у вас не жалуются? (потому что если да — то мне там делать нечего — но такого ниразу не было после одного единственного раза)
В таком случае если описывают плохих работников — это на самом деле не черная метка сама по себе, а задел на то чтобы задать вопрос как вообще происходит управление в конторе. У меня был опыт работы у таких товарищей где топ-руководство было супер токсичным и обвиняло всех подчиненных во всех проблемах конторы, вплоть до того что заказывали аудит чтобы потдвердить некомпетентность и возмущенно отвергать результаты аудита со словами 'да вы сами не компетентны раз этого не видите!!'
я теперь на каждом собесе про это рассказываю со словами 'а у вас как дела обстоят'?
никогда проблем не было
А можно пример такого "тестового кусочка для ревью"?
— Называю с десяток ошибок. Рассказываю, как сделал бы сам.Интервьюер понимает явно не все, что излагает интервьюируемый (не то чтоб совсем редкая ситуация)? Возможно, что интервьюер взял свой код, внес одну-две хитрых намеренных ошибки или там явно плохих паттернов, ну и соискатель их должен найти и объяснить, что с ними не так. А тут таких говномест в реальном участке коде, внезапно, оказывается аж с десяток, да с размазыванием подробностей. И еще пара присутствующих коллег это наблюдают с плохо скрываемым удовольствием, только что не прыскают открыто. И что ж теперь, бедному интервьюеру после этого сепукку делать?
«Всё понятно. До свидания.»
Насчет собеседований командой - команда обычно пропадает и пипл начинает "жить в моменте" по законам звериной стаи, по принципу "кто на новенького". Новенький фалломорфирует и начинает тупить или просто валит(есть вариант - ловит фан и смотрит чем цирк закончится - мой случай). Как правило коллективные собеседования не заканчиваются ничем, если в команде нет иерархии. Ну а чо вы ж хотели демократии. Вот она так и работает. У народа включаются гормоны и начинают дружно нагибать соискателя. А на тебе еще задачку а на еще вопросик.Аааа - не ответил вон пошел. =)
Ну вы так сборно самозванца-вайтишника и получите. Барана который выучил конечный перечень того, что вы спрашиваете. Нормальные кодеры в моменте все это не помнят.
Как пример - я в моменте не помню что там в java.nio.* - а тем не менее пользовался;
Все как по книжке Савельева "Сортинг мозга". 3 человек уже толпа. и живет по законам обезьяний стаи.
Происходит это по нескольким причинам:
- Люди не задумываются <...>
- У них мало опыта <...>
- Им попросту наплевать <...>
Вы забыли про банальное человеческое эго, работа по обслуживанию коего в той или иной мере свойственна всем нам, увы.
Ведите список всех мудаков кто вас собеседовал, ІТ круглое - рано или поздно можно будет отиграться :D
это может так не сработать. "мудак" в составе стаи был мудак, а выдернутый из нее вдруг начал вести себя вменяемо. Жизнь сложнее. У меня естьзнакомые кто так себя вел на собесах а потом образумился наконец то начал нормальных умных коллег нанимать. Есть те кто не изменился. Личный черный список вести - дурацкая идея. Идейных говнюков не так и много, как правило
Мда, самое интересное, что все хотят работников широкого опыта и обязательно с опытом в 15-20 лет, но при этом это должны быть вчерашние выпускники ВУЗов возрастом до 30 лет. И вот вопрос - а где, собственно, набираться опыта, если все хотят исключительно людей с опытом? Производственная практика? А где она? Если не выпускник ВУЗа - то всё, можно ставить крест и топать работать грузчиком? Ну и требования канеш для айтишника: делать кроме айти всё, что скажут, принимать звонки вместо секретарши и ездить по командировкам на собственном авто, без компенсации и аммортизаций... Спасибо, но вы сами знаете, куда вам пройти с такими требованиями :D
А вообще ситуация с работодателями и собеседования примерно такая же, как и между пользователями хабра.
Вот, к примеру, "...13 янв в 11:55 -1 Неконструктивное общение. Политика или пропаганда. Плохое оформление, ошибки..." Обиженка какая то решила свалить всё в кучу, приплетя еще и политику с пропагандой. И всё это анонимно, да. Руководству хабра ввести бы возможность апелляций, коли уж нам нельзя видеть этих "героев", что привыкли гадить где ни попадя. Особенно доставляет вариант "личная неприязнь" :D Лучше с себя начните, товарищи (хотя, скорее, волки тамбовские)...
И вот вопрос — а где, собственно, набираться опыта, если все хотят исключительно людей с опытом? Производственная практика? А где она? Если не выпускник ВУЗа — то всё, можно ставить крест и топать работать грузчиком?
А вы знаете какуюто еще отрасль где не так?
меня помнится очень забавляли ребята после института, когда у меня еще был бизнес и мы брали себе джунов в конце нулевых
приходит чел, только только со свежим дипломом, по техзнаниям — ну оч слабый, 'хочу зарплату 70к, у меня айтишный диплом!' ©… и они массово так ходили… прям рукалицо
Можете мне пояснить, чтО я как работодатель должен с такими делать? доплачивать за их обучение?
У меня еще в двухтысячных были знакомые с ВМК МГУ, так они все уже со второго или третьего курса где-либо работали по специальности в качестве стажеров. Двое из них сейчас в штатах, один в UK.
блин у меня в команде сейчас стажер работает студент 4 курса, каким чудным образом он к нам попал? магия?
ничего концептуально не поменялось с тех лет, кроме того что ватишники очень сильно перегрузили рынок джунов
Тут фигня в том что будь одни студентами в 2023 году
Ну, значит, просто ничего не изменилось, что радует. За все страны говорить не буду, но, например, в Германии или Израиле если ты к окончанию юни пару лет уже не отработал, то можешь просто вешать свой диплом на стену - будешь на него любоваться каждый раз приходя домой после смены в Макдональдсе :)
Не знаю как ваш, а у нас фирма в лице техлида приходит на кафедру к знакомому преподавателю (с которым этот техлид в свое время проект в одной команде поднимал, да не один) и спрашивает: умные ребята есть? И студент (но не каждый) уходит без собеса в фирму.
Тестовое же есть для таких целей.
Я правда не кодер, но когда junior-ов в BI искали, вот такую строчку в вакансии проставил:Опыт работы до 1 года. Либо готовность сделать тестовое задание / показать свои наработки
И сильно помогло. Задача на дом, нагрузка на час-полтора. Если человек простейшие вещи делал\учился, то справится. На бизнес-смысле больше отсеивалось, если честно...
Руководству хабра ввести бы возможность апелляций, коли уж нам нельзя видеть этих "героев", что привыкли гадить где ни попадя.
Зачем? Какой профит получит ТМ после выполнения ваших пожеланий? Кто будет оплачивать этот банкет (доработка и поддержка функционала, зарплата тех, кто разбирает апелляции)?
Для меня самое идеальное собеседование, это сделать тестовое задание.
Собеседования как правильно проводятся после рабочего времени, когда ты уставший с чугунной бошкой пытаешься в стрессовой ситуации что-то вспомнить.
Тестовое же задание ты можешь делать в свободное время, на собеседовании спокойно его обсудить и пообщаться. По коду будет всё видно. Если что-то не успел сделать, то там же на собеседовании можно рассказать как бы ты это улучшил.
если следовать вашей логики то тестовое вы делаете по выходным, сколько собесов такого формата вы осилите за месяц? 4? ps ни разу не сталкивался с тестовым, но вроде это общепринятый красный флаг
если следовать вашей логики то тестовое вы делаете по выходным, сколько собесов такого формата вы осилите за месяц?
Один собес за полгода и получу оффер с очень интересной беседой. И собесудующие будут настроены на найм сотрудника, а не как обычно.
И собесудующие будут настроены на найм сотрудника, а не как обычно
Когда я преподавал в вузе, мне было смешно слушать заявления студентов о том, что преподаватель их пытается завалить. Особенно когда этот преподаватель их тянет за уши так, что они того и гляди оборвутся...
Та же самая ситуация сейчас с собеседованиями. Вы правда думаете, что большинству людей настолько наплевать на свое время, что они ходят на собеседования, не имея изначальной цели нанять кандидата?
Нет, я понимаю, что есть люди, у которых какие-то личностные проблемы и которые так самоутверждаются, но врядли их количество выходит за размер стат погрешности.
Один собес за полгода и получу оффер с очень интересной беседой.
Оптимистично, но не всегда реально.
За последние 2 месяца собеседовался в 15 разных компаний. Получил 5 офферов.
Тестовое было в одной компании, сделал его, после этого действительно была конструктивная беседа по теме тестового, в конце собеседующий даже неофициально сказал, что решение будет позитивным для меня. Через 2 недели и 3 пинга с моей стороны я получил формальную отписку, що двигаются дальше с другим кандидатом.
Меня греет только 2 вещи: во-первых, тестовое было оплачиваемым, я потратил на него один вечер и получил что-то типа 150$, так что время проведено не совсем зря, и во-вторых, что отказ, очевидно, не из-за моих скилов (по крайней мере, я так себя утешаю - сужу по словам собеседующего, плюс я попросил чуть больше денег, чем была озвучена вилка).
Собеседования как правильно проводятся после рабочего времени, когда ты уставший с чугунной бошкой пытаешься в стрессовой ситуации что-то вспомнить.
Возможно это ваш личный опыт.
Я, как собеседующий, предпочитаю проводить его в своё рабочее время, так как вне его я и сам уставший и вообще другие дела есть.
Если же у вас рабочее время различается, то такая ситуация возможна, да.
Но ведь и вам нужно понимать что вы на собеседование идёте не просто показать что вы существуете, но и что-то нужно будет делать (да хоть тоже тестовое разобрать), а значит стоит немного себя разгрузить перед собеседованием.
Тестовое же задание ты можешь делать в свободное время
И именно по этому тестовое, выдаваемое на дом, принято создать довольно крупным (не на 30-40 минут), а к таким тестовым уже большинство кандидатов относится весьма негативно - на Хабре можно найти кучу статей на эту тему.
что может быть лучше чем делать тестовое по выходным или вечерами после работы? а ещё лучше когда после отправки тестового даже не зовут на собес, потому что не успел что-то сделать, или сделал не так как ожидал проверяющий. но шанса объяснить не будет
- За вас тестовое мог сделать друг или ChatGPT.
- Сейчас вам противники тестовых заданий насуют за воротник :)
Пробовали тестовое, в итоге поняли, что это бессмысленная трата времени кандидата и сотрудника компании.
Собеседования как правильно проводятся после рабочего времени
95% собеседований я провожу в рабочее время. Обычно в районе обеда.
Собеседования как правильно проводятся после рабочего времени
В душе первый раз такое слышу. Вот собеседующим больше нечего делать, как задерживаться после работы и кого-то собеседовать (может, правда, им платят за это по таксе овертайма, но сомневаюсь).
С тестовыми заданиями две проблемы:
Кандидаты их не делают, всегда можно найти вакансию без тестового задания и с собеседующим, который задает банальные вопросы чтобы зайти за мидла или даже сеньора.
Тестовое задание должно быть должно быть не слишком простым и не слишком сложным, при этом близким к теме нанимателя и не гуглиться в интернете. Короче много условий.
классический пример – сортировка с помощью двоичного дерева
Вот черт, выпустился в 2000 году, а сортировку помню, не знаю, как распомнить )
Да если про неё даже ни разу не слышал, но просто знаешь что такое двоичное дерево, то уже сложно не догадаться что это такое и даже написать простейшую реализацию максимум минут за 30. Я бы на собеседовании вообще писать это поленился - просто рассказал бы принцип работы, сказал бы что сложность O(n * log(n)) и что её достоинство это что можно сортировать прямо из какого-нибудь потока без его предварительной загрузки в память. Для вменяемых собеседующих этого должно хватить, а с невменяемыми мне все равно не по пути, так что результат уже без разницы.
история #2 да и коментарии некоторые...
Раз все такие умные, зачем вам отдел тестирования и прочие современные плюшки?
Закодили - и на прод.
Угу был у меня пару лет назад такой собес, больше похожий на перекрестный допрос, еще и с выключенной камерой одного из собеседующего. Естественно завалил, примерно с середины посыпался на простейших вопросах. Но даже если бы прошел, не пошел бы туда :)
Технические собеседования давно "must die", но до сих пор, почему-то, живы.
Я работаю программистом более 13и лет и на них положил болт ещё после первых лет 3х.
Тех. собеседование - это экзамен, с рандомными вопросами, в напряженной обстановке. Соответственно пройдут его единицы, в таком же рандомном порядке.
Помню самый показательный случай был одной днепровской компании, ещё где-то в 2016м. Там старший программист по JavaScript-у нанимал других сотрудников по принципу "загнобить" их на собеседовании побольше. Я не преувиличиваю, - "загнобить" его было чуть ли не любимое слово, которым он постоянно пользовался, придумывая вопросы для собеседования.
Работал я не с ним, но в смежной области, находясь у него за спиной, и просто офигевал от такого подхода. При этом их it HRка искренне выполняла свою работу, - регулярно подгоняя ему кандидатов, и недоумевая потом, почему они все не подходят после тех. собеседования.
Ну а это моральное *овно чисто получало удовольствие, от того, что унизило, очередного кандидата.
Вот и подумайте, в следующий раз, когда добровольно решитесь проходить тех. собеседования, а кто на другом конце у вас будет его принимать, и какие его мотивы.
Поэтому технические вопросы я принимаю только в одном виде, - сертификация.
Во первых у вас будет достаточно времени к ней подготовиться. Во вторых у известных сертификатов достаточно стандартизированные вопросы, многие из которых уже есть в интернете. В третьих, в случае успешного прохождения вы получите немедленный и ожидаемый результат, в виде сертификата, а не неизвестной работы, на которую всё-равно будет не понятно, примут ли вас, или возьмут всё-таки другого, что там будет за конкретная работа и сработаетесь ли вы вообще.
Решение как по мне давно известно: подробная беседа с кандидатом -> обычное тестовое задание, если оно нужно (небольшое и не на время) -> испытательный период в 1-2 месяца, во время которого уже всё станет ясно
если вы отказались от собесов в первые 3 года стажа, вы максимум мидл и остались на одной работе или ушли в фриланс
собственно вопрос, у вас какая вилка ежемесячного заработка?
Подход интересный, но собеседований, которые можно описать как "просто поговорить", в моей карьере было ну наверное.. 3. Из них на двух несколько очень базовых технических вопросов все же были.
Очень не популярный подход короче.
Технические собеседования давно "must die"
Конечно мастдай и место им в земле. Приходит человек у которого в резюме девяносто лет опыта работы с REST. На собеседовании просят просто "вольным текстом" описать REST API для примитивнейшего CRUD с одной сущностью и первое же что он делает это реализует удаление через HTTP GET.
Использования DELETE на удаления это самое популярное соглашения.
В итоге у нас возникает хороший вопрос, который отлично может прояснить и знания по специальности и личностные качества.
ибо некоторые фронтендеры сильно долго понимают, как вообще заюзать DELETE. А каждый раз обьяснять — мне влом.
Объяснить один раз, как генерить клиента из Open API (ака сваггера) и дело с концом. Но вообще фронтендеров, которые не понимают как вызвать DELETE надо бы гнать взашей - пускай идут у Лебедева баннеры рисовать. Бекендера который, например, упорно не понимает логическое "И" и поэтому везде пишет вместо него цепочку из нескольких вложеных if-ов вряд ли кто-то долго держать будет.
Если DELETE влом делать/объяснять/что-то ещё — существует же POST, пригодный для любого запроса. GET-то зачем делать? Чтобы однажды робот удалил весь сайт в попытке его проиндексировать или там показать превьюшку?
Технические собеседования давно "must die", но до сих пор, почему-то, живы.
Простите, а вы людей нанимали?
Поэтому технические вопросы я принимаю только в одном виде, - сертификация.
Сейчас нет ни одной достойной программы сертификации для программистов. Да и развивается все так быстро, что сертификат устаревает еще до его получения.
Решение как по мне давно известно: подробная беседа с кандидатом
Беседа о чем?
Попытайтесь держать в уме, что кандидат сильно нервничает и, вероятно, не выказывает и половины способностей, которыми обладает в спокойном состоянии.
Зато сразу видно, как будет работать сотрудник в стрессовой ситуации. Для многих ИТ-специалистов это состояние на работе становится перманентным.
Тогда может и хорошо что отсеивают. Ну ее нахрен, такую работу, на которой ты будешь находиться в перманентном стрессе. Для здоровья это нихрена не полезно.
Всё верно.
Если простая беседа вызывает стресс, то что станет с человеком на собрании отдела, управления, публичном выступлении?
Чего уж говорить, если он устроит небольшой факап и раздует его в своей голове до проблемы космического масштаба?
Это далеко не простая беседа, по уровню стресса так даже выше чем экзамен в ВУЗе - там у тебя хотя-бы конечное количество вопросов, которые могут задать.
А публичные выступления - вы точно про работу программиста?
" Происходит это по нескольким причинам: "
не только это.
очень часто приглашённые члены команды озабочены тем, что показать собственную крутизну и одновременно то, что кандидат хуже их. За этим же столом, зачастую, сидит или лидер команды, или один из РМ - ов, очень удобно повыпендриваться.
Причём если уходить в частности и мелочи проекта, с которым они работали 10 минут назад, а кандидат или не работал с подобным, или работал когда-то давно, то результат практически гарантирован.
А что касается их заинтересованности в подборе нужного кандидата.. по большому счёту, оно далеко не всегда им интересно. Им важны собственная значимость, их собственная зп и её возможное повышение. И людей можно понять : так им удобнее будет через какое-то время поднять вопрос о пересмотре их з/п.
Да, ещё. Толковый начальник, понимающий как грамотно организовать и провести подбор кандидатов - редкость, толковая хрюша - большая редкость.
Так чему вы удивляетесь ?
"всё идёт по плану" (с)
Даю небольшое тестовое задание связанное с работой. Объемом в пару часов. На дом. Срок недельку. Потом садимся и кандидат рассказывает о том, как он делал, объясняет свой код.
По моему это лучше, чем спрашивать абстрактную ерунду.
И кандидат за эту неделю находит другую работу, где обошлось без тестового. Во время активного поиска заниматься тестовыми обычно либо некогда, либо прямо очень сильно лень, тем более что полно вариантов без них.
Я помню, как-то успешно прошел собес в одну фирму, но они решили дать еще дополнительно тестовое (з/п на тот момент у них было очень даже приличная) я его даже решил, отдал, и оно им понравилось, правда к моменту когда они мне выставили оффер - я уже успел принять оффер от другой компании, отчего они потом сильно переживали (реально переживали, потому что через несколько лет меня потом опять к себе зазывали, но тоже как-то не сложилось).
Я это к тому - что тестовое тоже не слишком хороший фильтр, который может отсеять много подходящих кандидатов, которые просто по каким-либо причинам не могут или не хотят этим заниматься.
На удивление всегда более менее адекватных людей встречал на технических собесах. Ну может было одно два исключения.
Гораздо больше выбешивают тестовые задания, особенно те, которые дают делать прямо под чьим-то присмотром. Типа пиши, а я посмотрю как и что ты пишешь. Я быстро понял, что я так не могу, слишком сильное психологическое давление. И потом вы же не будете на работе надо мной стоять и смотреть, как я пишу код и решаю рабочие задачи? Так что теперь при отклике в первую очередь уточняю, есть ли у вас тестовое задание онлайн, и если есть - сразу разворачиваюсь.
Да и сами задачи в этом тестовом задании, даже не в онлайн, как правило, имеют весьма опосредованное отношение к реальным рабочим задачам. Однажды встретил одну компанию, которая проводила просто технический собес, и hr открыто мне сказал, что мы мол проводим тех собес, а все эти тестовые задания не считаем хорошим способом отбора кандидатов. Жаль, что таких замечательных примеров на рынке мало...
"и держите своего внутреннего козла в загоне" - прям надо запомнить
Цель собеседования - взять кандидата, который справится с поставленной задачей и отсеять кандидата, который с этой задачей не справится. При этом, если ошибочно отсеять подходящего кандидата, то никто об этом не узнает. Если же ошибочно нанять бестолкового, то это точно обнаружится. И это может стать проблемой, в том числе и для интервьюера. Исходя из этой логики выгодно максимально "звереть", чтобы неподходящий кандидат точно не прошёл.
Если вакансию точно нужно закрыть и есть Х кандидатов, то опять же интервьюеру выгодно максимально придираться к каждому, потом взять лучшего из них. А в случае провала в работе кандидата у интервьюера будет железная отмазка - "он и на интервью плохо отвечал, я в него не верил, но вам нужен был работник, а остальные были ещё хуже".
Дисклаймер: не программист ни разу. Может когда-нибудь лет через десять.. ;)
Продажник, в прошлом управленец среднего звена.
Провел больше двухсот (двухсот) собесов.
Прошел десятка четыре собесов.
Всё, что требуется узнать на собесе:
а) человек управляемый и адекватный (в критериях компании, куда он пришел)
б) человек впишется в команду
в) человек способен (не может в данную секунду исполнить, а способен) исполнять положенные на эту должность задачи
г) ну и общий уровень образованности
Если эйчар (руководитель, привлеченный специалист, etc.) этого не понимает - возникает озвученная ситуация. Понимая что программисты себя продают очень плохо - ну так значит работа эйчара купить программиста.
А эйчары, я вам открою секрет, практически нигде нормально не ищут никого. Ни в IT, ни в финансах, ни в продажах.
Козлами собеседующие становятся потому, что получают в свои неподготовленные руки власть над другим человеком: пусть на короткое время и небольшую, но власть.
А для не готового к этому человека испытание властью - самое трудное из возможных.
Во второй истории просто классический Стэнфордский тюремный эксперимент
Я пронаблюдал, как хорошие программисты (и хорошие люди) внезапно превращаются в каких-то козлов без капли сочувствия к кандидату.
Это что. Вы бы видели, что творится с такими собеседователями, когда кандидат как смог ответил на все каверзные вопросы, более менее отбился от натиска собеседователей и решил поспрашивать интервьюеров. Ну хочет человек получше знать, с кем ему возможно предстоить работать. Это очень хорошая практика и позволяет получше узнать компанию. И вот когда кандидат начинает с простых, но основополагающих вопросов, а на противоположной стороне молчание и замешательство, тут начинается самое забавное. Крики, грубости и нелестные пожелания прилагаются.
В копилку личных неадекватных собесов. Прямо вот совсем недавно общался. Техническая часть, спрашивают самые основы, по java core, на все успешно отвечаю, ибо примитив, жду продолжения.. но его не следует, собес сворачивают с коментарием - больше вопросов нет. И в фидбеке пишут что-то вроде - уверенное знание основ, твердый мидл (что за бред?!) мне синьорских вопросов и не задавали в принципе (вакансия синьорская). В недоумении что это было. Такое ощущение что просто был собес для галочки, и нахрена только время на него тратил.
На собеседовании, также как и в любой другой ситуации в жизни, каждый решает свою личную проблему. Соискатель хочет получить работу, работодатель хочет нанять недостающее звено в команду, эйчар пытается помочь своему работодателю. Ну а приглашенные для помощи программисты пытаются изо всех сил самоутвердиться за счет соискателя.
Как итог - программист доволен, он самоутвердился, эйчару добавилось работы, соискатель в лучшем случае просто пошел искать работу дальше, работодатель потерял потенциального исполнителя.
Мало того, на позицию Джуниор собеседуют как Мидла, а зарплату выставляют как дворнику в деревне(18 т.р-28 т.р). Глупость, я считаю, у таких людей зашкаливает.
Я бы тоже при__л от вопроса, "как создать таблицу". Как create table написать или что? Так для любой СУБД после этих 2 слов целая простынка идет обязательных и необязательных кляуз. Или ПКМ в ИДЕ и выбрать в меню "создать таблицу". Хз как бы я ответил на этот вопрос и стал бы дальше общаться или нет.
Непонятна прямая связь у автора с неправильным ответом и заваленным собеседованием. Вообще много вопросов норм. Я так и проводу собеседование. То, что человек не знает, помогает определить позицию и круг и последовательность задач. А агрессивность, так то ерунда. В работе что только не бывает. Если человек будет сразу увольняться от любой эмоции, так лучше сразу на собеседование пусть уходит
Это все нужно чтобы вы осознавали собственную ничтожность даже перед ChatGPT, смертные.
«Мы такие деньги платим, зачем нам здесь придурок какой-то, ха-ха».
Кто не сможет решить все задачи на всех языках программирования за минуту - те полетят в Канаду.
Жесткое и агрессивное техническое собеседование - это очень травмирующее событие. Даже если получала оффер, никогда в такие фирмы не шла потом работать.
И, наоборот, бывали собеседования, которые начинались как "серьезные", при этом чувствовалось, что интервьюер за меня правда переживает, подсказывает, сочувствует и мотивирует. Под конец многих из них мы уже были с интервьюерами как будто друзьями, шутили и смеялись. Вот в такие команды я шла, потому что чувствовалось, что к людям там по-человечески относятся.
Очень хороший пост.
Хотел от себя добавить 2 комментария:
- Многие (не только в IT) забывают что на собеседовании соискатель тоже собеседует работодателя, ибо как к тебе относятся на собеседовании, так же скорей всего будут и на ИС и дальнейшей работе. А это мне кажется действительно важно помнить всем.
- У меня в текущей компании на собеседовании интервьювером был наш архитектор и он мне тоже дал задачку на SQL, когда я забыл название метода, сказал что "ты мне скажи что делать будешь, а не как это называется, в Гугле нас не забанили еще"
Так что я полностью согласен с постом, хорошо что многие это помнят
Мне не понятна политика когда тебя собеседуют двое.
Во первых это психологически тяжело, находясь на чужой территории отвечать на вопросы сразу двух собеседующих.
Сколько раз ходил на собесы, всегда минимум было двое, может им тоже страшно, кто знает)
Так же у меня был момент когда мою квалификацию (frontend разработчика) определили по 13 вопросам из тестового которое мне скинули накануне.
Вопросы там были из разряда: Как валидно использовать тег noindex или какое событие нужно отлавливать на форме при ее отправке.
Я по какой то причине решил не пользоваться гуглом и ответил на все по памяти, естественно все перепутав, после чего мне дали разряд стажера, что меня унизило, так как ответы на эти вопросы узнаются буквально за пару кликов.
И вот такие компании (Как они себя называли: МЫ входим в топ 10 IT-Компаний России, Яндекс наш партнер) так собеседуют, а потом никого не могут найти (Либо целенаправленно ищут раба)
Двое это чтобы исключить предвзятость и размазать ответственность (в расстрельной команде, для этого выдают только один боевой патрон).
Как-то был забавыный случай на работе. Двое коллег выше среднего по росту собеседовали стройную девушку. Я проходил мимо в тот момент когда она что-то написала на листочке и они дружно привстали и нависли над ней.
Она правда не обратила на это внимание. Она пришла по рекомендации и кажется одного из интервьюверов видела до этого на конфереции. Интервью она прошла.
Просто
Технические собеседования нужно проводить в текстовой форме и асинхронно. Это наиболее приближено к реальности.
Был по обе стороны стола. Кандидатам всегда выдавал несложный тест -- написать небольшую программу плюс личное общение, для знакомства. И потом тестовый период в две недели. Это работает вполне.
От работодателей, кто просит решить в реальном времени задачу на бумажке или устно, всегда чураюсь. Потому что не нужно работать с мудаками.
Ё-моё, я даже считать без калькулятора уже давно разучился. Чтобы программировать мне нужны мои инструменты, интернет и немного времени, чтобы подумать)))
Кандидат отдает асинхронную задачку индусам написать и что с ним потом делать? Оплата за 2 недели покроет расходы на индусов.
Перебирать по одному кандидату раз в 2 недели это очень медленно. Тратить две недели на введение в курс дел неподходящего человека дорого.
Все текущие решения они неспроста такие. Всегда есть причина.
Как говорят психологи, шила в мешке не утаишь.
Конечно. Его уволят. Но время и деньги будут потеряны. Отсеять его на собеседовании заметно дешевле и быстрее.
Принять риск и работать. Ну обманет один человек из ста.
Чтож.
Подумаешь.
Давай ещё раз!
Это не стоит того, чтобы становится равнодушным. И презирать всех. Брать надо людей в работу, минимально отсеивать, смотреть на энтузиазм и мотивацию.
А если не получилось, то ещё раз.
А если не получилось, то ещё раз.
После того как не получится 3-4 раза тому кто вводил этих людей в курс дела и обучал надо в санаторий на месяц. Нервы лечить.
Онбординг новых сотрудников это сложнае и затратная по силам работа.
Брать надо людей в работу, минимально отсеивать, смотреть на энтузиазм и мотивацию.
Берите. Мне своих людей жалко, которые будут вот с этими свеже нанятыми страдать. И нанимать надо быстрее, а не по одному человеку раз в две недели перебирать. Считаем что процентов 10 прошедших это уже огромный успех.
Это не стоит того, чтобы становится равнодушным. И презирать всех.
Выгоднее заботится о тех кто уже работает и не заставлять их страдать с новичками которые не подходят.
Ну обманет один человек из ста.
Ха-ха-ха. 99 из 100 вероятнее. Вайти и вот это вот все.
Ну и кстати обман легко распознать. Используя текстовое ревью кода в ходе знакомства просто надо спросить, что и почему)))
Не очень. Точнее можно, но для этого надо давать большую домашнюю работу. На день работы примерно. Которую точно так же никто не любит. Работать день просто так, зачем оно нормальному кандидату надо? Проще онлайн за 2-3 часа собеседования пройти.
Изначально я писал, что проводить техническое собеседование нужно в текстовой форме, а не в аудио и не в видео и не в реальном времени. А вы вон куда повернули разговор...
Написание кода это и есть текстовая форма. Общаться не голосом, а в чатике странно. Вопросы в чатике задавать тоже странно. Это выглядит как бесполезное растягивание собеседования в разы.
Если вы наймёте человека, то как вы ему будете ставить задачи?
Вероятно, в текстовой форме, в какой-нибудь системе управления проектом. И тогда человек будет выполнять задачи с некоторым лагом. Будет их обдумывать, искать там что-то в сети и в итоге делать коммит и решать задачу.
Скажите разве вы знаете человека, который возьмет плохо сформулированную задачу переданную устно и тут же её выполнит?
Нет. Надо всё записать и обдумать и потом сделать. А не вот это вот -- дай ответ, немедленно...
И вы опять попадаете в ситуацию большого домашнего задания на день работы. Которое опять многим не нравится.
Тут или или. Сейчас рынок склоняется к лайвкодингу, он вызывает меньше отторжения у кандидатов. Возможно через год рынок перейдет к большим домашним заданиям. Я следом за рынком тоже буду их давать. Ничего личного, все как у всех.
Скажите разве вы знаете человека, который возьмет
плохохорошо сформулированную задачу переданную устно и тут же её выполнит?
Да, у меня вся команда такая. Все сложные задачи проговариваем голосом, это куда быстрее, эффективнее и понятнее чем тонны емейлов. А системы управления проектом - они не для эффективной постановки задачи, а чтобы потом через неделю/месяц/год знать, что и почему сделано, когда уже все забыли.
А плохо сформулированные задачи будут плохо сделаны, неважно, формулировать устно или письменно.
На собеседовании постановка задачи письменно имеет смысл только если вы ставите одинаковую задачу десяткам кандидатов. Заранее продуманное тестовое задание. А вот уточняющие вопросы (которые очень интересны, но индивидуальны) - письменная форма только тратит время всех участников.
Если вопрос неправильный поставлен, то и ответ будет неправильный. Это все знают.
>> Ха-ха-ха. 99 из 100 вероятнее. Вайти и вот это вот все.
О боже с кем вы работаете?! Сочувствую.
Ну и кстати обман легко распознать. Используя текстовое ревью кода в ходе знакомства просто надо спросить, что и почему)))
Самое идиотское собеседование было у меня. Устраивался инженером-конструктором на гос.завод. По времени. Приехал в 11.Ладно.Такой-то такой-то.Принесли чертеж из военно- специфичного СВЧ .Объяснить.Ладно. Хоть и немного не моё.Но объяснил,как работало. Название узлов,цепей, как ,что фурычит. 11-30. Объяснил. Ой,у нас обед. В 13-30 можете?-могу. В14-00,приходит руководитель..Смотрит дипломы. Ладно .Все ОК. Ой,а я отойду, на пару минут. Приведу начальника отдела. Поговорите. Хорошо.15-00 16-00 17-15.Никого. Спрашиваю. Мне,вроде,того,домой..Все расходятся. Где такой-то. А он уехал в 14-00- домой и не вернется. Зачем,что это было,я не понимаю. Плюнул,выкинул обходник собеседования в отдел кадров, ушел. Кстати,нюанс,это было в соседнем городе, опоздал на автобус,ночевал в здании автовокзала. Никто даже не перезвонил,даже я не звонил туда.Зачем?
У собеседующих обычно мало опыта проведения собеседований. Если вы провели скажем 50 собеседований по 1.5 часа и порефлексировали над проведенными собеседованиями, то ваш "налет" будет около 100 часов. Вспомните, каким вы были программистом через 100 часов обучения. Я провел 400+ собеседований, я хорошо чувствую настроение собеседника, и я же регулярно завожу собеседования не туда куда бы мне хотелось.
По первой истории:
забрасывать кандидата вопросами пока не нащупаешь границ - очень эффективная тактика проведения собеседования. Но если вы проводите стресс-собеседование то об этом нужно сказать как минимум после окончания стресс-части (и заодно тогда извиниться). Я предпочитаю заранее говорить чтонибудь вроде "отлично, спасибо. а теперь давайте попробуем за пару минут накидать еще 10 альтернативных вариантов ответа. любого качества. вот вам мой альтернативный вариант, а теперь давайте вы."
По второй:
пустячная ошибка в мелочи - тоже информация. В идеале стоило бы понять природу ошибки. Может кандидат понимает что эта ерунда вылезет и будет мгновенно исправлена уже на следующем же шаге в боевых условиях; а может кандидат плавает в понимании основ.
По третьей истории:
во-первых, ничего хорошего не ждите если в команде собеседующих у вас более одного технического специалиста на тему (который одновременно и ответственнен за оценку технического уровня кандидата в этой теме). Такая ситуация создает ряд проблем сама по себе. Во-вторых, автор просто забыл провести собственно собеседование в этой, третьей, истории.
история "как создать таблицу":
очень помогают вопросы вида "у вас есть X, вы хотите получить Y для того чтобы Z. Расскажите как вы будете действовать". Такой вопрос не создает впечатления что существует некий единственно верный ответ и дает пространство отвечающему. И, кстати если после фразы кандидата "я бы хотел вернуться к предыдущему вопросу" интервьювер обрывает его и идет дальше - то врядли будет ошибкой посоветовать кандидату встать и пойти домой. Не стоит забывать что процесс собеседования обоюден. Да, мы говорим "кандидат" и "собеседующий" но по факту обе стороны находятся на обеих этих ролях одновременно.
мотив кандидата
интересно что в тексте не затрагивается тема мотива кандидата. Зачем он пришел на собеседование и что он хочет получить. Это важнейший вопрос для собеседующего. От него зависит все собеседование. Причем часто чтобы узнать реальный ответ на этот вопрос (а не "вы переспективная компания а я как раз люблю деньги и программировать игры") - приходится проводить танцы с бубном.
интересно что в тексте не затрагивается тема мотива кандидата. Зачем он пришел на собеседование и что он хочет получить
Плясать с бубном, чтобы узнать "а еще вы ближе всех к моему дому, хоть я и надеюсь на удаленку, но вообще наравне с вами у меня еще 5 компаний, на те же деньги и устроюсь я в ту, которая быстрее даст устраивающий офер"?
На технических собеседованиях даже нормальные люди звереют