Comments 315
Сочувствую. Такая же фигня у меня. Отвратительно собеседуюсь, при этом 20 лет успешно выполняю работу. Но я уже смирился и забил. К собесам не готовлюсь, как пойдёт, так пойдёт.
Тоже был в этой проблеме. Но оказалось, что подстроившись под этот сломанный процесс и выучив все "типичные вопросы", можно проходить эти глупые собеседования не приходя в сознание. Для хорошего инженера это просто еще одна проблема которую надо решить, хоть и решать ее кажется противным.
Доходит до смешного: в одной компании меня даже не приняли на работу по причине "оверквалифайд", только потому что я рассказал им как работает сборщик мусора в Go. Делал ли я сборщики мусора сам? Нет, конечно, это была прочитанная за день до собеседования статья.
Возможно, за неимением факторов которые можно объективно оценить, процесс собеседования построен на попытке выявить коссвенные коррелирующие факторы, такие как любознательность. Если бы я не интересовался подобными статьями - о чем можно бы со мной говорить? А если поговорить не о чем, то и возможно работать вместе не будет увлекательно.
Не очень увлекательно не значит неэффективно.
Кстати хороший способ, хоть и несколько растягивающий процесс. Даем человеку всю необходимую литературу и время на подготовку и пускай он внятно расскажет что-то по теме.
Допустим, он ничего не знал про сборку мусора - лично я бы взял на работу человека, который спустя час-два времени сможет мне более менее толково рассказать как там что работает. В конце-концов это куда как более полезное умение, чем просто навык держать в голове миллион ненужных фактов. Если человек с полного нуля за некоторое разумное время может разобраться в достаточно сложном вопросе, то это отличный кандидат на работу (при условии что он подходит по другим статьям, разумеется)
Я бы взялся за такое исследование только если бы чувствовал ценность его для себя. Т.е. в нашем примере - если мне интересны сборщики мусора. В противном случае это сьест еще больше времени чем тестовое задание, и даст лично-бесполезный результат.
С другой стороны - если мне уже интересны сборщики мусора - то почему я уже сам не сделал такое исследование, не дожидаясь предложения от собеседующего?
Нам расскажите, вы приняты)
Отвратительно собеседуюсь, при этом 20 лет успешно выполняю работу.
А сколько у вас было собеседований за эти 20 лет? Сколько из них за последний год?
К собесам не готовлюсь, как пойдёт, так пойдёт.
Простите за навязчивость, но за свои 20+ лет успешной работы я понял, что любой навык прокачивается. Быстрее - если желание есть. Медленнее - если его нет.
Собеседование - это такой же навык. Сколько вы его качали? Вот то-то и оно.
Сходите на собеседования ну хотя бы раз 10-15 подряд не с целью устроиться, а с целью собрать грабли. Если вы получили оффер - задача не выполнена.
Искренне оттопчитесь по граблям (сбор информации)
Выделите грабли в отельные классы (систематизация).
Разработайте для каждого класса граблей универсальную заготовку, отрепетируйте (выработка решение)
С заготовками пойдите на следующий раунд собеседований (проверка)
Например, когда вам дадут задачу "спроектируйте Телеграм" или "спроектируйте чат-бот для банка" или "спроектируйте сервис уведомлений", вы просто уверенно достанете заготовку дизайна из кармана и доработаете напильником.
Вы удивитесь, но второй раунд даст сильно отличные результаты от первого.
Собеседование - это такой же навык. Сколько вы его качали? Вот то-то и оно.
Не находите глупым тратить на это время и силы просто ради собеседований? Ведь оно потом в работе почти не пригодится.
Навыки общения с совершенно незнакомыми людьми в стрессовой обстановке при практически неизвестных темах беседы?
Ну, если планировать использовать в работе исключительно технические знания, то не пригодятся.
Но мы ещё и живём вовне работы, где такие навыки однозначно полезны.
Этот навык хорошо влияет на зарплату.
Мы вообще по жизни тратим время и силы на то, что "почти не пригодится". Начиная от заучивания стихов в школе и заканчивая неоплачиваемыми овертаймами на работе.
А собеседование - редкое исключение. От этого навыка напрямую зависит зарплата, то есть благосостояния мое и мой семьи. От этого зависит моя уверенность в себе. Я могу в любой момент могу встать и пойти работать на другого "дядю".
Поэтому этот навык я считаю весьма полезным.
А зачем Вам навыки полезные в работе, если Вы не можете устроится на работу?
я хожу на собесы чтоб понимать что сейчас спрашивают на собесах и что предлагают другие компании. Это решает сразу 3 задачи, я понимаю актуальную цену своим навыкам, я лучше провожу собесы в совей компании и прокачиваю навык "холодного общения" в стрессовой ситуации. Так что я бы сказал "почти не пригодятся" это очень далеко от истины. И хоть я не навижу всякие литкодовские собесы которые часто проваливаю но я понимаю причину их проведения на некоторые позиции или компании.
Собеседований было под сотню за всё время. За последний год - 2. Уже никуда не зовут.
Если навык не используется, то он забывается. Ну вот пользовал я бейсик, паскаль, верилог, LLVM IR - всё забылось, ничего не помню через 5 лет. Так и навык собеседования забывается. Можно бы прокачать, да рынок мёртвый (или я уже старый и ненужный).
Мы с вами, вероятно, одного возраста.
Ну да, вы правы: навык забывается, если его не качать. Более того, даже обладай вы феноменальной памятью, этот навык за 5 лет устаревает почти полностью из-за изменений подхода к найму со стороны компаний.
Я тоже пользовал всякое разное начиная с ассемблера и С под однокристаллки и заканчивая бэйсиками и паскалями. Это никого не интересует. Для работодателя важен опыт за последние лет 5, и как при помощи этого опыта я собираюсь решить его (работодателя) проблемы.
Вот конкретно сейчас я продаюсь как группенфюрер на .NET. Как чистый разраб - наверно я уже слишком старый, чтобы поспевать за всеми новыми фишками. Поэтому позиционируюсь как лид.
И я вижу, что рынку надо чтобы я не забыл технику: как кодить, как жонгилровать потоками и управлять памятью. Не менее (и даже более) рынку важно, чтобы я умел в процессы, пипл менеджмент и продуктовые активности.
Я "щупаю" рынок, потом покупаю книжки, обсматриваюсь вебинарами, выбиваю из работодателя профильные курсы. Эпизодически занимаюсь пет-проектами, чтобы не забыть кодинг.
Потом применяю полученные знания на практике. Иногда при попытке применения сова лопается, но такова жизнь. Главное, потом на следующем раунде собесов у меня есть кейс из практики почти из каждого их вопроса.
Если вы действительно специалист в Верилоге, то крайне легко найдёте работу сейчас в России. Программистов ПЛИС сильно не хватает.
Мне кажется, вы не поняли суть, которую пытался донести автор статьи. Никто не спорит с тем, что собеседования, как навык, можно улучшить. Проблема в самих собеседованиях, они зачастую оценивают не то, на сколько хорош инженер в своей области, а лишь его навык прохождения собеседований. Автор буквально говорит, что говно, извините, воняет. А вы ему советуете съесть это говно 10-15 раз, и тогда он привыкнет к его вкусу. Я сам был на подобных собеседованиях, где от меня ждали знания консольной команды, которая мне нужна раз в год. Что дает заучивание этих команд - абсолютно ничего, любой инженер за минуту загуглит и применит эту команду, когда она потребуется.
Ну, если вы к этому так относитесь... то боюсь, мне тоже не удалось донести мысль )
Я не спорю, что от некоторых собесов воняет. Но во-первых, не от всех. А во-вторых, это взрослый мир. И в нем надо учиться себя продавать. Даже, если что-то не нравится, даже если поставили подножку и упал в грязь. А кто обещал, что будет легко?
Ну попросили вывести консольные команды, ну попросили повертеть красно-черное дерево на одном месте. И черт бы с ним. Отряхнулся и пошел дальше.
Я не продажник, но знаю что мне этот навык нужен: от него зависит мой успех и благополучие меня и моей семьи. И знаю, что сам по себе навык продаж не разовьется. Поэтому развиваю в меру возможности и сил. Собеседования - всего лишь тренировка.
Отряхнулся и пошел дальше.
Это не решение проблемы, это способ ее скрыть. Статья не о развитии навыков собеседований. Она к интервьюверам направлена, а не к интервьюируемым, как вы не поймете. Есть очень много людей, которые не попадают на должность именно из-за таких интервью, хотя они идеально подошли бы по скиллам. Просто потому что не знали эту консольную команду, которая им никогда в жизни не нужна была.
Очень хорошая и качественная статья + подкрепленная реальным, мощным исследованием международных компаний, с которым сам ознакомился недавно.
На мой взгляд собеседование - это прям очень субъективный момент, который зависит от такого множества факторов, в котором действительно показать, на что ты способен как профессионал, раскрыть весь свой технический потенциал просто нереально.
В идеальных условиях, если под вас все организовать, то вы и теоремы доказывать сможете и олимпийских высот в спорте достигнете. Но мир это неидеальные условия, возможно именно вам не повезет никогда не оказаться в условиях, чтобы показать себя как величайщий игрок на скрипке и никто о вас не узнает никогда. Собеседования же это способ показать, насколько вы в среднем хороши для работы и альтернативы этой процедуре по большому счету-то и нет.
Собеседования же это способ показать, насколько вы в среднем хороши для работы
Вообще и не близко.
Собеседования - это способ показать, насколько вы в среднем хороши в вопросе прохождения собеседований. Инфа 100 процентов. Говорю как человек, которому многократно приходилось быть с другой стороны процесса.
Собеседования в их массовом виде это безтолковый дегенеративный каргокультный караван булшита, где тратиться много времени и размывается ответственность, а в итоге всё равно нанимается кто попало, кто зачастую даже физически не способен выполнять работу. Да-да, я не опечатался, мне лично и косвенно знакомы примеры где после 5+ раундов собеседований на работу разработчиками нанимали в итоге людей, которые банально компьютерно неграмотны, не то чтобы они умели разрабатывать что-то. И это происходило не один и не два раза, и это происходило в разных компаниях, в разных странах, поэтому на проблемы конкретного места не свалишь всё.
И да, дело касается не только разработчиков к слову, другие специалисты имеют похожие проблемы.
К слову, я вполне пониманию почему всё в таком виде существует, и понимаю почему это воспроизводиться — причин там не одна и не две, но это не значит что это что-то хорошее или даже нормальное. Серебрянной пули как универсальной альтернативы, к сожалению, нет потому что слишком много факторов бьют по казалось бы адекватным способам решениям проблемы.
Собеседования - это способ показать, насколько вы в среднем хороши в вопросе прохождения собеседований. Инфа 100 процентов. Говорю как человек, которому многократно приходилось быть с другой стороны процесса.
Мы бы сказали, что более точно (и несколько меняет взгляд на вещи) собеседование это то, насколько человек в данном конкретном случае заинтересован получить конкретно эту должность в конкретно этой компании.
... насколько человек в данном конкретном случае заинтересован получить конкретно эту должность в конкретно этой компании.
Вот бы еще знать, чем на самом деле будет заключаться эта должность и что это за компания.
В какой-то степени для работника и работодателя найм – это лотерея, в которой неизвестно, найдешь ли классный коллектив в действительно интересном проекте или токсичную атмосферу и ковыряния в чужом коде.
Вот бы еще знать, чем на самом деле будет заключаться эта должность и что это за компания.
Если Вы устраиваетесь не во что-то совсем мелкое, то даже в россии это по большому счету не секрет.
Ну что значит не секрет? Работодатель не трубит о своем отношении к задачам и к своему персоналу. А отзывы в интернете о компании не всегда даже на 50% верны реальности. Уж очень сильно влияет на эти отзывы атмосфера повлиявшая на конкретного человека относительно его опыта "до" и "в" этой компании.
Тогда если "не секрет", какой есть способ узнать правду?
TerrorDroid - полностью согласен с Вашим небольшим дополнением :)
Уровень сервиса найма персонала не в it - а в промышленности ещё веселее.
Неквалифицированные выпускники HR курсов - или вообще дети полезных людей первым делом отсеивают толковых и ершистых.
Вообще не случается тестов по существу... В лучшем случае - "беседа с непосредственным руководителем".
И этот Энштейн должен за 5..30мин должен оценить деловые качества вообще - и предполагаемую эффективность в частности.
Отсюда норма - имеем низкоквалифицированных подхалимов на всех уровнях управления. И безинициативный линейный персонал.
Кайдзен по-русски: самый страшный грех - показать проблему руководителю.
На выходе структурообразования получается АвтоВАЗ.
Низкая производительность труда (при наличии любого оборудования), недовольный персонал, дорогая и не слишком качественная продукция.
Всё то,с чем пыталась бороться партии на XXV съезде КПСС :)
Что то как то не везло вам с интервьюерами, может быть проблема не в процессе, а в людях, которые в этот процесс не умеют? Так уж получилось что я за свою жизнь провел очень много собесов, находясь по разные стороны, принял штук 30 кандидатов в сумме, ни по одному из них небыло негативного фидбека в последствии. Отрицать не буду, хороших возможно отсеял тоже не мало, но как правило это либо люди имеющие высокий навык спорщика, либо откровенно слабые харды, и там и там потеря невелика.
Собеседования - это способ показать, насколько вы в среднем хороши в вопросе прохождения собеседований. Инфа 100 процентов. Говорю как человек, которому многократно приходилось быть с другой стороны процесса.
ну это лишь говорит, что у вас этот процесс сломан, как у большинства компаний, когда прохождение собеседование говорит лишь об умении проходить собеседования )))
Собеседования в их массовом виде это безтолковый дегенеративный каргокультный караван булшита, где тратиться много времени и размывается ответственность, а в итоге всё равно нанимается кто попало, кто зачастую даже физически не способен выполнять работу.
при нормальном процессе - просто невозможно. Собеседовался я тут на днях, так сказать для поддержания формы. Позиция Senior DevOps.
Само собеседование проходило не в типичном формате - вопрос/ответ, а обсуждался один большой проект. Если в 2х словах, то вводные данные такие - к нам приходит клиент и говорит, что хочет HA архитектуру в AWS с условием возможности прохождения аудита PCI DSS. И как говорится - поехали, опишите что и как вы будете делать, для чего использовать какие сервисы, что и как настраивать и интегрировать и т.д. и т.п.
Ну, например, когда начинаешь описывать сеть, то идут уточняющие вопросы по сетям - vpc, subnets, routing, security groups, IAM, nat gateway и вот это вот все. Как только мы подходим к теме - а как же все это разворачивать будем, а будем через terraform, то идет более глубокое обсуждение tf. Когда переходим к деплою приложения, задаются вопросы специфические для EKS и все что с ним связанно. В каждом топике были и вопросы со * так сказать, я бы сказал что они скорее оторваны от реальности ну или ты если и столкнешься с таким, то 1 раз за всю жизнь, но скорее показывают твой кругозор и способ нестандартного мышления.
Если ты не работал с этим или где то слышал краем уха, то в жизни ты не пройдешь. А это лишь 1й этап. Всего их 3 - 2 технических и 1 поговорить по душам с CEO
Лично мне такой формат очень зашел, намного лучше, отдельно оторванных вопросов по каждой из тем
Собеседования же это способ показать, насколько вы в среднем хороши для работы
Вообще и не близко.
Собеседования - это способ показать, насколько вы в среднем хороши в вопросе прохождения собеседований. Инфа 100 процентов. Говорю как человек, которому многократно приходилось быть с другой стороны процесса.
Собеседования в их массовом виде это безтолковый дегенеративный каргокультный караван булшита, где тратиться много времени и размывается ответственность, а в итоге всё равно нанимается кто попало, кто зачастую даже физически не способен выполнять работу. Да-да, я не опечатался, мне лично и косвенно знакомы примеры где после 5+ раундов собеседований на работу разработчиками нанимали в итоге людей, которые банально компьютерно неграмотны, не то чтобы они умели разрабатывать что-то. И это происходило не один и не два раза, и это происходило в разных компаниях, в разных странах, поэтому на проблемы конкретного места не свалишь всё.
И да, дело касается не только разработчиков к слову, другие специалисты имеют похожие проблемы.
К слову, я вполне пониманию почему всё в таком виде существует, и понимаю почему это воспроизводиться — причин там не одна и не две, но это не значит что это что-то хорошее или даже нормальное. Серебрянной пули как универсальной альтернативы, к сожалению, нет потому что слишком много факторов бьют по казалось бы адекватным способам решениям проблемы.
Вообще и не близко.
А есть какие-то альтернативы которые могут это показать лучше?
По моему опыту, лучше всего работает просто поболтать с соискателем про его опыт, над какими проектами он работал, что проиходилось делать в рамках тех проектов, какие были головянки и т.д. и т.п.
И в идеале ещё щепотку тестового задания в живом режиме, ничего серьезного, никаких там алгоритмов, никакой бумаги и т.д. Условно может ли человек например форму отправить с помощью JavaScript или там вставить данные в БД с помощью PHP и т.д. Но это тоже неидеально, ибо многие волнуются и тупо начинают тупиь на простой задаче, хотя потом когда их наняли нормально работают без проблем.
Но ведь это и так делают обычно. По крайней мере в бигтехе алгоритмические задачи это от силы 15% времени, остальное это ровно то, что вы описываете (в небольшие фирмы не собеседовался уже лет 10, так что мое "обычно" это с учетом данного факта). Алгоритмы это обычно 1-2 раунда из 10, просто дополнительный фильтр и алгоритмы там на уровне "вернуть максимальный элемент связного списка" что можно сделать без вообще какой-либо алгоритмической подготовки, просто надо знать что такое связный список, а это и так по хорошему надо знать как и все основные структуры данных которые скорее всего есть в стандартных библиотеках вашего языка.
По моему опыту, лучше всего работает просто поболтать с соискателем про его опыт
15-20 лет назад так и делали. Но тогда в индустрию не приходило случайных людей - и средненький джун после универа имел квалификацию выше, чем сейчас имеют в среднем сеньоры.
Но рынок изменился, и теперь проще сразу попросить человека развернуть бинарное дерево, убедиться, что он профнепригоден, и не продолжать этот цирк с конями.
И в идеале ещё щепотку тестового задания в живом режиме, ничего серьезного, никаких там алгоритмов, никакой бумаги и т.д. Условно может ли человек например форму отправить с помощью JavaScript или там вставить данные в БД с помощью PHP и т.д.
Подобные умения как раз скорее минус для кандидата чем плюс, обычно. Если человек помнит всякие ненужные в реальной работе вещи вроде апи, то, значит, он не помнит что-то другое - нужное. В силу ограниченности ресурсов.
То, значит, он не помнит что-то другое - нужное. Но мы не знаем, что нужно помнить, а вот если бы мы знали, что нужно, то не задавали бы вопросов про ненужное, но мы не знаем... Что... Что?
и средненький джун после универа имел квалификацию выше, чем сейчас имеют в среднем сеньоры
И трава была зеленее, и небо голубее
Трава с небом, может, цвет и не поменяла, а вот рынок труда в ит-индустрии поменялся кардинально - и это объективный факт.
Средний джун того времени - это человек, который с детства увлекался ИТ, еще в школе мог на нескольких языках инвертировать бинарное дерево (или уж на первом курсе универа, максимум) и к своей первой работе имел уже опыт программирования под 10 лет (при чем реальный опыт решения сложных инженерных задач, а не перекладывания жсонов), в комбе с глубокими и обширными фундаментальными знаниями. Ну и навыками из разряда быстро поднять ламп (с нуля, руками, без всяких докеров, ессно) и накидать самостоятельно какой-нибудь интернет-магазинчик. Причем это был результат именно фултайм обучения, которое приходилось на самый эффективный в плане восприятия мозгом этап жизни.
Теперь же, в 2024, у нас джун это условный 30+ человек после курсов - ну просто физически, чтобы достичь уровня джуна выше и хоть как-то на равных с ним конкурировать, ему придется потратить не менее 10-15 лет. И это при условии что будет эти 10-15 лет мотивация серьезно вжобывать. Попроси у такого современного "фронтенд сениора" написать гц или там на хаскеле типами пообмазываться - это же будет комедия.
ЗЫ: и да, вот люди с такими по современным меркам безумными и невозможными навыками тогда могли рассчитывать зачастую не более чем на стажировку за еду. Это к вопросу о том как сейчас сложно устроиться.
15-20 лет назад
и навыками из разряда быстро поднять ламп (с нуля, руками, без всяких докеров, ессно) и накидать самостоятельно какой-нибудь интернет-магазинчик
Пусть меня поправят более сведущие в вопросе люди, но 20 лет назад накиданный самостоятельно сайтик представлял собою набранный в блокноте спагетти-код из HTML с PHP. Никаких Angular, React, и прочих Vue там в помине ещё не существовало (раз мы о PHP вспомнили, то Laravel появился только лет 10 назад, ЕМНИП). Равно как не было адаптивной вёрстки под десктопы и мобилы, двухфакторных авторизаций, и прочего, и прочего, и прочего. Полстраны вообще сидело на тормознутом диалапе или помегабайтных тарифах, с отключенными в браузере картинками и скриптами.
Поэтому:
Теперь же, в 2024, ... , чтобы достичь уровня джуна выше и хоть как-то на равных с ним конкурировать, ему придется потратить не менее 10-15 лет.
не потому что люди другие, а потому что объём требуемых знаний увеличился на порядок (если не на порядки). Сейчас никого не удивить тем, что я подключил к компу принтер и наваял прогу, которая печатает на этом принтере товарные накладные из данных, вбитых оператором в поля ввода, параллельно сохраняя эти данные в файлик в формате CSV. 20 лет назад, в 2004, это была серьёзная заявка на успех.
.человек, который с детства увлекался ИТ, еще в школе мог на нескольких языках инвертировать бинарное дерево
В детские увлечения двоичные деревья обычно не входят. Что-то накодить, вывести какую-то надпись, взломать ресурсы в любимой игрушке - это да. А вертеть деревья, ну я с трудом представляю, ИМХО.
и да, вот люди с такими по современным меркам безумными и невозможными навыками тогда могли рассчитывать зачастую не более чем на стажировку за еду.
Ну тоже такое себе утверждение. "Тыжкомпьютерщиков" было довольно мало, толковых ещё меньше, и платили им вполне прилично. Естественно, на фоне других обычных профессий и по меркам тогдашней разрухи и уныния, о тысячах долларов речь не идёт. По нынешним меркам это может быть и "за еду", но тогда это так не воспринималось.
и платили им вполне прилично
Вот что предлагали программисту в регионе в те времена.
Ну, давайте по пунктам.
1. Всё относительно. 16 т.р. в 2011 году это $530. На сегодняшний день медианная зарплата в РФ порядка 60 т.р., или примерно $600, а джунам предлагают по 30-40 тыс.
2. Судить по отдельному скриншоту какой-то непонятной переписки обо всей стране в целом – такое себе. Что это за вакансия, что за программист, кто предлагал, сколько предлагали другим – непонятно. Например лично я зарабатывал в 2011 году намного больше, будучи, по сути, обычным эникеем. И тоже в регионе.
3. The last but not least. 2011 был не 20 лет назад, и жизнь в 2011 очень сильно отличалась от 2004.
Тут говорили про 15-20 лет назад, то есть про 2004-2009 гг., поэтому я решила, что 2011 год тоже близок к статистике. Это, кстати, максимальная зарплата, которую мне предлагали в те годы.
16 т.р. в 2011 году это $530. На сегодняшний день медианная зарплата в РФ порядка 60 т.р., или примерно $600, а джунам предлагают по 30-40 тыс.
Но мы-то о разработчиках говорим, а не о медианной зарплате!
мы-то о разработчиках говорим
Мы говорим не о разработчиках вообще, а о человеке, который в школе увлекался IT и только закончил универ, я процитирую коммент, на который отвечал:
Средний джун того времени - это человек, который с детства увлекался ИТ
И мой оппонент утверждает, что люди с
такими ... навыками тогда могли рассчитывать зачастую не более чем на стажировку за еду
Утверждать, что медианная зарплата = работа за еду, политически неблагонадёжно. В любом случае, всё познаётся в сравнении. Слесарь на заводе получал не больше.
Теперь вернемся к 2011 году.
максимальная зарплата, которую мне предлагали в те годы
Право слово, я не знаю, кто вам такие зарплаты предлагал, почему, и где. У вас на скрине осень 11го года. Весной 12го я купил первую в своей жизни новую иномарку в автосалоне. У меня платёж за автокредит был то ли 12, то ли 14.
Люди, которые считались "на неплохом месте", зарабатывали около $1000, т.е. в районе 30 в рублях. Были ещё популярны шутки про менеджера на кредитном форд-фокусе с пресловутой "штукой баксов" зарплаты. Это был такой средне-стандартный уровень, которого, конечно, нужно было достичь, но достигался он без какого-то сверхчеловеческого труда.
Повторюсь, я был эникеем, даже не разработчиком. Лично у меня выходило в среднем где-то до 25, это основная работа + доп. заработок вида зайти настроить модем/подключить принтер.пеерустановить винду. Да, в нашей стране были недолгие времена, когда эникей мог позволить себе купить новую машину. У разработчиков были з/п от $1000 примерно. У хороших разработчиков в хороших местах могло быть и $2000, и больше.
Вам, видимо, повезло) Или вы в Москве тогда находились?
Мне предложений с такими окладами в те годы не поступало. Обычно предлагали чуть больше, чем ставка доцента в вузе. Этим фактом я пытаюсь подтвердить основной посыл данной ветки комментариев о том, что раньше у разработчиков не было баснословных зарплат, а были обычные.
я пытаюсь подтвердить ... что раньше у разработчиков не было баснословных зарплат, а были обычные.
Позвольте возразить. Это как раз я пытаюсь подтвердить, что зарплаты были обычные. Мой оппонент пытается доказать, что джуны после универа работали за еду в лучшем случае, и вы ему вторите с какими-то фантастическими 16 т.р. У меня коллега в те годы работал техником в поликлинике после ВУЗа (да, этот тот самый чел, который картриджи по кабинетам носит) – у него примерно вот такая з/п была.
В конце концов, у нас есть интернет, и в нём есть архивы. Просто беглым поиском нашёл вот, например, хедхантер даёт такую картинку для сисадминов на январь 2011 по отраслям (формально и я был сисадмином, хотя по выполняемым задачам и уровню навыков скромно называю себя эникеем – как видите, по меркам сисадминов мне ещё и недоплачивали):
А вот например статья на CNews, правда на 2013 год. Но тут уже разработчики и цифры фигурируют 100+ Сходу более раннего не нашёл у них. Ну и так далее.
повезло) Или вы в Москве тогда находились?
Нет, это регион. Нет, я не считаю, что мне повезло. Это была совершенно рядовая ситуация, и вокруг была куча народу, которые зарабатывали куда больше. Разработчики – одни из этих людей.
Я не пытаюсь вас уличить во лжи или там ещё что. Просто не нужно свой, возможно неудачный, опыт выдавать за правило. Я и сейчас могу найти вакансии вроде такой:
Но это не повод утверждать, что во всей России все программисты работают за еду. Или пишут на Паскале.
Если уж речь зашла о техниках, то я вспомнила одну свою знакомую, которая получала в 2011 году 16 тыс. в месяц. Это руководительница отдела в областной научной библиотеке с огромным стажем. Но это исключение. Другая знакомая работала почтовым оператором, получала в 2008 году 4 тысячи, столько же, сколько и я за 1,1 ставки ассистента преподавателя.
Чуть больше чем ставка доцента для джуна — это ОЧЕНЬ неплохо. Доцент — это как правило от 10 лет стажа и защищенная кандидатская.
Я имела в виду, что в обоих случаях зарплата копеечная. Недавно на собесе назвала свою зарплату доцента в вузе, и собеседующий недоуменно спросил: "А на что же вы жили?") Сейчас, думаю, доцент в моем вузе получает за полную ставку тысяч 25 (но это времени на науку не будет вообще, так что я старалась полную ставку не брать).
Пусть меня поправят более сведущие в вопросе люди, но 20 лет назад накиданный самостоятельно сайтик представлял собою набранный в блокноте спагетти-код из HTML с PHP
20 лет фреймворков ещё особо не было, а вот технологии на которых они работают, по большей части уже были. Так что к спагетти коду можно легко добавить PERL (классика), MySQL (если хотелось много структурированных данных), JavaScript (если надо было красиво), ActrionScript (если хотелось флеша) и кучу всяких других вещей типа xml+xslt (который тогда работал через пень колоду).
а потому что объём требуемых знаний увеличился на порядок (если не на порядки). Сейчас никого не удивить тем, что я подключил к компу принтер и наваял прогу, которая печатает на этом принтере товарные накладные из данных, вбитых оператором в поля ввода, параллельно сохраняя эти данные в файлик в формате CSV. 20 лет назад, в 2004, это была серьёзная заявка на успех
Увеличился? Угу. Было дело. Перед печатью файлик ещё растеризовать надо было. Руками. И печатать напрямую кидая принтеру сырые данные, предварительно его настроив и контролируя работу. Не 2004, правда, чуть пораньше. Что там сейчас надо для этого сделать?
В детские увлечения двоичные деревья обычно не входят. Что-то накодить, вывести какую-то надпись, взломать ресурсы в любимой игрушке - это да. А вертеть деревья, ну я с трудом представляю, ИМХО.
Детство оно такое, разное. Сначала ты лохматишь ресурсы, потом хочешь свою игрушку. А вот тут и деревья вырастают, и много другой странной фигни.
PERL (классика), MySQL (если хотелось много структурированных данных), JavaScript (если надо было красиво), ActrionScript (если хотелось флеша) и кучу всяких других вещей типа xml+xslt
Простите, мы точно продолжаем говорите о человеке, который в школе увлекался IT и только закончил универ? Или о профессиональном fullstack-разработчике?
Перед печатью файлик ещё растеризовать надо было. Руками. И печатать напрямую кидая принтеру сырые данные, предварительно его настроив и контролируя работу.
Я, на секунду, напомню, что в 2004 уже не то что Windows 98, а очень даже Windows XP существовала. И печатались документы без вот этих всех плясок кучей всяких разных способов. Чтобы не растеризовать тексты и не рисовать поля вручную, правильные парни использовали генераторы отчётов. Ребята попроще писали <table><tr><td> ... в текстовый файлик и открывали его встроенным в ОСь Internet Explorer`ом.
Что там сейчас надо для этого сделать?
Ровно то же самое, взять какой-нибудь FastReports и выводить на принер свои накладные с отчетами (компонент для Deplhi у них, кстати, до сих пор предлагается). Только сейчас голая формочка с квадратными кнопками уже никого не устраивает, и выводом накладной на принтер уже директора не удивить.
Простите, мы точно продолжаем говорите о человеке, который в школе увлекался IT и только закончил универ? Или о профессиональном fullstack-разработчике?
Да не, мы просто о школьнике. Этим всем баловался ещё в технаре. Не на айтишной специальности.
Я, на секунду, напомню, что в 2004 уже не то что Windows 98, а очень даже Windows XP существовала.
В конце 90х у меня в технаре ещё в наличии были Искры с 5" дисководами. Вроде даже как-то использовались. Мышки там ещё прикольные были, кирпич на проводе и ход кнопок как у педали автомобиля. 486 с 3.11 были самый топ. В основном 386 с DOS Shell или голым DOS. В начале 2000-х у нас, как будущих инженеров, были курсы AUTOCAD. Ещё под DOS который. Всё управление только командами через консоль. 3DS тоже был зачем-то (3D Studio потом стал), тоже досовый. Но у некоторых богатых Буратино были и Пентиумы с вындой, да.
Только сейчас голая формочка с квадратными кнопками уже никого не устраивает, и выводом накладной на принтер уже директора не удивить
Да-да. А потом смотришь на эту "формочку" и думаешь, кому бы её одеть на голову. Потому, что красивая она ровно до того момента, как у тебе не появляется необходимость ей воспользоваться. В плане удобства и простоты вариант с табличками пока, чаще всего, выигрывает.
Я не совсем понимаю, в какую сторону вы клоните, честно. Я говорю, что в условном 2004 въехать во многие технологии было куда проще в силу того, что эти технологии не успели разрастить до нынешнего состояния. Да, были свои нюансы, но тупо справочник был меньше, ман короче, стек уже, и, самое главное, ожидания от результата – сайта или проги – были гораздо ниже, чем сейчас.
Но вы мне возражаете, что всё уже было сложно, потому что было интерактивненько и с ActionScript'ом и прочими MySQLями.
Но и при этом же вы утверждаете, что всё было сложно, потому что шрифт перед печатью растеризовать вручную, Искры с 5" флопами, а винда только у мажоров. Но для кого тогда ActionScript сотоварищи?
Но и при этом же вы пишете, что этим свободно владел простой школьник. То есть несмотря на все Perl, PHP, JS и XML это было вполне доступно для овладевания среднестатистическим школьником? И комп у него позволял, видимо, и СУБД крутить, и скрипты в браузере исполнять, то есть, выходит, не только у мажоров было что-то, отличное от DOSа?
Я, если что, вот последний абзац как раз и не оспариваю, более того, разделяю – но о чём же тогда спорите вы? Или просто возразить лишь бы возразить?
Да-да. А потом смотришь на эту "формочку" и думаешь, кому бы её одеть на голову. Потому, что красивая она ровно до того момента, как у тебе не появляется необходимость ей воспользоваться.
Да, но красивая формочка – продаётся. Сайт, на котором нет тёмной темы и который расползается на смартфоне – по определению считается УГ. И этому всему нужно соответствовать, и на это всё тратить усилия и ресурсы. Вот почему я говорю, что сейчас сложнее. А не потому, что условный vue освоить сложно. Может и просто, дело-то не в нём одном.
Во первых вы сами себя запутали. Поскольку сначала начали про примитивные сайты, а после моего возражения как-то внезапно переключились на школьника.
Во вторых вам ниже уже ответили про сложность. Она стала ниже. Ощутимо. Даже не смотря на более низкие ожидания в те времена.
Но для кого тогда ActionScript сотоварищи?
Вообще там же и было написано, что разброс техники тогда был сильно больше, чем сейчас. Не в разы, на порядки.
Но и при этом же вы пишете, что этим свободно владел простой школьник.
Да, простой школьник. Который на этой самой Искре сам по мануалу и справочнику изучил и ассемблер. Игрушки на ней всё равно не работали, так что пришлось играть по другому. Резиденты писал, в дровах ковырялся. Ничего особо сложного. С вирусами немного игрался. Какое детство, такие и игрушки.
И комп у него позволял, видимо, и СУБД крутить, и скрипты в браузере исполнять,
Вы таки удивитесь, но субд требовали меньше ресурсов, чем тот же ворд. Особенно если тебе поиграться, а не обрабатывать десятки тысяч записей в секунду. А ещё у школьников (ну я тогда уже в технаре был, так что студентов) ещё и бывает семья, которая может его поддержать. Комп (бу первый пень после школьной Искры) скидывались все вплоть до бабушки и собирался он месяца полтора (это с начала сборки, а не собственно начала поисков). А так - пол-года только разбирался, что там где и куда. Тогда с этим (если у тебя нет знакомых в теме) было пипец как сложно. Потом со всех рынков таскал по кусочку. На что хватало денег. Конфиг до сих пор помню. p1 70MGz (потом до 120 разогнал), 16MB, 850Mb винт, s3 trio какая-то самая простая, svga монитор 800*600*16(цветов, не бит) макс (его сложнее всего было найти). А, ещё мышку, почему-то, долго найти не мог. Вынду поставить уже мог, но без мышки это было... своеобразно. Потом друг ещё подарил модем на 2400 и ткнул носом в интернет. Железка до сих пор где-то лежит. Огромный, тяжеленный.
Вот почему я говорю, что сейчас сложнее.
А, если речь о том, что сложно продать, то увы. Народ зажрался слегка. А вот делать стало сильно проще. Сейчас вот этих сайтоклепателей на курсах из домохозяек пилят. Про качество умолчу, однако сам факт такой возможности хорошо говорит о сложности.
после моего возражения как-то внезапно переключились на школьника
Да ладно) Если б вы внимательно следили за дискуссией ,в которой решили поучаствовать, то не могли бы не заметить, что здесь обсуждается вполне конкретно определённый молодой человек (в школе увлекавшийся информационными технологиями, и на момент обсуждения находящийся где-то между выпуском из школы и первым трудоустройством после универа) во вполне конкретно определённом временном промежутке (15-20 лет назад, то бишь 2004-2009 годы).
Она стала ниже. Ощутимо.
Да, простой школьник. ... Какое детство, такие и игрушки.
То есть, сейчас технологии стали ощутимо проще, но и в те былые времена теми сложными технологиями спокойно мог владеть обычный школьник. Нынче же, по всей видимости, дети прям в детсаду пишут вебсайты, на продлёнке, а к окончанию начальной школы имеют в портфолио пет-проект уровня не ниже фейсбука. Ок, понятно, вопросов по этой части более не имеется.
пол-года только разбирался, что там где и куда. Тогда с этим (если у тебя нет знакомых в теме) было пипец как сложно
Блин, ну нет, всё же непонятно. Вот только что всё было просто и доступно школьнику, а теперь опять сложно. Таки что, собрать комп было пипец как сложно, а собрать сайт с Perl, MySQL, JavaScript – пипец как просто? Или написать сайт проще, чем собрать комп? А бинарные деревья на ассемблере сами изобретались, или в этой сфере были знакомые в теме?
разброс техники тогда был сильно больше, чем сейчас. Не в разы, на порядки
Этот разброс находится только в вашем сознании, потому что у вас двадцать лет с середины девяностых по середину десятых каким-то образом слились в единой точке. И в этом чудном винегрете у вас бок-о-бок соседствуют Искры с пятидюймовыми флопами – и ActionScript, ассемблеры и ручной рендеринг шрифтов перед выводом на печать – и СУБД с Wordом, DOS – и интерактивные вебсайты в браузере на винде. Хотя на самом деле это всё очень сильно разнесено во времени, хотя и менялась техника тогда быстрее, чем сейчас.
мышку, почему-то, долго найти не мог
Комп (бу первый пень после школьной Искры) скидывались все вплоть до бабушки
Во-первых, в середине 00х и далее никаких проблем с приобретением мышек не было, рынок был завален дешевой китайской продукцией а-ля Genius, Gembird, Trust, Defender и иже с ними.
Во-вторых, даже в занюханном райцентре на 70 тыс. жителей, неподалёку от которого я имел неудовольствие проживать, в означенный период времени находилось как минимум четыре компьютерных магазинчика. А в областном центре так даже специализированный салон-магазин Apple был. А в киосках спокойно продавались Chip, Железо, Xakep. А в книжном магазине можно было взять Фигурнова занедорого. С чем там было пол-года разбираться, особенно для человека, как нефиг делать пилящего сайты с СУБД, и вертящего бинарные деревья на Искре, я решительно не понимаю.
Pentium 1 – это начало девяностых. А в означенный период времени на коне был P-IV. В 2005-м вообще Pentium D появились уже с двумя ядрами. И в то время как такое топовое железо было непозволительно дорогим, что-то подержанное из предыдущих поколений, вроде AMD Duron 700, бюджетная материнка на VIA KT133 с парой гигов HDD и 14" ЭЛТ можно было взять за вполне вменяемые деньги в окрестностях $150. На 2004й год это было примерно одна средняя зарплата, на 2007й - примерно пятая часть средней зарплаты. Да, доходы населения тогда росли как на дрожжах.
Но да, девяностые закончились совсем недавно, компьютеры ещё были далеко не везде. Они уже были доступны, но в бизнес-процессах ещё не вездесущи. Многие предприятия, особенно мелкие, продолжали работать по-старинке, заполняя различные формуляры от руки, и не было у них ни веб-сайтов, ни электронной почты, ни постоянного доступа в инет. Да что там предприятия, у меня паспорт был от руки заполнен. Хотя компьютеры в паспортном столе вроде как уж были.
И именно вот этот эффект низкой базы и внезапно возникшего спроса обуславливал простоту и вхождения в профессию, и нахождения в ней. Когда компьютеры появились только вчера, и небольшое местное предприятие захотело себе сайт, а за ним второе и третье. Ну и что, что там заголовки где-то чуть съехали и расстояние между кнопками где-то чуть пляшет. Да даже гиганты вроде Рамблера/Яндекса/Мейла порой грешили таким на своих сайтах.
Это сейчас, если ты не делаешь pixel-perfect макет любой степени вычурности – ты криворукий идиот и место тебе на помойке. Тогда на такие мелочи внимание мало кто обращал. И исполнителей, тех же сайтописателей, эникееев, да хоть даже заправщиков картриджей – их было ещё не так много, а спрос на них постоянно рос. Это не был такой конкурентный рынок, как сейчас. Вот об этом я говорю, говоря о простоте.
Сейчас вот этих сайтоклепателей на курсах из домохозяек пилят.
Курсы были и тогда, и сайтоклепателей пилили тоже. Просто сейчас это из каждого утюга пиарят.
, то бишь 2004-2009 годы)
Я уже упоминал, что мой опыт чуть раньше. Конец 90х - начало 2к
Нынче же, по всей видимости, дети прям в детсаду пишут вебсайты, на продлёнке
Нынче это не модно. Модно тапать хомяка и мечтать быть блоггером. А ещё есть ютуб, тикток и огромное количество игрушек, которых в моё время не было. Ну т.ё. были у людей побогаче и приставки, и компы. Но не всем так везло. У меня был только та самая Искра.
дешевой китайской продукцией а-ля Genius, Gembird, Trust, Defender и иже с ними
Вы зря проигнорировали прошлый абзац. С моей степендии тогда можно было только мороженку съесть. Родители (инженер и КН) торговали на рынке, поскольку в 90е стали как специалисты никому не нужны. Пробовали когда-нибудь серый хлеб? Я вот им питался в середине 90х. Так что далеко не все могли себе позволить дорогие игрушки.
Этот разброс находится только в вашем сознании, потому что у вас двадцать лет с середины девяностых по середину десятых каким-то образом слились в единой точке.
У вас тоже точка весьма не точечная. И период я указал. Да, это не один точный год.
Pentium 1 – это начало девяностых. А в означенный период времени на коне был P-IV.
Ну вот следующей машиной после P1 и был P4. На который я заработал сам уже после института. Так что могу только позавидовать вашим возможностям в тот период. Впрочем у меня в институтской группе богатеньких было, пожалуй, большинство.
Это сейчас, если ты не делаешь pixel-perfect макет любой степени вычурности – ты криворукий идиот и место тебе на помойке.
Ага. В те времена было проще. Если ты хотел сайт, который бы хоть примерно выглядел у всех похоже - тебе надо было делать миниму два: для netscape и для ишака. Поскольку у последнего (традиционно для m$) было весьма вольное понимание стандартов. Не застали на сайтах переключатель браузера? А они были. Впрочем отдельные сайты ещё лет 5-7 назад требовали ишака для работы (гос структуры этим грешили из-за доп навески, которая работала только в нём).
Ладно, вашу идею я понял.
но 20 лет назад накиданный самостоятельно сайтик представлял собою набранный в блокноте спагетти-код из HTML с PHP.
И написание этого кода требовало на порядок более высокой квалификации, чем нашлепать формочки на реакте.
и прочего, и прочего, и прочего
Что именно это "прочее, прочее и прочее" то?
Равно как не было адаптивной вёрстки под десктопы и мобилы
Современная верстка с адаптивностью и мобилками просто в разы проще того ада, с которым приходилось работать людям в конце нулевых.
не потому что люди другие, а потому что объём требуемых знаний увеличился на порядок (если не на порядки).
Ну это же очевидная глупость, которая опровергается обыкновенным здравым смыслом. Технологии _всегда и везде_ развиваются в сторону упрощения (= снижения требований к квалификации пользователя), поэтому объем требуемых знаний неуклонно снижается. Если кто-то придумает более сложные, чем уже есть, методы/инструменты/подходы разработки - то их просто не станут использовать. А то, что в итоге используют - оно всегда проще. Написать интернет-магазин в 2024 намного проще и требует существенно меньшего набора знаний и навыков, чем было в 2014, а в 2014 - было проще, чем в 2004. А в 2004 проще, чем в 1994.
Поэтому если сейчас из криокамеры вылезет программист, который в 2004 туда сел, то он за выходные поскролит доки и с понедельника спокойно выйдет на работу, не имея ни каких проблем. Вы даже не поймете по его работе, что он из 2004. Т.к. он обладает абсолютно всеми навыками и знаниями, необходимыми для эффективной разработки в 2024. Если же современного фреймворк-сениора отправить в 2004 - хорошо если за месяц он сможет поднять сервер, отдающий хелло ворлд. Потому что он не обладает необходимым навыками и знаниями для разработки в 2004. И мануалы курить не умеет - а стековерфлоу в 2004 еще не изобрели.
в 2004, это была серьёзная заявка на успех.
Это даже в 1994 не было заявкой на успех. У вас какое-то странное представление о тех временах, будто тогда по городам телеги с лошадями ездили.
Тогда уже были сложные учетные системы на предприятиях, ввести что-то там куда-то там, которое благодаря автоматизации сделает чего-то там и распечатает что-то там - не было ни каким рокетсаенсом. И сейчас не то чтобы эти системы изменились, каким-то невиданным функционалом не обросли - по итогу они делают то же самое и так же. Их просто стало намного проще и дешевле разрабатывать.
В детские увлечения двоичные деревья обычно не входят.
Если человек изучал язык с ручным управлением памяти (а он изучал почти наверняка), то про списки и бинарные деревья он знает в девяти случаях из десяти. В оставшемся одном случае из десяти он без каких-либо проблем решит задачку, если ему сказать определение бинарного дерева. Там тривиальный алгоритм на несколько строчек.
По нынешним меркам это может быть и "за еду", но тогда это так не воспринималось.
Так и воспринималось. Это сейчас джуны всем нужны и к работодателю дверь с ноги открывают, а тогда "без опыта" было черной меткой. Люди буквально на минималку соглашались идти, чтобы полгодика поработать и получить отметку в трудовой.
В конце концов, у нас есть интернет, и в нём есть архивы. Просто беглым поиском нашёл вот, например, хедхантер даёт такую картинку для сисадминов
Так это же не джуновская зп.
медианная зарплата в РФ порядка 60 т.р., или примерно $600, а джунам предлагают по 30-40 тыс.
Это что за комедия?) Дешевле 100к вы джуна сейчас не найдете, а в целом и на 150+ джуны устраиваются. Я джунов имею ввиду, естественно, а не выпускников курсов, которым до джуна учиться надо 10 лет.
ЗЫ: вот кстати статья с хабра по зп за 2011:
https://habr.com/ru/companies/pruffi/articles/120633/
Что именно это "прочее, прочее и прочее" то?
То, что сначала у нас был HTML. В котором у нас были теги для заголовков, теги для текста, для картинок, гиперссылок, и была таблица с колонками и строками, посредством которой мы всё это не странице располагали. И был CSS, посредством которого мы могли описать правила, как те или иные элементы страницы должны выглядеть. Но нам было скучно, и мы захотели переходы, анимации, градиенты, маски, адаптивность, темную-светлую тему, что увеличило объём работы и раздуло де безобразия файлы CSS. Чтоб как-то с этим справляться, мы придумали SASS и LESS. А чтоб не изобретать велосипед каждый раз, мы придумали Bootstrap CSS, Tailwind CSS, etc.
А ещё нам захотелось интерактивности. Сначала мы рисовали падающие снежинки JavaScript'ом, потом этого стало мало, потом оказалось, что в разных браузерах JS отрабатывает по-разному, и у нас появился JQuery. Потом вещи быстро вышли из-под контроля, и теперь у нас есть React, Angular, Vue, Svelte, Next, Nuxt и ещё 100500 очень_полезного.js, которое возникает чуть ли не каждый месяц, и ещё у нас есть TypeScript, который вроде как JS с типизацией, да не совсем.
И если кто-то думает, что абстрагируется от этого всего, и будет работать только с Angular. Или вообще возьмёт за основу PHP и будет работать только с Laravel или там Cake PHP. То фиг там был, так это не сработает. И это я не говорю о том, что Bootstrap не один, а v3, v4, и v5 – и все используются! И Vue тоже не один, и jQuery всё пророчат смерть, а он до сих пор используется. И под одним скрывается другое, начинаем погружаться в React, там начинает вырисовываться Redux, Vite, и дна этой кроличьей норы не видать вообще.
И это только фронт. Я ещё не касался бэка. А ещё весь это ад нужно как-то оттестировать и собрать воедино. И вообще поддерживаь эти все либы в актуальном состоянии. И тут у нас пошли и NPM, и webpack, и модульное+интеграционное тестирование, и Docker с Kubernetes...
Да, это всё, конечно, очень просто и доступно и ну совсем ни разу не запутанно и не перегружено. Не то, что было раньше. И вы сами повреждаете мой тезис, когда говорите, что среднестатистическому взрослому человеку:
до джуна учиться надо 10 лет
Извините, пилота самолета меньше учат. Врача меньше учат. Но да, это же так просто, ну конечно.
Это сейчас джуны всем нужны и к работодателю дверь с ноги открывают, а тогда "без опыта" было черной меткой.
Дешевле 100к вы джуна сейчас не найдете, а в целом и на 150+ джуны устраиваются
Где мне без опыта открыть с ноги дверь в джуны, дайте контакты? Так уж и быть, 150 не надо, на 100 согласен для начала. На ХХ что-то три с половиной вакансии с зарплатой в 40К и на каждую под тысячу откликов. Дайте контакты, схожу попытаю счастья на собеседование.
И это только фронт. Я ещё не касался бэка.
И все вышеперечисленные технологии резко уменьшили уровень знаний, необходимых для решения проблем. Теперь не надо быть цсс-нинзей, чтобы выровнять один сраный элемент, т.к. благодаря современным фичам все just in works одной строчкой. Не надо курить многотонные мануалы по разворачиванию окружения - достаточно пару раз сделать ctrl+c ctrl-v в терминал и в докере все само поднимется. Не надо изобретать какие-то сложные архитектурные подходы для того чтобы привнести интерактивности в интерфейс - за тебя все сделают фрейморвки.
Современные инструменты разработки в типичных случаях просто берут на себя 90% всех знаний и умений. Достаточно тыкнуть пару кнопок и оно все само заработает. На магии.
Извините, пилота самолета меньше учат. Врача меньше учат. Но да, это же так просто, ну конечно.
Не знаю, что там на счет пилотов, но врача за эти 10 лет вы точно не выучите. Да и за 20. И за 30 - сомнительно. Вы же не забыли, что мы не о фуллтайм обучении в юности, а об обучении взрослого, 30+ вкатуна, которому удается иногда выделять на обучение часик-другой в перерывах между семьей/работой/етц.?
Где мне без опыта открыть с ноги дверь в джуны, дайте контакты?
Да в любой крупной компании. Джуна в принципе сейчас найти практически невозможно, нет их на рынке. Логично, что отсутствие предложения ведет к росту цен.
и на каждую под тысячу откликов
Ну так это не джуны откликаются и не джуновская вакансия.
Про пользователя согласен, но мы говорим не про пользователей.
Именно про пользователей мы и говорим. Разработчик - это пользователь средств разработки. И эти средства становятся проще с каждым годом - не "внутри", а именно для пользователя проще.
Багаж знаний постоянно растёт
Нет, это просто глупая выдумка.
Потому что просто нет таких гениев, чтоб в голове держать всю отрасль на достаточно глубоком уровне.
Ну как нет? Есть. Любой нормальный выпускник хорошего вуза по айти специальности является таковым.
И снова, это не я утверждал, что программисты работали за еду и что з/п программиста была максимум 16 т.р. в 2011.
Так ни кто не утверждал. Речь была о программистах _без опыта_. Именно это ключевой водораздел был в том время. Не имеешь опыта работы - изволь работать за еду первые месяцы, а потом уже можешь трудоустроиться нормально.
У вас какое-то странное представление о тех временах, будто тогда по городам телеги с лошадями ездили.
Тогда уже были сложные учетные системы на предприятиях, ввести что-то там куда-то там, которое благодаря автоматизации сделает чего-то там и распечатает что-то там - не было ни каким рокетсаенсом.
Это не у меня. Это другой комментатор здесь параллельно мне доказывает, что компы с виндой в 2004 были только у невероятных мажоров, а так люди на Искрах сидели с пятидюймовыми флопами.
Я как раз начинал, так сказать, трудовую деятельность в те времена. По-разному было. Где-то и учетные системы, а где-то и от руки накладные выписывали, и счеты деревянные в ящике стола лежали. И про формошлепство на Дельфях я тоже не понаслышке говорю вообще-то.
Технологии _всегда и везде_ развиваются в сторону упрощения (= снижения требований к квалификации пользователя), поэтому объем требуемых знаний неуклонно снижается.
Про пользователя согласен, но мы говорим не про пользователей. Современный автомобиль для пользователя гораздо проще, комфортнее и безопаснее, чем автомобиль 70х годов. Но под капотом это оборачивается невероятно сложным программно-аппаратным комплексом, который в последних версиях уже до внедрения ИИ дошёл. А пользователю да, квалификации минимум, в кресло сел, кнопку нажал, едем. Так и во всём остальном. Багаж знаний постоянно растёт, специализация конкретного человека постоянно сужается. Потому что просто нет таких гениев, чтоб в голове держать всю отрасль на достаточно глубоком уровне. Уже никого не удивляет, что один программист специализируется на вебе, а другой – на микроконтроллерах. И это отнюдь не от лени человеческой.
вот кстати статья с хабра по зп за 2011
Я в курсе про з/п. И снова, это не я утверждал, что программисты работали за еду и что з/п программиста была максимум 16 т.р. в 2011. Я как раз возражал этому.
Подобные умения как раз скорее минус для кандидата чем плюс, обычно.
Ну это сильно завист от того на какую позицию и какого разработчику ищут. Но также важно заметить, что никто не говорит, что от человека ждут феншуйный продакшен код из головый за пять минут. Это скорее что-то среднее между экзаменом по калиграфии тем самым (банально знает ли человек с какой стороны подойти к станку) и проверкой на то, способен ли человек думать, т.е. начнёт ли в правильную сторону ковырять, уточнять что-то, гуглить и т.д. (в том числе это над учитывать чтобы скорректировать проблему волнения и т.д.).
Дело ведь в том, что даже если человек пойдёт нагуглит решение со Stackoverflow и скопипастит с правками под себя, то это уже показатель, что человек не бесполезен. Потому что печальные реалии ситуации в том, что 9 из 10 не осилит задание это, хотя казалось бы что за бред.
Потому что часть это вкатуны с курсов, где их галопом по Европам протянули по азам, без какого-либо понимания что они делают, почему и зачем. В итоге, да, у человека есть гитхаб, там есть пара проектов, правда этих типовых, вроде каталога фильмов на ReactJS, который работает на основе API от IMDB (прямо бич половины курсов, судя по всему), но это ведь не создано с нуля даже: им просто дали репозиторий с заготовкой проекта, показали как склонировать и дописать, повторяя за преподавателем, пару вещей в него. Часто они даже не инициализовыввали пустой новый проект ни разу. Шаг влево, шаг вправо и трагедия.
А вторая часть это профессиональные заговариватели в зубы и выучиватели правильных слов, они вам и про патерны проектирования расскажут, и про всё остальное, вот только в жизни даже примитив уровня Hello World не смогут сами сделать. Да, я серьезно. И таких нанимают, и порой в крупных компаниях они успеют больше года популучать зарплату ничего не делая, пока кто-то не заметит, что что-то не то.
Это не собеседование? Что же это тогда?
Нынешний соискатель категории "вкатывальщик" хитер - у него куча домашних заготовок на предмет
просто поболтать с соискателем про его опыт, над какими проектами он работал, что проиходилось делать в рамках тех проектов, какие были головянки и т.д. и т.п.
Мне кажется такой подход плохо масштабируется. Допустим у вас в компании пара тысяч инженеров и 100 откликов на вакансию. Очевидно вам нужно иметь пул из пары сотен собеседующих и какой-никакой стандартизированный процесс собеседования, чтобы хоть как-то сравнивать кандидатов с разным опытом друг с другом. У каждого собеседующего как минимум должен быть чек-лист с тем, какие навыки или опыт нужно проверять обязательно (многопоточность, оценка сложности операций с базовыми структурами данных из стандартной библиотеки, работа с БД и т.п.).
Нужен процесс онбординга инженеров в собеседущие, метрики эффективности найма (сколько % нанятых отваливается на испытательном сроке например), оценки собеседующих (вдруг кто-то очень часто ставит Hire/No hire без весомых причин). Без измерения эффективности найм превращается в блуждание в темной комнате без источника света.
Так вот, кажется что "просто поболтать" в таких условиях уже не работает, а live coding на первом этапе очень даже да. И речь не о сложных алгоритмических задачах, а просто о возможности писать корректный рабочий код и тесты, которые доказывают его корректность. И тут оказывается, что некоторые сеньоры с 10-15 годами опыта не могут написать даже простейшее потокобезопасное решение или не знают как работает Hash Map.
Самым офигенным в жизни собеседованием было: датская компания прислала фрагмент кода на неизвестном ранее языке и сказала - пойми, что здесь, перепиши на любой знакомый тебе язык/фреймворк, потом расскажешь, что это и зачем, вот дедлайн.
Это собеседование было бы лучше и интереснее чем 90% других, что я проходил
Язык, разработанный самой этой компанией?
Какой-то DSL, возможно и собственный -- компания старая, раньше модно было велосипеды костылить. Главное, оно было почти вменяемо документировано.
Понятно. Когда-то пыталась писать для датчан на языке, который они написали. Он назывался flow. Из документации была только статья страниц на двадцать.
если хочется вспомнить https://github.com/area9innovation/flow9
Круче было бы дать код на неизвестном языке и попросить на том же языке чуть-чуть допилить какую-нибудь фичу ;-)
У меня это была реальная задача на реальной работе :-)
Не помню кто это сказал: "Работники делятся на два типа, на тех кто умеет проходить собеседования и на тех кто умеет работать."
согласно этой логике "те, кто умеет работать", никогда не будут наняты на работу?)
Вся жизнь рандом. Когда-нибудь случайно будут наняты
Это когда-нибудь случается, когда *внезапно* выясняется, что нужны были не олимпиадники, а проблем-солверы. Ирония в том, что все эти методологии разработки создавались чтобы подальше уйти от высокопарщины бюрократии, раздувающей сроки разработки бизнес продукта, но по-видимому, проблема лебедя, рака и щуки не одномерна (тоже внезапно) и решится только когда ещё один умник выпустит книжку на миллионный тираж донося новые-старые очевидности до менеджмента, о которых говорили разработчики десятилетиями.
Порой куда-то можно попасть просто по связям. И собес может быть просто формальным. При этом человек может хорошо работать.
Либо опять же может быть какой-нибудь стартап, например первого разраба или тестировщика или другого спеца врядли кто-то собесит
Мы собеседовали одного будущего коллегу, и я его не взял, поскольку посчитал, что у него нет некоторого специфичпспого опыта, его взяли в соседнюю команду. Потом мы несколько лет работали параллельно над общей задачей, и я узнал, что он был лидом проекта с нужной изначально спецификой. Я спрашиваю - а что же ты на собеседовании про это не сказал? Ему казалось, что проект был неинтересный и неважный для собеседования)
Как говорилось выше, разработчики не так часто сталкиваются с задачами по структурам данных и алгоритмам, чтобы запомнить их.
Тут штука вот в чем, если Вы в каком-то виде изучали курс Алгоритмы и структуры данных, то на техническом собеседовании (не кодиннг сессии) вы ответите, но и с другой стороны если Вас вдруг неожиданно попросят реализовать алгоритм сортировки например вставкой, то скорее всего интервьювер сам нихрена про алгоритмы и не знает, иначе придумал бы более жизненный вопрос.
Вроде собеседования в стиле leetcode содержат в ТЗ необходимую теорию, а не просто "реализовать %известный алгоритм%". Одно дело не знать какой-то алгоритм, и совсем другое - не суметь реализовать этот алгоритм по описанию.
В любом случае, отношение к подобного рода техническим собесам спорное и сам такие задачи не даю, у нас техническое собеседование сводится максимум к упомянутой просьбе верхнеуровнево порассуждать, как кандидат будет решать реальную задачу, взятую из практики.
может и хорошо когда кандидат не знает алгоритм, вот когда интервьюер объяснил суть сортировки вставкой и попросил реализовать - это уже что-то проверяет
Увы, но идеального метода оценки кандидатов не существует. А оценивать как-то нужно.
Поэтому используют то, что есть.
Не существует идеала, но можно делать лучше. В исходном описании задачи FizzBuzz для собеседований подчёркивается, что её суть не в
Кандидатам даётся функциональная задача, и они должны выработать идеальное решение.
а в том чтобы человек произвёл на свет хоть какое-нибудь решение. (Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения.)
Затем, задачи должны быть неожиданными. В частности, даже для HR выглядит несложным попросить программистов компании написать три-четыре элементарных задачи с нуля вместо извлечения их из базы. Это заведомо уберёт проблему
Как насчёт разницы между кандидатами, уже встречавшими эту задачу викторины, и теми, кто ещё её не встречал?
Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения
Не знаю, пробовал недавно решать задачи на LeetCode, и алгоритмы с асимптотикой хуже оптимальной почти всегда проваливают тест. Прокатывало только с easy-задачами, где изначально требовалось что-то простое. Ну и еще в конце показываеся рейтиг решений по времени исполнения, что мотивирует переписывать решение по нескольку раз, чтобы попасть в самый топ.
Желание получить 99/100% времени и что-нибудь хорошее по памяти понятно, но не должно быть частью использования LeetCode как инструмента отбора кандидатов. Если вас мало интересует оптимизация - потому что интересует мало и нефиг отбирать людей по тому что вас интересует мало, если вас сильно интересует оптимизация - потому что нормальная оптимизация делается профилировщиком, а не на глаз. Опять же, результаты LeetCode не отличаются хорошей повторяемостью, особенно по памяти.
Идеальный метод это попросить человека рассказать о своей работе в последние три-пять лет. Если он не может вспомнить, не рассказывает как тяжело ему было, не говорит о каких-то "случаях" на работе или делает все это слишком ярко, значит он только занимал место. А дальше нужно сделать вывод основываясь на ощущениях, а не показателях в бумажке.
По сути только так и прохожу все собесы, т.к. будущий начальник сразу понимает что я за человек.
Но и да, еще сделал вывод что не стоит мотаться по сотне собесов, лучше выбирать именно места где сможешь и чувствуешь заранее что приятно будет работать.
записывает звиздеть красиво, но не слишком.
попросить человека рассказать о своей работе в последние три-пять лет. Если он не может вспомнить, не рассказывает как тяжело ему было, не говорит о каких-то "случаях" на работе
Я не пройду ваш собес. И не потому что я не работал или не сталкивался с проблемами в работе. А потому что это рутина - поставили задачу, сделал, некст. Если возникли проблемы, разобрался, сделал, некст.
А потом меня спрашивают на собесе, ну назовите самую интересную проблему что приходилось решать.... да х его з, мой ответ, всякое бывало
если вы годами, именно годами работали на рутине, ничего не меняя - то собственно чего и удивляться отказам в места, где нужна инициатива и скиллы. Вам надо в новое рутинное место, там таких вопросов про хайлайты, наверное, и задавать не будут
Так то, что для одного хайлайт, для другого может быть вполне себе рутиной.
первые пару лет везде будут хайлайты, но я ж и предлагаю мерять относительно - если за N лет кому-то нечего рассказать о работе, делал одно и то же - это полюбому хайлайт.
А так жена когда-то первый раз устроилась бушкой, первые полгода и в бухучете было интересно, но потом ужаснулась что всю оставшуюся жизнь нужно будет заниматься одним и тем же и убежала
Да, согласен именно так и нужно, рассказ об опыте покажет, умеет ли человек работать, как он умеет работать может показать только сама работа на вас. А джунов только по наличию диплома, что как минимум подтверждает способность учиться. Но не на рынке, где переизбыток кандидатов, как сейчас (несмотря на все заявления гос. людей о нехватке кадров). Когда из множества подходящих кандидатов нужно вбрать одного, самый дешевый вариант - рэндом, но так как это, вроде бы, антинаучно и не солидно, будут кандидатов бесконечно фильтровать на разных этапах, пока не останется один.
Собствоенно, отсюда и этот вой о якобы "дефиците специалистов". Специалистов на сегодняшнем рынке на самом деле предостаточно. Просто собесы так устроены, что нанять с них можно кого угодно (читеров, зубрилок, мягкоскилловых балбесов), но только не реальных спецов!
А как провести идеальный собес? Не поделитесь опытом?
Я поделюсь - просто покажите свой код (который сами в команде пишете) и попросите соискателя его отревьювить.
Человек способный понимать, оценивать и схватывать - поймёт что написано и будет соответствовать уровню тех, кто его нанимает. А при большом количестве замечаний, ещё и будет понятно насколько он их превосходит.
Вот только ведь это палка о двух концах :) Ведь нанимаемый сразу поймёт, с кем он будет работать. А не сообразит это после выхода на работу на третий день.
Это возможно только для очень простых задач с простым контекстом.
Так этот кусок кода для ревью сольют в сеть, и последующие кандидаты будут знать о чём их спросят. Я это к тому, что такие задачи не очень разнообразны, их легко обойти.
В этом плане даже литкод выглядит надежнее, потому что всегда можно подобрать для очередного кандидата новую задачку на алгоритмы и структуры данных + задачку на SQL
Кусок кода для ревью можно брать с последнего рабочего ревью, хоть каждый день обновляй
Тогда нельзя сравнивать нескольких кандидатов. Вдруг кусок кода был идеален? Например, наконец то можно удалить эту ужасную ручку и 100500 строк про неё.
Тогда нельзя сравнивать нескольких кандидатов.
А зачем вам сравнивать несколько кандидатов? Вам нужен первый кто, по-видимому, будет справляться с поставленными задачами.
А с перфекционизмом лучше обращаться к психотерапеву.
Это бессмысленная трата времени и остальных ресурсов на поиск "идеального" кандидата. Всех факторов вы всё равно не учтёте. Кажется найдёте такого, а потом окажется что ему у вас неинтересно и свалит он через 3 месяца, например.
Ну и что там такого можно найти, в ежедневном рабочем ревью, 1-2 придирки к код стайлу?
Всё таки для подобных задач обычно выбирают сложные случаи, где можно много всего исправить. Но таких кусков кода немного, готовить их сложно, варианты решения довольно однообразны... Поэтому такие задачи быстро расходятся и повторять на очередном кандидате не имеет смысла.
Кусок кода с ревью надо будет куда то вырезать и класть, чтобы кандидат не видел уже написанные комментарии из Гита.
А вынося куда то во вне, бывает нужно попрыгать по коду и другим исходникам, чтобы понять о чём идёт речь, принято ли так вообще писать код в команде, какие типы это все передается, написаны ли тесты (и пишет ли их вообще команда?). Короче столько вопросов, которые нужно заранее знать и быть примерно погруженным, прежде чем начинать ревьюевить). Одни ответы будут крутыми, которые надо взять самим на заметку, а другие ответы - дикими (как? Вы не пишете тесты!?).
В этом плане даже литкод выглядит надежнее
поигрался в песочнице этого вашего литкода и скажу, что:
крутится он в докере на Ubuntu-22.04.1
на двух ядрах Xeon CPU @ 2.20GHz
с 8 гигами оперативки
под пользователем ubuntu
берёте ?
Такая штука работает только при найме специалистов лоу-синьер и ниже уровня. С вероятностью почти 100% кандидат начнет делать упор во всякие паттерны, что при неаккуратном выборе кода (если у вас хайлоад, бигдата итд) создаст возможно ложное негативное впечатление.
Люди дают то, что часто спрашивают, это вы на ревью и получите, а по факту требования в компании могут быть вроде "мне не нужен ваш солид, сделай так, чтобы оно нагрузку держало"
И вы опять отберете устойчивых к стрессу собеседования. У меня например, на подобных код ревью буквы сливаются и я вообще не могу понять кода. А на работе читаю код по диагонали. Сам провел много собесов, ощущение что у половины та же реакция что у меня.
Как вывести человека из этого психологического ступора, чтобы он раскрылся х.з. Некоторые умеют, у меня пока не получалось ни вывести ни самому выйти.
Нет. На работе вы не читаете код, т.к. полагаетесь на долговременную память. А в ситуации когда перед вами незнакомый код, надо начинать его изучать и решать проблемы:
1. Что он делает.
2. Зачем он нужен.
3. Почему он так написан.
4. Как его изменить и улучшить.
Это не психологический ступор, это режим изучения неизвестного и время от времени без отправных шаблонов, т.к. вокруг все настоящие творцы, шок тем больше, чем хуже и нестандартнее код.
Вы ищите коллегу, который будет полгода погружаться в ваши отвратительные решения и адаптировать свои стандарты работы к вашим. Благодаря его поведению вы поймете кто перед вами. И стресс от чтения кода "коллег" в первый рабочий месяц, лично у меня куда сильнее, чем "провал" на очередном собеседовании.
Про достаточное количество специалистов.
По некоторым направлениям в ИБИТь в том числе разработке ПО специалистов с нужными и определенными навыками и знаниями несколько человек на всю страну если не мир и этих людей знает вся страна. Например толковых специалистов кто грамотно и красиво может развешивать лапшу о том как космические корабли бороздят просторы Большого театра (в ИТ) примерно штук 20, в числах могу соврать, но таких людей точно очень мало, и три четверти из них поделена между "мастодонтами рынка".
Когда я собеседовал разработчиков / аналитиков / QA - в итоге пришел в части проверки навыков к очень простому тесту: произвольная (из нужной части) задача из древней книги The IBM Programmer's Challenge: 50 Challenging Problems to Test Your Programming Skills With Solutions in Basic, Pascal and C (см. например на Amazon или https://books.google.com/books/about/The_IBM_Programmer_s_Challenge.html?id=Ic1CAAAACAAJ).
Языки, конечно, менялись. Страницу книги мог рандомно выбрать кандидат.
Подбиралась так, чтобы уложиться в полчаса, максимум час. Без компьютера, карандашом на бумаге. При выходе за лимит времени оценивалось то, что есть.
Для аналитика - производная задача как сформулировать требования, для QA - как проверить результат.
Так сразу проверялось и понимание задачи, и готовые навыки структурировать решение, и "на память" ЯП, и английский, и подход, и умение работать в непривычных условиях.
... 100% работоспособность или полнота кода не имела значения.
Вторым подходом - тут же действующий разраб смотрел логику и задавал 2-3 вопроса, а если видел ошибки - задавал вопросы по ним.
Если было очень нужно - это было второй частью; первая - показать и объяснить свой код/требования/..., третья - задать вопросы (не прокомментировать) по коду/докам действующего сотрудника.
Т.е. всё на "ход мыслей", умение собраться, взаимодействовать и рассуждать, и только (остальное всегда требует врабатываемости и "права на ошибку"). На всё про всё хватало часа-полутора в один подход.
Заодно ограждало от "нашего стека", узких задач, почерка или предпочтений тимлида - автор книги лучший составитель задач, чем программист-практик.
А вам как вам такой подход? И как вы собеседуете?
!!!
Может имелось ввиду, что на бумаге пишется псевдокод/рисуется диаграмма? Тогда выглядит вполне логично
Способ реализации оставляется кандидату. Принцип - "решить или показать ход решения задачи за ограниченное время любым способом лично" (без гугления / ide / ...)
Ниже https://habr.com/ru/companies/ruvds/articles/861018/comments/#comment_27596024 есть про экзамен "пригласить полетать на тренажере" - это примерно то же самое. С учетом того, что в ИТ разнообразие тренажеров (средств разработки), и нужно время на привыкание - лучший по моему опыту - мозг / карандаш / бумага (иногда - пальцы рук и две коленки, т.е. просто рассказать/показать устно).
Ну или "принести с собой свой ноут" - но это тоже усложняет.
Только Вы уж тогда в описании вакансии указывайте, что на тех. собесе будет листочек с карандашом. Значительная часть кандидатов даже не откликнется на вашу вакансию, а сильно заинтересованные потренируются карандаш держать.
Я сам не люблю давать алгоритмические головоломки на собеседованиях. Но, с другой стороны, мне нужно убедиться, что, скажем, мид-левел, которого я нанимаю, понимает некоторые базовые вещи: что квадратичный перебор может привести к проблеме; что существуют, кроме списка, другие структуры данных; что перебор "в лоб" решает не любую задачу... Ну и так далее. Мне не нужно, чтобы кандидат с ходу умел реализовать любой алгоритм - но мне нужно, чтобы кандидат знал о существовании этих алгоритмов. Найти сейчас можно все, что угодно - но нужно сначала знать, что искать.
И схожая ситуация с вопросами про дизайн систем. Я совсем не ожидаю, что кандидат нарисует мне мгновенно на доске готовое архитектурное решение, да мне это и не нужно. Мне нужно убедиться, что кандидат (мид или сеньор) понимает некоторые базовые вещи, начиная с того, что такое вообще дизайн систем. (У меня был случай, и даже не один, когда кандидат, выслушав задание, немедленно начинал рисовать дерево классов и таблицы базы данных, а на вопрос о производительности под нагрузкой отвечал в духе "Ну, возьмем сервер помощнее").
а на вопрос о производительности под нагрузкой отвечал в духе
Какие вы хотите от кандидата ответы, не имея на руках реальную систему, которую можно было бы потрогать и в которой изначально нет очевидной проблемы?
Какой ответ хотите услышать?
Бессмысленные рассуждения, которые и близко не будут похожи на реальное решение проблемы?
Меня всегда умиляют эти умники, требующие от соискателя за 5 минут разработать им Фейсбук. А человек просто пришёл за средний прайс по больнице писать код очередного никому не нужного ноунейм проекта.
Милота просто.
Обычно в таких задачах даются функциональные и нефункциональные требования, либо про некоторые из них надо спросить
Очень похоже на реальный мир, когда требований почти нет, а микросервис нужен ещё вчера. И проверяет самый главный навык для сеньора: способность самостоятельно быстро систематизировать задачу и придумать какое-нибудь решение. Попутно объяснение логики рассуждений даст хорошее понимание о глубине знаний человека в куче релевантных областей (от балансировки нагрузки и кеширования до устройства бд и условного шардирования/реплицирования)
При этом никто не заставляет делать все 100500 фич фейсбука и идеально -- об этом интервьюер проговорит отдельно, а он используется только для иллюстративных целей: быстро создаётся общий контекст + понимание нагруженности системы. А заодно, можно узнать о способности человека находить компромиссные решения и понимание как система должна эволюционировать
При этом, всё время интервью собеседующий не сидит и записывает за человеком его ответы, а находится в диалоге -- задаёт более релевантные для позиции уточняющие вопросы, кое-где подправляет кандидата если его мысли убежали в сторону, может обрубить те самые "бессмысленные рассуждения"
А ещё круто проверяет навык тайм-менеджмента и приоритезации, кажется тоже мегаважные скиллы
Разумеется, такой раунд не нужен человеку который дальше будет 10 лет перекладывать json-чики, но на позициях сеньоров и условных техлидов такое точно требуется
Нанял двух замечательных staff-разработчиков и тимлида таким образом и не перестаю умиляться как классно они теперь работают :)
Проблема в контексте и культуре самого собеседования. Ты сидишь у себя пилишь какую-то специфичную хрень типа биллинга серверов у сервис провайдера. Там есть свои подводные камни. О которых знаешь ты, но не знает кандидат, который например делает поиск в ВК. Вот он приходит, ты кидаешь ему проблему и ждёшь какого-то чуда. Как правило кандидат что-то проектирует, но не учитывает тонкостей. И хорошо, когда интервьюер относится к этому правильно, корректирует путем задавания вопросов и вместе вы приходите к правильному ответу. Однако в моей практике интервьюер себя ведёт как аутист. Весь собес тебя слушает, не давая обратную связь - а в конце тебе говорит что мол все хреново и ты не учел того-то. Но делает это в конце, когда уже времени нет. Это как плохой менеджер, весь испытательный срок ходит с каменным лицом а потом увольняет тебя одним днём.
Как послушать всех интервьюеров - так все через одного гении проектирования. А приходишь в компанию, и сплошь и рядом костыли и сомнительные решения. Все мы умные задним числом.
Я сам не люблю придираться к дизайну, но должен же кандидат знать чем солид отличается от кисс. А то у меня был случай, идаженеодин, когда кандидат лез бэ-деревья имплементировать, кеши городить, а кто такая Лисков знать не знал. Я его спрашиваю: "А как вы обоснуете начальству переработку из-за прематурной оптимизации на стадии эмвипи?", а он мне в духе "Ну, любой успешный эмвипи через месяц в продакшн тянут, а у нас уже хайлоад будет" [моя надменная улыбка]
Это реально к мидлу такие запросы простые в плане алгоритмов? Я бы на любом уровне побоялся бы квадратичную сложность использовать, если могу что-то лучше выдумать(но обычно не могу). Да и вот я знал про проходы в глубь и ширину, но реализовать под конкретный кейс не смог, когда реально в таске понадобилось, да и сейчас врядли смогу в похожих условиях и даже далеко не сходу и не за неделю(((
Я сам не люблю давать алгоритмические головоломки на собеседованиях.
...... мид-левел ... понимает ...: что квадратичный перебор может привести к проблеме; что существуют, кроме списка, другие структуры данных; что перебор "в лоб" решает не любую задачу...
херня это всё
алгоритм нахождения нового сотрудника-айтишника быстро, качественно и недорого - вот алгоритм, который айтишники до сих пор ниасилии....
Про "Сервер помощней" это очень валидный поинт, зря отмахиваетесь. Твиттер вначале писал все в одну mysql базу, когда она заполнялась начинал писать в слудующую, и в таком виде достиг популярности и миллионов пользователей. Вотсап, в момент когда его продали за сколько-то там миллиардов, обслуживал сотни миллионов пользователей и работал на 50 четырехядерных сереверах. Эти истории наводят на мысли, что один современный сервер может много, а мощный сервер еще больше. Так что для подавляющего числа ситуаций вертикальное масштабирование отлично работает, а инвестиции в горизонтально масштабируемую архитектуру неоправданы.
Все верно. У некоторых разработчиков есть такая проблема - оверинжиниринг. На пустом месте выдумать уберконвейер чтобы бороться с выдуманными проблемами. Сюда же относится преждевременная оптимизация, когда ещё ничего толком не работает и непонятно не пойдет ли код в помойку через неделю - но мы уже прикрутили мемори пулы и ассемблерных вставки.
Есть два метода отбора сотрудников (на самом деле, это полюса спектра - можно получить и любое их соотношение в компании методом смешивания).
Первый метод называется: китайский экзамен чиновников по каллиграфии. Он применяется в ситуации, когда работа стандартная, от личных качеств претендента ничего особо не зависит, плата так высока что претендентов намного (в десятки или сотни раз) больше чем мест. Всех кандидатов собирают вместе, дают письменные принадлежности и листы рисовой бумаги. Ведущий экзамена называет иероглифы от более простых к более сложным и экзотическим. Тот кто не смог написать очередной иероглиф (то есть не знал/помнил его) - выбывает. Усложнение продолжается до тех пор пока число кандидатов превышает число вакансий. Данный способ хорош тем, что позволяет за короткое время отсеять любое число кандидатов, причем по объективным признакам - так что не нужно потом долго оправдываться, почему взяли "А", но отказали "Б".
Второй метод применяется для найма линейного летчика в авиакомпанию. Тут кандидатов с нужной квалификацией не так много, и цена найма неподходящего кандидата очень велика (внутренние процедуры во всех компаниях отличаются - сначала кандидата придется оформить, потом онбордить теоретически, потом на тренажерах, потом вывозными полетами на откидном кресле - и если он в конце отвалится, то это трагедия...). И как ни удивительно - самым эффективным способом (по словам нанимающих пилотов) - является просто пригласить человека полетать. То есть, его тащат в УЦ, сажают с пилотом-инструктором в тренажер, и предлагают выполнить типовой полет (без всяких усложнений типа отказов), но максимально правдоподобно - от подготовки к полету до cabin shutdown по прибытии. И за эти полтора-два часа - можно понять и что у человека с навыками, и что у него в голове - и чего будет стоить его переучивание на стандарты вашей компании.
Еще пример который я приводил раньше (до того как нашел пример про летчиков) - найм музыканта в оркестр. Можете себе представить долбанутого дирижера, который устраивает скрипачу экзамен типа: а назови-ка мне братец компоненты клея, которым клеится дека ? А назови-ка ты мне год когда написал "Бориса Годунова" Модест наш Мусоргский ?.. Так вот, сообщаю - хотя творческие люди в целом бывают долбанутыми с точки зрения инженеров, они не настолько долбануты чтобы так поступать. Если музыкант устраивается в оркестр играть - то (сюрприз!) и просят его что-то сыграть. А уж по следам этого начинают разговаривать...
Какого хрена в нашей ИТ-отрасли закрепился китайский экзамен по каллиграфии - мне не ведомо. Хотите чтобы кандидат у вас программировал - ну так попрограммируйте с ним часок-другой, и все будет понятно! Хотите чтобы пинал балду и решал в рабочее время задачи с летиткода готовясь к будущим собеседованиям - ну тогда проверяйте летиткод, хозяин-барин!...
Какого хрена в нашей ИТ-отрасли закрепился китайский экзамен по каллиграфии - мне не ведомо.
Потому что:
на вакансию прилетает 100+ откликов;
проведение нормального адекватного собеседования по сути занимает много времени толкового дорого специалиста;
многие соискатели, даже адекватные и реально умеющие работать, в гробу видали тестовые задания (даже оплачиваемые), при том что нормальное тествое задание ещё сложно придумать;
ещё больше они в гробу видали лайв-кодинг, в том числе потому что от волнения у них мозги отключаются как на экзамене;
и множество иных причин;
Тогда применяйте метод "разборчивой принцессы". Оцените сколько кандидатов вы способны в здравом уме и твердой памяти обработать (например, вы решили что 15 - это ваш максимум). Выберите из входящего потока случайным образом 15 резюме, проведите собеседование с 1/3=5 кандидатами, но не нанимайте; а затем наймите первого который будет лучше (или по крайней мере, не хуже) лучшего из первой трети. Математики утверждают что это оптимальная стратегия при широком спектре допущений...
Какая репутация будет у компании если это всплывет? Мы собеседуем, но не нанимаем.
Но позвольте - компании и сейчас не нанимают всех, кого собеседуют! Вряд ли схема капризной принцессы более (или менее) законна чем схема "прособеседовать всех, но взять только одного"... Или даже прособеседовать всех, и вывесить ту же вакансию с меньшей зарплатой (коль скоро претендентов так много!).
Какая репутация будет у компании если это всплывет?
А какая?
Мы собеседуем, но не нанимаем.
Ну да. При любой методике собеседую на конкретную позицию Х людей, а нанимают одного. Что не так?
Выберите из входящего потока случайным образом 15 резюме
И на этом этапе фейл, потому что рынок завален натруальными мошенниками или мошеннико-подобными соискателями, которые буквально ложкой в рот не попадают. Ну выбрал ты рандомом щепотку таких, проведи хоть все 15 собеседований, там с большой долей вероятности всё равно не будет кого-то адекватного, кого можно будет нанять. В это и проблема основная: сложно придумать подход, которы бы дал реальный эффект по отсеиванию проходимцев, и при этом устраивал бы адекватных соискателей, а ещё позволял проводить найм в удалённом режиме при этом.
Тогда придется требовать опыт. Или вообще начать нанимать "по-знакомству": когда за квалификацию кандидата может кто-то поручиться (рекрутер, предыдущий работодатель, коллега который уже себя зарекомендовал, и тд).
В любой фирме примут по знакомству, если представится такая возможность (конечно, не от рекрутёра или неизвестного работодателя, а от доверенного человека). Но где ж напасёшься безработных квалифицированных знакомых.
Тогда придется требовать опыт
Проблема в том, что опыт опыту рознь, даже когда он настоящий (а фейкового тоже вагон и тележка).
Я знаю случи когда человек пять лет работал с JavaScript и React в компании, но вот он даже не может инициализовать пустой npm проект, создать голый React проект или что-то типа того, хотя казалось бы как это возможно. А возможно. Человек этот пять лет был в крупной команде, где они условно «кнопки перекрашивали» в существующем проекте, а задачи были предварительно пережеваны старшими разработчиками, в том числе что именно сделать, как именно, что для этого требуется и т.д. и т.п.
То есть вот пять лет опыта, а на деле ты его не сможешь нанять и посадить работать вне такого же контекста крупной команды, где он раньше работал.
Но это, наверное, нормально. У нас в прошлом проекте миддлы сидели, писали сервисы. Если вдруг какая-то кафка перестала соединяться - это уже выше их понимания, ибо они не различают: SSL у нас отвалился, файрвол закрылся или аутентификация пропала. Такие проблемы передаются сеньору или лиду, в обязанности которого входит отблокировать сирых и убогих. Понятно, что жизнь была бы еще приятнее если бы каждый сотрудник обладал квалификацией системного инженера, а еще бы и код писал. Но где взять столько людей и столько денег, чтобы их нанять?! Поэтому и грейды...
Если милы не могут посмотреть логи и сделать хоть какой то ресерч, то это не мидлы.
Но они же по логам опознают упавший коннект к кафке! Причем так же уверенно как Штирлиц из анекдота опознавал лыжников... А дальше - уже ой! Да и в целом, посмотрев на то как оно работает - я прихожу к выводу что оно имеет смысл при большом числе народа. Там где джун будет сидеть неделю и ничего не высидит, а миддл - несколько дней - там специально обученный человек за пару часов разберется, создаст тикет на смежную команду чтобы починили (или лично кому надо скажет что они сломали - и ему починят даже без тикета). И другим командам проще - с ними примерно одни и те же люди коммуницируют, и нам эффективнее. Единственная проблема которая меня лично волновала - это knowledge transfer. Мы вообще поощряли сеньоров рассказывать, а миддлов - интересоваться как решилась та или иная проблема. Но по моим наблюдениям - это было интересно хорошо если четверти миддлов. У остальных - work-life balance, тикеты закрыл и голова свободна...
У остальных - work-life balance, тикеты закрыл и голова свободна...
А. Ну то есть они должны бесконечно поднимать свою объективную ценность (норму выработки) за тот же прайс? А где тут их интерес?
Да я не то чтобы имел к ним претензии - но мне лично некомфортно находиться в ситуации когда произошедшую с моим участем проблему как-то решили, и я не знаю как. Я вообще не чувствую себя комфортно когда вокруг меня творится какая-то чертова магия - надо чтобы явления были объяснены, уложены в формулы, и по-возможности находились под контролем.
Математики утверждают что это оптимальная стратегия при широком спектре допущений.
Эта стратегия нацелена только на одного лучшего кандидата (но не на других топов), и она не гарантирует, что вообще будет сделан хоть какой-то выбор.
На практике оптимальная стратегия должна постепенно понижать планку по мере исчерпания кандидатов.
Это не ко мне, это к математикам. :-) Насколько я понимаю их доказательство (а я его понимаю плохо) - эта задача относится к классу exploit/explore задач (где вы можете часть ресурсов потратить на лучшее понимание ландшафта целевой функции чтобы ее эксплуатировать более эффективно, но ценой за это будет то, что вы эти ресурсы потеряете для фазы exploit). Соответственно математики доказывают, что разделив пул кандидатов в соотношении 1/e, вы в среднем наймете наилучшего из кандидатов.
Если вы решите использовать меньше чем 1/e для фазы explore - меньше шансов что вы никого не наймете, но больше шанс что наймете не одного из лучших возможных кандидатов. Если же вы используете больше чем 1/e кандидатов для исследования характеристик входящего потока - меньше шанс что вы наймете не лучшего кандидата - но больше шанс что вообще никого не наймете.
Соответственно, волшебное основание натурального логарифма (округленное для практики до трех) - максимизирует вероятность успеха.
И да, в терминах этой задачи - если вы никого не наняли, то это неприятно но статистически возможно, и вам надо повторить эксперимент (возможно, заменив принцессу и кандидатов). :-)
Насколько я понимаю их доказательство
В этом доказательстве, если я правильно понимаю - очень существенно, что к просмотренному однажды кандидату не возвращаются. Что, на практике, очевидно, не совсем так.
(Режим бреда on)
Вообще, оптимальное, вроде бы - это аукционная система, когда и те и те стороны какое-то время ждут, накапливая предложения, а потому разом, в какой-то момент, организатор аукциона говорит "это вам, а это-вам".
Это да. Но грубо говоря - если у нас три кандидата, то мы можем их всех отсобеседовать, попросить подождать - и выбрать лучшего. Если же у нас 100 кандидатов, то пока мы отсобеседовали пятидесятого, первые 25 уже приняли другие офферы. В целом, конечно, предположение что нельзя возвращаться к кандидатам - может быть чрезмерно консевативным, но не выглядит слишком искусственным при большом количестве претендентов (а народ как мы видим, жалуется именно на это...).
. Если же у нас 100 кандидатов, то пока мы отсобеседовали пятидесятого, первые 25 уже приняли другие офферы.
Вот потому и нужен 'аукцион'. Чтобы 'уже приняли' не было, а был понятный интервал времени, когда происходит выбор.
Проблема в том, что какие бы правила мы не приняли внутри компании, для кандидата они необязательны. Он может параллельно участвовать в нескольких аукционах от разных компаний начатых в разное время и принять первый оффер который его устроит. Идея же возложить материальную ответственность на кандидата за отказ от оффера (например, брать залог за рассмотрение его кандидатуры) - прямо противоречит и сложившейся бизнес-практике, и (я подозреваю) - законодательству...
Внутри компании оно вообще смысла не имеет. Это имеет смысл на площадке трудоустройства.
Условно, неделю идут всякие собеседования, тесты, встречи, что работодатели, что кандидаты результаты и свои предпочтения 'кого хочу' (а то и записи самих собеседований) вносят в площадку. И в конце недели все это обсчитывается и всем выдается результат с объяснениями "похоже, вы друг другу подходите. Нет, лучшего нет - другие расхватали, потому что были популярнее. Вон там данные лежат, можете посмотреть".
Отказ - долго промывать мозги на счет "а чего это вы, граждане указывали, что такой-то кандидат/работодатель вам подходит с приоритетом X, а теперь нос воротите? Нехорошо..."
Теория игр нашептывает мне, что если компания захочет сделать предложение понравившемуся кандидату по "внебиржевому каналу" в период аукциона, то ей за это ничего не будет. И кандидат - если он откликнется на такое предложение - тоже ничего не потеряет. Таким образом, наилучшие предложения будут разобраны до конца периода аукциона, а в котле останутся те, кого нанимать уже не очень хочется. В общем, без энфорсмента оно не взлетит - а энфорсмент требует совершенно другого устройства общества...
Ну, в настоящих биржевых торгах как-то все работает так, что торговать предпочитают именно на бирже, а не перехватывать еще более выгодным предложением мимо нее.
И 'настоящие' аукционы - тоже проводятся, а не все участники в процессе договариваются и перехватывают лоты мимо устроителя.
Так что утверждение, что менять общество придется сильно - мне не очень очевидно.
Биржевые торги проводятся единообразным товаром - одна акция не лучше и не хуже другой. Отсюда - стороны не получат выгоды заключая сделку вне биржи, но повысят транзакционные издержки. А представьте ситуацию когда одна акция в пакете золотая, другая - серебрянная, а остальные - бумажные. Тут мгновенно появляется соблазн выхватить первые две мимо процедуры, и оставить остальных торговаться за бумажные...
И, кстати, классические аукционы проводятся во многом именно так, чтобы нельзя было заключить сделку мимо стандартной процедуры: вещи передаются аукционисту заранее и забрать их обычно до торгов уже нельзя без штрафа; за участие в аукционе с претендентов на покупку берется залог который не возвращается если ты победил но отказался заключить сделку; физически невозможно присутствовать одновременнно в нескольких аукционах (ну по крайней мере раньше так было - сейчас с электронными уже вопрос..), аукцион проводится очень ограниченное время (часы, а не дни или недели) и т.д...
Как все эти свойства перенести на рынок труда - я слабо представляю...
И, кстати, классические аукционы проводятся во многом именно так, чтобы нельзя было заключить сделку мимо стандартной процедуры
Ну так участники на все это сами соглашаются и аукцион таки проводят. А могли бы как-то договориться самостоятельно, без всех этих ограничений. Т.е. участие в аукционе и соглашение с его условиями - выгодней, чем без него.
Почему тот же механизм не сработает на рынке труда?
Зависит от природы торгуемого товара, наверное. Классический аукцион в области предметов искусства обеспечивает прослеживаемость, проверку подлинности, и так далее. То есть, уменьшает транзакционные издержки.
А залоговые аукционы 90-х в РФ, несмотря на название, как раз являлись примером сговора продавца и покупателя для того чтобы не выводить предмет на чистые торги...
Соответственно математики доказывают, что разделив пул кандидатов в соотношении 1/e, вы в среднем наймете наилучшего из кандидатов.
Здесь должны выполняться несколько условий:
не должно быть возможности отфильтровать кандидатов заранее, повысив "качество" исходной выборки
нельзя собеседовать следующего кандидата до того, как полностью отвергнут предыдущий
надо максимизировать качество кандидата
Ни один из этих пунктов в найме не выполняется - мы _можем_ улучшить качество выборки, мы _можем_ переходить к следующему кандидату до того, как отвергли предыдущего (и даже опрашивать нескольких одновременно), и нам не нужен с максимально ожидаемыми скилами - нам нужен первый, кто нас устраивает (или даже сразу все). Исходя из этого, процесс найма и устроен.
Если вернуться к вашей аналогии с оркестром - допустим, нам в оркестр понадобилась скрипка, пришло на прослушивание сто человек, и мы знаем, что из них хорошо если десяток вообще хоть раз в жизни видел скрипку ирл. Тогда мы сперва применяем примитивные фильтры - просим, например, продемонстрировать, как кандидат будет держать смычок во время игры. Половина кандидатов берет смычок не за тот конец и идет домой. Потом предлагаем сыграть гамму (без всяких технических изысков вроде там децимами или двойными флажолетами - просто гамму, как захочется) - в итоге остается 5 человек, их можно вести на прослушивание.
На самом деле, при отборе в реальные оркестры именно так и происходит - только туда уже на первоначальный отбор приходят люди в айтишной терминологии уровня сениор++, поэтому вместо того чтобы развернуть бинарное дерево (= подержать смычок) их просят быстренько перепрошить микроконтроллер (что-то такое сыграть минуты за 3 чтобы жюри восхитилось и дало возможность пройти по отбору дальше). Ну а потом уже несколько недель подготовки к настоящему собеседованию, и дальше их как раз будут гонять и по скоростной печати, и по навыкам демосцены, и змейку в compile time на типах в хаскеле написать попросят. И тому, кто все это пройдет - предложат по итогу испытательный срок)
Т.е. у таких людей нет смысла просить подержать смычок - они и так умеют, это только время тратить. А вот в ит - смысл есть, натурально половина приходит и не умеет. Потому и задаются все эти вопросы при найме, что - смысл есть, люди действительно умудряются не обладать даже самыми базовыми навыками программирования..
Я и согласен, и не согласен. Пункт первый - повышение качества выборки: согласен. Собеседовать человека с улицы без репутации на сеньора в горящий проект - скажем так, немного безумно. Здесь я за разделение джуниорских и интерновых позиций - куда мы вынуждены брать людей с улицы. И мидлы и выше - где мы хотим чтобы кандидат уже продемонстрировал какой-то подтвержденный опыт.
Пункт второй - оно, конечно, можно - собеседовать второго кандидата не дав ответа первому. Но во-первых, если вы не HR-агентство, то ваши мощности по собеседованию ограничены (и как правило, ресурс потраченный на собеседование = ресурс выдернутый из реального приносящего деньги проекта). Да и кандидат тоже не обязан ждать вашего решения - к моменту когда в к нему вернулись, он уже может принять оффер другой компании - и с этим вы ничего не сделаете. Поэтому ограничения задачи принцессы в этой части я нахожу, возможно, консервативными - но тем не менее, применимыми к задаче реального найма.
Пункт третий - не согласен. По моим наблюдениям - компания всегда хочет наилучшего кандидата за деньги которые она готова потратить. Иногда она хочет даже такого хорошего кандидата, которого не существует за эти деньги в природе. Поэтому ограничение задачи принцессы тут важно, и оно присаживает менеджмент обратно на землю...
>на вакансию прилетает 100+ откликов
Подходящих под вакансию? Вы лукавите :) и даже близко нет, иначе бы по личкам не бродили рекрутеры. И да, у меня открыто вакансий в которых в требованиях 3 пункта на уровне умею скрипт писать.
Подходящих под вакансию?
Делающих вид в резюме и сопроводительном письме, что они подходят. Вам никогда не встречались кандидаты, врущие в резюме и указывающие там фейковый опыт?
>на вакансию прилетает 100+ откликов
Подходящих под вакансию? Вы лукавите :)
да беда у этих айтишников совсем беда, хз почему, что за ажиотаж ..
Если бы зарплаты были такими же как в верхнем углу думаю и откликов было бы сравнимо
зарплата в максимум 2 раза больше, а просто откликов в 20-50 порядков больше ? т.е. 150 уже ниочём чтобы "битики перекладывать"?
Если бы зарплаты были такими же как в верхнем углу думаю и откликов было бы сравнимо
факты говорят об обратном:
а вот где действительно наплыв желающих (больше 800)
Ну так нижним двум специализациям на курсах не учат)
По моим наблюдениям качество соискателей упало до такого уровня, что мы просто вынуждены сначала проводить "экзамен по каллиграфии".
Если следовать вашей аналогии - зачем тащить лётчика в УЦ и тратить время тренажера, если он банально не знает, что означают просто слова "тангаж" или "эшелон" . Тратить время на такого человека бессмысленно и беспощадно.
Ну или с музыкантом - компоненты клея он может и не должен знать, но что такое "аккорд", "гамма", "октава" и базовые понятия нотной грамоты - знать наверное обязан , не?
С некоторых пор я свои собеседования начинаю с простейшего опросника по предметной области (предметная область, если что СУБД Oracle). И я не вижу смысла переходить к каким-то обсуждениям задач и даже тестам, если человек (который пришел на позицию, на минуточку, сеньор разработчика) не может внятно своими словами объяснить, что такое "курсор", "транзакция" и как работают блокировки в той БД, под которую он писал код, если верить резюме, последние 10 лет. И я не утрирую, я буквально спрашиваю "что такое курсор" и 6 из 10 не могут ответить ( позиция Senior PL/SQL Developer, напоминаю).
Опросник (экзамен по каллиграфии) просто позволяет банально отсеять людей, которые пришли "на шару" и не тратить дальше ни их, ни моё время. Опросник естественно тестировался на всех текущих разработчиках компании на адекватность. Никто не верил, что человек, который подразумевается, что ЕЖЕДНЕВНО пишет код на заданном языке программирования - может не знать даже каких-то совершенно базовых терминов и синтаксиса.
Я, вероятно, неисправимый оптимист - но не из скита же отшельника в густом лесу вышел соискатель?! В цивилизованном обществе у него должен быть или послужной список, или хотя бы документ об образовании! Если вы, гм, заявитесь с улицы в лондонский симфонический оркестр - вас тоже там никто не станет собеседовать, а пошлют сначала поиграть в места попроще... И как пилота никто не будет человека рассматривать без действующего пилотского. То есть если позиция не специфически джуново-интернская, мы туда зовем либо по-знакомству, либо с опытом работы, либо с профильным образованием. Тех кто пришел без этих аттрибутов - мы без разговоров разворачиваем. Тех кто пришел с ними - ведем на тестовый полет попрограммировать...
Опять-таки, нельзя упираться только в знания - надо смотреть на низких позициях обучаемость... Могу рассказать пример который наблюдал в региональном интернет-провайдере: в какой-то момент кандидаты на должность сисадмина массово перестали понимать что такое "маска подсети". То есть, реально - три-пять лет назад приходили люди которые это знали (если не каждый, то через одного). А теперь приходят - и все в разных форматах выдают одно и тоже "определение": мол маска подсети - это волшебное число которое тебе пишет интернет провайдер, и которое надо вводить вот в это поле в настройки сети, иначе интернета не будет. Казалось бы, тут провайдера можно уже и закрывать. Но в реальности, оказалось что они через одного продолжают быть обучаемыми - просто им то-ли не рассказали про маску, то-ли они уже с детства впитали что это "волшебное число". И в целом, когда им сказали что теперь они на стороне провайдера, и надо самим творить магию, а не вбивать числа с бумажки - соответствующая концепция мозгами успешно осваивалась... Понятно что брали таких только на стажировку - чтобы прямо в сисадмины, нет - это ж была бы катастрофа: чувак с магическим мышлением на дежурстве в ЦУС... :-)
И какая же из современных БД блокировщик? Вроде даже неродной MS SqL давно уже мультиверсионник, насколько МС это себе представляет
Кстати, а не проще дать задачку на SQL, попросить написать запрос?
Простой select какой-нибудь с джойнами группировкой. 5-10 минут времени и сразу понятно стоит ли дальше продолжать собеседование.
Смешная ситуация в том, что многие разработчики действующие толковые не ответят на такую задачу из головы без времени и гугления, и не потому что какие-то плохие или глупые, а потому что индустрия их десять лет стращает и бьёт по рукам, что писать самому SQL это зашквар, неоптимально, небезопасно, слишком долго, неудобно потом поддерживаь и т.д. А надо использовать ORM и пусть оно само генерирует SQL (а потом оно рожает мутантные запросы, который раком всё ставят, да).
Мне кажется тут вы зря ругаете ORM
ORM так же умеют в блокировки и уровни изоляции
И даже если ты 10 лет только и писал, что запросы с помощью ORM, то это не отменяет того, что нужно знать, что такое блокировка.
Один из моих любимых и простых вопросов про блокировки: "реализуй deadlock"
Упрощенная версия вопроса: рассказываешь что такое deadlock, рассказываешь как сделать блокировку и просишь реализовать.
Вторая версия вопроса показывает насколько человек быстро схватывает новые концепции
На всякий случай: я знаю и про курсоры (и даже различаю имплицитные и эксплицитные) и транзакции. Ну мало ли )) В будущем там... )))
Есть два метода отбора сотрудников
И ни тот ни тот не работают, если прежде чем человек начнет приносить пользу ему нужно здоровенный контекст в голове уложить.
Даже этот "найм пилотов" - там проверяется более менее стандартная по индустрии процедура.
А в нашей индустрии это неформализованная (именно неформализованная - даже несмотря на то, что в виде кода описана) Institutional memory - чуть ли не основное, с чем работа идет.
Людей, которые занимались leetcode-дрочеством, довольно легко отлавливать.
Во-первых, они ожидают задачу, в которой все определено и разжевано. Они задают вопросы только потому, что так принято. Полученные ответы они благополучно забывают и удивляются, когда им об этом напоминаешь. Они ожидают детальных примеров.
Во-вторых, они не могут написать решение в виде псевдо-кода, в любом формате. Они сразу пытаются писать код.
В-третьих, они не могу проверить свою программу без запуска. Они не могут сгенерировать данные для тест кейсов.
Самая большая проблема - это уровень вранья. Ладно с враньем в резюме, без этого уже не пробраться через фильтры. Но когда тебе постоянно врут про свой опыт на собеседовании и знание всего на свет, то это приводит к разочарованию. Первые 100 интервью ты еще пытаешься вкладываться в кандидата, закрывашь глаза на ошибки и зависания с ответами, пытаешься помочь. Из этих 100 только ~5 оказываются адекватными, остальные - шлак. А ведь эти 100 уже прошли какой-то уровень фильтрации. Печально, что процент адекватных не растет. Так что, основной задачей интервьюера становится борьба с шлаком. К сожалению из-за большого процента шлака, страдают вполне нормальные кандидаты.
Ну, литкод это ведь не только про алгоритмы.
Можно подобрать задачку на структуры данных, даже подсказать кандидату чтобы он именно их использовал и тем самым продемонстрировал как он с ними умеет работать (а это довольно близко к тому что нам и так приходится использовать каждый день).
Опять же задачи на SQL для backend разработчиков (и это тоже есть на литкоде).
Я это к тому что литкод задачи это хороший первичный фильтр чтобы увидеть как кандидат пишет код/sql-запросы и как рассуждает при этом. И можно сделать вывод, стоит ли дальше продолжать собеседование на более глубокие темы.
А ведь эти 100 уже прошли какой-то уровень фильтрации.
Может, именно на этом уровне фильтрации, отсеяли адекватных?
Отсеяли тех, кто не хочет врать о своих настоящих навыках в принципе, даже в резюме.
"неудачники нам не нужны" (с)
Думаю, создание автоматической системы фильтрации с анти-читингом - очень непростая задача. Чем сложнее будет система, тем больше денег будут брать конторы по подготовке резюме.
Сейчас активно используют системы online assessment, когда кандидату дают задачки и разумное время на их решение, чтобы кандидат решал их без стресса. Да и там читинга хватает. Кандидат набрал максимум баллов, а сам не знает что такое связанный список и чем он отличается от массива.
Пока еще лучше всего работает система найма по рекомендации. Там процент адекватных кандидатов сильно больше.
... остальные - шлак. .....Так что, основной задачей интервьюера становится борьба с шлаком. К сожалению из-за большого процента шлака, страдают вполне нормальные кандидаты.
ну так забань их! делов то ...
Всё это звучит здорово, но достаточно очевидно, что большинство проводящих собеседование забракует кандидата, не выполнившего задачу. Ситуация становится ещё хуже, если кандидат никогда не сталкивался с данной ему задачей — это может затормозить его и привести к провалу на собеседовании.
Мне в Яндексе напрямую сказали что нужно было подготовиться к алгоритмической секции. Ощутил вайбы ЕГЭ
Возможно, дело в том, что крупным компаниям не нужны гении или даже просто нестандартно думающие разработчики - техпроцессы в компаниях забюрократизированы и уже заточены под "винтики", которые:
смогут работать в условиях сильного стресса - это и проверяют 3-5 техсобесами в один день.
будут подчинятся и просто выполнять ту работу, которую им поручили, не выходя за разрешенные рамки - это проверяют литкодом и алгоритмами -> зазубрил все что сказали, без лишних вопросов "А зачем это?" - молодец, прошел дальше.
винтики должны быть стандартными и взаимозаменяемыми - поэтому в крупных компаниях примерно одни и те же, кажущиеся нам нелогичными, процедуры найма.
Поэтому и задачи на собеседованиях никак не коррелируют с реальной работой - цель HR нанять не специалиста на конкретную работу, а стандартный винтик, который подойдет в любое место системы - плюс-минус в любой отдел на любую позицию в пределах грейда.
А если что-то пойдет не так, например - ошиблись с наймом или разработчик выгорел, этот винтик без проблем заменяется на другой такой же - по той же схеме.
Давно доказано, что самый опасный человек для любой корпорации - энтузиаст.
Да, все примерно так и есть. Потому что "звездные" участники команд в крупных компаниях показывают строго отрицательную бизнес-ценность. Единственный путь, когда их удается использовать хорошо - это собрать "звездную" команду и засунуть в RnD. А потом оправдываться, почему RnD денег приносит ноль, а жрет как 4 вполне себе прибыльных бизнес юнита...
16 лет пишу код и только пишу код. Не могу сказать что я прям какой-то дохрена гений, наоборот, объективно я профессионал ниже среднего, но большой опыт компенсирует. На днях завалил технический собес, минут 20 не мог решить простейшую, элементарную проблему, запутался, завис, замямлил, полез не туда, забыл синтаксис. Когда собес закончился, налил себе чайку, выдохнул, и решил ее для себя уже за 3 минуты ровно.
Тоже смирился уже с этим проклятьем, просто знаю что 80% интервью я провалю на какой-нибудь фигне, и просто заранее это закладываю в поиск работы.
Говорят там ближе к 50 начинается другое проклятье когда тебя считают уже слишком старым и даже не зовут, вот тогда не знаю что буду делать, наверное пойду дворы мести.
В целом все ок, но позвольте заметить, «три минуты после собеса» не аннулируют время которое было потрачено на анализ задачи во время него и фоновый процесс пока софт часть шла
безусловно без стресса вы бы решили задачу быстрее, но не за три минуты)
Лично я давно забил даже пытаться алгосекути походить и первый вопрос эйчару - есть ли алгоритмы?
при этом к лайвкодингу отношусь спокойно
Меня другое удивляет. Вот на собеседовании требуется знать, как работает некий (полу)стандартный алгоритм. Чтобы на его основе реализовать некую задачу. Такое впечатление что книги по-прежнему только из бумаги. И только в библиотеке.
Как по мне, гораздо важнее вообще знать, какие алгоритмы могут реализовать данную задачу. Их плюсы и минусы. А как именно он работает - изучу при необходимости реализации..
Ну обычно на собеседеваниях такие задачи не с целью чтобы соискатель её решил, нет цели чтобы соискатель именно знал решение, это возможно даже минус и собеседующему следует дать другую задачу. Цель этого всего, посмотреть как кандидат мыслит, самая большая ошибка тут замолчать. Хотя мы алгоритмы редко даём, мы спрашиваем про прикладные задачи, с которыми кандидат мог столкнуться в реальной жизни, например сервис крутится в нескольких подах, нужно поменять тип колонки в бд без простоя, почему то большинство кандидатов не знают как это делается, хотя задача хоть и не вполне приятная, но в вполне обычная
Хороший интервьюер как раз и спрашиват о том, чем можно решить данную задачу, и проверяет, что кандидат понимает вещи, которые он использовал при решении задачи.
Например, если используется хеш-таблица, то какие есть плюсы и минусы.
Я даю задачи, которые не требуют больше чем 10-20 строк кода, даже для brute-force решения. Например: удалить из связанного списка элементы, удовлетворяющие определенному критерию. С кандидитом мы обсуждаем, как меняется решение, если имеются разные ограничения. В такой простой задаче, как удалить элемент из списка, в решение кадидатов всегда есть баги. Поэтому, мы обсуждаем тестирование и отладку.
Это верно. Но без стресса я бы первые 20 минут не потратил на очевидно ерундовое не-решение.
Мне немного за 50. Правда, я на столько не выгляжу (надеюсь). Пока на собесы зовут и даже успешно прохожу и выбираю из нескольких офферов. ) Навык решать задачи в стрессовой обстановке требует тренировки. Два-три собеса без ожидания обязательно сразу получить оффер обычно достаточно, чтобы дальше уже не мандражировать и примерно представлять, что будет на очередном собесе.
У меня 19 лет разработки эмбеддед софта и 5 лет железа. Тоже косячу на собесах, капец. Один раз затупил на элементарной задаче работы с файлами на си. Тупо забыл, начал читать маны на собесе :) Я в своей работе с файлами обычно не работаю, на питоне иногда нужно логи распарсить и всё. И кстати, за всё время работы ни разу мне не попадались задачи, связанные с алгоритмами сортировки или с каким-нибудь бинарными деревьями. Даже связные списки не использовались нигде. :) Хотя в институте нас по ним гоняли.
Та же проблема. Меня отвлекают от решения эти люди по ту сторону монитора)
Зовут, брехнея. Мне 50, полгода назад нашел нормальную синьорскую позицию, начав собесы с адски нерелевантного мидловского опыта. Чтоб кого-то волновало что я в 50 хожу мидлом, вообще не заметил.
Отличная статья! И все в точку. Как же мне надоело пытаться объяснить то же самое подобным "шаблонным" компаниям. Предпочитаю просто не иметь с такими никаких дел. Вроде яндекса, брр-р
Здесь важно отметить, что многие организации подчёркивают, что главное — это не окончательный ответ. Вместо него оценивается то, как кандидат работает и коммуницирует. Всё это звучит здорово, но достаточно очевидно, что большинство проводящих собеседование забракует кандидата, не выполнившего задачу.
Тут дело в том, что признак "задача выполнена" - очень не бинарный.
Я когда смотрю тестовые, не жду безупречного исполнения, это утопия. Даже если работа содержит многочисленные огрехи и недоработки, но все они нефатальны - это уже считается успешным ТЗ. Нужно просто понять: мы сможем исправить эти недоработки подсказками и направляющими вопросами? Или тут всё безнадёжно, нужно выкинуть и переделать с нуля (желательно другими руками из правильного места)? Большой процент тестовых относится ко второй категории.
Я думаю с лайв-кодингом похожая история. Умеренные ошибки и шероховатости - это нормально, главное общее впечатление осмысленности человека. А вот если там поток бреда или вакуум - ну значит мимо. Тренируйтесь.
Точно не бинарная. Даже если, с вашей точки зрения, ошибки фатальны, но человек может внятно обосновать, почему он сделал именно так - обязательно надо вникнуть. Бывали случаи, когда задачу просто никогда не решали подобным способом. И даже не предполагали, что её можно так решить при заданных условиях.
Перепод рассказывал, как его курсу дали учебное задания спроектировать хранилища для ОМП. Все строили подземные бункеры. А один студент принес проект простого ангара. Когда его спросили "от чего он защищает?" ответ был - "от крупного града". На немой вопрос в глазах он обосновал что на момент нанесения удара ангар будет пустой, так как все содержимое давно будет установлено на носители. Удар будет наносится чем-то очень мощным. При нанесении удара ангар конечно сметёт, а бункер, возможно, уцелеет. Вот только извлечь содержимое бункера сразу после удара будет почти невозможно, а потом -уже не нужно. Проект приняли.
Таких баек много, но в реальности не пойдет. ОМП должно быть защищено от случайных внешних воздействий, можно же вообразить падение самолета, например. Боевые действия могут идти без применения ОМП (такой сценарий считался возможным), по крайней мере, на первом этапе. В общем, лучше перебдеть, чем недобдеть.
Я в общем не программист по образованию, но программирую с начала 90-х. Это были и ка можно сейчас называть и pet проeкты, и разработка приложений на заказ параллельно с основной работой, и почти основная работа по созданию типа ЕRP. В промежутках я занимался электроникой, руководством проектов, был зам. главного конструктора и параллельно разрабатывал электронику,. На последнем месте было собеседование, где в общем нанимали человека на разработку электроники, но меня в этом не тестировали а просто побеседовали насчет моего опыта, указанного в резюме. Но в общем я был один в команде начал сам искать себе в команду программиста по микроконтроллерам. Поднял старые связи и нашел нужного человека с большим опытом. Его наняли почти без собеседования, выдернув с прежней работы. По мере готовности прибора встала задача его производства и тестирования и я , памятуя о своем опыте программиста БД начал искать человека на разработку клиентского приложения. Базой данных решил заняться сам. _Удивительно, но такой человек нашелся в команду, через коллегу, который увольнялся. Сторонних кандидатов отмели еще до этого, была парочка, но они не понравились мне. Его собеседовали просто. В прежней конторе от работал на заводе в должности ведущего инженера программиста. Его взяли и дали простое задание реализовать несколько простых команд протокола связи нашего прибора за неделю. С работой он успешно справился и я получил в команду человека, с которым можно было работать,. Хотя до этого он не работал с БД, но тут пришлось и ему в общем это далось легко благодаря тому что я бизнес логику приложения поместил в БД, оставив ему интерфейсы с приборами. Потихоньку он начал разбираться в простом SQL. В общем получилась команда, которая сделала и прибор и систему тестирования и производства его, которая успешно работает.
Не ждите что работодатель найдет вам в команду нужных людей путем собеседования без вас с помощью каких-то заданий. Все это чушь. Главное креативность мышления, способность обучаться и нормальное руководство проектом. Я хоть и не был руководителем, но был неформальным лидером, так как мои коллеги не были в теме, но успешно ее изучили в процессе работы над проектом. Я даже написал статью об ней на Хабре ( можно изнакомится с публикацией в моем профиле)
Обобщая свой опыт проведения технических собеседований: задание должно быть сформулировано так, чтобы для решения требовалась не очень сложная композиция из базовых элементов и приемов, которые неизбежно закрепляются на уровне рефлексов при регулярном использовании.
Поэтому у меня на собеседовании (Java) кандидат пишет код в IDE по своему выбору, имеет право смотреть в документацию и искать в интернете, а чтоб закодить решение ему нужны только базовые компоненты JDK, а так же JUnit.
Следующим уровнем может стать обсуждение решения. Ожидается, что кандидат видит границы его применимости, рассуждает о плюсах и минусах, предлагает улучшения, альтернативу, или даже обоснованно защищает свое решение.
Я до сих пор не перестаю удивляться, насколько хорошо итоги собеседования в таком формате коррелируют с трудовыми успехами.
Уровень ложно отрицательных ошибок оценить не могу.
15 лет в айти, и я точно такой же. Но у меня был опыт выдрочки к собеседованиям, когда после 2-3х понимаешь что к чему, и начинаешь щёлкать собесы...Это было позволительно когда мне было 23-30 лет, я мог сесть позадротить пару недель...но сейчас...во первых больше начал ценить свое время, потом дети, родители, куча других вариантов заработать...есть ощущение, что эти временные затраты себя совершенно не оправдывают, особенно если вырос к потолку зп по рынку в своём профиле...
И тут начинаешь злиться на капитализм, и верить в заговоры HR и курсомейкеров типа Япрактикума, которые уже в сговоре с HH продвигают эти идеи "великой сложности" стать айтишником, ради которых не достаточно просто ВО в сфере айти...
Откройте вопросы по GIT на Hh, и станет все понятно...
куча других вариантов заработать
Накидаете чтобы сравним доход был? А то у меня мысли выйти из айти бывают, но все какое то так себе :)
есть ощущение, что эти временные затраты себя совершенно не оправдывают, особенно если вырос к потолку зп по рынку в своём профиле
Имхо меньше чем за 30% прибавки переходить если все в целом устраивает на текущем месте как-то странно. Тем более через современные эти унизительные собесы
в разделе как надо - TS предлагает разные подходы между джуном и сеньором.
А как понять - что перед тобой сеньор а не джуниор? В пасспорте не написано ведь. А опыт сейчас массово фейкают
А как понять - что сеньор - не балабол? я лично встречал инженеров, что отлично могут на словах спроектировать системы. Но когда доходит дело до реальных действий - там просто атас. ну и снова фейкеры
Глубокая защита требует просто КАПЕЦ сколько времени на подготовку. А сама секция займет много часов защиты. Очень много кандидатов не готовы так вкладываться, и просто свалят где процессы короче
Руководитель с 17-летним стажем, который мямлит, потеет и зависает при беседе с незнакомыми человеком? Хмммм.....
Здесь важно понимать, что этот человек зависает только в одной ситуации - когда здесь и сейчас оценивают его лично и инициатива вместе с абсолютной властью в принятии решений находится у оценивающего.
В реальном бизнесе таких ситуаций не бывает вообще. Оценивают продукт, результаты команды, работу за день, за неделю и всегда инициатива и власть распределены и есть пространство для дискуссий, а не 15 минут за которые тебя забракуют срвсем.
У меня баг? Не вижу пост
У вас не баг, просто открыли секцию комментариев, а не саму статью.
При каких-то условиях (не знаю могу хорошо сформулировать каких, не тестировщик) ссылка на комментарии (с /comments/) не позволяет видеть текст поста, в то время как ссылка на пост при прокрутке вниз отображает комментарии.
Поздравляю, вы приняты тестировщиком.
человек открыто написал что программировать не любит и не умеет и ищет себе нишу где можно поболтать языком
Двоякое ощущение от статьи, и да, и нет
У нас лайвкодинг достаётся только джунам и миддл-
Спроектировать архитектуру системы - вообще за гранью добра и зла (если человек может её набросать за полчаса, учтя при этом хотя бы 10% контекста, он с вероятностью 99% просто натаскан на этот тип интервью и эту задачу)
С остальными - поговорить за жизнь, оценить широту поляны (кругозор), послушать нестандартные кейсы из практики, возможно обсудить свою боль и послушать его рассуждения на эту тему
Конечно и опрос по конкретному инструментарию тоже проходит, но тут вполне прокатывает ответ типа: - да просто аннотацию поставлю, забыл название то ли [...] то ли [...], но она точно есть и делает то-то и то-то..., а вот если надо ещё и [...], то придётся ещё и тут докрутить...
Просить синьора на память помнить все аннотации и все сигнатуры функций, которыми он пользовался в работе, это нонсенс...
Спроектировать архитектуру системы - вообще за гранью добра и зла (если человек может её набросать за полчаса, учтя при этом хотя бы 10% контекста, он с вероятностью 99% просто натаскан на этот тип интервью и эту задачу)
Нет, просто у того, кто хорошо спроектирует архитектуру - скорее всего есть сильное техническое образование.
Проанализировать системы, найти самое сложное место, которое и будет определять максимальную сложность системы, и исходя из потребностей уже подобрать инструменты: БД (1, 2, индексы, партишн), системы на запись, на чтение, на кеширование
Взять две системы:
1. Медленно пишем 10 млн строк в день в течении месяца, и раз в месяц систему начинают насиловать на агрегацию данных в самых разных разрезах.
2. Операций на чтение в 100 раз больше, чем на запись, критична быстрая фильтрация 50 тыс товаров по фильтрам и не продать дважды один и тот же товар.
Совсем разные системы и каждую из них очень легко набросать за полчаса, рассказав как будут покрываться узкие места, а что делать, если вдруг мы выросли еще в 5 раз.
Если Вам не попадались такие кандидаты или коллеги - это не значит, что их нет
Они есть, их много, и для крупных компаний это критичные навыки
Если Вам не попадались такие кандидаты или коллеги - это не значит, что их нет Они есть, их много, и для крупных компаний это критичные навыки
Наоборот, таких кандидатов как собак нерезаных, после курсов "Стань архитектором "ВСЕГО, прямо вообще ВСЕГО", за три месяца, без смс и регистрации"
Только они проектируют "сферического коня в вакууме"
Такое каждый второй миддл (прочитавший кабанчика и ещё пару тройку профильных книг) делает на раз
Только вот нам не нужны такие системы, да и вообще они редко кому нужны
А как только даёшь ему чуть чуть контекста - например:
- ПО должно входить в реестры разрешённого как в РФ, так и в собственный реестр заказчика, и иметь сертификацию
- Инфраструктура и железо должны использоваться существующие
- Переобучение сотрудников сопровождения ПО на стороне заказчика не должно требоваться
И ещё десяток пунктов
И получается, что все выверты с проталкиванием записей в горячие кэши на шардированных, географически распределённых, нодах...
Внезапно идут лесом
А архитектуру делать надо
Вот прямо интересно, с чем несогласен человек, заминусовавший комментарий не несущий ни какой эмоциональной или оценочной окраски, не вступающий ни с кем в спор, и в котором человек, который возможно будет собеседовать вас когда вы придёте наниматься в одну из тех самых крупных компаний, в которых, как утверждается в реакции на мой коммент, умение проектировать - критичный навык, просто делится своим опытом по теме статьи?
Ладно, я понимаю, что представители бизнеса по обучению вкатыванию в IT очень не любят, когда хомячкам раскрывают глаза на ценность "знаний" которые им обещают дать на подобных курсах, и во втором комменте минус в принципе можно понять)
Но, блин, чем не угодил первый то?)))
Из каждого утюга только и слышно про лайвкодинг сессии, аглоритмические секции и прочие литкоды. При этом сам я уже 8 лет работаю программистом и ни разу ни с чем подобным не сталкивался, хотя и бывал на всяких собеседованиях с обеих сторон. Причём со стороны нанимателя я проводил технические собесы как полностью самостоятельно, так и в качестве наблюдателя типа "мы этого чела поспрашиваем, а ты сиди смотри и делай выводы, подходит ли он нам". Наверное, стоит отметить, что я никогда не ломился во всякие фаанги и яндексы. Но всё равно, мне не даёт покоя это странное чувство, что все вокруг так упорно обсуждают то, чего я ни разу не видел.
PS: я на 99% уверен, что тоже завалю подобный собес, если окажусь на нём)))
После крайнего обновления резюме начали стучаться эйчары в WhatsApp, телегу, на hh.ru получил пару приглашений. И ведь есть вакансии действительно интересные, но я как вспомню все эти стрессовые собесы под камерой, стараюсь вежливо отказать. Не моё это. Конечно, если будет прям супер-пупер предложение придётся заново все эти наиболее частые вопросы на собеседованиях повторять).
последнего. Задолбала эта бабская суеверность, думал хотя бы айтишники не должны ею страдать...
Крайний - это который находится с краю некой последовательности объектов (очереди например). Обновление одиночного объекта не может быть крайним по определению..
И запомните, товарищ подполковник, - по моему пониманию, а значит и по пониманию всего моего экипажа, крайними бывают плоть, Север, мера, срок и необходимость! Все остальные слова маркируются у нас словом последний, то есть позднейший или самый новый, по отношению к текущему моменту!
...
Конечно же, если вы штабной офицер, программист, таксист, какой-нибудь там офисный работник и так далее, то обязательно используйте слово "крайний" вместо "последний" везде где это уместно и неуместно, - так вас будет легче отличать от нормальных людей.
Автор поправьте формулировку предложения, а то...
Учитывая нестабильность в отрасли, увольнения и тому подобное, люди любую должность со стабильной зарплатой.
В целом полностью подписываюсь, я тоже не пройду "ваше техническое собеседование".
Просто не удержался
Из последних случаев, которые считай меня возмутили... Постучался HR, предложил вакансию в известную компанию на букву "Y".
Я очень сообщил, что НЕ в поиске, работаю на проекте, работу менять не планирую, спасибо за предложение. При этом добавил, что в целом вакансия классная и главное - проект тоже интересный.
HR стал просить мол, давайте на собеседование, вам же проект понравился, мы вам там ещё плюшек накидаем, короче head hunting в чистом виде.
Ну я, дурак, взял и согласился. Пришло время собеса, код пописал, на бОльшую часть ответил, где-то потупил, не буду давать сам себе оценку. Самое интересное, последний вопрос на собесе: "Почему ищете работу?", я взял и ответил тупо правду "Я собственно не ищу, меня HR уговорил". После этого подосвиданькались.
Через неделю приходит фидбек "Отказ. Кандидат не ищет новую работу".
Что это было?
Ну вы поймите, надо же людям как-то KPI отрабатывать.
Ну так то если б собес прошёл "на ура", то могли бы и предложить что-то, заинтересовать человека, чтобы он захотел новую работу таки )
Не исключено...
Тогда и напишите типа "не знает всех алгосиков", низкий уровень в leetcode и т.п.
Это проще и не противоречит факту зазывания на собес.
Со слов HRа, цитата, "все впечатление о собесе испортил ответ на последний вопрос"
Ну, на мой взгляд, случился максимально идиотский подход. Компания потратила время, кандидат потратил время. Можно было бы свести это к ситуации win-win, поторговавшись с кандидатом, но нет, мы напишем, что обиделись на кандидата, потому что он не сказал, что всю жизнь искал эту работу и мечтал работать в нашей компании, а сказал всё как есть. Не ищет он работу [в нашей чудесной компании], видите ли, подлец какой ))
Что с программистами не так? Работаю физиком ни разу у меня не было собеседования, чтобы меня не звали на работу. На собеседовании ни разу не просили вспоминать какие-то уравнения, физические величины, решать какие-то модельные задачки на бумажке. Обсуждаем спектры задач, какие разделы физики будут важны, какие ограничения у компании по методам производства и финансирования. Что мешает программистам делать то же самое? Что кодили, на чём кодили, какие задачи решали? Ну типа и всё.
Что с программистами не так?
Тяжкое наследие FAANG-ов.
На это надо минимум полчаса-час чтобы всё обсудить. А теперь представьте что у вас сотня откликов (минимум), из которых больше половины просто устроили массовую рассылку и даже не подходят, но надеются проскочить, часть "тренируется проходить собеседования", некоторые с нарисованным опытом, а действительно релевантных откликов в лучшем случае десятая часть. И на каждого надо потратить время весьма дорогостоящего специалиста, который может оценить кандидата, потому что опыт у всех разный. И это только на одну вакансию.
Что с программистами не так?
Искаженное восприятие реальности, а именно: своего истинного места в пищевой цепочке, навязанного извне (и ими самими) чувства элитарности (отчасти из-за высоких зарплат в лучшие годы). Добавляем сюда инфантильное поведение (от которого многие не избавились к третьему и более десятку своей жизни), какие-то детские комплексы/обиды и синдром "вахтёра", когда вчерашний забитый ботаник (которого ещё недавно в школе окунали головой в унитаз) внезапно получил роль собеседующего и зарплату выше, чем у его вчерашних обидчиков.
В итоге эта ядрёная смесь даёт то, что мы видим: сегодня собеседования в IT - это не разговор специалистов, а разговор двух людей, один из которых (собеседующий) ментально напоминает скорее гопника из подворотни, а не интеллигентного и умного инженера.
Сегодня с большей долей вероятности собеседование на стройку в качестве разнорабочего будет проходить для вас в более дружелюбной и не столь токсичной атмосфере, как в IT. Потому, что если на стройке начать сношать мозги кандидату (особенно, если он с опытом работы и ему за 30 лет) и спрашивать у него, знает ли он химический состав цемента и клал ли он когда-нибудь кирпичи, то у собеседующего есть неиллюзорный шанс как минимум быть посланным, а как максимум - лишиться зубов за неадекватность.
Меня однажды тут, на Хабре, заминусовали за то, что я рассказал как меня, сорокалетнего человека, всю жизнь работающему бекенд-разработчиком, просто выворачивает наизнанку, когда на собеседовании у меня спрашивают "работали ли Вы когда-нибудь со SQL?". Заминусовали ровно по той же причине, что я и описал выше - в IT каждый третий мнит себя чуть ли не учёным, но при этом свято верит в то, что все остальные повально ничего не соображающие дураки. Т.е. такой внутрепрофессиональный каннибализм, когда сожрать ближнего своего и заочно навешать на него ярлыков профнепригодности - это норма.
Вы совершенно правы. В IT так же нет ни одной объективной причины спрашивать "уравнения, физические величины, решать какие-то модельные задачки на бумажке". Это сугубо человеческий фактор членов этого "илитраного" кружка по интересам.
Будьте осторожны, а то вдруг и на вас найдут управу. Например, будут на каждом собеседовании гонять по списку фундаментальных физических констант) Или просить вывести их значение)
никогда не слышал о таких ситуациях, чтобы кому-то в реальности приходилось реализовывать решение из префиксного дерева и поиска за O(n) в рамках тридцати минут.
Поиск за O(n) - это типа все элементы перебрать?
У меня в одной компании было два вопроса:
Как бы я продал билеты в один конец на марс, когда миссия состоится через год и нужно чтобы клиенты не потребовали все обратно
Как бы я продавал домашние установки для термоядерного синтеза
А я пофантазировал и ответил, опираясь на все то, что зачем-то слышал перед сном из всяких около научпоп каналов чтобы быстрее уснуть, ну или просто на фоне ставлю плейлист и там что-то вещают. И мне предложили оффер одному из около 50 вроде кандидатов, но я забил, потому-что перепутал контору, думал у них удаленка. Вообще я не готовился и почти не читал текст вакансии. Уже столько собесов проходил, и просто думаю на опыте затащу как-нибудь ))
Могу лишь отметить, что чем пофигистичнее относишься к подготовке к собесу или не готовишься вообще, тем меньше стресса, тем спокойнее методично отвечаешь на вопросы, ну а тех. интервью в моем случае UX/UI дизайн, довольно просто.
В целом справедливо, но двойственно:
Корпоративный HR не ищет "хорошего специалиста", он ищет "человека-детальку", который, встанет в уже отлаженный производственный процесс "без зазоров".
Встречал в практике ситуации, когда отличный, грамотный, старательный специалист разваливал проект, потому, что не стыковался с остальной командой. Причем именно технически нестыковались.
Вот интересно, как в других отраслях? Ну не одно же IT сталкивается с проблемой поиска кадров. Не берём младшие должности, в любом случае, наверное, нужно профильное образование. Но если это средний специалист или младший менеджер, как автор статьи? Как ищут таких в медицине? В юриспруденции? В финансах? В управлении транспортом? Тоже институтские задачки дают?
Вот да, ну полный бред же эти студенческие знания у динозавров 40+ и 20+ опыта спрашивать.
Представляю как у хирурга со стажем спасения 100+ жизней спрашивают задачу из органической химии, или состав лекарства наизусть со всеми вспомогательными компонентами а потом через месяц: "ну мы тут подумали, вы нам не подходите, и к тому же у вас была лампа накаливания в операционной, а не LED".
Проблема в том что часто и интервьюируют вчерашние студенты уже которым это типа еще норм.
Вот интересно, как в других отраслях? Ну не одно же IT сталкивается с проблемой поиска кадров.
Расскажу, как это ощущается с позиции соискателя на как раз таки начальную позицию (Junior+ / entry Middle). Прошу прощение за многословность, но иначе никак.
Самая большая трудность, это конечно пройти HR фильтр. Так как из-за обилия откликов и неумения с этим работать, HR не тратит больше минуты на просмотр резюме, дойти до технического интервью крайне сложно. За последние 3 месяца я попал только на 5 интервью с HR и 4 технических интервью. В остальных случаях это был либо игнор, либо отказ в ту же минуту, как компания просмотрела моё резюме. В одном случае был отказ из-за недостатка коммерческого опыта (у меня чуть больше года, а в вакансии просили год), в оставшихся 4 я спокойно дошел до технической части.
Ни в одном из интервью не было проверки на знание алгоритмов или структур данных. Да и правда не так часто их приходится реализовывать, чтобы постоянно держать в голове.
Первое интервью можно назвать техническим в кавычках, так как проводил его человек не знающий темы. Это был просто опросник по заранее подготовленной табличке с вопросами касательно разных нетривиальных нюансов синтаксиса. В итоге я не смог получить от них обратную связь, но меня забрили. Хотя вопросы были достаточно простые и я сомневаюсь, что где-то ошибался. Возможно из-за волнения, ведь я тоже начинаю мямлить в стрессовой ситуации.
Второе интервью было тоже достаточно странным. Там был уже настоящий разработчик, но как я понял, он тоже слабо знает язык, указанный в вакансии (Если кому интересно, то это Go). Здесь к моему опыту вопросов не было. Меня сначала закидали вопросами по предыдущей работе, по нюансам реализации конкретных модулей и так далее. Но когда дело дошло до проверки знания стандартной библиотеки, тут появился неожиданный нюанс. На вопрос, как можно запустить в один момент N кол-во потоков (да, я знаю, что горутины, это не потоки, но и Go не все знают, так что упрощаем), я ответил, что это невозможно, ведь так оно и есть, этим делом рулит рантайм. На что получил комментарий, что я ничего не знаю и вообще там есть структура WaitGroup, у которой есть метод запуска нескольких горутин..... И так далее.... Я попытался оспорить это, рассказал как работает эта структура, для чего она нужна и предложил открыть документацию, на что был послан со словами "я и так всё знаю, там точно такое есть, документацию смотреть не будем". Либо я оказался слишком наглым, что посмел поправить тим-лида, либо что-то ещё, но как вы понимаете, получил отказ.
С третьим интервью всё было быстрее и проще. Интервьюер решил применить крайне странную тактику, которая заключалась в немедленном ответе на вопрос не задумываясь. Большая часть вопросов касалась языка и классического стека Redis, Docker, Postgres, но и малознакомые темы тоже были, например шифрование. Местами я просто не успевал сформулировать ответ из-за стресса, как слышал фразу "долго думаешь, значит не знаешь. Идем дальше". Пару раз отвечал неправильно, хотя знал правильный ответ, но доходило до меня это уже позже. В итоге провал с формулировкой "нулевые знания".
В четвертом случае, это скорее не техническое интервью, а просто результат проверки тестового задания. Причем задание было достаточно объемное, на что у меня ушла неделя времени (примерно по 10 - 12 часов в сутки), чтобы не просто написать рабочий прототип, а готовое решение. После отправки задания на проверку я начал готовиться к сессии зашиты, но получил письмо с примерно следующим содержанием: "Знаешь язык, знаешь технологии, но вот нам не понравилось, как ты методы именуешь в нескольких местах и у тебя не чистая архитектура, так как в паре мест прямой юз зависимостей минуя интерфейсы. Грейд ниже ожидаемого, отказ." Даже без диалога, сразу отказ. К слову архитектурных требований не было, как и стайл гайда. Обычно реализуя тестовые задания, люди опираются на предыдущий опыт. Я никак не могу знать, как у них принято именовать методы или что мне нужно было использовать только чистую архитектуру. Да и касательно повсеместного использования интерфейсов, это не даст хев. Из того, что я вижу, тренд идет к отказу от этого дела.
В итоге просто продолжаю поиск, в основном получая отказы в ту же минуту, как hr открыл резюме.
Местами я просто не успевал сформулировать ответ из-за стресса, как слышал фразу "долго думаешь, значит не знаешь. Идем дальше".
Это допрос какой то а не собеседование.
И в целом печальный опыт вы описали конечно.
Но то, что не дай ктулху сильно спорить с собеседующим - это тоже печально но много где, особенно обидно когда у тебя опыта всяко больше чем у собеседующего но он так уверен что он прав что даже аргументированный спор приводит только к недовольству.
И с тестовым заданием жесть какая то еще и неделю потратили. Я бы не стал выполнять что-то объемное, конечно, без каких либо гарантий - уже красный флаг.
"долго думаешь, значит не знаешь. Идем дальше"
это он в Тину Канделаки не наигрался...бывает....
там есть структура WaitGroup, у которой есть метод запуска нескольких горутин..... И так далее.... Я попытался оспорить это, .... на что был послан
так это ж прекрасно! что это выяснилось на собесе, сейчас ты встал и ушел, а завтра он мог быть твоим начальником, у которого ты отпрашиваешься к зубному .....
задание было достаточно объемное, на что у меня ушла неделя времени (примерно по 10 - 12 часов в сутки), .... "Знаешь язык, знаешь технологии, но ..... Грейд ниже ожидаемого, отказ."
скажи: "спасибо, Господи, что взял деньгами!"
а прикинь как бы они тебя дрюкали кабы стал их подчинённым ? ты что не сделал задание, которое я дам тебе завтра?
Когда сам проводил собеседования QA, в первую очередь смотрел на опыт. Если джун — спрашивал теорию, если мидл — интересовался только опытом. Ладно, если кандидат проработал в “Рога и копыта”, возможно, имеет смысл его хорошо погонять. Если у кандидата опыт работы в известных компаниях, как думаете, смог бы он там находиться для галочки хотя бы год? Зачем такого кандидата заваливать вопросами по теории? Сейчас вышел на рынок — через одного на собесе лайфкодинг. Да не пройду я такой собес никогда со своим эссенциальным тремором: у нормальных людей, судя по постам, зубы стучат и в клавиши не могут попасть. А загадки? Ну зачем? Но всех затмило предложение приехать в офис и сыграть в настолку...
Но всех затмило предложение приехать в офис и сыграть в настолку...
Забавно, а что за настолка предполагалась? :) Ну кстати это могла бы быть интересная и неординарная компания как место работы.
Скажу прямо. К it не имею никакого отношения. Сайт почитываю давно, попадается что-то интересное, что можно взять на заметку. Как раз из статей, подобных вашей, можно подчерпнуть что-то интересное и для другой сферы. Но ради данной статьи я даже зарегилась, чтобы дать комментарий.
Описанные вами ступор на собеседовании, глупые ошибки на простых вопросах, мямлить вместо говорить - это оказалось так знакомо, что удержаться от комментария было невозможно
И про провальные собеседования вы совершенно правы. Есть профессии, где не языком молоть надо, а показывать свои навыки на деле
Я не сталкивалась с практическими тестовыми заданиями (в моей сфере это невозможно), но часто спрашивают теорию, когда тебе нужно выстроить алгоритм действий. И там я всегда теряюсь. Ведь есть столько факторов, влияющих на конечный результат, что предугадать их порой невозможно. Отвечаю по шаблону - вы мыслите без фантазии. Начинаешь развернуто - слишком много вольнодумства
Сталкивалась с тем, что в команду отбирали более подходящих по возрасту/общению/интересам, якобы быстрее войдёт в коллектив, не смотря на опыт. Вот такая странная дискриминация. А я оставалась за бортом. Пару раз даже перезванивали, видимо отобранный кандидат не подошёл, предлагали прийти на стажировку снова
По роду профессии сталкивалась с разными её представителями всех возрастов. И на практике правда не поймёшь с чем тебе придётся столкнуться в реалиих, а не за офисным столом.
Из личного опыта.
1. Человек с опытом в 30 лет может оказаться никудышным исполнителем, который приходит "пересидеть, ни за что не отвечать", даже за себя. На критику реагирует болезненно, обижается. Руководство и более опытные коллеги её просто не понимают, ведь она работает идеально, отдаётся полностью, в её понимании. Дошло до того, что на неё порыкивают даже стажёры, видя откровенный вред общей цели. А человек обижается, с его-то опытом недооценивают, слезы на глазах. И дело не в возрасте, у нас работали его ровесники. И возраст ещё молодой, всего 49 лет
Ситуация 2. После выпуска девочка попала в склочный коллектив. Все инициативы обрубались на корню коментариями, вроде "ты ещё зелёная", " Это не твоё дело", "ты всё равно не умеешь". Я её знала как практикантку, после практики мы продолжали общаться. Настоящий огонёк, полный любопытства, желания узнавать новое. Какое-то время лично не виделись, общались через мессенджеры. Думала всё хорошо, а тут она выдаёт, что её травят, дают задачи, которые по силам даже уборщице (и я не утрирую), новому не учат, а ещё и капают на мозг, что получает как все, а работать не умеет. Такое чувство, что человека взяли лишь бы утвердиться за её счёт (я, к сожалению, через это проходила). Уволиться от туда она смогла с трудом, её заявление "теряли. Дважды. К нам пришла зашуганая мышка. Любопытная по-прежнему, но очень осторожная. Два месяца понадобилось, чтобы я увидела ту девочку, что знала до этого. Но при этом вижу, как она всё ещё настороженно оглядывается
Вывод из этих ситуаций таков, что собеседование прошла бы первая дама. У неё опыт, навыки, харизма, умение расположить собеседника. А вторая на это собеседование даже не пришла бы, из-за страха опыта на предыдущем месте, хотя какой потенциал ☺
Спасибо за статью. Она вне профессий. С таким сталкиваются все, независимо от сферы деятельности
Абсолютно и полностью согласен:
Ты можешь отлично справляться с задачами на работе, на протяжении десятков лет. Ты можешь создавать отличные продукты. Ты в принципе имеешь талант вести за собой команду , и находить оптимальные решения...немного подумав, а потом, по ходу работы, ещё подумав.
Но...ты с вероятностью почти 100% можешь завалить техническое собеседование. Работодатель же, потеряв в твоём лице хорошего, опытного специалиста, рискует нанять (и наймет) весьма посредственного, но который сталкивался с подобными задачами на собеседовании ранее.
Объективно лишь одно решение: дать кандидату некий объем работы, за некий испытательный (стажерский) срок, посадить в коллектив - а по итогу проверить и качество работы, и степень срабатываемости с коллективом.
Здесь важно отметить, что многие организации подчёркивают, что главное — это не окончательный ответ. Вместо него оценивается то, как кандидат работает и коммуницирует.
Это в случае, если вы разговариваете с человеком. А в случае если вы решаете контест или что-то подобное, то никакой коммуникации не будет и вас будут оценивать машинально. Вы - всего лишь цифра в столбце результатов таблицы. И разговаривать будут с теми, у кого цифра больше
С какого-то момента, лет так 15-16 назад, я хожу на собеседования практически нон-стоп. При этом я достаточно часто на работе либо нанимающий техлид, либо просто собеседующий. У меня огромная насмотренность и куча интересных навыков.
Так вот. Всё что сказано в статье - правда. Мы просто пытаемся найти хоть что-то в мутных людях, что пришли собеситься. Поэтому и есть фильтры, которые позволят вкатышей откинуть на первом, ну максимум втором этапе.
.... а всё равно ничто не покажет человека лучше, чем испытательный срок.
Если коротко, чтобы узнать как человек работает, нужно чтобы он работал.
А чтобы узнать как он проходить собеседования, нужно чтоб он проходил собеседование.
Испытательный срок? Не?
Я вот спустя 8 лет начал намного лучше справляться с собесами. Я легко прохожу алгоритмические секции сейчас вот плыву только на System Design, но тут у меня просто опыта мало.
Согласен практически со всем. Дело в том, что я, как человек побывавший по другую сторону, скажу, что собес не дает абсолютно НИ-ЧЕ-ГО. Все ответы заучиваются, все задачи (тем более алгоритмические) какой-нибудь олимпиадник знает наизусть и хрен ты поймешь сам ли он додумался до решения или просто пишет тот же код, что писал сто раз, деля вид, что у него это впервые. Я может идиот, но если на собесе мне попадется задачка, которую я знаю, то я об этом сообщу и там уже человек сам решает менять или нет (один раз было, что человек удалил и дал другую, с которой я, на тот момент, не справился).
Но у меня не раз было, что человек круто отвечает на вопросы, он очень крут в коммуникации. И вот вы начинаете работать, спустя две недели оказывается, что в командном взаимодействии он никакой. Да, он ответил мне, что такое эвакуация в мапах, но ты даешь ему задачу и он не может ее решить.
Поэтому, как в одной статейке я когда-то прочитал, моя формула такова - собесы = удача * (знания + субъективное мнение). Все думают помнят пост про то, что Линус Торвальдс как-то не прошел собес в одну компанию :) Это не делает его плохим спецом (пусть он не идеален, как и никто в принципе), но и говорит это о многом в то же время
Из прошлогоднего интервью на одну галеру:
— Что-то вы часто в документацию смотрите.
— Я только на этой неделе писал на пяти языках (а их реально было 5 и это я ещё не стал говорить о естественных языках, где помимо стандартных русского и английского сталкивался с грузинским, ивритом и испанским). Я знаю, где посмотреть — этого достаточно.
— Ну не-е... Надо наизусть знать!
Сейчас зачастую складывается ситуация, когда по итогам собесов рекрутеры получают не оценку релевантности кандидата конкретной позиции - а оценку того, насколько человек подготовился к собеседованиям. Усугубляют эту ситуацию типовые вопросы, которые на 80% повторяются - даже в разных компаниях.
Мы для себя нашли выход в применении кейс-интервью.
Лично я получаю более качественный сигнал от собеседований в виде свободного общения или STAR
Ага, то есть человек, который не любит "Smalltalk", но отлично справляется с работой имеет почти 100-процентный шанс завалить ваше интервью. Хотя если вам нужны болтуны, а не технические специалисты, то, наверное, тоже хороший вариант.
Ну а в целом вы повторяет ту же ошибку, которую находите у любителей проводить "технические" интервью. Вы, почему-то считаете, что ваши методы оценки более универсальны и лучше подходят другим, чем их методы. Вашим STAR вы точно также забракуете хороших кандидатов просто потому, что они не умеют проходить STAR интервью. Какой из вариантов бракует больше хороших кандидатов - я не знаю.
Вообще, человек, который считает, что умеет проходить STAR интервью, находит именно эти интервью ценными. Тот же, кто умеет "в алгоритмы" считает ценными алгоритмы и умеет извлекать качественный сигнал именно из них. Все могут ошибиться и получить не тот сигнал. Но если человек умеет проводить какой-то тип интервью, то именно из этого типа интервью сигнал будет наиболее качественным. Поэтому кто-то проводит тех интервью, кто-то просто болтает и т.п. Реально плохой результат будет тогда, когда всех интервьюеров заставляют использовать одну и ту же методику, в которую умеет один , а другие - нет.
Поэтому я приходил в каждую из компаний, практически ничего не зная о пространстве её задач, а затем быстро становился специалистом в той или иной предметной области.
Для того, чтобы справляться со своей работой, я накапливаю контекст и понимание решаемой задачи.
работал в таких организациях, которые раздают подготовительные материалы к своим собеседованиям. Как же так? Разве многих лет опыта недостаточно для подготовки? Я готовлюсь к должности или к самому собеседованию? Зачем мне нужна специальная подготовка…
Как раз для того, чтобы проверить как вы усваиваете новый контекст для новых задач, и разбираться в нем, в свободной бесконтрольной обстановке без тикающего таймера, в своем собственном темпе/режиме.
Разве это не то, в чем как раз заключается ваша сила?
Другое дело, что на практике это скорее проверяет насколько я готов посвятить себя этой компании, чтобы бесплатно этим всем для них заниматься, зная, что именно в эту конкретную компанию я скорее всего не пройду просто статистически.
На 10 таких компаний, я физически могу успеть хорошо подготовиться только к одной. Видимо, такие компания отбирают уже из тех, кто больше всего подготовился именно к их контексту, т.е. из тех кто воспринимает эту возможность важнее других, и с меньшей вероятностью начнет сливаться в последний момент (ибо FOMO)
Но, чаще всего, технические собесы проводят люди без какого-то глубокого анализа и понимания. Чаще всего, это либо вчерашние мамкины комочки детских комплексов, которые уже досидели до сеньорской позиции и прочитали кучу книжек по алгоритмам, но не-технических вопросах продолжают вслепую мимикрировать под какого-то авторитетного коллегу, без понимания почему именно так; либо профдеформированные зазнайки, которые считают, что если лично у них в работе встретилась какая-то аббревиатура, то значит все кто идет на смежную позицию обязаны эту аббревиатуру знать, и никак иначе. Последние еще громче всех жалуются на кадровый голод обычно.
Поэтому я приходил в каждую из компаний, практически ничего не зная о пространстве её задач, а затем быстро становился специалистом в той или иной предметной области.
Для того, чтобы справляться со своей работой, я накапливаю контекст и понимание решаемой задачи.
работал в таких организациях, которые раздают подготовительные материалы к своим собеседованиям. Как же так? Разве многих лет опыта недостаточно для подготовки? Я готовлюсь к должности или к самому собеседованию? Зачем мне нужна специальная подготовка…
Как раз для того, чтобы проверить как вы усваиваете новый контекст для новых задач, и разбираться в нем, в свободной бесконтрольной обстановке без тикающего таймера, в своем собственном темпе/режиме.
Разве это не то, в чем как раз заключается ваша сила?
Другое дело, что на практике это скорее проверяет насколько я готов посвятить себя этой компании, чтобы бесплатно этим всем для них заниматься, зная, что именно в эту конкретную компанию я скорее всего не пройду просто статистически.
На 10 таких компаний, я физически могу успеть хорошо подготовиться только к одной. Видимо, такие компания отбирают уже из тех, кто больше всего подготовился именно к их контексту, т.е. из тех кто воспринимает эту возможность важнее других, и с меньшей вероятностью начнет сливаться в последний момент (ибо FOMO)
Но, чаще всего, технические собесы проводят люди без какого-то глубокого анализа и понимания. Чаще всего, это либо вчерашние мамкины комочки детских комплексов, которые уже досидели до сеньорской позиции и прочитали кучу книжек по алгоритмам, но не-технических вопросах продолжают вслепую мимикрировать под какого-то авторитетного коллегу, без понимания почему именно так; либо профдеформированные зазнайки, которые считают, что если лично у них в работе встретилась какая-то аббревиатура, то значит все кто идет на смежную позицию обязаны эту аббревиатуру знать, и никак иначе. Последние еще громче всех жалуются на кадровый голод обычно.
Когда готовился к собеседованиям - в 90% случаев дико тупил и лежал.
Когда пустил процесс на самотек - собеседования перестали приносить дискомфорт, появилась уверенность и, как следствие - больше офферов :)
Автор статьи напрямую не предлагает конкретных альтернатив проведению технических собеседований. Он скорее ставит под сомнение их эффективность и призывает задуматься о том, что они на самом деле оценивают.
Однако, исходя из критики автора, можно выделить несколько неявных рекомендаций:
Снизить значимость или отказаться от алгоритмических задач и задач на структуры данных (оценка кодинга/leetcode) для большинства должностей. Автор утверждает, что в реальной работе такие задачи встречаются редко, и их решение на собеседовании не отражает реальных навыков разработчика.
Быть осторожным с задачами на разработку приложений с нуля. Автор считает, что они не реалистичны и не мотивируют кандидатов, так как являются "работой на выброс".
Применять задачи на проектирование систем только для должностей, где это действительно необходимо (архитекторы, ведущие инженеры, инженеры-управленцы). Автор ставит под вопрос необходимость такого типа собеседований для всех разработчиков без исключения.
Признать, что запоминание конкретных алгоритмов и структур данных не так важно для разработчиков вне позиций начального уровня. Автор подчеркивает, что важнее понимать принципы, а не помнить наизусть детали.
Понять, что существующие форматы собеседований могут давать преимущество кандидатам, которые специально готовились к ним, а не тем, кто обладает реальными навыками.
Основной посыл статьи - это призыв к переосмыслению подхода к техническим собеседованиям. Автор не предлагает готовых решений, а скорее подталкивает читателя (в первую очередь, менеджеров по найму) к самостоятельному поиску более эффективных методов оценки кандидатов.
По сути, статья фокусируется на проблемах, а не на решениях. Автор подчеркивает недостатки текущего положения дел, чтобы стимулировать дискуссию и поиск альтернатив в индустрии.
Почему я провалю ваше техническое собеседование