Комментарии 45
Прикол в том что хрюши не очень шарят в реальный кодинг и прикрывая свою жопу ставят изначально завышенные требования и задают сложные и каверзные вопросы с учетом на то что если уж на них кандидат ответил то с кодом в продукте точно разберется
Полностью поддерживаю. Ещё бывают ситуации, когда условый синьор, который проводит собес, отклоняет кандидата из-за того, что мнениеили решение последнего по поставленной тестовой задаче или вопросу не совпадает с мнением самого интервьюера. Ну или просто лицо не понравилось?♂️
Чуть-чуть кашеобразная статья, наверное от недостатка опыта.
Ответ на вопрос почему, как мне кажется довольно простой. Народ из HR модет реально помогать на собеседовании опытом. Банально оценивая кандидита как человека, его опыт, компании где работал. Проще говоря, выявляя неадекватов либо потенцальные проблемы в soft-скилах. Но это если есть опыт, так как через HR проходят и увольнения, и другие сложые кейсы. Если опыта у HR нет, а это никогда не понятно - то польза от них сомнительна.
Тех. спецы не проходят курсы по подбору персонала, они часто и менеджерами в прямом смысле не являются, поэтому ожидать от них вменяемого интервью тоже сложно. Поэтому тех. спец оценивает только уровень знаний и умений.
Понятно ращные люди собеседуют по разному и закон больших чисел говорит о том, что любое извращение обязательно где-то происходит, возможно прямо сейчас. Поэтому я продусь по некоторым моментам
"С другой стороны, можно примерно догадываться о том, какие вопросы задают на технических собеседованиях по многочисленным роликам и шпаргалкам." - можно идти от опыта кандидата. Спрашивать не то, что надо тебе (обычно какое-то пересечение уже есть, так как резюме проходят фильтрацию), а то, что кандидат считает, что знает хорошо. Начать с просьбы рассказать об опыте, обязательно "давить" на то, что знаешь лично и вот где-то тут начать "мучить" техникой. Почему сделали так,а что если внесем доп. требование и как вы поменяете решение. Шпаргалка вряд ли поможет, так как больше идет живоц диалог и обмен мнениями.
"На какого лешего, простите мой французский, ему уметь решать задачки из лабораторной по программированию?" - интересно посмотреть на способность решать логические задачи. Иногда на собеседованиях спрашивают просто задачи на логику.
"Вы как будто не понимаете, что так называемые софт скилы куда важнее опыта использования всех известных элементов фреймворков? " - как технарь, я оцениваю техническую сторону в первую очередь. Это то, что не проверят остальные. Поэтому я делаю свою часть работы, а потом интересуюсь тем, где меня могут подстраховать другие. Плюс часто надо понять, человек реально чего-то знает, либо копипастил не парясь.
"Там человек - это ресурс, шестерня, винтик - там реально никого не интересует умеешь ли ты в коммуникации." - на самом деле, "винтик" - это классический совковый подход. На "западе" куда больше смотрят на софт скилы
интересно посмотреть на способность решать логические задачи
логические задачи может стоит поинтересоваться знает ли выпускник вуза. у мидла то зачем это спрашивать. разве есть требование от команды по логическому мышлению? какая шкала тогда? что вы узнаете то? как повлияет на качество выполняемой работы логика на два и на пять?
я оцениваю техническую сторону в первую очередь
да это сколько угодно. у кандидата есть резюме. задача узнать правду ли человек написал. так? и как здесь поможет прогон по книжкам Мартина или Эванса? я это имею ввиду. написал человек что разбирается в технологии Х, посмотрите как он ей пользуется.
это классический совковый подход
ну тут вы хватанули конечно ) на западе для этого есть специальные коммуникаторы, менеджеры, аналитики. это у них лет 30 уже исправно работает. технарь там чисто технарь, ему там запрещено общаться. это у нас только внедряется. ладно.
технарь там чисто технарь, ему там запрещено общаться
Зачем тогда у технарей проверять софт-скилы?
Хотя лично я против такого "запрета". Иногда как технарю полезно поприсутствовать на совещаниях с заказчиками, чтобы понимать, как думает заказчик, так и заказчику полезно послушать технаря, чтобы чему-то поучиться дополнительно или совет или идею какую полезную подкинут. (Естественно при обоюдном согласии). А то будет как в песне Наутилус Помпилиус: "В нашей семье, каждый делает что-то, но никто не знает, что же делают рядом. Такое ощущенье, словно мы собираем машину, которая всех нас раздавит".
о чем и речь. там то это может быть оправдано, когда всё в порядке с промежуточными звеньями. а наши просто слизали не глядя методику технического собеса, ни разу не думая о том, что в реальности у нас разраб должен уметь массу посторонних вещей, скорее разбираться в целом в процессе, а не вот это всё о чем спрашивают
как здесь поможет прогон по книжкам Мартина или Эванса
Очень даже поможет. Вот человек заявляет, что пишет по SOLID. Заявляешь - отвечай. Происходит такой диалог.
Я: Вот есть у нас класс-оркестратор, который делает то-то и то-то и то-то - оркестрирует, короче. Можем ли мы лишь на основании этой вводной сказать, нарушает он SRP или нет?
Типичный знаток SOLID: Точно нарушает, т.к. делает сразу много всего, а должен что-то одно.
Я: Ок, получается SRP явно запрещает существование оркестрации в рамках класса? А где тогда ее организовывать?
Типичный знаток SOLID: Ээээ...
Правильный ответ: лишь на основании этой вводной сказать невозможно, нужно изучить ряд других нюансов. Простейший "прогон по Мартину" показывает, что человек врет в своем резюме. Собес, конечно, не прекращаем. Но это лишний довод в пользу "не берем".
Вот человек заявляет, что пишет по SOLID
Кто так делает? А если и так, то это такое требование к вакансии? Ладно, если есть такие, то пожалуйста, пудрите друг другу мозги. По мне так совершенно не имеющее к никакого отношения к действительности требование. Я бы лучше спросил у такого кандидата зачем он вообще такое пишет в резюме.
Кто так делает?
Примерно каждый второй.
А если и так, то это такое требование к вакансии?
Да, мы применяем эти практики и довольны результатом. Ожидаем, что и новые члены команды будут их применять.
По мне так совершенно не имеющее к никакого отношения к действительности требование
Ок, практики написания кода не имеют отношения к написанию кода. Так и запишем.
Я нетипичный знаток SOLID, но очевидно, что класс оркестратор нарушает принцип srp. Да и вообще практически любой класс нарушает принцип srp. А ещё практически любой класс нарушает принцип dry и абсолютно любой класс нарушает принцип ocp. А ещё любой программный код, кроме разве что Hello World нарушает принцип KISS. А в некоторых ЯП даже хэллворды настолько сложные, что нарушают KISS.
я например даже понял, что за SRP, пока не загуглил, оказалось Single-responsibility principle.
Мне кажется не стоит задавать вопросы открытого типа, с подвохом и ждать на них единственно верную формулировку. Мало того, что это сбивает с толку, так еще и конкретно на этот вопрос можно ответить совершенно шаблонную фразу "зависит от ситуации" и формально я буду прав.
Мне кажется это как раз пример того вопроса, который никогда не следует задавать.
Зачем нужна логика? Вообще странный вопрос. От програмиста помимо знаний требуется их примение. И применение - это часто логика, умение написать псевдо-код и т.д. Знания в какой-то степени вторичны. Человек может багально не знать, как называется тот или иной паттерн, просто потому что он к нему уже давно пришел, но ему в руки не попалась книжка, где кто-то безусловно умный его описал. И то, как кандидат показывает свое мышление, является очень важным. Потому что этому нельзя быстро научить.
В резюме ... на самом деле важно чаще не споавочное знание фреймворка, а понимание его концепции и целей. Так как понимание зачем и как позволит человеку найти то, что там просто должно быть, но он забыл как оно называется. Или даже никто не испольщовал, но точно знает, что оно там есть. А есть такой забавный прикол, что концептуально многое придумано очень давно :) И всегда интересео насколько человек глубоко погрузился в вопрос от уровня могу найти пример в инете и скопировать себе
Про совок. Про "винтики" - это именно оттуда. Тут не с чем спорить :) Про остальное ... надо понимать цель общения. Если "аккаунт" общается с спонсором со стороны заказчика, чтгбы понять возможный бюджет, win- price и другую подноготную, там технарь не нужен :) Особенно если "аккаунт" - SME. Но если дискуссия уже дошла точки, когда есть что предложить потенциальному заказчику, рассказать о преймуществах платформы - то тут вполне может выступить архитектор, и даже было бы неплохо, чтобы он это озвучил и показал на своих слайдах.
Если задача обсудить статус проекта, то тех. лид вполне может быть, чтобы дать экспертный комментарий по техническому вопросу, оценить вариант решения проектной проблемы технически и т.д. Но его может и не быть, если ПМ способен закрыть вопрлс сам, а то что нет - запишет и потом уточнит у команды
Если задача "снять требования", присутствие архитектора очень желательно, а снятие нефункциональных требований - это вообще его хлеб
Что касается "рядовых" технарей? А с кем им общаться? Не, ну правда? Как ты это себе видишь? Разраб будет въезжать в процессы заказчика, собирать представителей разных подразделений, чтобы свести их в одну точку и выработать единое представление, сидеть над планом проекта и потом под него выбивать ресурсы. Каждый на своем месте. И этот прдход с раздедением есть везде, где проекты реализуются командой
Вы немного не поняли мой тезис наверное. Всё очень просто. Прогоняя человека по заготовленным и выдуманным вопросам вы на интервью узнаете лишь одно - то что человек специально подготовился. По факту вы узнаете практически ничего. Среди прошедших такой контроль может оказаться и как человек вполне соответствующий своему резюме, так и просто тот кто перед интервью прошел курс прохождения техсобеса. Да нынче нейросеть пройдет легко таким образом.
Логика слишком объемное и субъективное понятие, что бы его как-то проверить в часовом интервью. Можно, я подчеркиваю, отсеять тех кто совсем не бум бум. Но речь о позициях чуть выше юниора.
А откуда кандидат знает мои вопросы, а так же те требования, которые я хочу проверить? Даже если они выдуманы, их ведь много? А ьак как вопросы идут не как на тесте, а с углублением - то шансов отвечать по шпаргалке нет :) В смысле успешно ответить
Подготовка вопросов - это нормально. Я же не хочу сидеть и говорить "за жизнь" только потому, что не могу придумать, что спросить? И вообще, я по крайней мере, тоде готовлюсь и выписываю категории, которые надо проверить и по которым надо сравнить кандидатов. Вопросы подбираюся под категории и на собеседовании задаются до момента, пока я не решу, что оценил. Ну блин, странно не готовться
Логика - это одна из категорий для некоторых специальностей, иногда опциональная. Т.е. в сравнении не участвует, но может принести "черный" шарик :) На ней можно посмотреть, как человек вообще реагирует на незнакомое. И предположить, что в работе он будет делать так же. Так же от логики легко строить мостик к коду или псевдокоду :)
Вы всё-равно рассказываете про интервью черной лошадки у которой нет ни нормального резюме ни примеров выполненных работ. Вопросы выдуманные "специально" для интервью как правило типовые, и на них есть типовые ответы, к ЕГЭ же как-то готовятся. И при помощи таких вопросов вы максимум выясните, что человек умеет моделировать странные ситуации. Это плюс минус умеют просто люди. Никакого отношения к конкретной занимаемой должности оно иметь не будет.
Если я правильно понял ваше высказывание по поводу логики, то крайне согласен. Дать кандидату небольшую задачу, к примеру сокращение урлов (знаю, что эту задачу уже 100 раз изъездили все, кто мог, но для примера он подойдет, а для собеседования все же лучше придумать другие задачи), ну и дальше смотреть какие вопросы кандидат уточнит и как будет строить свои рассуждения по решению этой задачи: какая максимальная длина урла должна быть? нужно ли использовать новый домен для этого? если нет, то есть какое доменное имя будет использовано? Нужно ли учитывать длину этого домена? Нужно ли делать какой-то путь помимо домена, чтобы сокращенный урл в случае чего не конфликтовал с другими урлами? Должен ли быть этот урл читаемым([cat, dog, car] запоминаются лучше, чем X34j78)?Насколько большим должен быть пул урлов(частично связан с предыдущем вопросом)? Урл должен быть временным или постоянным, или должен быть выбор? Урл должен быть на определенное количество переходов? Есть ли какая-то существующая инфраструктура для реализации(будь то монолит или микросервисы, функции и тд)? Какой приоритет задачи(далеко не всегда бывает, что новую задачу выдают, когда завершаешь предыдущую, нужно понимать, что важнее делать в данный момент)? Для чего будут использовать этот сервис(от этого может зависеть потенциальная нагрузка на эту часть приложения; может выйти неприятная ситуация, когда менеджеры сделали рассылку условной миллионной аудитории с какой-нибудь акцией, а ссылки не работают из-за нагрузки)?
Не все эти вопросы надо задавать тому кто ставит задачу в обычных условиях, часть из них разработчик должен задать себе в голове, но на интервью озвучить их надо. На основе этих вопросов будет уже понятно, какая модель хранения данных будет, нужен ли кеш, в зависимости от нагрузки. Не лишним будет спросить, как этот сервис тестировать, какие пограничные случаи бывают.
От каждого пункта выше можно развить еще несколько вопросов. На основе всего этого будет уже понятно: как кандидат размышляет, какие подходы использует, как подходит к написанию тестов, любит ли изобретать велосипеды. Останется разве что дополнительно уточнить моменты по яп, который нужен компании. Как он обращается к базе данных к примеру, как обрабатывает ошибки, какие стандартный библиотеки использует, какие использует не стандартные библиотеки и для каких задач, как структурирует код и тд.
Техническое интервью должен проводить Лид отдела, а не эйчар. Эйчар по любому проверяет совсем другие навыки, да и не может проверить. Тем более, что подбор идет на разные ваки.
На моём последнем собеседовании с местным ит-гигантом интервьюер не знал языка программирования должности, на которую нанимал. Поэтому предложил решить логическую задачу в уме, а потом записать на псевдокоде (именно после решения).
В аналогичной ситуации интервьюер предложил мне решить в уме какую-то очередную унылую задачку по postgres (потому что ЯП он не знал, а язык СУБД знал), над решением которой я не особо старался, потому что был жаркий солнечный день, да и зачем нужна работа, если мы всё просто трупы, гниющие на дне зловонной ямы, покрытой копошащимися опарышами...
Мне всегда казалось, что собеседование это что-то вроде лотереи: понравился/не понравился. В конце концов в результате собеседования вы должны прийти к обоюдному согласию, как личностному, так и техническому.
Просто ищите другую компанию в которой будет то что вам нужно. Лучше разочароваться на начальном этапе собеседования, чем понять, что вы попались на какой-то трюк, согласились, а в действительности ваши ожидания оказались напрасными.
Сколько раз вы в жизни переворачивали строку задом наперед или писали свой алгоритм балансировки дерева? Ну вы чего?
Да, мы, ничего. Мы с большим энтузиазмом решаем транспортные задачи в которых ооочень много чего скрыто - и поиски кратчайших маршрутов во взвешанных графов, и поиски циклов и еще много всего. Или планируем объёмы грузоперевозок с использованием задачек об укладке ранца. Это даже не касаясь gpt и прочей генеративной псевдо эйай части. А вы потом садитесь в такси и оно вас везёт куда надо. И товар из маркета вам привозят (почти) вовремя и куда надо. И платежи ваши уходят в нужный банк, а не на деревню дедушке. И тд и тп. И да, там внутри внезапно и алгоритмы Дийкстры и укладка ранца, и нет, для них нет готовых библиотек.
Зачем вам специалист, который с нуля может написать СУБД
Вы не поверите, но в природе есть и тарантул и вайдиби и кликхаус и вайтизаурус... И над ними тоже кто-то работает. И вы можете. А, нет, вы не можете. Вы на собесе гордо отказались даже строку перевернуть.
кандидат должен уверенно сказать, что вопрос поставлен неверно. Сколько вы людей на работе видели, которые неприкрыто перечат начальству? Раз начальник спрашивает, может быть он знает что-то что неизвестно мне?
А вы точно в айти хотя бы рядом проходили? Нет, не в госконторах, где "программистом" называют студента-эникейщика, который настолько запуган, что рта открыть не смеет, а в нормальных? В реальности ПОЧТИ ВСЕ постановки задач некорректны. А в том небольшом количестве случаев, когда до разработчика доходят корректные прстановки задач, это всего лишь означает, что в этой компании первый удар на себя берут сильные аналитики. Если вы не сталкивались с этой частью работы, значит вы, вероятно, сильно начинающий и она просто скрыта от вас. Если не научитесь "открыто перечить начальству", далеко не продвинитесь. Просто поинтересуйтесь у старших товарищей откуда берутся постановки задач, которые вы делаете и напроситесь на предыдущие этапы. Вот там и увидите как "открыто перечат начальству" :) И ещё как!
Вам ведь нужен работник, который изо дня в день будет решать какие-то известные проблемы
Ну,.. нет... Для решения известных проблем изо дня в день пишется скрипт, который и решает их изо дня в день. Разработчиков нанимают чтобы решать неизвестные проблемы. Для решения известных проблем они слишком дорого обходятся. Интереснее было бы, конечно, решать проблемы не имеющие решения, но до уровня Кристобаля Хунты не всякий программист дорастает.
— Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.
— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос…
Но некоторые и так могут, вот про Джеффа Лина на хабре статьи регулярно появляются :)
Что делать, когда задача поставлена некорректно.
Да, мы уже поняли, что ожидаемый ответ - не перечить начальству. :-/
Да просто поговорите о жизненном пути, о домашнем железе, о предпочтениях в кофе, суперспособностях, отношении к рок-музыке.
Зачем? Я пришёл на работу устраиваться, мне моё время дорого, -дети не кормлены, ипотека не дояна жена в Большой театр на премьеру не свожена. Хотите поговорить за рокенролл - встретимся на кофепоинте или уан-ту-уане.
ПС. Вообще, рынок найма в РФ сейчас причудливо изменился - ушли большие галеры, с пристрастием искавшие себе готовых спецов в своей узкой области знаний (в одной галере как-то собеседовался с десятком команд, каждая из которых искала полное совпадение набора навыков). Сейчас с этим стало попроще, но и предложения почти все однообразно-скучно-неприемлимые - либо пилить скучный банковский финтех, либо унылую госку либо вообще госковый финтех... Ну, наверное, при найме туда и остаётся только о сортах кофе, (пропавших с рынка) поговорить...
Это вы наверное сильно удивитесь, но большинству нужны специалисты по скучному банковскому финтеху и пилить екомерс. Единицы которые умеют править кликхаус без никаких технических интервью прекрасно друг друга знают. Это вот видимо как-раз вы из тех характерных любителей блеснуть безупречной грамотой перед быдлотой, которая родилась вчера и ничего не смыслит в высоком.
??? Простите, но для продолжения разговора в таком тоне вам придётся поискать другого собеседника.
Справедливости ради, но раннее вы перешли на личности и такой тон.
А вы точно в айти хотя бы рядом проходили? Нет, не в госконторах, где "программистом" называют студента-эникейщика, который настолько запуган, что рта открыть не смеет, а в нормальных?
Если вы не сталкивались с этой частью работы, значит вы, вероятно, сильно начинающий и она просто скрыта от вас.
Сильно ничего против перехода на личности я сам не имею, но других не стоит в этом упрекать, когда сами это используете.
ну, лично я не вижу ничего страшного в том, что человек начинающий и не имеет опыта работы в определённых сферах. Кажется, относится к человеку как к начинающему и как к быдлу, о чём пишет гражданин, - это немного разные вещи. Но тут, как говорится, - "не я это сказал". Тут у товарища посерьёзнее проблемы, он считает, что на западе инженеру "запрещено общаться" (рукалицо) - сразу видно, что поработал во многих западных компаниях :)
Ну в целом некоторые проблемы в статье есть, но отчасти с автором соглашусь, куда не посмотри, на технических собесах иногда происходит какой-то хаос. Где-то требуют знание конкретных мало кому известных технологий, когда это абсолютно не нужно. Где-то требуют знания алгоритмов наизусть, опять же не понимая зачем они нужны. Зачем условному гуглу или яндексу алгоритмы я понимаю, им проще нанять работника на основе понимания общих концепций CS, а не каких-то отдельных реализациях. Рынку в целом не хватает золотой середины.
Где-то требуют знания алгоритмов наизусть
Наизусть нигде не встречал. Да и вообще, алго-секции кроме яндекса нигде не встречал. Максимум, что спрашивали - оценить алгоритмическую сложность. И у яндекса алго-секции довольно простые.
им проще нанять работника на основе понимания общих концепций CS, а не каких-то отдельных реализациях.
А это для всех так. И это не цель "нанять тех, кто умеет переворачивать строки". Это цель - не нанять балбесов. И с этой целью даже пресловутые круглые люки справляются.
Рынку в целом не хватает золотой середины.
Да в порядке всё с рынком. Если бы найм был снандартизован, как в ЕГЭ, то как бы вы неадекватов на рынке распознавали? ;) вот то-то же!
Где-то требуют знания алгоритмов
Ахахах, только что птичка в клювике принесла, что в тинькове есть алго-секции!
Всё верно Вы написали. Поставил бы плюсик, да нет возможности. Жаль только, сейчас понабежит толпа защитников, которые будут красоваться своим великим умом и доказывать Вам, какие они умные, а Вы, соответственно, на их то фоне.
Насколько я вижу, по своему опыту поиска работы, найм в IT сейчас полностью отдан на оутсорс, хрюшам и рекрутёрам. И никто их не контролирует, т.е. они могут делать всё, что захотят и как захотят. Это они решают, узнает о существовании кандидата вот этот тимлид, которому нужен программист, или не узнает. И всё усугубляется тем, что работать они не хотят. Нас много - они одни. У них тысячи кандидатов. Что они, всё это читать что-ли должны. Они за лёгкими деньгами в это наше IT пришли. Да и бизнесу тоже всё это не особо нужно. Тот-же тимлид сказал, что ему нужен программист. И всё. Пусть ему кто нибудь найдёт, по щучьему велению. Ему вообще никто не нужен, это ему менеджер сказал кого-то там найти. А менеджеру тоже до лампочки, кого там найдут или не найдут. Как-то всё работает, ну и нормально. А кому не нравится, пусть идут к другим, потому, что там тоже самое. Наступила эпоха быстрее-быстрее в продакшн и некомпетенции на всех уровнях.
Насколько я вижу, по своему опыту поиска работы, найм в IT сейчас полностью отдан на оутсорс, хрюшам и рекрутёрам. И никто их не контролирует, т.е. они могут делать всё, что захотят и как захотят. Это они решают, узнает о существовании кандидата вот этот тимлид, которому нужен программист, или не узнает.
Мне жутко интересно, а что такого нужно сказать рекрутёру, чтобы он не сообщил своему нанимателю о существовании нормального кандидата? Рекрутёр кровно и денежно заинтересован протолкнуть вас дальше и чтобы он этого не сделал надо прямо сильно постараться. Вот как, Холмс?
По-моему, от рекрутёров есть много разной пользы и надо этим активно пользоваться. Можно вытягивать инфу о зарплатной вилке - даже если она не указана в вакансии, рекрутёру она может быть известна и рекрутёр не заинтересован хранить её в строжайшем секрете. Можно просить рекрутёра стрясти с компании фидбек и не ходить самому его выпрашивать. Да ещё много всего можно и нужно сгружать на рекрутёра. Зачем их не любить?
Можно вытягивать инфу о зарплатной вилке
Мало я встречал рекрутёров, которые могут ответить на этот вопрос. В большинстве своём, либо отвечают общими словами, либо просто исчезают. Вот такой у меня опыт последнего года поиска работы. Так за что их любить? За то, что ставят в линкедин "я прочитал ваш профиль и так им восхищён, вот вам вакансия младшего закручивателя нижней гайки"? Из чего сразу понятно, что ничего оно не читали. За это что-ли их любить?
Мало я встречал рекрутёров, которые могут ответить на этот вопрос
Ну, не знаю, я, вот тоже думал, обычная мутотня начнётся с торговлей, но нет, последние несколько раз общался, когда спрашивали пожелания к зарплате, я прямо спрашивал о вилке и мне отвечали вообще без проблем.
я прочитал ваш профиль и так им восхищён, вот вам вакансия младшего закручивателя нижней гайки"?
Вот тоже иной опыт. Мне приносят любопытные вакансии. А на нелюбопытные я не отвечаю и не злюсь - оно мне надо? :). При том, что профиль ни линкеде написан у меня левой пяткой, а на хаха только последнее место с комментарием - остальные 20+ лет в резюме, я вам его дам, если захотите :).
20 лет??
Мне тут какой-то шутник за мои несчастные 7 лет оверквалифайд поставил, остальные просто автоматические отказы шлют... А как вы с 20 годами опыта выживаете?
Как, как... Прикидываюсь идиотом, конечно же :)
Но с оверквалифайед, да, бывали отлупы тоже. Но это же нормально - наверняка, там было бы скучно.
А вообще, в резюме раньше было многое подробно. Потом сделал раздел ancients technologies used, куда скидывал то, чего никто не помнит. Типа алгола-60 или фортрана iv. Потом и его выкинул вовсе, чтобы не смущать работодателей :). Сейчас, кажется, упоминания паскаля уже вымарал, а пёрл ещё где-то остался ;)
Честно не прочитал все комменты, но после первой смены работы (как говорится отработал 6 лет на одной галере полез на другую) ты начинаешь что-то подозревать
Первое и самое главное - разница между тобой и условным стажёром всего лишь в нескольких вещах:
1. Написании читабельного кода (и это зависит от тоего языка и опыта рзработки, но в целом опять же по опыту выпрямляется бувально в течении месяца на ревью внутри команды)
2. Не писать где не надо алгоритмы квадратичной сложности - ну тут вам как раз и нужны алгоритмы и вся эта фигня с алгоритмами и стреляет. Да в основном нужно представлять разницу между мапой и массивом, но много кто и этого не умеет
3. Задавать правильные вопросы - это уже навык сложнее. Я бы сказал что отчасти он проверяется на интервью по системной архитектуре, но там вопросы вполне себе тоже можно выучить, потому что 90% попадает в диапазон - а сколько тут rps, а есть ли геораспределённость, а какая задержка и т.п. А вот задавать правильные вопросы по задаче - это про то что нужно изучить документацию, почитать код и прийти с реально важными вопросами, которые до этого были не проработаны
4. Доводить продукт до конца - выяснить откуда получить данные или что их неоткуда получить, продумать как продукт будет работать от первого запроса до последнего, поймать тонкие моменты. Что-то можно проверить на алгоритмах, но в целом тоже до реальной работы фиг проверишь.
В итоге - как отличить синьора от стажёра фиг его поймёшь... Зато за 3 месяца испытательного срока отсеят на раз два.
Во-первых, у вас операторные скобки от паскаля, а комменты от сей. Что вы имели ввиду?
Во-вторых, не понятно кому задаются эти вопросы. Если к большим конторам, то не понятно, как автор предлагает решить проблему отсева 90% резюме. Где альтернатива? Если к небольшим, то просто не ходите в конторы где плохой процесс найма. Если процесс найма плох, то, и команда, и продукт будут плохи. Либо сразу, либо в ближайшей перспективе.
Вы как будто не понимаете, что так называемые софт скилы куда важнее опыта использования всех известных элементов фреймворков?
В-третьих, как надоели с этими "софт скиллами." В моём понимании, если человек смог придти на интервью трезвый и в чистом, а так же за два часа не обматерил интервьюеров и не обосрал бывших коллег, то у него достаточно "софт скиллов", чтобы работать программистом.
Статья не совсем про меня. Можно сказать это такой выкрик в пустой комнате.
В моём понимании, если человек смог придти на интервью трезвый и в чистом, а так же за два часа не обматерил интервьюеров и не обосрал бывших коллег, то у него достаточно "софт скиллов", чтобы работать программистом
А здесь позвольте возразить. Вот примерно так выше один из авторов относится к манере общения с коллегами. Мол надо громко возражать начальству, считать незнакомых людей по определению некомпетентными проходимцами ну и всё в этом духе. Нет, в реальности так не работает. Субординация, уважительное отношение к коллегам, вежливая (не сказать учтивая) манера общения это общие принципы на которых работает общество. В том числе и трудовое, в том числе и программистское. Нет такого, что программисты это какие-то особенные снежинки или единорожки. Как-раз такое поведение можно наблюдать за инфантильными эгоцентричными особами, из-за которых многое не ладится в профессионально разработке. Профессионал - это прежде всего часть общества таких же профессионалов, понимающих и уважающих друг друга. Никакой принципиальной разницы в общении между профессионалами столярами, врачами и программистами нет.
Получил фидбек с одного интервью - видно, что кандидат не готовился. Аж согнуло пополам, там реально нужны студенты, которые к сессии по билетам готовятся, а не инженеры.
>А эти странные загадки с ловушками, с заведомо неверными формулировками? Типа кандидат должен уверенно сказать, что вопрос поставлен неверно.
У меня по плану должно было быть тех интервью, но со стороны работодателя пришла только девочка из HR. Она мне задала вопросы по списку, записала ответы. Дала задачу, оформленную максимально запутанно, с "поясняющей" картинкой в паинте, где все три кейса нарисованы на одной структуре данных одним цветом. Литкод в этом случае дает по картинке на кейс. На мои вопросы о задаче ответить, естественно, не смогла. Задачу я решил плохо. Вывод - "мы вам перезвоним".
Begin /* Техническое интервью