Comments 124
Кстати, этот переход от: "Ой, лишь бы взяли" до "Давайте поговорим и посмотрим, чем можем быть друг другу полезны", он и в бизнесе хорошо работает. Когда понимаешь, что нужно тебе и готов услышать, что нужно клиенту/работодателю, то жизнь проще становится
Эта картинка как раз больше про опыт и наличие текущего места работы (работодатели прям любят чтобы текущего не было, и торговаться удобнее, и договориться о выходе проще же)... Ну левый случай можно опустить конечно. Сам так ходил, до сих пор улыбает, как один собеседующий, получив ответ на вопрос "Почему вы хотите сменить работу" в виде "Не то, чтобы вот прямо хочу, просто решил пообщаться и посмотреть ...." весь скривился и спросил "А где гарантия, что вы через год работы у меня не захотите еще где-то просто посмотреть" =) Собственно вопрос, как и ответ настолько очевидный, что зачем его вообще задавать? Вот в итоге раз в пару-тройку месяцев походил на собесы, в итоге таки ушел туда, где не "Я начальник - ты дурак", а вполне комфортная атмосфера и интересные проекты, в принципе как и любая социальная связь - нужно просто найти место, где две стороны поняли друг друга, и не придется корчиться и подстраиваться под враждебную обстановку...
Ну а пока опыта нет - тут уже "Готовиться, заучивать, доказывать что ты тот самый", потому как и сам еще не понимаешь, куда пришел и по каким критериям отличить адекватное место от филиала ада...
работодатели прям любят чтобы текущего не было, и торговаться удобнее, и договориться о выходе проще же
Дело не в этом. Довольно много людей ходят по собеседованиям, не собираясь устраиваться на работу изначально. Кто-то за оффером, чтобы повышение просить на текущем месте, кто-то чтобы в тонусе себя держать. А время интервьюверов не бесплатное.
Да, но я на это смотрю как на неизбежность: точно также люди звонят по объявлениям о продаже машин и квартир и ходят на просмотр без мысли о покупке. Можно пытаться отсеивать подобных на старте конечно, но это приводит к ситуации, когда собеседование превращается в допрос. Я еще допускаю такое, когда нанимают менеджеров, в каждодневные задачи которых входят подобные социальные баттлы "переиграй партнера на переговорах", тогда сразу видно как человек держится, как реагирует и может это имеет смысл. Я например инженер, я люблю паяльником в плату тыкать и код писать, а вот переговоры/интервью это неизбежное зло и когда меня пытаются в чем-то уличить и прогнуть, требуя каких-то красивых ответов я просто вежливо пытаюсь держаться, но как правило дальше желание продолжать отпадает. Уже пару раз такое было, и в общем-то не жалею, что сразу не сложилось, сэкономило время всем, как я считаю :) Я придерживаюсь мнения, что просто это не мой тип общения, кому-то наверное подходит...
Я пару лет назад ради интереса завёл анкету на hh. И через месяц и пару собесов через скайп, неожиданно получил оффер на удалёнку. Пошёл с ним к начальнику и получил контроффер.
Причём на собесах сильно не напрягался. Относился к этому как к развлечению. Потом даже неудобно было отказываться от оффера. Всё-таки люди на меня время потратили..
Кто-то за оффером, чтобы повышение просить на текущем месте
Подумалось, что в РФ оффер ведь не имеет никакой формальной силы - что мешает самому себе его нарисовать :) Можно, конечно, влипнуть, если ты с ним на текущем месте придешь, а тебе в ответ скажут: "Ну и иди нах" - тогда уже всерьез по собеседованиям забегаешь :)
Что мешает людям, например, воровать, когда этого никто не видит и вероятность быть пойманым минимальная?
Не хотят-с...
лень :)
Ну, например, те материальные ценности, которые мне потенциально могут быть доступны для, скажем так, присвоения нечестным путем, они просто не стоят тех хлопот - мне намного проще заполучить их честным образом (т.е. заработать). Если бы речь пошла о суммах много-много больших, то можно было бы подумать, да - но это малореально :)))
Ну воровство всё же отличается от, например, пиздежа приукрашивания в резюме. Чем нарисованный оффер в таком случае отличается от второго?
Хочу сказать, что очень мало информации в Вакансиях, о том какой уровень нужен в конкретном стэке и поэтому много людей пытаются попасть хоть куда-нибудь. И видишт по 200-400 откликов на Вакансию и если купишь HH просмотр конкурентов, то 40-60% не проходят вообще. А ты из-за этого проходишь мимо...
Мало людей сейчас знают фундамент, потому что он в общем-то очень легаси. Мало людей интересуются задачами дальше чем описание своей джиры.
Потому что фундаментальные знания они на самом деле весьма обширны, и не используются напрямую. Они погрязли где-то под тоннами фреймворков и библиотек, и люди пользуются готовыми кирпичиками, не понимая откуда они взялись и как работают. А без этого очень сложно наработать интуитивное правильное мышление.
Если ты работаешь с абстракциями, логика будет как в "Алиса в зазеркалье". Если с фундаментом - можно не знать много чего, но ты редко будешь ошибаться в глобальном плане.
Именно поэтому курсы, даже 4-6 месячные - это очень мало. Для фундамента нужно минимум пару лет покрутиться в сфере, либо активно интересоваться с детства, тогда за 8-10 лет игр, при некоторой доле любопытства можно стать продвинутым пользователем и многие фундаментальные вещи встроятся уже в днк
Если с фундаментом - можно не знать много чего
Я так пролетал на собесах, когда решил сменить профессию. Никому мои знания по CS не пригодились, зато нужно было знать проклятые фреймворки и иметь опыт.
Подход "снизу вверх", часто, не работает. Сперва пробуем решаем так, как умеем, а если результат не устраивает, то гуглим/читаем теорию. Иначе можно увязнуть в "базе" и так и не начать работать.
Чувство прекрасного (архитектура, кодстайл) прийдет со временем, когда начинаешь понимать, почему это сделано так или иначе. Тоже относится к "фундаменту". Безусловно, какие-то элементарные вещи знать нужно, но человек, который занят CRUD проектами, уже ими обладает. Вот когда он захочет пойти дальше, тогда уж...
Никому мои знания по CS не пригодились, зато нужно было знать проклятые фреймворки и иметь опыт.
опыт нужен, фреймворки не нужны (по факту, это все гуглится читается учится)
проблема старта без опыта стала актуальной только последние несколько лет, сейчас тупо проще найти джуна с опытом чем джуна без опыта. неважно какие у него базовые знания
опыт нужен,
Фокус в том, чтобы его получить, зачастую, не нужно погружаться в теорию с головой. Вот я, начитавишь с хабра умных советов, поперся проходить курс по sicp, читать проклятую книгу Ахо, Ульмана с драконом, Кормана, Таненбаума и что? На собесах это никому не было интересно. Вот сейчас, спустя 7 лет я мало что вспомню оттуда.
Бизнесу нужны люди, которые решают конкретные проблемы, а не теоретики. Я понимаю, что у JetBrains тоже бизнес, но компании такого уровня - это прям топ, который где-то далеко и туда не пробиться.
"То ли нужно менять слуховой аппарат, то ли менять окрестность..." (c) БГ
Мне кажется надо идти на собесы к тем кто спрашивает по сикп и книге дракона - у них и денег больше и работать интереснее
Мне кажется надо идти на собесы к тем кто спрашивает по сикп и книге дракона - у них и денег больше и работать интереснее
а по факту будете пилить круд вторичного сервиса который никогда не попадет в прод, ага
задачи но собесе сочетаются с реальностью в 1% случаев
Я просто хотел стать рядовым, программистом. Но, начитавшись хабра про "базу", начал с нее. Потерял очень много времени. В результате пришел к драконам только спустя 7 лет, и только теперь все начинает складываться в одну картину.
Так вот проблема с "базой" как раз в том, что она бесконечная. Мало того, нужно понимать, зачем она нужна. Иначе изучение ее будет пыткой, которая, кроме убийства мотивации, ничего хорошего не принесет.
Мне кажется надо идти на собесы к тем кто спрашивает по сикп и книге дракона - у них и денег больше и работать интереснее
Так это же фундамент, как говорят. Каждый должен знать. Что-то мне подсказывает, в подобных компаниях далеко не типичные программисты работают.
Так вот проблема с "базой" как раз в том, что она бесконечная. (с)
Плюс один.
ЗЫ. Мало того, она еще и кусочками как в анекдоте про слона, которого щупают несколько незрячих людей.
подобных компаниях далеко не типичные программисты работают
Самые обычные. Просто им теперь надо как-то быстро фильтрануть воронку на вакансиях с диким кол-вом откликов. Заниматься вы там будете той же перегонкой джонсонов и покраской кнопок. Очень мало кто пишет новые ОС и СУБД, таких людей в мире единицы
Бизнесу нужны люди, которые решают конкретные проблемы, а не теоретики
только интерьюверы так не думают
ходил тут некоторое время назад к яндексу на их прославленный собес, капец они там упоротые по литкоду, я тупо с середины первого собеса сказал что эту хрень и игру в компилятор и играть не хочу, мне времени жалко, у вас сервисы черти как работают в некоторых случаях и знание как сортировать список из литкода на среднем уровне сложности им явно не поможет
только интерьюверы так не думают
ходил тут некоторое время назад к яндексу...
Это вы прямо удачно попали, потому что про него даже тут много историй.
Можете поделиться ссылками на такие истории? А то задачи с литкода на собесах для меня больная тема)
Есть же поисковик... Ну да ладно.
Собеседование в Яндекс: театр абсурда
Как проходят алгоритмические секции на собеседованиях в Яндекс
В последней статье почитайте комментарии.
А то задачи с литкода на собесах для меня больная тема)
Лично мне банально жалко времени на литкод. Я не получаю удовольствия от решения, а тратить полгода на натаскивание себя только для собеса в яндекс - так себе идея. Лучше уж, про какой-нибудь COM почитать, и то полезнее будет.
На литкоде задачи не решал, на собесе яндекса задачи мне показались вполне разумными, несложными, и в случае косяка - вполне есть о чём поговорить. В Яндекс в итоге не пошёл, но именно алгоритмическая часть мне понравилась.
Я знаю что есть люди которым нравится такие задачи и к ним я не отношусь. я подобные штуки. если они встречаются мне на работе, решаю в течении нескольких часов с чашкой кофе и несколькими итерациями в стиле "сделал в лоб, улучшил-улучшил-улучшил-во норм работает-еще улучшил-отлично!"
А не в течении 15 минут наваять код в блокноте и описать построчно какой будет результат, под наблюдением молчаливого интервьювера (который когда включается то - ну а вы же забыли обработать последний символ..и опять тишина)
Я воспринимаю такие задачки именно как несложные задачки, а задачки мне всегда нравились. Ну и написать аккуратно, в том числе не забыть про углы - это мне тоже нравится. Слишком много видел коллег, которые про углы не думают совсем, один такой месяц форму допиливал, потому что если одного параметра нет - всё разъезжается. Параметров несколько, вот по одному за раз и чинил. Ну и 15минутные задачки полдня решать... Не привык к такому расслабону. Я лучше сделаю за 20 минут, проверю ещё за 20 и пару часов почитаю что-нибудь полезное, если время есть.
Наблюдатель немного нервирует, но негативных я не встречал (послать нахер - за мной не заржавеет), а с дружелюбным и поболтать интересно. Опять же, про потроха компании узнать заранее.
Ну, "дракона" это, все-таки, весьма специализированная книга - если конкретно этим не занимаешь, то вряд ли она нужна, а, вот, Таненбаума те же "Архитектура компьютера" и "Современные операционные системы" разок в жизни "по диагонали" прочитать, я считаю, всяко стоит. Приходит на интервью чувак, формально даже не джун, с опытом работы (.NET / C#), заметно что плавает в "ref" и "out" параметрах. Начинают его расспрашивать немного глубже, даже наводящие вопросы задают, и выясняется, что чувак про такие концепции как "указатель" или "адресация памяти" он вообще ни сном ни духом - у него в словарном запасе просто терминов даже таких нет. Его когда-то просто научили писать что-нибудь типа: var foo = new Foo(); вот он просто и пишет. Возможно, что для него даже "оперативная память" это всего лишь какая-то колдовская плашка с какими-то микросхемами, которую надо купить, а потом воткнуть, чтобы новая игрулина заработала :) Не, ну, в принципе, ему даже можно подобрать какую-нибудь роль "вечного джуна" - но сильно ли рационально держать человека за которым всю жизнь (кому-то) присматривать придется.
"Архитектура компьютера" и "Современные операционные системы" разок в жизни "по диагонали" прочитать, я считаю, всяко стоит
Если читать по диагонали, то лучше уж какое-нибудь видео посмотреть на ютубе. Времени займет - час-два и общие концепции понять можно. Все этого достаточно. Ну не обязательно помнить 100500 алгоритмов замещения страниц или правила работы планировщика.
Приходит на интервью чувак, формально даже не джун, с опытом работы (.NET / C#), заметно что плавает в "ref" и "out" параметрах.
Ему указали на это - он и подучил. Mission complete. Я против подхода - закончи мехмат, выучи электротехнику, изучи Hardware layer, os layer, software layer. И вот теперь, в 60 лет можно смело начинать писать на питоне, когда фундамент отстроен.
Ему указали на это - он и подучил.
Может подучил. А может просто пошел (возможно и сюда) плакать на какое зверьё он на собеседовании нарвался :) Здесь полно людей, готовых без промедления отх*есостить любого за "-тся/-ться", неправильное употребление феминитива, или расстановку запятых в деепричастном обороте, но вот не знать программисту таблицу умножения - это нормально, это не нужно :)))
совсем другое кажется базой для современного программиста, в частности: теория алгоритмов, теория вероятности, дискретная математика, из более прикладного: компьютерные сети и нормальные формы баз данных
Похоже на таблицу умножения? Если человек учился на мехмате, то ок. Но в другом случае это все ботать не обязательно ДО достижения определенного уровня профессионализма.
Если человек учился на мехмате, то ок
Вообще-то, программированию тоже надо учиться. А ученье свет подразумевает наличие каких-то базовых знаний. Никто (адекватный) не станет на собеседовании требовать знания какого-нибудь "алгоритма Тарьяна", но уж знать что такое "О(...)", уметь обойти дерево (или, хотя бы, знать что это такое) и подобные вещи - это для программиста вещи такого же уровня как таблица умножения для, скажем, обычного выпускника средней школы.
Просто поделюсь реальным опытом, пока неудачным. Ищем дата инженера. Помимо всего прочего задаю простой тест на знание SQL, запрос написать, ничего выдающегося вроде найти макс значение в разрезе и вывести, кому оно принадлежит ... и полный трындец. Задача просто неподъемная. Люди сначала пишут полную хрен, потом с третьей подсказки иногда приходят к результату.
При этом, я смотрю как люди пишут (прошу шарить экран), то сразу видно (ну и по общению), люди просто не понимают как это вообще работает
Что интересно, ChatGTP осилил задачу с третьего раза, тоже при помощи "сильных" подсказок
Вот и получается, что либо дата инженерам база (и вообще, SQL писать не барское дело) не нужна, либо ... сорян, этот весь опыт не имеет смысла, так как получается люди чего-то знают, но исключительно как "собака павлова". Шаг влево или вправо - и все
Просто интересно, речь про запрос вида
select f1, max(f2) from table group by f1 where f1='xxx',
или же речь про over partition by?
Ну, такого рода запросы разве что для QA актуальны :)
Простая задача: две таблицы, сотрудники и отделы. У сотрудников есть ЗП и имя. Ну и ссылка на отдел, в котором они работают
Надо выбрать для каждого отдела среднюю ЗП, максимальную ЗП и имя того, что получает эту самую максимальную ЗП. Естественно одним запросом
Наверное, я именно такой дата инженер, кто подошёл бы под ваше описание. Но, я правда редко пишу sql сложнее обычного select * и сноровку уже потерял, чтобы сходу в незнакомой бизнес области выдать хорошее решение, абстрагировано словами в какую сторону я бы делал - легко.
В дополнение - не знаю как у других, но за счёт удаленки и флешбеков со школьных времён, когда над душой ждут решение, моя способность писать код распадается до забывания как вообще писать, думать и говорить)
Возможно, я не прав, но считаю, что если интервьюер достаточно подготовился к собеседованию, то уровень и навыки собеседника можно определить и без лайв кодинга
Никому мои знания по CS не пригодились, зато нужно было знать проклятые фреймворки и иметь опыт.
Эм, так дело не в том, что не нужно знать фреймворк. На собес когда идешь там же видны требования в вакансии.
Но вот знать фреймворк без фундамента - значит быть косоруким человеком, которому очень сложно понимать как вообще стек технологий работает, связан друг с другом и у него интутитивно кривые решения идут.
Эм, так дело не в том, что не нужно знать фреймворк. На собес когда идешь там же видны требования в вакансии.
Фреймворки я упомянул для красного словца. Т.е. в требованиях написаны крайне прикладные вещи, которые, в общем-то можно и без базы осилить.
Но вот знать фреймворк без фундамента - значит быть косоруким человеком, которому очень сложно понимать как вообще стек технологий работает, связан друг с другом и у него интутитивно кривые решения идут.
Если эти кривые и косые решения покрывают требования заказчика, о чем разговор? Не поймите меня неправильно, я не ратую за стратегию фигак-фигак и в прод. Я за, скажем "выборочное" обучение. Т.е. изучение материала в тот момент и именно тогда, когда текущего будет не хватать. Информации в мире полно, но времени мало. Так зачем тратить его на то, что скорее всего не пригодиться?
Да, с некоторыми вещами так не прокатывает. Например: ios программиста посадили создавать что-нить на винду. Потом, когда человек будет знать, что следующие год-полтора его будут связаны с этой платформой ему следует почитать Русиновича. Лучше, имхо, пусть будет так, чем пару лет изучения устройство операционных систем, Win32 api, ассемблера и в результате пойти в сбер на жабе кодить.
Если эти кривые и косые решения покрывают требования заказчика
Если вы работаете в команде, косорукие решения сложно поддерживать команде. То есть решение такое становится дороже, требует кучи непонятных телодвижений просто на поддержание - при апгрейде версии ОС, например, нужно перепроверить совместимость 100 зависимостей, а не 10ти. И так далее.
У меня есть примеры, когда косорукие решение устраивали заказчика, пока они не вышли в продакшен, а там выяснилось, что работают они не так, как хотелось, и делают не то, что нужно, и вообще в таком виде никому не нужны. В результате потом проект закрывается, а потраченные миллионы долларов они конечно были освоены, но было бы лучше, чтобы они были освоены проектом, который затем продолжает жить и приносить пользу. Плюс рабочие места не сократились.
Если вы работаете в команде, косорукие решения сложно поддерживать команде. То есть решение такое становится дороже, требует кучи непонятных телодвижений просто на поддержание - при апгрейде версии ОС, например, нужно перепроверить совместимость 100 зависимостей, а не 10ти. И так далее.
Если мы еще про бизнес, а не про красоту, то заказчику нужны финансовые показатели, а не эти ваши абстрактные зависимости и идеальная архитектура. До тех пор, пока техдолг не бьет по кошельку нет смысла что-то менять.
Если пм покажет с графиками заказчику, сколько он может сэкономить или заработать, все технические проблемы никого не интересуют. Если появится задача сделать лучше - гуглим/читаем, образовываемся.
У меня есть примеры, когда косорукие решение устраивали заказчика, пока они не вышли в продакшен, а там выяснилось, что работают они не так, как хотелось, и делают не то, что нужно, и вообще в таком виде никому не нужны
Внезапно? Для этого и придумали разные методики разработки. Это прям эпичный факап менеджеров, а не прогеров.
То, о чем вы говорите - это хорошо и правильно, но, зачастую так не бывает. Сегодня вам нужно одно, а завтра - другое. У вас жизни не хватит получить все "базовые" знания. А если и хватит, то вы либо один из гениев, либо живете жизнью бывшего тут дедфуда. Программисты-сетевики занимаются только сетью, они могут не знать, что там на физическом уровне. Для кого-то это база, между прочим. Но вот им(сетевикам) и без этого есть что поизучать. И это нормально.
Внезапно? Для этого и придумали разные методики разработки. Это прям эпичный факап менеджеров, а не прогеров.
Там был факап конкретного архитектора, который придумал и решение и навязал продукт, который можно было сделать ну наверное на порядок проще и дешевле. В результате когда продукт дошел до продакшена, он оказался в разы дороже готовых и существующих решений (даже опенсорс), которые можно просто взять и использовать
потраченные миллионы долларов они конечно были освоены
Задача, стратегия, и тактика любого аутсорса это "лечить" заказчика, кормя его завтраками, пока он исправно платит денег. Уйдет в конце концов (к таким же "лекарям"), да и хер с ним - другого найдем. Почти всю жизнь в аутсорсе - исключений не встречал, увы.
мои знания по CS
Первая же ссылка в гугле по CS такая.
А можно всех вот тут спросить, кто комменты писал, просто из любопытства, в какой вы возрастной категории? Мне почему-то кажется, что отношение к собесам и поведение на них сильно зависит и от возраста.
Мне 24, отношение к собесам сегодняшнего дня резко негативное. У тех, кто постарше, оно обычно ещё хуже
Спасибо за ответ! Да, действительно, если и в этом возрасте люди, скажем так, не слишком мотивированы работодателям на собесах, что же говорить о категории 35+, в которой, в том числе, я.
Нормально всё у нас:)
Я в юном возрасте палкой крапиву бил;)
Участвовал в построении сети между домами через кабеля;)
Гордился рейтингом на торренте;)
Собесов не боюсь, отношусь к ним как к необходимому этапу для понимания: сможем ли мы вместе решать задачи
как к необходимому этапу для понимания: сможем ли мы вместе решать задачи
в больших компаниях вас может собесить человек которого вы никогда не увидите больше
И у меня был разок фейл, в компании где я отработал 2 года потом постоянно каждый день ругался с тимлидом по поводу буквально всего,по разным причинам я не мог в тот момент быстро поменять работу...хотя на собесе всё было идеально
50+
А как без собеса понять, подходит человек или нет? А как без собеса понять, подходит тебе компания или нет? Мне вот не нравится умирать, но меня не спрашивают. И собесы мне не нравятся, но другого пути нет (если не нанимать/ся/ по резюме, конечно)
Спасибо. Так я не говорю, что собесы не нужны - от них по факту и невозможно, и не надо уходить. Просто на подготовку к собесам, поведение на них, эмоциональное состояние и, в конечном итоге, успешность, влияют много факторов. Многие перечислены в статье, но есть и другие. Я вот и подумал про возраст. Например, я по себе могу сказать, что какое бы важное для меня собеседования сейчас я ни проходил, я уже не буду, скорее всего, так волноваться, как, например, 15-18 лет назад. Возраст просто )) Научился относиться более философски ко многим вопросам.
Тут не столько возраст, сколько опыт и обстоятельства. Поскольку я собесы прохожу примерно раз в 10 лет, то и опыта нет, и некоторое волнение есть. Собесы сейчас и собесы 10 лет назад отличаются кардинально, а 20 лет назад это было просто "опыт есть? Тогда вот чем мы занимаемся" и два часа рассказа о перспективах.
Ну и одно дело, если у меня горит, и другое - если я на расслабоне просто решил посмотреть на пресловытые Яндексовые собесы, и ХРша уж очень удачно попала мне в окно
Мне 50 - на собеседования (технические) хожу с удовольствием - практически всегда интересное общение, частенько что-то новое можно узнать. Но у меня опыт и запрашиваемый грейд такие, что техсобеседование чаще с людьми уровня архитекта проекта или руководителя разработки. Такого, чтобы меня кодло мидлов по бумажке спрашивало "чем value type отличается от reference type" давно уже нет :)) Джунам, конечно, сложнее.
А нет у Вас ощущения, что, по крайней мере, некоторые компании отказывают по причине возрастной категории? Ну просто ищут молодых, до 35 (условно), но уже с 15-летним опытом?
В резюме возраст не указываю, когда дело доходит до интервью (особенно технического), то по-моему всем уже возраст без разницы. Все чаще и чаще попадаются и руководители/лиды/архитекторы моего возраста (а то и старше) и даже целые команды 35-40. В общем-то те, кому сейчас ~50 - это те кому было ~15-20 когда компьютеры стали становиться массово доступны, так что ничего ненормального в возрасте 50 в контексте IT я вообще не вижу - если у какого-то отдельно взятого HR тараканы в голове на эту тему, так бог ему судья - на нем и его вакансии(ях) свет клином не сошелся.
В 50+ уже накапливается усталость от этого всего, а готовности работать ради перспектив и 16/7 нет уже лет 20 как. Не всем это нравится. Ну так и нам к этим "не всем" точно не надо
Ну есть усталость, ну и что. Зато я пришел на работу и сделал аккуратно за 8 часов то что на эти 8 часов было запланировано. А не сижу над работой по 14 часов кряду с горящими красными глазами, выдавая кучу какого-то полуработающего нечто.
Это мы с Вами понимаем. Но большинство молодых и шустрых, а также все ХРы - не понимают.
а также все ХРы - не понимают.
Ну я выше написал - здоровья им и долгих лет, ничто не мешает найти других. Сейчас, в общем-то, проблема совсем не в возрасте, а в средней адекватности того что предлагают - после массового исхода евреев из Египта иностранных компаний с этим наступил какой-то армагеддон :)
Мне ХРша в Яндексе гордо сказала "мы решили Вам техническое интервью не проводить", радуйся, мол. А два алгоритмических и архитектруное меня поразвлекали.
Мне 46. Отрицательно отношусь к тестовым заданиям, особенно если они больше чем на 2 часа, и если у тебя уже есть проекты для оценки навыков. И у меня устойчивое ощущение, что многие компании отказывают по причине возрастной категории - на себе проверил. Это в корне неправильно, многие "возрастные" могут и хотят работать разработчиками.
И оказалось, что во мне увидели понимание фундаментальных вещей
я так собесы провожу, потому что тупость упарываться в академическую зубрежку, я несколько человек из своей команды (которых не я набирал) увольнял по причине что они на зубок знают теорию и задачки с литкода решают, но реальные бизнес-задачи это просто клин...человек вообще не понимает что и зачем он делает и не чувствует систему для которой пишет
но по факту, большинство техсобесов у других, устроены именно на упарывании в зубрежке доскональном знании какихто академических вещей и т.п. и валят именно на этом
помню недавно собесил человека в соседний отдел QA с требованиями "писать тесты на pytest на уровне хотябы middle", с очень неплохим опытом и широченными знаниями в разработке (и чё он в QA упарывается непонятно)...очень продуктивно пообщались, чел прям изумился что я первый за последние 10 собесов который его тупо не завалил на тех.собесе уйдя в дебри всякого ООП и программинга и знаний особенностей постгри и mysql и отказывали ему из-за недостатка знаний
и чё он в QA упарывается непонятно
Полагаю, упарывался в QA как раз из-за тех самых зверских собесов для разрабов
ну на 5 зверских собесов приходится 2 нормальных (во всяком случае в 10х годах так было)
Я когда был рядовым разрабом железобетонно устраивался с 3 максимум с 5 собеса, заваливая только зверские и отказываясь от пары самостоятельно ;)
а на высоких грейдах оно вообще проще становится...
p.s. я за то чтобы разрабы все росли в сеньоров, тут реально спокойнее и лучше в плане поиска работы..да и на работе интереснее
во всяком случае в 10х годах так было
То, что было в 10-ых, уже можете смело выбросить из головы, это уже не актуально в крайней степени. Люди сейчас по много месяцев на некоторых стэках могут работу искать
ну справедливости ради, я тимлид/техлид, я начал отвечать hr-ам в конце февраля чтобы помониторить рынок, и вот только сегодня получил оффер который принял, это заняло 5 тех. собесов от разных контор, от одного оффера я отказался по причине гибрида (пытались уговорить что прям ради меня разрешат удаленку...но нет, я такое не верю), у большинства контор где разговор закончился после общения hr-ом я был выше их максимальной вилки по которой они могли меня взять, я даже для развлечения потыкал в потолок открытого рынка тимлидов (когда вам hr-ы пишут), когда вообще перестают писать hr-ы или написавшие сразу исчезают когда называешь сумму...на прошлой неделе опустил вилку чуть ниже...и бац, оффер причем с суммой выше которую я запрашивал..но несущественно ниже той на которую вообще никто не отвечал ..(однако)
отказался от нескольких вакансий где предлагали чистого сеньора...но мой путь сейчас в менеджмент скорее лежит и идти назад смысла нет
Сейчас по количеству откликов на резюме как-то все сильно оживилось по сравнению с прошлым годом, когда по ощущениям был вообще швах. Удручает (я уже выше это упоминал) не количество, а качество. Такое ощущение, что остались только банки, их вендоры, и всевозможные, буйным цветом расцветшие "аккредиташки" с их госзаказами. Дико затянутые процедуры фидбеков - проходишь первичное собеседование с HR, потом HR исчезает, а потом появляется спустя месяц (когда ты его уже даже из всех контактов поудалял): "- Оппа, вот и я - мы хотим вас на тех интервью пригласить.", "- Бл*, а ты кто вообще такой(такая)?". Проверки СБ, которые присылают анкеты о восьмистах вопросах и лезут тебе в анус копают пару-тройку недель твою биографию и родословную до времен Рюриковичей. Принимаешь оффер, тут, оказывается, что все твои бумаги должны еще у заказчика семь кругов ада пройти, и реально договор с тобой подпишут только к следующему китайскому новому году (причем еще без всяких гарантий, что по дороге что-то не сорвется). Когда-то и почему-то (хотя, в общем-то, понятно почему) было дохренища приличных вакансий, где можно было в понедельник отправить резюме, к концу недели получить оффер и со следующего понедельника уже просто начать работать. Где оно все теперь (впрочем, тоже можно догадываться).
Считаю наличие фундаментальных знаний обязательной базой, глубину знаний по различным тех. инструментам спрашиваю минимально и вглубь. На мой взгляд условный сеньор должен идеально разбираться в базовых для большинства ЯП вещах (ООП, ФП, SOLID, Наиболее распространенные паттерны, структуры данных), чем больше уровень, тем увереннее и глубже, а также понимать, для чего конкретно нужны те или иные инструменты, их плюсы и минусы без зубрешки. От гуру жду понимания того, как то или иное работает под капотом. Как правило так достаточно минут 30-60, чтобы понять, кто перед тобой, профессионал, дилетант или просто трепло в резюме. Бывало встречал так тех. архитекторов, у которых уровень понимания базы был на уровне стажера и таких на работу брали только потому, что они хорошо умели пудрить мозги начальству, мне же 10 минут общения в тех. вопросах хватило, чтобы понять, что человек вообще ничего не понимает. Как говорится: "Рыбак рыбака видит издалека"
И как, наличие фундаментальных знаний у ваших разработчиков позволяет вам (предприятию) как-то вырваться вперёд в своей области?
Вопрос без подкола, мне правда интересно, есть ли вообще какая-то разница на выходе, или по итогу просто вам комфортнее с такими людьми работать?
И да, "удобнее работать" одобряю, но интересно всё-же понять есть ли эффект именно для бизнеса.
Еще лучше, чтобы условный сеньор был бы автором всех этих аббревиатур. Ну или хотя бы парочки...
Главное чтобы с этим сеньором не вышла история как с автором какого-то проекта, который в Гугле используется, который был заявлен в требованиях на вакансию, и которому отказали по причине недостаточного знания этого самого проекта )))
Кстати охотно верю если проект прямо большой, а человек работал над его частью, то относительно остальных частей проекта взгляд может быть зашорен вполне, больше чем у человека со стороны его активно использующего.
Homebrew что ли?
Это вроде история была с FastAPI. В вакансии требовался опыт FastAPI, больший, чем существовал сам FastAPI.
Под этот критерий разве что Дядя Боб попадает.
был у меня как-то собес (хорошо не первый, а где-то 10й) и там отвечал что такое "ООП, ФП, SOLID, Наиболее распространенные паттерны, структуры данных" и много еще чего типа "правильного"... и я прошел его.. и когда дело дошло до задач - там в html разметке на php делались запросы в БД...
вопрос: нафига спрашивать базовые понятия, если у компании код вообще не по-понятиям написан?
был собес на задачи по литкоду (хорошо, что от спортивного программирования еще не все было забыто). на работе же нужно было, поменять банер на сайте.. добавить форму с опросом..
вопрос: нафига спрашивать литкоды если это веб!?
ну был собес про "под капотом" (хорошо что мне это самому просто интересно). Мы полчаса обсуждали гарбадже коллектор и слайсы в Go.. как думаете, сколько раз мне эти знания пригодились на практике? (ответ: 1 раз - когда слайс выжрал пару гигов оперативки и не отпускал их)
к чему это я все - не надо спрашивать то, что не релеватно... ну не сидят синьеры на работе и не ковыряют исходники языка, чтоб посмотреть что же там у него под капотом - нет времени. Да и мидлы не устраивают холивары в МР - это не по SOLID, тебя за такой бы код Liskov на кол бы посадила
ну а так: джунов - можно мучать по литкоду, там опыта нет, а понять кто перед тобой хочется.. мидлов - можно погонять по "solid", и то если у вас у самих код нормально написан.. а лучше всего предложить описать решение какой-нить проблемы, которая у вас возникла и вы ее решили... ну а синьеров с 10 летним стажем - там просто про опыт поспрашивать, да на резюме посмотреть.
предложить описать решение какой-нить проблемы, которая у вас возникла и вы ее решили
Мне такой подход нравится, именно так я и устроился программистом. До этого на собесах были стандартные вопросы, от которых у меня начиналась чесотка и хотелось скорее сбежать из этой атмосферы экзаменационной духоты.
Ещё раньше мне понравилась тема, когда подсаживали к возможному коллеге посмотреть за его работой, пока ждёшь собеседующих. Можно примерно прикинуть, интересно будет тут работать или нет (и уйти, если нет). Мне тогда, как джуну, конечно мало чего понятно было, что за проект и для чего, только в общих чертах, но, глядя на код, заинтересовался. Мидлу с опытом проще будет. Само собой, если код под NDA, этот вариант отлетает :D
До этого на собесах были стандартные вопросы, от которых у меня начиналась чесотка и хотелось скорее сбежать из этой атмосферы экзаменационной духоты
Ох, помню один cобес, который рил напоминал экзамен. На нём были вопросы буквально ОБО ВСЁМ: начиная с модели OSI и заканчивая внутренним устройством горутин в Go. Уже через 40 минут (из 2-ух часов, отведённых на собеседование) я начал себя чувствовать неважно, настолько это было нудно и изнуряюще. Я на паре вопросов сильно зафакапился (что-то не помнил, потому что учил давно и не сталкивался, что-то просто не знал, потому что вообще не надо было в работе) и уже понял, что меня отсеят, ибо за забором очередь и обязательно найдётся чел, который ответит лучше. Это при том, что это даже не финальная встреча была, лол, там потом ещё какие-то предстояли
Во-первых, в магистратуру ИТМО по программной инженерии попасть было проще, блин, чем на позицию в айтишке сейчас
Во-вторых, какое отношение вся эта куча имела к непосредственным рабочим задачам? Я даже примерно не мог понять, чем именно я на позиции буду заниматься и в каких условиях я буду работать
В-третьих, это такая попутная проверка на стрессоустойчивость была или что? Собес - это витрина галеры. Какой смысл мне хотеть на неё попасть, если я ещё в процессе интервью выгляжу вот так?
Ну то есть, к вам приходит человек, который работал сеньором или, как вы говорите, гуру, в других компаниях, приносил пользу, но так как он не знает именно ваших "фундаментальных знаний", то вы его просто отклоняете? На месте вашего начальства, я бы выбрал другого человека в компании для проведения интервью, чтобы вы не отклонили стоящего, в котором распознаете "трепло".
Вот я учился на прикладной математике и мне совсем другое кажется базой для современного программиста, в частности: теория алгоритмов, теория вероятности, дискретная математика, из более прикладного: компьютерные сети и нормальные формы баз данных. Я бы с удовольствием работал (и болтал) с человеком, который подкован в этом хотя бы на университетском уровне. А ООП, SOLID, паттерны мне кажутся максимально узкими знаниями в одной из областей программирования, притом даже не знаниями, а неким мнением о том, как упростить работу программиста.
Но спрашиваю я на собеседовании не о том, что мне кажется базой, а о том, что нужно для позиции, на которую собеседую, и о том, что указано в резюме для того, чтобы предположить, похожий ли у нас образ мысли и вольётся ли человек в команду. А тому, как мы по файликам разделяем код и какие сущности для этого используем, я его научу.
А расскажите, если не сложно, почему для современного программиста (подразумевается же некий усреднённый, а не узкоспециализированный?) вы считаете базой то, что считаете. Особенно про теорвер инетресно.
Всё так. Только с какого хрена руководители условной компании должны слушать какого-то совершенно левого для них чела в вопросах, кто полезен для их компании, а кто нет? Я почему-то сильно подозреваю, что те, кто на месте начальства этой компании, сами разберутся, как им вести свой бизнес.
То, что некий кандидат где-то раньше работал и кому-то раньше приносил пользу, никак не влияет на то, будет ли он полезен данной компании. Им же польза для себя нужна, а не для тех, на кого он раньше работал. Они его полезным для себя не посчитали. Это для них самое важное. Причем здесь вообще прошлое кандидата?
Это всё равно, как если бы вам кто-то выкатывал претензии, что вы не взяли с улицы собаку. "Ведь она столько пользы принесла прошлым хозяевам. А вы не берете. Да как вы вообще смеете!?" А вы, к примеру, вовсе не собаку хотите взять, а кошку. И потому для вас вся та польза, что собака приносила прошлым хозяевам, совершенно бесполезна.
Отвечу сразу всем. Полагаю, что мы по разному понимаем фундаментальные знания. Мне не нужна зубрешка и ответ по методичке, мне нужно понимание их использования и это легко проверить, распросив человека о его проектах, которые он делал и какие решения там внедрял. Это банально показывает, что человек не напорит в структуре пурги, чем страдают частенько слабые мидлы, джуны и сеньоры. Вопросы про конкретные инструменты не исчезают совсем, они есть, но по ним гораздо проще понять, что человек разбирается, задав буквально пару сложных вопросов про внутренку и в каком-нибудь решении, которое делал человек, тут ответ джуна от сеньора будет отличаться координально, так как глубже уровень понимания. Это все-равно что спросить будущего ремонтника двигателей авто с опытом, как работает двигатель внутреннего сгорания и не получить ответа, вам же не нужен инженер, который "заточен" под пару марок авто? Как человек может разбираться в какой-то марке и при этом не понимать принципы работы? Я могу к примеру задать человеку кучу вопросов про Redux, но если мне такой сеньор не может объяснить в каких случаях он вообще считает Redux применимым и когда он плох, понятия не имеет на каком паттерне он базируется и как работает (пусть и не под капотом), то нафиг он мне сдался? Он будет лепить его везде где не попадя, раздувая кодовую базу. Или не понимает принципы SOLID начнет плодить кучу дубликатов кода, человек может не знать как называется тот или иной принцип, но из распросов можно понять и даже указать человеку, что он это знает и называется это так то, вот это мне и интересно.
Разница на выходе при приеме на работу таких профи колоссальна, над ними не нужно стоять и бдеть за качеством их работы, они сами зададут всегда нужные вопросы и будут работать эффективно как правило, если их работой не перегружать (и да я разработчик, а не манагер). С такими всегда приятно вести дела и менеджменту и другим инженерам, как менторы такие люди еще более ценны.
вопрос: нафига спрашивать базовые понятия, если у компании код вообще не по-понятиям написан?
Если вы такое видите и понимаете, что не так, то вы работаете где-то не там, имхо
Мне нафиг не сдалось с людей требовать знания всех алгоритмов по кнуту или олимпиадных задач, еще раз. Вот что я имею ввиду. Мне нужно, чтобы человек рассказал базис и показал свое понимание исходя из своего практического опыта, а не выдумывал коней в вакууме или цитировал книжки
Ну то есть, к вам приходит человек, который работал сеньором или, как вы говорите, гуру, в других компаниях, приносил пользу, но так как он не знает именно ваших "фундаментальных знаний", то вы его просто отклоняете?
Это не "мои" фундаментальные знания, этим обладает любой крепкий инженер-программист, у которого есть кругозор и понимание, а не опыт трех месячных курсов по js/c++/java/c# и тп. Зубрешка мне не нужна, я хочу услышать как человек что либо понимает своими словами, можно на примерах из практики. Если человек называет себя сеньором и не может объяснить хотя бы в чем особенности хеш мапа, когда это вполне себе часто встречаемая структура, но при этом он прошел курсы по js и считает ее просто списком, вы точно хотите такого "сеньора"?
Джунов мучить литкодом я тоже считаю маразмом (если человек не нанимается для какого-то рокет сайнс), все тоже самое, только более по простому и требования ниже разумеется, как и уровень понимания (тут Solid и сложные структуры данных в чем то больше поверхностного понимания, уходят на второй план), изредка могу дать какую-нибудь задачку на логику решить, если не могу решить по другому
Более того, я всегда людям даю развернутый фидбек и объясняю, что не так, иногда могу даже коротенько мини лекцию прочитать по теме, если время есть, не редко я из-за этого засиживаюсь до поздна, чтобы закончить то, что не успел из-за этого.
Исключением могут быть разьве что требования по уровню знаний различных разделов математики, но это больше зависит от специфики работы. Думаю для большинства понятно, что чтобы условно писать ПО для ракет, нужно еще как понимать физику и математику. Есть много сфер, где без таких вопросов никуда...
Точно также при смене работы, я скорее пойду в компанию, где на "фильтре" работают реальные профессионалы у которых есть чему поучиться, чем к типичному опроснику/литкод интервью + бесплатному домашнему заданию и тп, как у многих крупных и модных компаний, что думаю задолбало уже давно большинство
А если человек в прошлом имел неплохую базу а потом получал опыт скажем по ремонту или проектированию гидравлики и пневматики а потом прошел пару курсов и решил вернуться к программированию. И при этом относительно адекватно отвечает на базовые вопросы? Я начинал заниматься вэб бэк эндом, фронт энд неплохо освоил. Потом пошел работать технологом безалкогольных напитков лет 10 назад, заочно учился. В процессе работы научился многому кроме гидравлики. Электрика, сантехника, пневматика и далее по списку, больше эксплуатация и ремонт но и нередко проектирование. Часто сталкиваюсь с такой ситуацией что люди которые не один десяток лет работают скажем с гидравликой или ремонтом двигателей или топливной аппаратуры автомобилей понимают что они делают меньше чем я через полчаса поиска в интернете. Ну или время сильно экономят. Даже когда я готов заплатить в 2-3 раза больше лучше сделать говно 4 раза и вроде выхлоп лучше будет.
Я скорее возьму человека, который явно умеет учиться и понимать, чем человека-справочника по узкой спецификации. Как правило такой очень быстро во всем разберется. Исходя из своего опыта работы с более чем двух десятков языков программирования, а начал я в этом крутиться еще когда мне 10 лет было до всяких мейнстримов, подавляющее большинство подходов во многих языках и инструментах, это переиспользование того, что было изобретено очень давно. Большинство современных ЯП заимствуют почти все оттуда, часто причем это какие-то мало известные языки. Именно поэтому я считаю, что такой человек разберется практически в чем угодно, если это не какая-то очень специфическая область.
На счет полной смены стека разработки, это опять же легко проверяется заданием сложных вопросов по тем или иным вещам, как правило такому человеку можно или предложить поработать с этим с потенциалом роста, на грейд-два ниже, чем он есть в другом стеке, но во многом принципы схожи. Кругозор как по мне решает гораздо больше, чем узнкая заточенность.
При этом хочу подчеркнуть, что ни один человек не может быть гуру во всем, т.к невозможно физически поддерживать актуальность знаний во всем. Я к примеру долго работал в бекенде (нынче уже 4 года фронтенд, иногда девопс) и для меня не составит труда с ходу начать писать практически что угодно, но я осознаю, что мои знания многих актуальных инструментов устарели, правда это не значит, что я не смогу эту актуальность вернуть буквально за пару недель чтением актуальных доков на досуге + месяцем работы непосредственно на проекте, потому что все базисы мне и так известны, я там практически наверняка не встречу ни новых для меня структур, как бы они не назывались по другому (это все решается гуглением, порой даже в тупую "как называется аналог X из языка Y в языке Z"), ни новых паттернов, а в большинстве случаев просто другие наименования общепринятых в разработке вещей.
Скажите многое изменилось? Да, это так. Только изменились в основном обертки, а под капотом старая добрая математика, логика, ООП, ФП и паттерны с алгоритмами, которым порой по 50+ лет. Я людям даже гуглить не запрещаю на собесах при редком решении практических задач, т.к прекрасно понимаю, что тот же синтаксис порой забывается или не все помнят по памяти название всех методов базовых классов.
Из опыта собеседования стажеров также могу отметить, что бывает сразу понимаешь, что "надо брать", видно что человеку интересно и что он может чего-то не знать, но умеет понимать, учиться и объяснять своими словами, дружит с логикой и здравым смыслом при обсуждении решений. Пару лет назад довелось принимать финальные экзамены по Angular в большом кол-ве у стажеров в одной дорогой галере, эти ребята самостоятельно все изучали, изредка обращаясь к менторам и делали задания. Так вот могу сказать, что это были именно очень подробные опросы (т.к людей нужно было продать заказчикам, галеры они такие) на полтора-два часа и многие из них понимали те или иные вещи порой лучше, чем многие гораздо более "матерые" инженеры с рынка, редко но бывало я в рекомендациях вообще писал, чтобы людям провели ассесмент на уровень выше сразу, чтобы могли пробоваться на мидлов. Не было среди них человека, который бы не сказал мне спасибо, что помог им закрыть большинство пробелов по разным вопросам. Примерно того же я придерживаюсь и на обычных собеседованиях
В целом хочу подчеркнуть, что я считаю самоучек - лучшими инженерами, как правило их навыки гораздо шире чем у многих "школьных" и "университетских" инженеров, либо людей которые "сидят" на одном месте по 20 лет, ничему толком не учась
Мне взяло где-то несколько лет
С какого языка вы переводите?)
Я однажды ходил на собеседование "поболтать", до сих пор стыдно, что потратил рабочее время людей.
А вы в резюме/на первом этапе с HR указываете, что не ищите работу, а просто "поболтать" хотите?
Как вы отнесётесь к тому, что вот приехали на собес (час на общественном транспорте в один конец), а вам там говорят, что в принципе никого и не ищут, просто "поболтать" хотять или если вдруг к ним гений какой заглянет - его и взять?
Мне вот интересно, как кандидаты будет относиться к компаниям, которые нанять то и не хотят, а просто размещают вакансии чтобы HR опыт фармил, да "поболтать" с потенциально интересными людьми....
А как вы относитесь к компании когда вас мурыжат 155 левелами собеседований а потом говорят что вы не подходите?
155 не встречал, встретил только один раз больше 2х технических, на втором сразу сказал "спасибо, всего хорошего" и пошёл общаться с компаниями, у которых обычные три этапа (HR - tech - директор). Не знаю, зачем вы участвуете в 155 если вам это не нравится.
Не искали Вы работу в Германии в 2024, сразу видно ))))) Тут 4-5 этапов , да с техническим заданием стали нормой вещей.
Ох, прошло 2 года, а до сих пор бомбит. На первом созвоне с hr озвучил вилку. Да все ок, идем дальше. 3 этапа. Вынесли мозг. Зовут на созвон с hr. ну думаю оффер. "Вы нам очень понравились, но вы на 70тысяч больше нашей максимальной вилки" (с).
(вспомнилось)
было два этапа, вилку озвучил в начале, в конце созвон с hr - "вы на 40 тыс ниже нашей минимальной вилки по данной вакансии, ставим вам на 40тыс больше"
p.s. чесслово я охренел, чобывает
Аналогично было, но ровно 1 раз. Я тогда переезжал (опять) и плохо ориентировался в целевом рынке труда. Но разница между их минималкой и моими запросами была меньше, но сам факт приятно удивил.
Это Вам еще свезло, что откровенно сказали в чем нестыковка. Обычно просто "не подходите" и все на этом.
Тоже такое было и не раз, дали больше чем просил, причем существенно. Был еще случай когда HR фрилансер сам сказал: "проси больше они заплатят" в итоге я удвоил ЗП при смене работы
Мне вот интересно, как кандидаты будет относиться к компаниям, которые нанять то и не хотят, а просто размещают вакансии чтобы HR опыт фармил
Вы так пишите, будто это какая-то фантастика, а не ситуация, встречающаяся на каждом шагу :)
Если честно, думал что фантастика, никогда такого не встречал и сам не устраивал (когда харил).
А тут есть кто-то, кто прямо в таком участвовал со стороны работодателя? Расскажите подробнее как оно и зачем, интересно было бы послушать.
Есть у нас пару компаний, которые сами пишут и звонят, приглашают на собесы, но потом отмораживаются. Мне звонили, но было не интересно и я сразу заградительную сумму назвал. Коллега ходил, сидело аж 2 hr и еще куча народу из разных отделов в переговорке, он говорит такой толпы еще не видел. Ну и я за местным рынком слежу, у этой компании и еще у некоторых одни и те же вакансии всегда висят на hh, так что все реально... hh вообще скатился в принципе. Из линка как-то адекватные запросы, а из hh одни крайности...
Ну я тоже прошел этот путь, от страшно, потом заучивание кучи технического материала, а потом уже "просто приходишь за жизнь поговорить на равных". И казалось все, конец, куда дальше-то. А вот оказалось что таки есть новый уровень, culture fit и soft skills как тут говорят, так его разтак. И снова сперва вообще непонятно и страшно, потом заучваю наизусть все эти 12 принципов лидерства амазона, прям как задачи на литкоде, а наступит ли время когда и это пройдет, не известно даже...
Понял, только что мне без опыта надо идти работать за еду.
А где лайвкодинг в блокноте, извините? Как-то всё лайтово очень.
Поделюсь своим самым ужасным опытом с собеседований:
Я уже после 6 лет работы в большой компании, стал в небольшой тиме ведущим разрабом на Java. У нас было Desktop приложение на 200k строк кода и 2k Java классов. Но пришло время двигаться дальше.
Нахожу интересную вакансию в этой же компании. Подаю документы. Звонит мне тимлид и мы с ним очень мило общаемся около получаса. Он тут же назначает мне техническое собеседование буквально через несколько дней. Я тут уже думал что дело в шляпе :-)
Техническое собеседование: собираются несколько разрабов, этот же тимлид и я. Первые 5 минут small talk, потом первый же вопрос "у тебя IDE открыто? Давай с лёгкого начнём, напиши простой RestController для Spring (или Boot) который что-то должен возвращать". Я смотрю на них и говорю что понимаю как Rest работает с обеих сторон, там несложно, но опыта написания RestApi нет и даже синтаксис не знаю. Да и IDE не настроена. На меня смотрят точно так же как и я на них - мягко говоря с непониманием. Я предложил перейти к другому заданию. Ответ: "Ххххм, все наши задания базируются на этом первом". Я: то есть программирование Rest это основное занятие у вас? Да, примерно так.
Тут я смотрю на тимлида, мол "что это сейчас вообще было?". Ни в описании вакансии, ни в первом собеседовании не упоминался ни Spring, ни Rest и ничего похожего, речь шла просто о Java и ещё несколько технологий которые я знал. Но тимлид не нашёл ничего лучше сказать "прости, я думал ты умеешь программировать". Face-palm. Не надо таким тимлидом быть.
Видать, ты просто оказался в неправильном месте в неправильное время, а именно на стыке эпох, когда десктопная разработка уступала вебу. Или просто просидел в своём заповеднике с десктопной Жабой слишком долго и теперь не обладаешь навыками, необходимыми для трудоустройства (а они в IT раз в ~5 лет устаревают). Потому что сейчас десктопной разработки на Java НЕТ. Ну, за некоторыми исключениями
есть 2 типа нанимателей.
один ищут "инженеров" - им не важен язык на котором вы пишете, не важны фреймворки которые вы используете, им важен ваш опыт: опыт работы в команде, закрытия тасок, понимание инфраструктуры и тому подобное.. они понимают, что новый язык можно освоить на "сносном" уровне месяца за 3, новый фреймворк за месяц, и они готовы оплатить вам эти 1-3 месяца за ваш 5-10 летний опыт работы
а есть вторые. Эти ищут человека под вакансию со 100% совпадением, чтоб ты вот прям писал на том же языке что и они(тут в принципе норм), использовал тот же фреймворк, и чуть ли не те же библиотеки. Им важно, чтоб ты пришел и на след день уже закрыл пару багов
я все больше вижу вторых, а хотелось бы первых
Это точно, но тем не менее, секция "Системный дизайн" в таких компания существует, а это значит, что разработчику десктопных приложений будет практически невозможно получить должность в такой компании (хотя бы мидла). Джуном и или интерном вроде можно и без дизайн секции пройти
Не спора ради, просветления для, но чем же таким отличается системный дизайн десктоп и веб приложений?
Основные принципы MVC/MVP и там, и там, одинаковые. Да и с чего бы они отличались? Репозитории, DI, ORM и прочие обертки вообще идентичные. Короткие таймауты - так по ним на десктопе как бы не жестче все, потому что где браузеру прощается пара секунд, там на десктопе часто не прощается даже пол секунды. Всевозможные микросервисы и там, и там, прикручиваются и используются одинаково.
Да, отличается механизм транспорта, но не сказал бы, что это нечто невероятное, потому что десктопщик в подавляющем большинстве случаев уже побывал по другую сторону, играя роль клиента.
Плюс есть ряд отличий, связанных с ограничениями самих платформ, но на фундаментальные различия они тоже не тянут.
ЗЫ. Сам уже много лет .NET десктопщик, но был опыт и веб-разработки фуллстаком, и даже параллельное сопровождение WebAPI + внешних сервисов в пару к десктопу. Если честно, именно принципиальной разницы в подходах к проектированию я так и не увидел. Тут скорее веб-приложения выглядят как сильно урезанный десктоп.
Наверное здесь у нас недопонимание небольшое: Системный дизайн != проектирование микросервиса. Системный дизайн - проектирование всего решения, которое включает в себя набор микросервисов и определения способов взаимодействия исходя из задачи (синхронный/ асинхронный/ протоколы), какие инструменты лучше использовать для асинхронного взаимодействия Kafka, SQS, Flink. Например на собеседовании в Амазон меня просили спроектировать Netflix, на другом собеседовании разработать сервис для курьерской службы и т.д.
Скорее у нас недопонимание в вопросе "что есть разработчик". Серьезное сравнение Кафка vs SQS - это уже работа архитектора / системного аналитика, но никак не рядового разработчика, каким бы сеньором он ни был. Не говоря уже про то, что выбор технологии на 80% состоит из финансов и на 20% из степени того, на сколько оно подходит. И иного я пока еще не встречал, потому что деньги считать разработчики не умеют. ))
Задача разработчика - проектирование отдельных связанных кусков системы на заранее заданном стеке технологий. Сказали кафка - значит кафка. Сказали переезжаем на рэббита/SQS - разработчик козыряет и переезжает. Завтра сказали, что с очередей переезжаем на вебапи, плачут и грызут кактус. А вот как все это обернуть, что бы переезжать было безболезненно, особенно при большом количестве подсистем - это уже самая прямая обязанность того самого сеньора, чем он постоянно и занимается.
Ну и будем честными, описанный вами уровень проектирования будет одинаков по сложности, что для десктопщиков, что для бэкендеров, которых к выбору инструментов и на пушечный выстрел не подпускают, если это не стартап из ходячих оркестров. А в остальном и те, и те, щупают и используют одни и те же инструменты.
Скорее у нас недопонимание в вопросе "что есть разработчик". Серьезное сравнение Кафка vs SQS - это уже работа архитектора
Наверное я вас удивлю, но не во всех компаниях, даже крупных есть solution architect (например в компании где я сейчас работаю), и бремя выбора инструментов лежит на "сеньорах". Они проектируют системы и пробуют, внедряют разные инструменты.
Ну и будем честными, описанный вами уровень проектирования будет одинаков по сложности, что для десктопщиков
Как правило, "бэкенд сеньор" за свою жизнь уже успел потрогать много технологий и инструментов из этого стэка, поэтому ему будет проще проходить такие интервью.
А так в "System design" ничего сложного, так как 30 минут недостаточно, чтобы спроектировать полноценную систему, но вполне чтобы показать свои знания или улучшить текущую систему.
Наверное я вас удивлю, но не во всех компаниях, даже крупных есть solution architect (например в компании где я сейчас работаю), и бремя выбора инструментов лежит на "сеньорах".
Все таки, чаще всего это один единственный человек. Который хоть и зовется сеньором, но играет роль архитектора и пинает всех, кто пытается эту архитектуру нарушить.
Как правило, "бэкенд сеньор" за свою жизнь уже успел потрогать много технологий и инструментов из этого стэка, поэтому ему будет проще проходить такие интервью.
Так если десктопщик не красил кнопки 8 часов в день, то почти все из этого стэка он тоже уже потрогал. А часто не просто потрогал, но и поковырял, пиная все команды по цепочке, в поисках где цепочка оборвалась, которую он запускает, но результат не получает. Ну или это просто у меня ненормальный опыт и привычки везде совать свой нос, докапываясь до людей в поисках решения проблем.
Я первых вообще никогда не видел, лол
Собеседования больная тема для многих людей
Я какой-то неправильный. Собеседования для меня почти всегда проходят как-то с интересом, легко и непринужденно. Бывает кринжовенько, но кто в этом мире без греха. Вот как-то так.
Самые смешные собеседования: как-то прихожу в компанию, сижу оглядываюсь, на стенке фотка команды с тимбилдинга в спортклубе. А я там подрабатывала как техник по выходным (мне 19 было). Приходит директор - "о. Привет. Доступы вышлю через полчаса." До сих пор общаемся, уже с другим директором даже.
Другое - "это знаете? “ — "даже аббревиатуру не расшифрую", "а это? “ — “не, не сталкивалась" -" подходите!". Команда супер оказалась, долго работаем.
Ещё одно: "здрасти. Когда можете приступить?“ — "эээм, а вопросы задавать будете?“ — “видите, на столе две сотни резюме. И одно ваше программист с медицинским образованием, у меня вариантов нет". Работа была проектная, несколько проектов за несколько лет, очень круто.
Страх и ненависть в собеседованиях: от позорного провала до 24-кратного роста ЗП