×

Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

[Об авторе: Николай Лотоцкий — более 15 лет занимается разработкой программного обеспечения. Знаком со всеми этапами работы на проекте и развил карьеру от должности QA Engineer до Technology Expert. Несколько лет был JavaScript Software Architect и принимал активное участие в разработке сложных масштабируемых приложений. Кроме того, есть опыт работы с PHP, .NET, Python. Более трех лет проводит различные курсы и тренинги]

В прошлой статье я затрагивал тему подготовки соискателей для вхождения в отрасль. Теперь давайте же посмотрим на проблему нехватки специалистов с другой стороны баррикад. Никогда проблема не бывает односторонней, если в ней задействована больше, чем одна сторона.

Техлид хочет видеть в соискателе самого себя

Сначала давайте разберемся, кто создает описания вакансий? Их создают техлиды. Как по мне, основная проблема в том, что каждый техлид хочет видеть в соискателе самого себя. То есть берем свой опыт, отнимаем от него 5-6 лет, берем свой багаж технологий, отнимаем от него то, что за эти 5 — 6 лет совершенно устарело, и вуаля — готовы требования к кандидату. По итогу нам нужен перспективный джун с опытом работы не менее 10-12 лет, со знанием PHP, JavaScript, .NET и Python и желанием выучить GoLang. После этого добавляется английский, знание процессов и методологий гибкой разработки. И как вишенка на тортике — «Большим плюсом будет»: опыт работы с BigData, опыт в создании нейронных сетей и т. д. Так гордо вырисовывается пунктиром портрет вашего техлида, помолодевшего на 5 лет и не отягощенного знаниями COM, VisualBasic и WinForms.

Когда рекрутер получает такую заявку, полагаю, что волосы у него на голове и не только на голове, встают дыбом. Потому что, если и есть такой человек, то это Толик из R&D, который составил описание требований и который и так уже работает у нас. Далее все бегут к проектному менеджеру, к которому, собственно, человек и пойдет работать, а он гордо заявляет рекрутерам: «Такие люди есть, и их много, вы просто плохо ищете». Ну и, как говорится, завертелось.

Зреет всеобщее недовольство

Теперь мы перемещаемся на два-три месяца вперед. Поиск кандидатов не принес желаемых результатов. Проектный менеджер давит на рекрутеров, потому что они плохо ищут. Всем рекрутинговым агентствам были обещаны бонусы, превышающие средний бюджет маленькой африканской страны. Техлид, который составлял вакансию, рассказывает, что в его время и народ был смышленее, и деревья выше, и вообще на дворе сплошной мрак, деградация, разврат и коррупция. А проектная команда либо же овертаймит, как Стаханов в забое, или же многие проектные активности были поставлены на паузу.

В любом случае заказчик теряет деньги, качество продукта страдает, а также зреет всеобщее недовольство. У проектного менеджера — рекрутерами, у команды — овертаймами, рекрутеры так вообще ненавидят всех — от техлида до кандидатов, которые каждый раз не подходят по критериям (ребята, без обид, но так оно и есть).

Что делать

Надо разбираться, что мы делаем не так? Как можно выйти из тупика, который не выгоден никому. В этой ситуации все находятся в проигрыше: перспективный кандидат не может найти работу, мы не можем удовлетворить всех потребностей заказчика, команда не может нормально функционировать, так как у ее членов совершенно нет времени. Конечно, можно пойти по пути «сильных» людей и обвинять в своих несчастьях кого-то третьего, а лучше всего списать все на конъюнктуру рынка и поколение дегенератов, но мы не будем так делать и разберемся, что мы делаем не так.

У меня есть одно правило. Если каждый новый шаг требует у меня на порядок больше усилий, я останавливаюсь и пытаюсь понять, что все-таки идет неправильно. Может дело не в обстоятельствах, а во мне? Может изначально, что-то было сделано неверно?

Первое — нужно описывать не того, кого хочется нанять, а обязанности, которые будет исполнять тот или иной работник. Если нам нужен формошлеп, то не стоит писать в требованиях «большим плюсом будет знание теории нейронных сетей». Нет, я не предлагаю снизить планку в ноль. Но, по-моему мнению, планка прохода должна быть снижена до приемлемой величины, и задирать ее не имеет никакого смысла — можно потерять очень хороших перспективных кандидатов.

Второе, что стоит сделать, — это поговорить проектному менеджеру с техлидом. Техлид должен осознать, что если не будет человека, то ему придется делать все самому, а также, самое сложное, — что сам он не успеет сделать всего намеченного, потому что у него есть семья или личная жизнь, хобби, планы на отпуск и так далее. Да, он может описать своего идеального кандидата. И рекрутеры могут параллельно с низким приоритетом искать этого супермена. Но полагаться на такую позицию нельзя ни в коем случае, так как ее закрытие — дело случая. А все, что связано со случайностями, а не четким процессом, нам в бизнесе не подходит. Да, мы можем себе позволить положиться на волю случая, когда у нас есть неограниченный ресурс времени, но это бывает редко и в основном только в продуктовых конторах.

Третье, что надо сделать, — поговорить с рекрутерами. Может, ищем не по тем критериям? Может, стоит показать пару-тройку страниц LinkedIn, по всем параметрам подходящих под требования? Может, стоит рассказать, кого еще мы можем рассмотреть, чтобы расширить поле поиска. Техническим парням нужно осознать, что рекрутеры, какие бы толковые они ни были, не обладают тем бэкграундом, который позволил бы им расставить допуски в поиске кандидата.

И четвертое, самое сложное. Надо мыслить на перспективу. Может, стоит взять кандидата на вырост? Может, кому-то стоит дать шанс? В некоторых случаях можно пойти на минимальный риск. Если вы видите, что человек адекватен, ему интересен ваш проект и он полон способности работать, то почему бы и нет. Вам же кто-то когда-то дал первый шанс? Попробуйте, по крайней мере, у вас всегда есть в запасе испытательный срок. Да этим не стоит злоупотреблять, но и пренебрегать этой возможностью тоже не стоит.

Итак

  • Всегда надо исходить из должностных обязанностей человека, а не из хотелок к нему, иначе дело затянется на неопределенный срок.
  • Нельзя выставлять завышенные требования. Они должны быть составлены на основе тех должностных требований, которые вы предъявляете к кандидату.
  • Не бойтесь давать адекватным, я подчеркиваю, адекватным людям шанс. Пробуйте брать людей на вырост.
  • Пытайтесь смотреть на мир реально и не пытайтесь воевать с окружающей реальностью, потому что именно она определяет ваше бытие.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному2
LinkedIn

Схожі статті




Найкращі коментарі пропустити

В нашу супер перспективную контору с гениями внутри и офисом в районе мухосранска нужен толковый джун который закончил Хогвартс и проработал не менее 40 лет. Будет плюсом, если Вам не более 20 лет:) И конечно, он должен знать язык на уровне переводчика: птиц, змей и единорогов.

Смешно? А мне нет. Это реальные требования ИТ контор. Замените только Хогвартс на пару высших ИТ образований, а все остальное на огромный стэк технологий который нужно знать и иметь опыт коммерческой разработки от 1+ года. И не забудьте после тех. собеседования ещё сделать нормальный продукт, типа как тест задание.

А после этого мы Вас просто проигнорим: даже не перезвоним и не скажем результатов. Потому что мы — большая и именитая контора к нам все хотят: а вы никто и звать вас никак.

И при этом, посмотрите на рынок труда: катастрофическая нехватка мидл и сеньор во всех компаниях. Ну так откуда же они возьмутся, если у джунов требуют умение летать на гриффоне и разговаривать с ящерицами при «входе» в ИТ? При этом, половина того бреда, что спрашивают на собесах и пишут в требованиях к вакансии вам просто не понадобиться в работе.

ПС. Под «большая и знаменитая» я вполне себе конкретно :) имею ввиду одну очень известную ИТ контору. Но зачем включать «вентилятор», правда? Просто пометим этот класс ключевым словом «abstract».

Я бы просто снял ограничения по возрасту и вск остальные проблемы решатся легко, люди сам потянутся к вам. И еще — размер зарплаты имеет значение

По факту стаття вийшла про проблеми найму сіньорів.

Не розкрита в статі тема 5 — бажання техліда напхати у проект максімум технологічних рішень. Де потім знайти людину, яка все це знає? Адже команда вчила ці технології одна за одною, а часто навіть знання нерівномрно розмазані. Не рідко лише одна людина знає первну технологію зі списка, а все разом не знає ніхто, навіть всередині проекту.

Але кори приходить ПМ/HR і питає які технології використовуютсья на проекті (навіть окремо у бекенді чи фронтенді) — він отримує свій фантастичний список :)

Технічні спеціалісти, з того що я бачив, не оцінюють вплив своїх рішень на вартість підтримки проекта, вартість розширення команди (включно з пошуком) і ризик, що хтось піде з проекту.

Хороша стаття, якщо її прочитають ті, кому вона адресована, буде ок.

Не побачив чи не найважливішого пункту — співбесіда.
Якщо з опису вакансії повикидати все непотрібне, а на співбесіді умовного джуна питати нейронні мережі і просити писати код обходу червоно-чорного дерева на листочку, то так теж нікого не наймуть.
Також дуже фіговим патерном на співбесіді є ситуація, коли тім/техлід читає різні науково-популярні статті і починає питати на співбесіді питати різні екзотичні випадки з цих статей.
На таке запитання найкращою відповіддю буде: «В проекті таке використовуєте? Ну то навіщо питаєте?».
А взагалі, якщо вам не потрібна людина з вузькоспеціалізованим скілом, який вийде на роботу завтра і зробить, те, що потрібно «на вчора», то, на мою думку, вам може підійти будь-який технічний спеціаліст з непоганими базовими знаннями. Задумайтесь, чому faamg компанії набирають людей не на конкретний фреймворк, а в компанію.

ИМХО, Техлид не основной источник проблемы. Человеческий фактор конечно есть и эго есть, но не в них основная проблема. Проблема в неправильных ожиданиях менеджеров. И нежелании компаний тратиться на обучении джунов. Вы можете написать в вакансии что угодно, но у менеджеров есть четкое ожидание — больше людей это больше сделанной работы в единицу времени. Нанять людей, чтобы получить ухудшение показателей (даже временное) никто не хочет. Деньги лучше объясняют причины происходящего, чем вера в плохих людей. Я был в роли тех, кто проводит собеседования и собирает требование на вакансии. И нет, Техлид не хочет (точнее это не основная причина) видеть в соискателе самого себя. На него обычно давит менеджер и компания в целом. Именно они хотят платить как за джунов, а получать работу как от сеньоров. Техлид не управляет бюджетами, но отвечает за проект и прогресс. Требования это единственный защитных механизм, который у него есть. И собеседования часть этого. Думая о добавлении людей в команду, он думает — а разгрузит ли его этот человек или только добавит ему работы. Техлид хочет иметь в команде надёжного человека, которому можно делегировать задачи и не бегать за ним. При этом он осознаёт, что если человек не будет справляться, то ему придётся делать работа за двоих. У него обычно мало времени и делать чужую работу он просто не может себе позволить. Объяснять потом, что новый человек оказывается ещё долго будет учиться достаточно сложно. Особенно, когда компании ожидают быструю отдачу от новых людей.

205 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Все верно подитожино!!!!! Четкие мысли!!!! Надеюсь дойдет до многих в IT.

По этому поводу мне очень понравилось высказывание, думаю начинающим будет полезно услышать. youtu.be/_optSIMTHR0

Если долго крутить носом, можно потерять весь проект. Долгий поиск каждого специалиста это проблема для бизнеса. Бизнес склонен решать проблемы кардинально, производство должно быть либо возле рынков сбыта либо возле ресурсов. если в этом регионе (читай городе, стране) недостаток нужных ресурсов, бизнес уедет туда где их полно. Но только уедет целиком, не только новая не закрытая вакансия, а и позиция тех. лида, который долго крутит носом, станет вакансией в другой стране.

Класс! Респект! Реально!
...но выход из ситуации в решении парадокса, с которым мы стыкаемся дальше...

Вы описали тим лида «делай как я» — собственно не лучший вариант.
В лучшем варианте команда состоит из специалистов, дополняющих себя.
Когда команда исчет нового члена?
Когда не хватает специалиста в определенном направлении, в котором «знания команды поверхносны».
Ейчары нахрдят такого специалиста и команда пробует его протестировать на знания. То есть — имея в лучшем случае поверхностные знания, пробуют тестировать человека с глубокими знаниями... И что? Скорее всего они скатятся на тестировании тех знаний, которые они уверено знают и будут его тестировать по направлениям, которые никак не актуальны для команды.

Вывод. Любое тех.собеседование изначально тупо. Сейчас с миллионом страниц в интернете со всеми теоретически возможными вопросами и ответами... в лучшем случае получите зубрилу, который впоследствии всех вас достанет своей тупостью и ограниченностью.

Выход. Самый важный показатель для кандидата — насколько Вы сможете с ним работать. Поверьте — адекватный человек, вписавшийся в вашу команду, всегда найдет себе правильную нишу. В худшем случае сам уйдет.
С другой стороны предыдущий опыт работы — всегда опыт командной работы, опыт успехов и неудач. Есть опыт — есть ситуации. Есть оценка ситуации. Ваша и кандидата. Анализируйте вместе и вы с большой точностью увидете какой будет кандидат дальше...

А все остальное ерунда. Поймите это.
Вот один «придурок» теч.лид на моем собеседовании на тимлида начал расспрашивать «как определить абстрактный класс». Верите, эту фирму я надрлго себе записал как такую, в которой никогда не буду работать... :)
Не, или давайте от бухгалтеров требовать написания диктанта... :)

Уже даже перестал спрашивать по хотелкам кастомеров/рекрутеров, спрашиваю то что в резюме написано... многие сыпятся даже на этом.
И это при том что я не девелопер, а инфрастуктурщик, тут некоторые вещи 10 лет не менялись.

... так и по разработкам! Участие в команде на любом проэкте — определенная роль, котопую человек выполнял. ...может чел просто делал всей команде кофе и рассказывал клиенту на правильном английском анекдоты, пока каманда думала что ему ответить... :)

Я как-то не сталкивался с такой проблемой на практике. Не знаю. В основном вакансии достаточно адекватные, в том случае если они созданы компанией, а не HR агентством, и предназначены для того, чтобы найти сравнительно узкого специалиста. Например, эксперта в React. Не получится попасть в компанию, если написать в резюме, что мол я знаю javascript, на реакте я правда написал только один пет-проект, но вы меня возьмите, я разберусь по ходу, отвечаю. Уж как компании изгаляются, чтобы найти нужных людей, и не могут. Например, наш бывший СТО рассказывал, что количество откликнувшихся на вакансию резко скакнуло вверх, когда он просто упомянул в вакансии, что нужно будет «переписать с нуля наш текущий клиентский дашбоард». :)

Тут на ДОУ и на других джоб-порталах есть описания вакансий для джунов с адекватными требованиями. Но при этом некоторые из этих вакансий висят по полгода и больше, как бы намекая, что ищут джунов-единорогов и это при том, что кандидатов хоть отбавляй...

И кроме этого, как сказал один умный человек — менторская экспертиза есть не у всякой компании

...чесно, не понимаю. Это что, на Амазоне бесплатный вариант уже прикрыли?
Доков по любому фреймворку миллион. Потрогать, попробовать... ну пять минут...
Разве не интересно просто посмотреть, потрогать, разоьраться???
Интерес — двигатель технологий!

Счас фреймворков обычно очень много — именно в этом и причина всех бед — все хотят что-б был кандидат который работал именно на этом фреймворке — а взять кагндилдата который работал на другом но за 2 месяца выучит этот — не хотят .... — вот и висят вакансии по пол года

Но человек не может работать одновременно на 2-х, 3-х. Либо на одном, либо на втором, либо на 3-м, либо по очереди. То есть ты себя уже в 3 раза ограничиваешь.
Ты ищешь получается не программистов, а фреймворк разработчиков)

...на лайт-технологиях единственный правильный вариант — тестовое задание.
Вот год назад пришлось отбирать на курсы из 300 Джунов. Дал им тестовое на уровне Сениора. 30 человек решили.
После моих полугодовых курсов на английском и полугодового опыта работы в команде (5 команд по 6 человек) — 12 из них уже работают сениорами, остальные — оч. увереные мидлы. И то всго лиш от «недостаточной уверенности в возможности потянуть обязаности сениора»... («...ну я ещё немного поработаю мидлом...»)...
И это «типа джуны». Правда, Java.

Конечно, может быть и такой вариант. Но не стоит упускать из виду, что компания растет и за год у них идет набор сотрудников с типовыми профилями. Вы думаете, что единорога ищут, а они уже 7 джунов подобных застафили.

Опасная статья с однобоким перегибом. Очень слабо выраженно, что речь в статье идет именно о джунах, а не в целом о проблеме хайринга. У меня сейчас кейс, мне нужны люди на проект с шефом, терраформом и амазоном. В бекграунде есть саппорт легаси с паппетом и клаудформешном. Мне нужны люди в первую очередь с правильным майндсетом, с пониманием зачем нужно писать тесты, делать CD, селф-сервис и вот это все. Но мне так-же нужно, что-бы человек пришел и сразу начал писать кукбуки и модули с тестами, коих нам нужно в большом количестве. Мне присылают толпы кандидатов, которые позавчера были админами а вчера скриптили что-то очень базовое на ансибле. И намекают, что я каких-то единорогов ищу. Такая статья мне абсолютно не помогает.

Техлид должен осознать, что если не будет человека, то ему придется делать все самому, а также, самое сложное, — что сам он не успеет сделать всего намеченного, потому что у него есть семья или личная жизнь, хобби, планы на отпуск и так далее.

А если сделать как в статье предлагается, то по факту придется бебиситить всех нанятых вместо своих прямых обязанностей. Не поймите меня не правильно, статья справедлива и работает для 90% случаев, но точно не для сеньоров и точно есть проекты где нужно поднапрячься и отхватить кусок пирога создав еще десяток рабмест в перспективе на которых уже и можно будет неспешно набрать джунов и раскочегаривать их.

Пытайтесь смотреть на мир реально и не пытайтесь воевать с окружающей реальностью, потому что именно она определяет ваше бытие.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. © George Bernard Shaw

У меня все норм в JD. А еще fyi есть тут некоторые конторы, которые за 25к человек, которые вообще не выходят на рынок за кандидатами, они сначала хайрят просто «к себе» в пул, а потом из пула предлагают на конкретные проекты.

То есть писать кукбуки и тф модули на сегодняшний день это уже «чимало». Простите, что по вашему должен уметь среднестатистический мидл-девопс на его среднерыночную зп? Заходить по ссш на сервер?

мне нужны люди на проект с шефом, терраформом и амазоном
Мне нужны люди в первую очередь с правильным майндсетом, с пониманием зачем нужно писать тесты, делать CD, селф-сервис и вот это все.

Для информации описано что есть в бекграунде на проекте, но это не имеет ничего общего с реквайрментами на позицию. Хотя-бы ИЛИ шеф ИЛИ терраформ квалифай на мидла, на синьора и то и другое. Не надо перекручивать плиз..
Еще раз, приходят вчерашние админы с каким-то базовым количеством ансибла в сиви и считают себя синьорами. Это я то быкую? :)

ИМХО не хватает покуляризации темы кто такой девопс...
Как тимлид дев Java скажу что даже для меня, с опытом суппорта, хороший девопс — чтото типа волшебника.
Слаженость работы девов, QA, девопсов и релайзеров — основа успеха любого проэкта...

Знаю одну успешную траснационалку... 60 офисов по миру, начиная с Сан-Франциско-Бей, гдето 700-800 команд девов, 200-300 команд QA, окола ста команд девопсов и ...одна релайзеров...

..потому, совет один по девопсам.
Делайте так, как делали мы, девы, 20 лет назад. Ищите командныз игроков и учите. Без вариантов. И, поверьте, будет еффективнее...

...автор писали про чтстых дэвов.
И написано актуально.
По девопсам...
Во-первых, очень молодое до сих пор направление
Во-вторых, более требовательное к тому «каков человек есть».
Если взять, например, 30 архитипов по Юнгу, то для дэва подходить шесть архитипов, а для девопса всего два. И это при том что на админа все 15-ть... :)

...а тяжелее всего с релайзерами...

На початку ніби йде мова про початківців, а потім «В любом случае заказчик теряет деньги, качество продукта страдает, а также зреет всеобщее недовольство. У проектного менеджера — рекрутерами, у команды — овертаймами, рекрутеры так вообще ненавидят всех — от техлида до кандидатов, которые каждый раз не подходят по критериям (ребята, без обид, но так оно и есть).» — якщо є якісь очікування стосовно продуктивності, то ми вже шукаємо мідла, а не джуна. Джуна ще 1-3 місяці треба буде бавити, що значить втрата продуктивності ще когось в команді і від людини навряд чи буде якийсь якісний результат.

Який реальний відсоток джунів з тих, хто вважає себе джуном?

..насьогодні, джун, мідл та сеніор — це не рівень знань, а досвід роботи в команді, досвід пошуку знань та досвід брати на себе відповідальність...
Тож, якщо Ви правилтний тімлід — будете бавитися з усіма, якщо потребуватипе ефіектмвної команди. Ж бо кожна команда грає за своїми правилами...

На мой взгляд все очень правильно написано.

Написано все правильно, но тема до конца не раскрыта. Технический специалист, герой этого топика — это не обязательно техлид. Зачастую это синьер или даже крепкий мидл, тянущий на себе весь проект (большую его часть). Он и дальше не против тянуть все на себе, но хотелось бы зарплату по-больше. А вместо этого ему предлагают помощь (читай частичную замену). Через месяц безуспешного поиска по его же критериям, он думает: «Ну что, нашли такого спеца, как я, суки? Не цените вы меня...»

Тоже отдельная статья будет посвящена теме заменимости и незаменимости и вообще подбору тим и тех лида

Я бы просто снял ограничения по возрасту и вск остальные проблемы решатся легко, люди сам потянутся к вам. И еще — размер зарплаты имеет значение

А что в IT компаниях на технические должности ещё где то есть ограничения по возрасту?

Ну примерно в половине, планка ограничения тоже на разном уровне.

Просто вы еще с этим не сталкивались.... Есть и явные, и неявные.

Прикольный вопрос.

Есть, как мне кажется гдето у 75-90% украинских работодателей. Хотя и утверждают публично обратное.

Нанимался я в одну контору джуном, мою резюмеху одобрили, назначили собес, на собесе нормально общались, пока внезапно не поменялась атмосфера. Как потом мне рекрутёр «мягко» объяснил — увидели мой возраст. И как само собой разумеющуюся вещь мне сказали, что «в 30 лет быть джуном — поздно, извините, но мы, наверное, ищем кого-то перспективнее». Таким извиняющимся тоном. Возможно, это был обычный съезд и/или и вообще наняли уже человека на позицию, а меня нужно было как-то слить — не знаю, но вот такое было у меня лично. Афишировать компанию не буду, незачем портить людям перспективы. Ну и всегда есть вариант, что я был плох — но тогда зачем было меня на собес тащить?)

Мне на данный момент 36. Ну что тут скажешь... Как есть, я свои года не могу к сожалению назад отмотать (а хотелось бы :) ). Меня спрашивали про возраст (хотя зачем, в резюме все указано) после окончания беседы уже не перезванивали. Может на собесе что-то не так было, а может что-то похожее, что Вы написали в своем посте. Не знаю... Как я понял, игнор после собеседований это отличная практика среди ИТ-компаний.

возможны исключения. например, если на вчера нужен матлабер с коболом, то не отказываются от сорокалетних дедушек.

... со знанием кобола. єто важно бггг

Просто в современном мире без знания программных инструментов ты ничего в подобных областях не сможешь.

Ось тут не погоджуюся. Шукайте позиції, де фігурує R&D. Я працював у команді, де інші знали програмування на початковому рівні, але були одними з ключових працівників компанії. Двоє мали ступінь професора, один перед тим вивчав Data Science у King’s College у Лондоні. І вони могли без глибокого знання програмних інструментів, тому що в команді був я, який розумів, про що вони говорять, і допомагав з реалізацією ідей.

Я не сказав би, що вони нічого не робили. Читати наукові статті, описи існуючих релевантних реалізацій, думати, обговорювати — це теж робота. І теж може принести гроші компанії. А перевіряти можна, якщо є у розпорядженні хтось, хто може зрозуміти ідею і допомогти з реалізацією.

Ну, це була компанія, засновником якої був виходець з Ізраїлю. А ця нація вміє рахувати гроші як ніхто інший)))
Давайте вгадаю: Ви ніколи не подавалися на R&D вакансію?

А, тепер все зрозуміло: замовники були не з Заходу...
Знайти хорошого спеціаліста з досвідом дослідницької роботи і хорошим знанням програмування значно важче, ніж 2 людей, кожен з яких має щось одне.

Я понял. Спасибо. Печально конечно.... Значит шансы еще меньше, чем я думал ранее :) Ну, все равно кодить я не перестану. Когда что-то нравиться — оно становится хобби :)

Понятно. 4 года искал работу.... (Тут следует драматичная пауза с моей стороны). Как сказал один очень известный киногерой: Уже слишком поздно для меня, сын ©.

Я могу Вам так еще сказать: если компания смотрит на возраст, то есть большая вероятность того, что случиться так, что у нас все молодые и перспективные с горящими глазами, а работать некому. Заказчику это не понравиться.
Таким компании лучше сразу отвечать: Вы кто такие? Я Вас не не знаю! Идите на .... :))))

Я не отказываю как Вы говорите, хрюшкам. Любое собеседование это опыт для меня. Позитивный результат был, но меня не устраивала сама компания. Детали конечно не раскрываю как и почему.
У меня есть знакомые, которые устроились работать в ЕПАМ в 40+ на джунов. И ничего, уже мидлы в свои 42. Работают — нравиться, довольны и рады, рассматривают предложения на релокейт.

Да, мне 36 лет. Да, я еще молод. Да, я senior в аналитике/экономике. Да, я хочу сменить профессию на кодера, не смотря на то, что потеряю в несколько раз в деньгах (не мне говорить, сколько аналитики получают). Мне это не важно. Мне нравиться кодить. Я знаю свои знания и что я умею, и мне насрать, что обо мне думают не совсем адекватные собеседующие. Пусть думают. Это их проблемы. Я знаю, что я буду полезен конторе в которую устроюсь. И я все равно получу то, что хочу.

Исключено. Я уже допустил эту ошибку 10 лет назад. Она мне стоила очень дорого (не по деньгам). Никакой аналитики/экономики. Я зайду со стороны девелопера. Если конторе будет нужна помощь как аналитика, то конечно я помогу на втором фронте — опыт и знания ведь никуда не денутся.. Но при условии, что я буду девелопером. Точка.

Ошибка потому, что я пошел не «позову сердца» ,а позову «денег». Да, вот так вот пафосно.

... поверьте, что кодер — это худшее, чем может стать аналитик. Ставайте програмистом.
Кодер — ремесленик, тупой и ограниченный.
Программист — мастер, креативный, разносторонний и «дух реальности нереального»...

Ни один програмист не скажет — этого сделать нельзя. Для програмиста сделать можно все. Вопрос как, вопрос в средствах и адекватных временных рамках...

Будьте програмистом. Кодеров хватает...

Любий каприз за Ваші гроші! :)
Просто є речі, котрі зробити можливо, але ще ніхто не додумався як...
Хоча — дякую за ідею! ...а то судоку вже набрид... :)

Какое интересное сравнение... Есть над чем подумать. Хм... Знаете, я был бы рад, если бы человек Вашей философии попался мне на одном из собеседований.

Я же не сказал что, именно он должен быть. :)

Да, тут я с Вами согласен. Поэтому многие работодатели и позволяют себе просто игнорировать кандидатов, если вдруг им не понравилось что-то на техническом собеседовании — да банально «морда лица не такая» :) . Потому что на это место приходят сотни резюме — это не нравится — придет еще 10 вместо него. Вот прошел собеседование, потратил свое время — отпросился с работы и т. д. Побеседовал... И тишина... Словно тебя и нет :)
Зато мидл и выше катастрофическая не хватка. Парадокс получается.

...эта проблема есть на всех уровнях. Ейчары у нас многопоточники и иногда боятся сказать — «вот тут фидбек и отказ» — а ждут когда вместо этого смогут сказать — а давайте может такую вакансию посмотрим?...

Что делать? Изучать «правильный стек технологий». Идеально предугодать кого будет нужно через год и год посидеть или на опен-соурс, или на каком-о своем местном проэкте, но чтобы реально разобратьс в стеке, который будет нужн через год, два...

Вы ж поймите. Когда это все начиналось, нас, програмистов, считали «дуриками». «Ну что ты за своим компом сидишь? Иди на базар, открывай свой бизнес с Турцией или Китаем»... Но мы верили что все так не будет... :)

Вот сижу сейчас и копаю только что вышедший Spring Boot 2.0 в вариации с Netty и WebFlow... а они «маленькими буквами» написали, что Spring Security под него будет лиш к концу года...
Но пробовать и реализовівать на «своих проэктах» нужно сейчас —чтобі разобраться с ньюансами, а спрос на это решение будет через год (если SS выйдет вовремя...)...

Три года моим тим лидом был принципал с Санта-Клары, который паралельно проводил квалификацию програмистов для той крупной корпорации, в которой мы работали. Поверьте, там важнее понимать их подходы, их «бест практициз»...
Да, конечно, есть варианты проверки насколько человек в состоянии оченить время на решение задачи... Но кодеры там точно не нужны! :) — кодеры работают на них от сюда или, скорее, с Индии... Мы, украинцы, у них ассоциируемся больше как раз как програмисты, которые могут придумать уникальное решение, сделать удивительную оптимизацию или рефакторинг... ДАвайте не разрушать их стереотип по отношению к нам!

Опытный как раз скажет, что можно, а что нельзя.

Опытный не скажет что нельзя. Опытный в самом худшем случае скажет что пока не знает как. И если клиент согласен на определенный R&D — любой каприз за его деньги. И обязательно предложит клиенту солюшн из набора, который знает, который близок к проблеме, которую нужно решать.

Ведь собственно это кодер имеет набор всегда готовых решений.
Програмист понимает, то если клиент о чем-то спрашивает, значит для него это важно. И если действительно с этой проблемой никто еще не стыкался — что маловероятно — то решение этой проблемы и есть искусство програмирования!
Да, конечно, честность с клиентом тут обязательна.
Но, с другой стороны — двадцать лет назад многие современные решения казались бы чем-то нереальным. Но кто-то их «сгенерировал» и «скреативил»...

Конечно, обратный вопрос — нужны ли програмисты на галерах? Не факт. Есть варианты когда четко затачиваются на кодеров. потому что есть варианты при которых идеально — стандартное решение...
Но стоит ли об этом???

А як же задачі, для яких є формалізоване математичне доведення, що розв’язку не існує?)
Ви знайомі з теоремою Геделя про неповноту?)

А часто море заказчиков хочет за 2 недели получить то, что требует несколько лет на решение (а тупое увеличение количества работников работает только в случае руками бульбу с поля убирать).

Это не говорит что задача не реашема. Просто «алгоритм решения», сроки, стоимость и так далее...

Просто есть «подарки» которые начинают доказывать клиенту что это сделать не возможно. В принципе...

Вот пример. Аутстафф. Тим лид и два матез в Калифорнии, четыре человека у нас тут... Лид на митинге говорит «ребята, нужно подумать как нам сделать такое» и вот тут один с наших срывается и начинает ему доказывать что такое в принципе сделать не возможно... И вот остальные «наши» понимают что тот не прав, но с другой стороны и спорить между собой — низзя...

И про что мы тут дискутируем? Много клиентов Вам ставили задачу из раздела R&D? 90 процентов рынка работает на аутстаффе...

А вот эта решаема только в далеком будущем.

беспроводная зарядка, например. индуктивность или мощный лазер.

А часто море заказчиков хочет за 2 недели получить то, что требует несколько лет на решение

У мене був схожий замовник (CEO). Розказав, яку задачу треба вирішити. Я сказав, що ок, досліджу, позитивний результат не гарантую (це R&D), але гарантую кожного дня звіти про те, як просувається процес, і що мені будуть потрібні ресурси: люди для ручної підготовки датасету, машини з GPU (для тренування нейронної мережі). У відповідь — мовчання. Через деякий час, після періодичних нагадувань, що потрібні ресурси, і що мені самому доводиться розмічати датасет, отримую: де результат, над цією задачею занадто довго працюємо... Після цієї компанії зрозумів, що треба взнавати національність менеджменту, коли йдеш у компанію.

Якщо компанія існує багато років, відома і фон відгуків про неї позитивний, то я вважаю, що можна працювати і більше 2 ніж тижні.

Підняти темку... Якщо робота постійно в межах вузької спеціалізації, то, можливо, не шкода, якщо потратити на це свій час і він зовсім не буде оплачений. Інакше ні, бо забувається.

Я працював з корінними американцями, вихідцями з Ізраїлю, вихідцями з Індії. Кожна з цих 3 груп відрізняється від інших.

Мова йде про роботу з клієнтом, в якого є проблема і яку треба вирішити... Ви багато бачили клієнтів, для яких важливо рішення вами теореми Ферма?
...тож давайте говорити по суті...

Рішення теореми Ферма — ні, але працював над задачами з Data Science. А Data Science базується на математичній теорії: мат. статистиці і не тільки. Щоправда, мені не доводилося отримувати задачі, для яких не існує рішення)))

Кодер — ремесленик, тупой и ограниченный.
Программист — мастер, креативный, разносторонний и "дух реальности нереального"...

я такую фигню в рекламе видел, там одни вещи постирали кодером обычным порошком, а другие программистом ариэлем, ну а по факту реальной разницы нет

там одни вещи постирали

вещи то на самом деле говно что стирали что нет нет никакой разницы ))

так зачем же ж платить больше!? (к) (тм)

...какие-то странные вещи рассказываете...
В свои 48 вижу что проблем с работой не предвидется — выбираю я, а не меня...

Конечно, не без ньюансов...
Логично, что всез интересует современный тех.стек... Хотя например, Prolog и Lisp, на которых я сидел 30 лет назад (программирую с 1984-го) — актуальны как никогда (Prolog — Apache Drool, Oracle Drool suite, WSO2..., Lisp — Cloujure, Apache Storm, собственно все что около Hedoop...

Тут де вопрос простой. Мы, девы за 40, всегда были фанами и энтузиастами. Еще вопрос у кого глаза больше горят!
Это доя молодых — програмирование это круто. Для нас — мы и есть програмирование! :)

Кроме того... в штатах дескриминация по возрасту приравниваетсяик гендкрной дискриминации. Любоя фирма, например, работающая с Силиконовой Долиной, хочет или не хочет должна иметь в штате девушек-програмистов, програмистов-инвалидов и програмистов «всех возрастов»... ...и, поверьте, при обилии работы в нашей индустрии, просто смысла нету работать в компании, которая работает не по американским принципам...

Хотя, конечно, в 48 предложений от фирм, котрые между Сан-Хосе и Санта-Кларой больше, чем от тех, которые между Львовом и Киевом...

Не могу понять вот такое. Они берут человека (не важно сколько ему) в надежде, что вот они вложат 2 месяца в обучение и он дальше всю жизнь будет на эту контору пахать их чувства благодарности??!
Да любой отработает 1-2-3 года и свалит в другую «молодую, быстро развивающуюся», где печеньки свежее и кофе горячее. И всё. Какая при этом разница сколько ему было на входе 23 или 43, не?

Вот потому в Штатах есть норма: человек рабоатет на фирме от трех до пяти лет. Если будет работать долше — его ниодна фирма больше на работуего не возьмет — так как он остановился в развитии... — и тут не играет значение — ему 25 или 45 или 55

..почему басни? Сам с этим сталкивался... Собственно. когда сталкнулся стал расспрашивать матез почему...

Один раз короткая работа, два — да, не показатель.
Но если их 10 и на каждой полгода, тут есть о чём задуматься.
В обратную сторону тоже работает, и даже на одном месте — если 15 лет тестишь одно и то же и не задолбало — то почему меняешь работу сейчас и может ли он учиться чему-то новому?

Если б я имел такую возможность — я бы увеличил бонус рекрутера за нахождение хорошего кандидата примерно вдвое, но разбил бы его на части:
— когда кандидат прошёл испытательный
— каждый раз, когда кандидат получает повышение
НО, я бы так же ввёл штраф за каждого провального кандидата. Под провальным подразумеваю фидбек тех. собеседования а-ля «Как он вообще попал на это собеседование, он же совершенно не подходит!»
Тогда рекрутеры будут больше сфокусированы на качестве, а не количестве, тем самым сэкономят кучу денег (ведь ставка технаря, который собеседует — высокая) и нервов

Как рекрутер может проверить техническую составляющую, если он не компетентен?

норм, мне раз пришлось выстраивать sql, R и Python в порядке значимости

Что может сделать ейчар? Он может пообзаться с человеком и почувстовать когда он «заливает» или наоборот «излишне скромен»... Собственно, команная работа всегда на первом месте, а владение технологиями — дело времени и быстрого интернета (до Google или StackOverflow)...

в итоге бы тимлиды сами сотрудников начали искать, потому что нафиг надо нормальному человеку, то что ты придумал, а на тимлида можно любой треш и угар повесить, куда он денется

НО, я бы так же ввёл штраф за каждого провального кандидата. Под провальным подразумеваю фидбек тех. собеседования а-ля «Как он вообще попал на это собеседование, он же совершенно не подходит!»
Тогда рекрутеры будут больше сфокусированы на качестве, а не количестве, тем самым сэкономят кучу денег (ведь ставка технаря, который собеседует — высокая) и нервов

Вообще-то рекрутеры только спрашивают резюме в лучшем случае «просят привести его в удельный формат» либо же ж всячески помогают привести сами (в т.ч. и делая это «неявно» никак не ставя в известность самого кандидата что реальное «резюме на галеру» уйдёт не «как есть» но «по мотивам») и проводят совсем первый скрининг и совсем очень иногда некий «технический прескрининг» обычно силами как-то слева неформально нанятого на неполный почасовой сдельный день «типа ыксперта» такой «технический прескрининг» сводится почти в 146% случаев к составлению «карты ключевых слов из ТЗ заказа галеры» да да да типа вот то самое «у вас был sql? а mssql? а чем отличается?» (к) (тм)

На этом собственно всё и звать на собеседование уже решает сама контора галера на основании полученного резюме и того самого первичного скрининга который про то что кандидат вообще существует в общем разговаривает и даже более или менее адекватный (помнится лет 10 впрочем может и сильно меньше тому назад киевские «типа рекрутеры конторы» звали исключительно на личное собеседование в офисе для этого я даже был не менее пары раз «ходил в разведку» смотрится спессфисски (к) (тм)).

Рекрутеры тоже научились список хотелок подурезать на скрининге

По факту стаття вийшла про проблеми найму сіньорів.

Не розкрита в статі тема 5 — бажання техліда напхати у проект максімум технологічних рішень. Де потім знайти людину, яка все це знає? Адже команда вчила ці технології одна за одною, а часто навіть знання нерівномрно розмазані. Не рідко лише одна людина знає первну технологію зі списка, а все разом не знає ніхто, навіть всередині проекту.

Але кори приходить ПМ/HR і питає які технології використовуютсья на проекті (навіть окремо у бекенді чи фронтенді) — він отримує свій фантастичний список :)

Технічні спеціалісти, з того що я бачив, не оцінюють вплив своїх рішень на вартість підтримки проекта, вартість розширення команди (включно з пошуком) і ризик, що хтось піде з проекту.

З того, що я бачив, технічні спеціалісти знаходяться на рівень-два нижче по ієрархії рівня, на якому видно вартість підтримки, розширення команди і ризики. В ідеалі цим усим займається менеджер проекту за участі і зацікавленості замовника і технічних спеціалістів.

Твердження, що техлід бажає напхати максимум технологічних рішень, досить спірне. Це може бути політичне рішення «використати мову / технологію / фреймворк Х». Це може бути наслідок бажання вивчити на практиці нову технологію, зробити себе незамінним або додати рядом у резюме.

А те, що технічний спеціаліст не займається задачами ПМ-а, це нормально. Вірно й протилежне: ПМи не оцінюють вплив даних обіцянок / взятих зобов"язань на архітектуру проекта, вибір технологій, можливість забезпечити якісне виконання й дешеву підтримку продукту.

ИМХО, Техлид не основной источник проблемы. Человеческий фактор конечно есть и эго есть, но не в них основная проблема. Проблема в неправильных ожиданиях менеджеров. И нежелании компаний тратиться на обучении джунов. Вы можете написать в вакансии что угодно, но у менеджеров есть четкое ожидание — больше людей это больше сделанной работы в единицу времени. Нанять людей, чтобы получить ухудшение показателей (даже временное) никто не хочет. Деньги лучше объясняют причины происходящего, чем вера в плохих людей. Я был в роли тех, кто проводит собеседования и собирает требование на вакансии. И нет, Техлид не хочет (точнее это не основная причина) видеть в соискателе самого себя. На него обычно давит менеджер и компания в целом. Именно они хотят платить как за джунов, а получать работу как от сеньоров. Техлид не управляет бюджетами, но отвечает за проект и прогресс. Требования это единственный защитных механизм, который у него есть. И собеседования часть этого. Думая о добавлении людей в команду, он думает — а разгрузит ли его этот человек или только добавит ему работы. Техлид хочет иметь в команде надёжного человека, которому можно делегировать задачи и не бегать за ним. При этом он осознаёт, что если человек не будет справляться, то ему придётся делать работа за двоих. У него обычно мало времени и делать чужую работу он просто не может себе позволить. Объяснять потом, что новый человек оказывается ещё долго будет учиться достаточно сложно. Особенно, когда компании ожидают быструю отдачу от новых людей.

ИМХО, не «неправильные ожидание менеджеров», а желание (менеджерами) того, что выгодно и удобно.

Думаю, людей легче бы брали, если бы была возможность легко с ними расстаться во время испытательного срока. Техлид не хочет брать кандидата, если есть сомнения, потому что потом это будет исключительно его проблема. Рекрутер(ы) и ПМ — молодцы, закрыли вакансию и, если кандидат оказался не торт, им не выгодно его заменить, проще сказать техлиду: ты его взял, теперь и работай.

Дьявол в деталях. Зависит от условий формирования проектов.

В больших продуктовых компаниях может и сработать. Но есть детали с переездом из других городов, визами и т.д. На таких условиях не все согласятся стартовать.

А аутсорсинг может даже проект не запустить, пока нет людей. Уволить человека в середине проекта может быть проблемой. Зависит от взятых обязательств. Внутренний пул людей есть, но он может и не спасать, так как люди должны еще собеседование с заказчиком суметь пройти. А со стороны заказчика или снова «желание того, что выгодно и удобно» или уже их лиды с теми же обширными требованиями.

Обучение людей стоит денег и вполне понятно желание экономить. Но очень неприятно, что в последствиях этого автор статьи обвинил исключительно лидов. Явление с плохими требованиями и собеседованиями явно имеет массовый характер и существует не только в Украине. Я не верю, что у нас Все лиды плохие и дружно саботируют процессы из сомнительных интересов и личной глупости. Вместо выявления системной проблемы автор нашёл крайних. Оказывается, это положение всем невыгодно и только лиды все портят. Теперь то он научит нас как правильно жить и что делать... Так уже и вижу, как завтра все начнет улучшаться благородя глубокому анализу в его статьях.

Оно да. Но тим лид как раз на пересечении «чнто нужно делать» и «тимбилдинга».
Тим лид входит как в профсоюз програмистов, так и в профсоюз ейчаров...
Это тич лид, если он не СТО, во второй профсоюз не входит.
Зато тич лид входит в профсоюз коачеров... :)

Статья называется «Проблемы вхождения в IT» и я так понимаю тут речь идёт про джунов но по тексту про слабых мидлов. Если так то...

Техлид хочет видеть в соискателе самого себя

и это нормально, если ты стал техлидом значит обладал нужными качествами и их же в первую очередь будешь искать (например широкий кругозор), и только потом будешь интуитивно обращать внимание на качества которые ты видел у других хороших спецов (например скурпулёзность, которая как раз очень мешает кругозору).
Если ты пять лет назад уже знал много технологий то это нормально, я на первую работу когда устраивался уже знал Делфи, турбо паскаль, SQL (через ADO к MS Access) немного бейсика и прочёл пару советских книг какие попались про Фортран и Си. И это была доинтернетная эра, был бы у меня тогда интернет я бы знал больше.
Недавно помогал одному джуну, так вот он сам написал интерпретатор Brainfuck (!) на Джаваскрипт (!) я ему помогал учить Джаву (!) а устроился работать он Рубистом (!).

После этого добавляется английский, знание процессов и методологий гибкой разработки.

Да добавляется, но на невысоком уровне погружения. Английский у джунов обычно требуют на уровне прочесть документацию, с переводчиком написать письмо. Знание процессов тоже базовое можно получить из тоненькой книги, нет там ничего замысловатого. Другое дело что слеовать им в работе уже тяжело, но и не очень понятно как им можно следовать джуну, когда ты даже примерный эстимейт дать не сможешь.

Короче, по поводу требований к джунам: всё обычно очень адекватно и вполне оправдано и реально.

Далее все бегут к проектному менеджеру, к которому, собственно, человек и пойдет работать

Тут что-то совсем не так: из-за джуна никто ни к кому не бегает, джун — это ученик на вырост. Если из-за него кто-то бегает то значит что от него что-то зависит а значит в компании дела совсем плохи. И я вообще не понял как это у вас так что техлид пишет вакансию а ПМу с ним работать.

«Такие люди есть, и их много, вы просто плохо ищете».

Они есть действительно, но их искать не нужно, они сами ищут работу и рассылают по десять резюме в день. Откройте почту — там уже с десяток резюме, возможно среди них один такой есть. Подсказка: у него в резюме будут ссылки на сделанные проекты.

Поиск кандидатов не принес желаемых результатов. Проектный менеджер давит на рекрутеров, потому что они плохо ищут.

Я ни разу не видел такой ситуации в жизни, но подозреваю что так и есть. Я не открою тут америки но если у вас хороший и достойный проект с нормальными условиями то у вас будут нормальные кандидаты. Немного, но будут. Их даже возможно исктаь не придётся, просто по рекомендациям найдутся.

Ну и по выводам, они в целом вроде адекватные но вот что-то всё равно не так как в жизни:

Всегда надо исходить из должностных обязанностей человека

проблема в том что обазанности в айти очень текучие. Мы автоматизируем сами же свою работу и тут нету такого что «выучил и работаешь до пенсии». Тут нужно бежать и учится. Поэтому брать формошлёпа, узкого спеца или инженера это очень большая разница уже в ближайшей перспективе.

Техлид должен осознать, что если не будет человека, то ему придется делать все самому, а также, самое сложное, — что сам он не успеет сделать всего намеченного

Какой кошмар у вас в компании.

взять кандидата на вырост

Тут есть пардокс, чтобы взять работника не вырост нужно чтобы он сначала этот рост уже показал. Просто блеск в глазах и желание работать тут не работают. Расти — это больно, и это привычка которая вырабатывается с детсва.

Может, ищем не по тем критериям?

Из моей практики критерии почти всегда нормальные, просто людей физически нет. И это даже не только у программистов так, попробуйте найти врача, няню да или хотя бы грузчика. Я работал на складе стройматериалов и точно могу сказать что найти нормального грузчика это тоже огромная проблема, даже несмотря на то что там очень лояльно относятся к предыдущим судимостям. Их тоже «хантят» и переманивают у конкурентов.

Короче, мой посыл в следущем: сейчас есть определённые трудности, но не всегда это настоящий проблемы либо проблемы в другой области (может если вы просто денег начнёте платить нормально то всё у вас будет ок).
И не надо думать что просто все тупые и не знают как же людей нанимать, а нужно то всего навсего просто «поговорить техлиду с ПМом».

Недавно помогал одному джуну, так вот он сам написал интерпретатор Brainfuck (!) на Джаваскрипт (!) я ему помогал учить Джаву (!) а устроился работать он Рубистом (!)

Вообще для джуна это как раз нормально — знать всего по чуть-чуть и ничего в целом.

Английский у джунов обычно требуют на уровне прочесть документацию, с переводчиком написать письмо.

Может это раньше так было, сейчас конкуренция и, соответственно, требования слегка выросли.

требования, может и выросли, но переговоры вести некому ;-) www.facebook.com/...​rmalink/1793424664070933

Расти — это больно, и это привычка которая вырабатывается с детсва.

Кем вырабатывается?

Хороша стаття, якщо її прочитають ті, кому вона адресована, буде ок.

Не побачив чи не найважливішого пункту — співбесіда.
Якщо з опису вакансії повикидати все непотрібне, а на співбесіді умовного джуна питати нейронні мережі і просити писати код обходу червоно-чорного дерева на листочку, то так теж нікого не наймуть.
Також дуже фіговим патерном на співбесіді є ситуація, коли тім/техлід читає різні науково-популярні статті і починає питати на співбесіді питати різні екзотичні випадки з цих статей.
На таке запитання найкращою відповіддю буде: «В проекті таке використовуєте? Ну то навіщо питаєте?».
А взагалі, якщо вам не потрібна людина з вузькоспеціалізованим скілом, який вийде на роботу завтра і зробить, те, що потрібно «на вчора», то, на мою думку, вам може підійти будь-який технічний спеціаліст з непоганими базовими знаннями. Задумайтесь, чому faamg компанії набирають людей не на конкретний фреймворк, а в компанію.

Статья про собеседование, уже в стадии 90% готовности. Я посчитал нужным выделить ее в отдельный материал

А взагалі, якщо вам не потрібна людина з вузькоспеціалізованим скілом, який вийде на роботу завтра і зробить, те, що потрібно «на вчора»

faamg компании могут себе позволить обучать джунов, так как более менее уверены, что человек сразу от них не уйдёт. Имидж работает на них. И даже они мотивируют сотрудников обещанием акций через N лет работы. Ну и их собеседования с алгоритмами и другими формами бега через препятствие тоже очень спорная штука. Действительно ли в реальной работе потом все эти алгоритмы сами ручками пишут, на доске, на время.... Остальным нужны люди именно «на вчера». Чтобы хотя бы не приносили убытки. В собеседованиях много глупостей и их можно и нужно проводить лучше. Но пока компании ожидают мгновенной отдачи, то собеседования так и будут адом. И я не вижу экономических причин для компаний хотеть настоящих джунов, а не просто зарплатных.

Процессы-процессы. Если бы в компаниях четко понимали, что они хотят от той или иной позиции, такая проблема не возникала бы. Не такая уже большая проблема ввести нового человека, если сам четко представляешь скоуп и роадмэп проекта, имеешь документацию и готовые практики А по факту просто стараются ухватить как можно больше баззвордов на часовой рейт. Про запас, вдруг пригодится.

документация, практики, скоуп,.... уж не помню, когда последний раз мне бы так свезло, чтобы на проекте полноценно было бы хоть что-то одно из перечисленного. а всё сразу и качественно, так это вообще Sci-Fi.

Ну так и результат такой же. Честно говоря для меня до сих пор большая загадка — на стройке, в автосервисе, в торговой сети берут людей практически с улицы, учат и работают по строго установленной процедуре. Еще и немаленькие ТМЦ доверяют. А в программировании — сено-солома и взлетевший проект скорее исключение, чем правило.

Однозначно плохой совет по поводу ответа

«В проекті таке використовуєте? Ну то навіщо питаєте?».

Во время собеседования это выдает предельную дерзость кандидата и сразу сбрасывает шансы трудоустройства практически до нуля. Если кандидат (или интервьюер) не понимает, что необязательно знать ответы на все вопросы — то как бы ну и дурак. Для меня вообще нормальная ситуация, когда человек на собеседовании не ответил на половину, мне лучше как можно более полно представлять что кандидат НЕ знает, чем то, что он знает / прочитал-повторил перед собесом.

Собеседование — это очень сжатый по времени диалог, в котором нет места для спора с кандидатом «а зачем это вообще надо». Спросили херню — сделай себе пометочку, скажи, что не знаешь, и погнали дальше. Если проект — поддержка сайтов на WP, а тебя дрючат по ORM, юнит-тестам и еще какой-то несвязанной хрени — вот тебе и сигнал, что тебе не в эту компанию.

К сожалению, бывает так, что про проект даже не рассказывают, а сразу начинают сыпать вопросами, едва человек снял куртку/пальто. При этом, по окончанию собеседования говорят, «всем спасибо — все свободны» и ставят условную галочку у себя — кандидат не спросил о проекте — не заинтерисован в работе — нам такой кандидат не нужен.

Так и замечательно! Кандидату значит туда и не надо.

На рынке множество замечательных компаний и возможностей, поэтому пусть работодатели-долбоебы практикуют 1000 и 1 способ провести дебильное собеседование.

Гораздо хуже, когда и о проекте рассказали, и спросили легкие вопросы, и оффер дали, а там...

Знаете, в силу огромной конкуренции любой оффер в радость кандидату (именно оффер о работе, не оффер прийти на беседу :) - это значит, что есть шанс прекратить оббивать пороги/попадать на не очень хорошие собеседования и начать наконец приносить пользу компании и качать скилы себе. Опыт важнее любых денег.). Говорю как всегда лично за себя и свое личное мнение, потому что я сам кандидат.

На вкус и цвет фломастеры, конечно, разные, но позволю себе отметить следующие вещи:

— никакой огромной конкуренции на рынке нет, спрос на кандидатов превышает предложение почти во всех сферах (ну разве что jun. QA/PM). А вот компании, наоборот, устраивают настоящее рубилово за опытных сотрудников.
— разве не лучше лишний месяц потоптаться по собесам, чем оказаться на полгода закрытым работать с неадекватами?

— разве не лучше лишний месяц потоптаться по собесам, чем оказаться на полгода закрытым работать с неадекватами?

На співбесіді не завжди вдається зрозуміти, якою буде робота з компанією.
Наприклад, цікаво, як можна взнати, що невелика маловідома компанія буде платити вчасно і не кине в кінці співпраці? Якщо пояснюєш свої побоювання тим, що у минулому стикався з таким на власному досвіді, і в відповідь чуєш «ми не такі»?

Для меня вообще нормальная ситуация, когда человек на собеседовании не ответил на половину

Я стикався з технічними інтерв’ю, тривалістю більше півгодини, коли після відповіді на 80-90% запитань була відповідь від рекрутера, що рівень недостатній для вакансії)))

Уровень технических знаний и теории с опытом вообще не индикатор на собеседованиях. Грубо говоря это бинарный тест, выпили бы вы вместе пиво или нет, во всех компаниях от Apple до студий однодневок.

Також дуже фіговим патерном на співбесіді є ситуація

Кожен патерн є солюшином до певної проблеми, інакше це антіпатерн. чи відчуває проблему, Може, свідомо чи підсвідомо, лід бачить проблему у вмінні як раз вирішувати екзотичні ситуації?
Зазвичай, команда шука до себе когось, хто доповнить її новими знанями чи вміннями...
Тож, не факт що «варіант зі статтєю» антіпатерн...

В нашу супер перспективную контору с гениями внутри и офисом в районе мухосранска нужен толковый джун который закончил Хогвартс и проработал не менее 40 лет. Будет плюсом, если Вам не более 20 лет:) И конечно, он должен знать язык на уровне переводчика: птиц, змей и единорогов.

Смешно? А мне нет. Это реальные требования ИТ контор. Замените только Хогвартс на пару высших ИТ образований, а все остальное на огромный стэк технологий который нужно знать и иметь опыт коммерческой разработки от 1+ года. И не забудьте после тех. собеседования ещё сделать нормальный продукт, типа как тест задание.

А после этого мы Вас просто проигнорим: даже не перезвоним и не скажем результатов. Потому что мы — большая и именитая контора к нам все хотят: а вы никто и звать вас никак.

И при этом, посмотрите на рынок труда: катастрофическая нехватка мидл и сеньор во всех компаниях. Ну так откуда же они возьмутся, если у джунов требуют умение летать на гриффоне и разговаривать с ящерицами при «входе» в ИТ? При этом, половина того бреда, что спрашивают на собесах и пишут в требованиях к вакансии вам просто не понадобиться в работе.

ПС. Под «большая и знаменитая» я вполне себе конкретно :) имею ввиду одну очень известную ИТ контору. Но зачем включать «вентилятор», правда? Просто пометим этот класс ключевым словом «abstract».

Как по мне так требовать конторы могут все что угодно, но когда таки человек уже будет реально нужен , то и требования будут выдвинуты адекватные! Это не всегда на пользу самой компании, потому что в этой мясорубке могут упустить реально хорошего кандидата.
Но с другой стороны, я считаю, что человек если хочет, то вся эта пурга не остановит целеустремленного специалиста!

Человек может хотеть хоть до вытекания мозга через уши. Может хоть на Луну слетать и «всосать» в себя знания межгалактического разума. Последнее слово все равно останется за тем, кто тебя собеседует.. И кстати, эта самая «пурга» как раз и останавливает специалиста с вполне логичным вопросом: что это было и что им еще надо? :) Любое собеседование плавно балансирует на грани: адекватно и «тупо издеваются».

И кстати, эта самая «пурга» как раз и останавливает специалиста с вполне логичным вопросом: что это было и что им еще надо? :) Любое собеседование плавно балансирует на грани: адекватно и «тупо издеваются».

так кто кому еще делает одолжение получается:))) ибо зачем рабоать с такими мудаками?

Верно. Кто кому? Компания, которая мнит себя «офигенной» или перепуганный джун у которого от страха и от нервов того и гляди сердце выскочит и груди? Так кто же?

джун закаляется в ристалищах интервьюирования и получается возможность искать другую компанию с адекватными людьми)

В ристалищах интервьюирования только плавится мозг от не всегда адекватных вопросов и легких издевок со стороны интервьюверов. А джун закаляется на работе. На реальных тасках. На вопросах, которые он задает ментору. На стремлении показать, что он не хуже, чем остальные. На умении работать в команде.

Неадекватных интервью повидал достаточно и понимаю о чем ты говоришь, но уж большо ты категоричен в своих утверждениях, ты прямо скажи, это тебя на работу не берут как девелопера? и ты пытаешься найти причину в ком то другом, но не в себе?

Вот сразу интересен аспект, что для Вас неадекватные вопросы. сразу скажу что уже в слоедующей статье их указал для себя, но хотелось бы знать vox populi

это очень от многих факторов зависит, но главной неадекватностью считаю, когда интерью проводят не профильные специалисты/ специалист и получается как разговор слепоглухого с глухонемым (утрирую конечно, но куда уж без этого).
Из этого вытекает обычно много ситуаций котоыре трудно поддаются анализу после интервью)))

Програма минимум: Собеседующий должен задавать вопросы на которые сам знает правильные ответы (либо подготовиться к интервью) например на одном из «Лидеров Е- коммерсе» ТимЛид задал вопрос по Смоук Тестингу на который явно ожидал ответ по Сайнити тестингу

и тебя туда не взяли?)))

Конечно не взяли ) я ж ответил на поставленный вопрос а не на то что они подразумевали .... в результате эта компания сейчас устраивает «курсы молодых джунов» — а отсеяли человека с 10 лет опыта в IT

Всегда говорил правду и Вам отвечу здесь: нет, дело не во мне. История моего трудоустройства это отдельная тема для трактата, который будет не всем интересен :) Однако, я как соискатель и кандидат конечно же сталкивался с разными людьми и ситуациями. Мой пост выше лишь одна из них.
И уж тем более, никогда не ищу причин ни в ком, кроме себя. Все выше сказанное -взгляд со стороны. С моей стороны и моего личного мнения.

аналогично) и я работаю над собой и уже не принимаю близко к сердцу откровенно трешовые интерьвью) вот бы еще научиться уходить с них и не тратить свое время) пока воспитание не позволяет)))

Верно. Нужно научиться. Но как Вы правильно заметили — воспитание не позволяет. И наверное, взгляды на жизнь.

и еще один, как по мне не маловажный факт, даже в откровенно идиотских интервью я пытаюсь найти позитив и извлечь какую то пользую для себя)
Я оптимист))

Все верно говорите, но в результате вот таких вот не совем адекватных встреч и требований к соискателю, мы имеем вот такое:
d.radikal.ru/...​/1804/ec/5e604efce5f8.jpg

А потом появляются вот такие статьи на DOU. Логика, ау? Мы сами себе создали такую ситуацию. Только вот работодатели продолжают свою политику. Ну тут уж: just business nothing personal...

Извините, я .Netчик, взял то, что роднее.

Так я думаю ± такая ситуация везде)
у меня недавно была ситуация, когда по внутренней реферальной ссылке меня позвали на интревью, я знал всю ситуацию изнутри, знал какие у них проблемы , именно этим я занимаюсь последние 3 года, вот прям 1 в 1 весь техностек и даже продукт из той же области.
в итоге меня интревьюровал человек даже не из той команды и которому было абсолютно пофигу на ситуацию там , куда меня звали! Причем когда он залез в дебри которые никакого отноеня вобще не имели к тому что я занимаюсь , я ему попытался напомнить на какюу позицию и для чего меня сюда позвали, но он как тетерев на току продолжать спрашивтаь меня , его не оставливало даже то , что уже было потяно, что направление им выбранное в вопросах я не знаю на том уровне на котром он ждал ответов. такое впечатление что ему нужно было получить от меня 10 неправильных ответов и отрапартовать, что я не подхожу)
В итоге позиция до сих пор открыта, а компания устроила hiring freeze.

Вы случайно говорите не о «большой и знаменитой» компании? :) А то я что-то прочитал одну из своих историй в Вашем посте :)

в действительности такие ситуации это классика и встречаются во многих крупных компаниях

Я думаю мы про разные , но сути дела это не меняет , получается это подход котрый типичен для больших компаний.
Ксати аналогичная ситуация у меня была в другой крупной компании, там я говорил с менеджером котрый в свою команду искал, но там было по другому, но не менее смешно.
Он в результате чательного 2х часового допроса, нашёл мою слабую сторону :) а именно то что я забыл как конкретно называется аннтоация , это притом что я ему рассказал на прикладном уровне как это работает и как я с этим работал , но ай ай ай , последние два года я для этих целей использовал другой фреймворк и там это называется иначе :) компания была оракл , менеджер был из Бангалора

Тоже была ситуация когда меня собеседовать прислали человека который занимается другим проектом. По нему было видно что он хз о чём спрашивать и задавал общие вопросы по Java.

«Извинните пожалуйста, мне кажется, у нас разные взгляды на одни и те же вещи, и я боюсь, что не смогу работать с Вами в команде, а для меня это очень важно — понимать коллег и быть понятым в ответ. Если Вы согласны, я бы хотел прекратить интверью.»

Не так важно, что Вы хотите сказать, просто старайтесь быть вежливым.

вот бы еще научиться уходить с них и не тратить свое время)

так не ходите на трешовые интервью ))))

спасибо за такой емкий и всеобъемлющий ответ, но вот пока не получается ! Ведь оно как в больших компаниях каждые проект это как отдельная компания и тут уж как повезёт :)

мммм..... не ходить в большие компании? ))))

и тут уж как повезёт :)

это русский авось называется ))))
не повезет )

Я оптимист на позитиве :) да и легко тебе говорить :) в Харькове так то больших и нету :))

тогда пример большой компании в студию ))))

Apple, Google, Amazon, Oracle, Deutsche bank, Fidelity.

p.s. это с теми с кем мне приходилось сталкивался так или иначе.
Пальму первенства по неадеквтаности на интервью, для меня держит первая ))))

10 Отмазок...

4) Дело не в тебе, дело во мне (дело не во мне, дело в тебе).

Если на вакансию супермена в течение долгого времени откликнутся только косой, хромой и горбатый, то одному из них вскоре выдадут синюю плюшевую майку и красный плащ. И тот полетит. А если не полетит, то пойдет или похромает. И все смирятся с этим и будут работать с тем, что есть, пока не найдется альтернатива. ©

Как вариант, вакансия будет вакантна, возможно, долго, возможно, всегда. Это из реальной жизни.

Буває, що рекрутер пропонує вакансію, яку раніше (декілька місяців назад, чи навіть більше як рік назад) пропонувала рекрутер з іншої компанії. :-)

Нафига вообще на Джуна подаваться если можно на мидла

ріл тру, бро!

Так и есть. Но с другой стороны CV примерно следующего содержания: возраст: 20 лет; образование: школа танцев (реальный случай); уровень: сеньор; желаемая должность: технический директор; минимальная зарплата: 10к у.е/мес.

Чувак телепат. Ти прочитав думки тисячі людей одночасно!

Лучше на это смотреть с позитивной стороны, такие конторы останутся в болоте которое сами создали, и таланты к ним не зайдут. Рекрутинг это состояние компании на 100%

позволю себе сообщить поддержавшим сообщение Андрея, что в качестве задачи на собеседовании ему предложили найти сумму элементов целочисленного массива с помощью цикла for.

Интересно, а Вы откуда знаете? Телепатия? Да, действительно. На одном из собеседований в одну из крупных ИТ компаний было такое задание и я в нем запутался. Если бы точнее, я рассказал как это можно сделать, но вот написать код на бумаге я не смог. Оправдание? весьма банальное — нервы. Тогда это было мое первое собеседование вообще и в целом. Но да: я не справился тогда.

человек, претендующий на позицию программиста, не умеет написать цикл for? извините мой фронцузский, но это дно не имеет дна.

Хз, я на первом собеседовании обрадовался бы такому вопросу. Ладно ещё сортировка хотя бы... и то.
Меня, например, на самом первом спрашивали про курсовой проект по большей части, и чем там пользовался (без задачек — видно было, что собеседующему нужен определённый стек, и раз у меня его не было, то и расспрашивать смысла никакого), на следующем (которое прошёл) — по WinForms, делегатам и ивентам.
Последнее собеседование, которое не то чтобы заставило нервничать — просто вогнало в лёгкий ступор — содержало такое. Я не знаю JS от слова совсем (кроме C# и Java не знаю других языков), звучит вопрос: представьте, что в C# нет виртуальных методов (в JS нет), и нужно решить проблему переопределения иначе. Т.е., вот код класса на C#, вот его невиртуальный метод, вот код класса-наследника с таким же методом — что делать? Подсказка — ожидается паттерн. На попытке представить, что в Шарпе нет виртуальных методов, параллельно перебирая знакомые паттерны, и каким они там вообще боком, мозг начал буксовать, и я начал тупить на все последующие вопросы в том числе.
В остальном, все собеседования содержали правильные и адекватные вопросы.

звучит вопрос: представьте, что в C# нет виртуальных методов (в JS нет), и нужно решить проблему переопределения иначе.

Ага клёвая фишка кстати здорово расширяет сознание.

Вы на своих интервью надеюсь все циклы и hello world-ы правильно написали и поведаете нам о своих успехах?

Помню как в школе на семестровом экзамене по информатике я лайфкодил рекурсию на паскале на бумаге перед учительницей. Вот тогда я волновался. Ну блин, запутаться в for — это или клинический случай панической атаки, или клинический случай «янеучилноячитал»

Эмпатия полезная вещь, но не всем дана.

И что? Ну вот запутался в for или fizzbuzz каком-то, вы пришли сдавать зачет а рекрутер дрючить студентов, так выходит? Какую информацию о сильных сторонах кандидата вы узнаете, о выполнении рабочих обязанностей? Как кандидат я узнаю о вашей профессиональной некомпетентности и того кто вас нанял.

Так, бувають вакансії, де виставляють майже нереальний список вимог.
Тим, хто шукає роботу, радив би на співбесіди на такі позиції, дивитися як спосіб потренуватися у проходженні інтерв’ю, якщо запросять.

Позитивне, що є вакансії, де список обов’язкових вимог невеликий. От знайшов декілька, по яких мене колись успішно наймали, причому не як junior:

Qualifications
• 2+ year experience in development using one of the following programming languages:
o Java (preferred)
o Delphi, C#, Python, Ruby
• Reasonably good level of OOD/OOP
• Strong mathematical background is a plus
• R library knowledge is a plus
• Hadoop knowledge is a plus
• System administration experience is a plus
Привет, у меня две вакансии во Львове, одна больше Data Scientist, другая больше разработчик. Обе Natural Language Processing & Machine Learning.
Если интересно, можем пообщаться подробнее.
Must have — досвід роботи з:
— Java
— MySQL
— А також розмовна англійська :)

Буде плюсом, якщо ти мав справу з:
— MQ, Kafka
— NoSQL
— MapReduce, Spark
— А також виконував управлінські обов’язки (в будь-якому розрізі :)

А ось список вимог, які я склав для свого PM-а:

Mandatory skills:
— Java (Java 8 or later is preferable)
— Spring (Spring Boot and Spring Integration are highly desirable)
Preferred skills:
— BigData experience (Spark is preferable)
— ETL
— Ruby
— Kafka (or at least any message broker)
— Cassandra (or at least any NoSQL Database)
— RDBMS
— Docker, Kubernetes
— AWS
— Ubuntu

У «Mandatory skills» — те, що потрібно, щоб людина з перших тижнів могла приносити користь для проекту, нехай і невелику. У «Preferred skills» — те, що ще використовується. Співбесіда і випробувальний період — це можливість оцінити, чи людина підійде, тобто чи замовник, команда будуть задоволені співпрацею: чи кандидат зможе і буде хотіти за розумний час вивчати технології, що використовуються, чи відповідальний, як поводиться, коли є розбіжності у думках, ...

Дякую. Я так і дивлюсь на співбесіди зараз. Як досвід. Як шлях, котрий потрібно пройти щоб дістатися мети :)

Подпишусь под каждым словом! Есть работодатель лояльный а есть не ...

Підписатись на коментарі