Комментарии 93
оно да, но вопросы про php, аплоад и 20 мб — мы сейчас в 2021 или 2005?
нынче чтоб файлик залить достаточно юзеру полиси в s3 выдать разовое и залить напрямую в ближайший к нему локейшн. у того де амазона 5 терабайт макс размер и 5 гигабайт на разовый put.
и не надо думать ни про свой балансер, ни про таймауты коннекшеннов, ни на место под временный файл, ни куда этот файл лить потом.
Но проще минус поставить, это да :) ведь у каждого на исповеди своц php в шкафу
Наша тестовая инфраструктура уже в амазоне и там да, свою нюансы и спецэффекты. В то же время проекты команды напрямую связаны с шаред хостингом, в котором проблемы 2005 года все ещё могут быть актуальны для конечных пользователей и которые мы, в том числе, решаем в своих проектах за счет автоматизации взаимодействия между пользователем и системой, где расположен хостинг.
В данном случае считаю, что конкретный пример не имеет значения, намеренно избегал любого контекста. Пример из области настройки системы — показался мне наиболее общим для широкой общественности, который удобно будет разложить на простые и понятные этапы.
Но идея интересная, можно на досуге подумать, какой бы показательный пример можно было выбрать для оценки знаний в области инфраструктуры амазона.
я шучу про минус :)
что касаемо самой идеи статьи — тут есть такая проблема, что во-первых, про свои фейлы никто не расскажет, а про победы — это тоже никак не проверить. Я, лично, предпочитаю свой вопрос, вместо опыта.(если, конечно, цель не нанять именно ради этого опыта). А то можно нанять "рассказчика", а не инженера.
Я пару раз пробовал особую методику — предлагал прособеседовать меня и рассказать потом впечатление о мне, как кандидате.
Это совершенно ломает стереотип соискателя о собеседовании, но не работает с некоторыми типами психики, к сожалению.
Я, например, очень opinionated в выборе технологий. Я могу использовать неприятную мне технологию, если очень нужно, но в жизни я пропихиваю красивые технологии и стараюсь закопать некрасивые. Более того, стек технологий в компании, в которую я собеседуюсь, matters. Потому что если всё время соглашаться с тем, что сейчас нравится работодателю, так и останешься админом 1С и AD.
В крупных компаниях либо зоопарк, либо фашизм. Один человек не может охватить всё, и либо каждая команда сама себе стек держит, либо всех железной уздой в указанный стек вгоняют. В одном случае имеется диверсификация и внутренняя технологическая конкуренция (ценой усложнения), в другом — бонусы унификации за счёт людей, из которых не получилось выковать гвозди.
Если мы о продуктовых компаниях.
Но есть же еще интеграторы-аутсорсеры-прочее. Там ты стек не выбираешь, сегодня одно, а завтра — новый клиент, со своим «особенным» зоопарком
Ну тут всё просто. Либо у интегратора отряд многоруких шив (сказали делать на vmware c docker swarm, делаем на docker swarm, сказали писать на powershell и salt, пишем на чём сказали. Да хоть HANA c 1C), либо зоопарк специалистов в каждой технологии.
В целом, интеграторо-аусорсный бизнес мне выглядит слегка непривлекательным. Его используют с какой целью? В 99% для удешевления стоимости владения инфраструктурой. (Да, бывают исключения, когда, например, IBM привлекают за большие деньги спасать неудавшийся уход с банковской системы, но это исключения).
Соответственно, интегратор оказывается в ценовом цейтноте, что неприятно транслируется в запас эксперименты, исследования и внутреннее качество.
- Нужно запилить разовый проект, искать и кормить нишевых специалистов дорого
- Бизнес развивается быстрее чем возможность найма
- Компания вообще не связана с высокими технологиями, но активно их потребляет(скажем, Пятерочка или Магнит)
- Контракт с интегратором подрузамевает ответственность интегратора и не только моральную
- Выращивать свою культуру выйдет дороже здесь и сейчас(часто это выливается в покупку другой компании, а не аутсорс, но все же)
- Нужно поддерживать какое-то нудное легаси за пять копеек(1с 1.7 там, например)
Но со стороны работника-специалиста, не стремящегося в менеджмент, но стремящегося улучшать собственные скиллы — я согласен, сомнительное удовольствие.
настоящему профессионалу и специалисту не то чтоб все равно, имхо. Он может. Но не всегда станет :)
и 20 мб — мы сейчас в 2021
Я правильно понял, что вопрос именно про 20Мб? У нас вообще 10 ;) Этого достаточно для 99,999% документов, а льют их у нас от 4 000 до 14 000 в сутки. Да, пару раз в год бывают проблемы, решаем в индивидуальном порядке.
Достаточно интересно, что у вас техническое интервью перед HR. Обычно все наоборот. Сначала HR отсеивают неадекватов (и иногда адекватов), а только потом стартует техническая секция.
От перестановки фильтров результат не меняется.
Меняется, если фильтр дает веса, а не булевое значение.
В результате, может быть ситуация, когда HR дает заключение «интроверт, не знает английский, нельзя ему работать с заказчиком», а тех лид — «пофиг, зато его тех.стек такой что он стоит пятерых, а сам буду работать с закачиком за него, а ему только таски в джире кидать».
Собственно, да. А зачем мнение HR-а? Это HR-у потом с ним работать?
Это не риторический вопрос, я, действительно, хочу понять — зачем? Ну, не считая случая, когда нанимают нового HR-а, тогда HR-у с ним и работать.
хочу понять — зачем?
Хороший HR (действительно, хороший с психологическим образованием) способен обнаружить скрытые проблемы в характере кандидата. Мы один раз в команде проигнорировали мнение HR, потом пожалели.
Программисты любят считать, что софт скилс ерунда, но действительно проблемные кандидаты встречаются (вида, я «Д`Артаньян, а все остальные… и буду я делать все как я считаю правильным и пофиг»).
Если раппорт установлен и человек расслаблен, то очень часто (но не всегда) человек отвечает, проецируя ситуацию на себя, то есть отвечает про себя, а не про каких-то там мифических людей.
На самом деле там довольно большая теория за этим всем. Собеседовать — это конкретный скилл, чтобы им овладеть, TechLead (нанимающий менеджер) должен пожертвовать развитием в чём-то другом, и де-факто это происходит не так уж и часто. Поэтому HR — это хорошо.
Это уже полдела нынче.
будет четкий и ясный план
Разумеется, четкий и ясный план… как сделать, что-то что не нужно клиенту, менджменту и что не смогут подерживать коллеги.
Условно такой человек может годами пилить продукт с идеальным кодом, но совершенно не способный выдержать даже 1% реального трафика, когда бизнесу нужен результат через месяц.
Либо он будет писать лютый нечитаемый код и его совершенно невозможно никому убедить, что код нужно писать по-другому… либо… ну в целом, иногда в программировании встречаются удивительно оторванные от реальности люди, при этом достаточно хорошо подкованные технически.
Другими словами, я б сказал, это люди «с яйцами» и «без яиц».
Одни говорят: «давайте для простоты предположим, что мое мнение — правильное», а другие — «опросим всех вокруг и сделаем design by committee»
Вот в этом плане Д'Артаньяны очень просты — успешных отрывают с руками по рекомендациях, не очень умных — увольняют с оркестром.
На самом деле, коллеги, менеджмент, да и даже клиенты «без яиц» и так всегда подстраиваются под этих Д'Артаньянов. Они им сами говорят их потребности.
В вашем случае, это такой «Д'Артаньян курильщика», их и правда нужно всеми силами избегать — геммороя много а выхлопа нет.
Также нормальный HR способен подбить и хорошо выдать развивающую обратную связь (это ответ на вопрос зачем кандидату интервью с HR). Ещё нормальный HR ведёт документацию, сопровождает сотрудников (онбординг, развитие, коучинг и так далее), то есть как раз работает с нанятым сотрудником и после найма.
То есть нормальный HR позволяет нанимающему менеджеру тратить намного меньше ресурсов плюс нормальный HR влияет на рост кандидатов (то есть работает на будущее).
Единственная проблема с нормальными HR-ами — они на дороге не валяются, поди их ещё найди.
Мне важно, например, понимать, будет человек готов работать автономно или ему комфортнее, когда ставят четкие задачи «от забор и до обеда». Это не значит, что что-то из этого — плохо. Вопрос в том, какая в данный момент открыта позиция, какой круг задач придется решать новому сотруднику.
У меня в собеседовании обычно три фазы: я рассказываю про нас и проект (если кандидату это не интересно уже тут можно вежливо разойтись), потом спрашиваю про знание технологий, потом про опыт.
Про технологии я просто начинаю спрашивать о том, что кандидат обозначает как «знаю». Знает, что такое multithreading в .net — спрошу про способы реализации и проблемы разных подходов, потом ещё глубже можно копнуть, например про синхронизацию и способы борьбы с блокировками. А можно спросить, какие задачи решились многопоточностью.
Про опыт как раз спрашиваю про сложные и интересные задачи из личного опыта, что это было, как решалось, пригодилось ли в будущем.
Таким образом оцениваю и хард и софт скиллы, как человек думает, склонен ли докапываться до сути, сам решает проблемы или с гуглом/коллегами, знает ли он заказчиков/клиентов или старается их избегать…
Полностью согласен с таким подходом, особенно с фазой рассказа о проекте. Почему-то собеседование принято рассмаривать, как что-то одностороннее — подходит кандидат или нет. Не принимается во внимание то, что кандидат точно так же должен оценить проект и людей, с которыми предстоит работать.
Вообще у человеческой памяти есть особенность, что тяжело вот так просто без контекста вспоминать кулстори из жизни. Это все примерно как спросить человека рассказать анекдот.
Так что не назвал бы этот подход хорошим.
вы знаете, что там понадобится разрекламировать себя и свой опыт.
Разумеется, однако вы можете быть не подготовить ответ на вопрос вроде «как вы использовали монгодб при работе в высоконагруженной системе и какие настройки вы использовали», особенно если это было лет пять назад.
Поэтому чтобы работу работать современный инженер обязан иметь множество софтскиллов. Иначе он не сможет работать в крутой команде.
В остальном, чтобы достаточно эффективно работать в команде вполне достаточно свойств указанных в моём предыдущем комментарии.
кстати, хорошая штука про анекдот. я бы в такую компанию пошел.
с другой стороны, помню пятое(!) собеседование, оно случилось с владельцем бизнеса, он спрашивал про мою последнюю прочитанную художественную книжку.
так я и не попал в ту компанию. они сказали, что не готовы делать офферы людям, которые не уверены, что хотят у них работать :)
В самом деле. А ещё из-за того, что соискатель обычно готовится именно к экзамену и мысленно на это настроен, зажат. Поэтому надо строить разговор таким образом, что бы перевести его из состояния собеса в состояние «за кружкой пива». Единого рецепта, к сожалению, нет, но если понимать цель, это всегда рано или поздно получается.
У меня в прошлой компании тоже был креативный подход к собеседованиям, и начальство этим очень(прям капец как) гордилось, но работала система найма с точностью 50% — половина взятых на работу потом были вполне успешны, половина — совсем мимо.
Но начальство их не увольняло, чтобы не признавать, что облажалось, просто не повышало ЗП и не платило премии и они сами потихоньку/со скандалом постепенно уходили.
Итого — точность системы найма считалась за 100% (иногда достигала 146%)))
хотелось бы увидеть статистику — взяли 100500 новых сотрудников, из них такой-то % успешно влились в нашу команду, такой-то процент — не очень успешно, но сойдет и так, с таким-то % мы ошиблись по полной. Тогда будет ясно — работает система найма хорошо или не очень.
Статистика из одной компании будет совершенно неприменима для другой. Может в одной компании балду гоняют и там любому норм, а в другой рокет сайенс и поэтому большое число новеньких отсеивается?
Не могу назвать описанный подход именно креативным, для меня это всего лишь структура, каким образом выстраивать диалог. Так или иначе подобные вопросы задаются, только делается это неосознанно. Алгоритм позволяет упорядочить это и получать больший выхлоп при тех же условиях :)
согласятся ли эти старшие инженеры быть ответственными за найм?
кстати, вот вам, читателям-старшим-инженерам, вам когда-нибудь доплачивали за то, что вы в hr департаменте подрабатываете?
Я, лично, не разу не слышал.
к тому же, как только вы сделаете инженера ответственным за найм вместо hr не введя ответственность за не найм(у hr это их зарплата) — знаете, что случится?
согласятся ли эти старшие инженеры быть ответственными за найм?По факту, они и так ответственны. Ведь новые коллеги-неумехи будут пить кровь и портить кодовую базу именно старшим инженерам. По-этому, думаю если явно прописать задачи и ответственность, от этого только все выиграют.
Почему надо доплачивать за работу с кадрами, если это делается в рабочее время, в рамках должностных обязанностей?
потому что на то они и инженеры, что им в массе своей интересны технологии, а не проблемы нейронов в отдельно взятой черепной коробке. Попробуйте замутить внонимный опрос среди инженеров на эту тему, готовы ли они вместо эйчара заняться наймом.
может я и ошибаюсь :)
про "по факту". уволеных инженеров я видел, а вот зоть бы депремации собеседовавших их инженеров — нет. Это такое "по факту"?
занимаемся. на добровольных началах. По негласному договору с hr с нас честный фидбек, с них — отсутствие головной боли у нас, это вин-вин.
А теперь представьте ваш вариант? как я выше написал, возможность найма отличного коллеги не отменяет шансов получения люлей за найм негодного. Как инженер оптимизирует эти обязанности писать, думаю, не стоит
По негласному договору с hr с нас честный фидбек, с них — отсутствие головной боли у нас, это вин-винГлавный «вин-вин» в том, что никто не отвечает за результат: если предъявить кадровикам они скажут, что инженер сказал, что новичок хороший, а они ни при чём. А если предъявить инженеру, он скажет, что ему некогда, у него прод упал, и вообще, людей кадровики нанимают, к ним и вопросы. Б — Безответственность. В моём же варианте есть ответственные, причём это именно те люди, которые и заинтересованы в профессиональных качествах новых коллег.
Как инженер оптимизирует эти обязанности писать, думаю, не стоит
- улучшит тестовые, что бы они отсеивали большую долю неподходящих людей
- с оставшимися проведёт собес
- суммирует опыт
- вернётся к пункту 1.
Как только это всё инженеру скинут он сделает
«0. реджектить всех»
и пойдет дальше любимые байты перекладывать.
Тут, кстати, как у Гришковца, «учительница была нужна не для любви» — обычно этих инженеров на собеседования зовут вообще не для оценки скиллов. А посмотреть, как они сработаются вместе. Как совместно обсуждают общие проблемы. Смогут ли приходить к компромиссам, и.т.д.
Но team lead это не тоже самое, что
senior software engineer
staff software engineer
principal software engineer
(потом эти люди, не имеющие желаний учавствовать в социальных играх растут в архитекторы)
Тим лид подразумевает менеджерскую позицию, а эти — нет. Поэтому, делать ответственным за найм человека, который потом не будет иметь управляющей роли над этим человеком — такое себе.
Поэтому, кстати, и HR не несут такой явной ответственности.
Переводить engineering lead в «ведущего инженера» не очень корректно. В первом случае определяющее «lead» — лидер, менеджер. Квалификатор — инженерный. А во втором — определяющее «инженер» а квалификатор «ведущий», что ближе к staff engineer.
Если в данном контексте исповедь — это разговор о косяках из предыдущего опыта, то даже из косяков и ошибок можно извлечь пользу и сделать правильные выводы. в этом смысле негативные кейсы не менее важны, чем позитивные.
Не знаю почему этого никто не делает, но, по-моему, достаточно показательным было бы поставить задачу типо "наш бух пытается на корп сайт зайти, а там ошибка, что делать? Адрес сайта такойтакой.ру". Потом по ходу придется подсказать логин/пароль на ssh. Всё остальное решается самостоятельно.
Конечно, сайт не настоящий, а заглушка в локальной сети, на худой конец, локально запущенный headless-инстанс virtualbox. А уж какими способами "уронить" апач или нгинкс, каждый решает сам
почему этого никто не делает, но, по-моему, достаточно показательным было бы поставить задачу
Делают, проблема в том что таким способом можно проверить всего несколько навыков/задач (просто не успеете больше), причем джун, который недавно решал эту задачу, сможет справиться лучше синьора, который успешно подерживал систему из тысяч докер-контейнеров и зоопарка операционок и систем.
В какой-то момент навыки синьора становятся настолько общирными, а задачи, которые он будет решать настолько трудоемкими, что даже за месяц не факт, что вы сможете адекватно оценить его уровень.
Согласен с тем, что экзамен зрелом возрасте это что то, не совсем нормальное явление.
Я при поиске работы в анкете так и указал — не провожу длительные собеседования. И вежливо откланивался, когда после одного собеседования назначали другое.
Причина, почему я перестал проходить долгие собеседования и обсуждения заключается в том, что во первых, в желании досконально проверить кандидата кроется чувство недоверия к нему. А какой смысл начинать сотрудничество, если в основе него лежит недоверие. Если допустим я претендую на работу, то наверное подразумевается, что я способен её выполнять, в противном случае логично я бы не пренедовал на неё. Или неужели работодатель думает, что взяв специалиста на работу, который сказал, скажем что он умеет работать со spa приложениями. И вот приходит этот человек на работу, ему дают задачи по spa приложению и он не знает как их делать? И в чем суть обмана со стороны? Дескать, на собеседовании обману, а реальную работу будет выполнять сосед Федер? Вы не находите, что все это абсурд?
Проходил не мало собеседований, подметил некоторые особенности:
- Большинство заявленных требований на практике не используются. Как правило компании работают с более узким стеком, чем это заявлено изначально.
- Компании публикуют примерно одинаковый набор требований, а значит делают это несколько из за потребностей сколько из за тенденции и моды.
- Собеседования в большинстве случаев пустая трата времени. СоБЕСЕДОВАНИЕ — то бишь в снове этого действия лежит суть БЕСЕДА — размять, так сказать язык, обменяться мнениями. А ещё в этом слове есть корень БЕС.
Реальность состоит в том, что люди иррациональны, и ведут себя совсем не так, как вы думаете.
Собеседование нужно как раз для того, чтобы потратить меньше времени, чтобы кандидат как можно раньше понял, что это не его компания, и чтобы компания как можно раньше поняла, что это не её кандидат.
PS: если мы откроем морфемный словарь, то увидим, что в слове «собеседование» корень «бесед», и никакого корня «бес» там нет и не было.
Проводить собеседования, что бы как можно раньше убедить человека в том, что вы друг другу не подходите? Вы на самом деле, невероятно точно объяснили смысл собеседований, и почему они в большинстве случаев неудачны.
Да, стар-классный метод
Но всегда стоит учитывать, что это просто одна из формализаций хорошо поставленного диалога, где нужно следовать всего 3-м вопросам:
1) что компании нужно на данной должности
2) на сколько кандидат подходит п.1
3) как качественно проверить п.2 с учётом когнитивных особенностей человеческой сущности (причем всех участников процесса собеседования, а не только кандидата)-т е не задавать вопросы, на которые можно получить социально ожидаемые ответы или быстро нагуглить или заучить, и т д и т п
Все
А стар это будет или что-то иное уже не так важно, если кто проводит собеседование четко понимает и осознает данные три вопроса здесь и сейчас.
Если же идти просто от стар или другой методологии, а не от этих трёх вопросов, то смотрится это со стороны грустно: скрещивание ежа с ужом в попытках натянуть то, что не растягивается и как-то это интерпретировать.
Человек ничего не придумывает, все уже есть-важно наблюдать и затем формализовать в разные методологии для разных ситуаций.
Вот только формализация-это заранее ограниченная картина мира.
Лучше всего: осознанность+креативность+инициативность=импровизация. И немного критического и системного мышления.
Как я перестал превращать собес в экзамен: оцениваем хард- и софт-скиллы за одно собеседование