Comments 8
Как-то тихо в комментариях, к прошлой статье за день кучу насыпали :-}
Лучше расскажите, как через терни к звёздам в SRE прорываются прикладные python/java разработчики с академическими знаниями в алгоритмах? И как с ними работать?
US офисы страдают (по-крайней мере, они об этом пишу) от непрофильного найма и последующейго онбординга длинной в полгода-год.
ну или нема неинтересная, раз уж не так широко нужная. или просто я что-то не то пишу.
не знаю про US офисы ничего — меня там нет и не было, я не в теме :)
пол года онбординг это нормально в принципе, так как впитать надо много внутреннего около продакшена, плюс специфику проекта. я слышал даже внутренние трансферы в некоторых особо критичных сервисах до года онбординг полноценный — и это никак не связано с наймом, это специфика и уровень ответственности.
ну или нема неинтересная, раз уж не так широко нужная. или просто я что-то не то пишу.
Тема на самом деле скользкая, потому что если вы забыли, то совет ваших рекрутеров по подготовке к этому интервью — изучение соответствующей главы в "Cracking the coding interview".
То есть, вы сами закладываете возможность пройти интервью с синтетическими знаниями. Плохого в этом ничего нет, но из этого вытекает занимательный артефакт: человека без релевантного опыта на интервью гоняют по синтетике, потому что он глубже не может, и в итоге он успешно решает верхнеуровневую задачу, а человека с реальным опытом, который первичную задачу решает быстно, начинают возить по деталям, которые он наизусть не помнит и не хочет помнить. Ну, дальше вы знаете: отсутствие softskills и щит-шторм постфактум в бложиках.
Занимательно другое: все, кто хотели пройти интервью — прошли его с n-раза.
Но вопрос то был не про это.
Вы говорите про технический онбординг, а в us жалуются, что после всех компанейских тимбилдингов, тренингов и прочих митингов, люди не хотят принимать специфику конкретных команд и просят трансфер. И так целый год по кругу, пока тонкая творческая личность не найдет себя, ну или до performace review. (тут показания разделяются, но почти все говорят о том, что тех, кто ходит в офис, в первый год не увольняют). Но это про совсем клинических персон.
В более общем же поле зрения — люди с математичекой базой, алгоритмами и одним GC языком.
То есть: там ноль по сетям, ноль по кишкам, ноль по system design. И это беда-печаль в SRE.
и это никак не связано с наймом, это специфика и уровень ответственности.
Со стороны судить тяжело, но вот по SRE book и псто на medium создаётся впечатление, что Google работает по схеме, схожей с AWS, где есть сервисы со своим SLA, которые можно использовать для построения конечного продукта, — это простой и понятный подход с многоуровневой архитектурой, где явно разделены уровни ответственности, а сложности скрыты за реализацией API.
Не очень-то и сложно, учитывая handbooks :-P
Тема на самом деле скользкая, потому что если вы забыли, то совет ваших рекрутеров по подготовке к этому интервью — изучение соответствующей главы в «Cracking the coding interview».
Я не забыл. Я не знал :) Мне ссылки какие-то для подготовки давали, я их мельком глянул, понятнее не стало, забил.
Плохого в этом ничего нет, но из этого вытекает занимательный артефакт: человека без релевантного опыта на интервью гоняют по синтетике, потому что он глубже не может, и в итоге он успешно решает верхнеуровневую задачу
Мы все еще про систем дизайн? Для SRE конкретность очень важна, и чисто высокоуровневое решение — только для невысокого уровня SRE :)
засыпаться нельзя если просто забыл детали, это норма — подскажут. но и ошибаться на три порядка тоже не стоит. это тоже часть навыка. не уверен — спроси. делаешь предположение — уточни где взял и т.д.
Ну, дальше вы знаете: отсутствие softskills и щит-шторм постфактум в бложиках.
ну… ортогональные вещи. больше всего меня расстраивает отсутсвие полноценной обратной связи — именно на это больше всего жалуются те, с кем я разговаривал после собеседований. :( я понимаю почему так получается, но тем не менее — как по мне, это первичная причина шторма и обидок.
Занимательно другое: все, кто хотели пройти интервью — прошли его с n-раза.
это так кажется :) те кто прошли — научились. вопрос-то каждый раз разный…
Вы говорите про технический онбординг, а в us жалуются, что после всех компанейских тимбилдингов, тренингов и прочих митингов, люди не хотят принимать специфику конкретных команд и просят трансфер.
ничего не смогу сказать — я даже не слышал о таком.
В более общем же поле зрения — люди с математичекой базой, алгоритмами и одним GC языком.
То есть: там ноль по сетям, ноль по кишкам, ноль по system design. И это беда-печаль в SRE.
SRE довольно большая организация, и место есть всем, кто умеет и хочет копать глубже в специфику. Если ноль сейчас — научится же, есть тех онбординг и команда поддержит. В конце концов, после универа сразу приходят люди — и весьма эффективны, и быстро растут. То есть опять же — извне это выглядеть может странно, но контроль есть, менеджеры работают, люди растут. Или уходят в SWE если им некомфортно. Свобода она такая :)
есть сервисы со своим SLA, которые можно использовать для построения конечного продукта
ага, вот вам кирпичи в четыре девятки, сложите из них «счастье» в 6 девяток.
это не всегда тривиально, учитывая сколько зависимостей и дополнительных осложнений.
плюс, коогда ты SRE и у тебя сыпется что-то: не всегда эффективно ждать кого-то, часто быстрее дебажить самому :) плюс, знание специфики часто помогает в интерпретации доступной дебаг информации.
Не очень-то и сложно, учитывая handbooks :-P
А мы покупаем или продаём? :D
Так-то можно свести до «был релиз? откатить; не было? кластер в дрейн и там пусть разработчики думают». Вот только не всё и не всегда так просто.
Короче — заходите на огонёк! Посмотрим как оно после реального ощупывания ;)
Про вкус устриц, так сказать, надо не по напеву соседа судить.
О чем думать на NALSD собеседовании