Я вам ровно об этом и писал: не может нанять, потому что нельзя из /dev/urandom сгенерировать инженера.
Кроме того, любой техногигант — это в первую очередь множество legacy, которое надо поддерживать. Об это разбилась ни одна сотня, а может и тысячи инженеров, которые приходили двигать индустрию вперёд, но бизнес говорил им делать другое :-P
и так на каждое место у них претендует 100500 «ракетных учёных»
Даже если это — их подсознательное желание, оно не соответствует действительности.
Рынок говорит нам о том, что соотношение спрос/предложение на инженера с опытом 10+ лет улетает в комос по экспоненте. И имеется тенденция увеличение стартовой скорости ;-)
Вот Facebook даёт з/п в 1.5 раза больше в кэше, Microsoft лоббирует возможность завозить разрабов из стран третьего мира пачками, кто-то открывает офисы разработки не в it-долинах, и отвоёвывет локальные рынки труда. Все пытаются доставить своих космонавтов на орбиту по-разному.
Касательно же самого Google… по моим личным наблюдениям, у них явно прослеживаются циклы закручивания и откручивания гаек при найме.
Но компании с некоторой задержкой понимают, что нельзя нанимать интернов пачками на работу, иначе они через 3-4 года сгорят и всем отрядом уедут на острова пить ром. (нет, ну круто же в 25 лет быть миллионером?), и что если не нанять толкового человека, который a little bit below the line, то потеря времени просто чудовищная, и значительно лучше дообучить сотрудника в контексте компании, потому что так или иначе, но синдром самозванца начинает жрать всех, кому за ..
PS. Почему-то большинство людей думает, что в %big_company_name% всё сложно-сложно и ничерта не понятно. Но это же не так, потому что сложные системы сложно деббажить и разрабатывать, а на сотнях и тысячах банок — это вообще ад и погибель, поэтому системы состоят из более мелких и максимально тупых подсистем. Об этом говорят на каждой конфе.
ну или нема неинтересная, раз уж не так широко нужная. или просто я что-то не то пишу.
Тема на самом деле скользкая, потому что если вы забыли, то совет ваших рекрутеров по подготовке к этому интервью — изучение соответствующей главы в "Cracking the coding interview".
То есть, вы сами закладываете возможность пройти интервью с синтетическими знаниями. Плохого в этом ничего нет, но из этого вытекает занимательный артефакт: человека без релевантного опыта на интервью гоняют по синтетике, потому что он глубже не может, и в итоге он успешно решает верхнеуровневую задачу, а человека с реальным опытом, который первичную задачу решает быстно, начинают возить по деталям, которые он наизусть не помнит и не хочет помнить. Ну, дальше вы знаете: отсутствие softskills и щит-шторм постфактум в бложиках.
Занимательно другое: все, кто хотели пройти интервью — прошли его с n-раза.
Но вопрос то был не про это.
Вы говорите про технический онбординг, а в us жалуются, что после всех компанейских тимбилдингов, тренингов и прочих митингов, люди не хотят принимать специфику конкретных команд и просят трансфер. И так целый год по кругу, пока тонкая творческая личность не найдет себя, ну или до performace review. (тут показания разделяются, но почти все говорят о том, что тех, кто ходит в офис, в первый год не увольняют). Но это про совсем клинических персон.
В более общем же поле зрения — люди с математичекой базой, алгоритмами и одним GC языком.
То есть: там ноль по сетям, ноль по кишкам, ноль по system design. И это беда-печаль в SRE.
и это никак не связано с наймом, это специфика и уровень ответственности.
Со стороны судить тяжело, но вот по SRE book и псто на medium создаётся впечатление, что Google работает по схеме, схожей с AWS, где есть сервисы со своим SLA, которые можно использовать для построения конечного продукта, — это простой и понятный подход с многоуровневой архитектурой, где явно разделены уровни ответственности, а сложности скрыты за реализацией API.
Как-то тихо в комментариях, к прошлой статье за день кучу насыпали :-}
Лучше расскажите, как через терни к звёздам в SRE прорываются прикладные python/java разработчики с академическими знаниями в алгоритмах? И как с ними работать?
US офисы страдают (по-крайней мере, они об этом пишу) от непрофильного найма и последующейго онбординга длинной в полгода-год.
Первый человек собеседует, второй молчит, может быть что-то отмечает у себя.
По крайней мере, у меня на интервью второй парень сделал ровно два действия:
поздоровался
подтвердил, что основной интервьювер пишет не в тот документ
Не хочешь — не собеседуешь.
А какова мотивация собеседовать людей в другие команды?
Это стандартный ответ при коммерческом использовании zfs не от Oracle.
При определенной нагрузке начинают проседать iops, в том числе из-за компрессии.
Я уже писал, и ещё раз скажу: вполне себе обычный собес. Как обычно, многое зависит от умения конкретного человека проводить собеседования, но не все могут, увы :-}
datacompboy а как вас готовят к проведению интервью? Понятно, что какое-то время вы ходите на второй позиции, а дальше? Есть ли возможонсть отказаться от проведения интервью в принципе, или это обязательно?
Там используются одинаковые системные инстурменты для создания окружений.
И точно так же там есть поддержка и overlayfs, и blockdevices.
И как в Swarm, там можно управлять удалённо кластером нод и контейнерами.
Так как подаваться через сайт дело достаточно гиблое, занялся поиском знакомых, работающих в Google.
Мне года четыре назад написал рекрутер из Google на Linkedin, но я ему честно сказал тогда, что проходить собеседование не готов. Просил стажировку, — к сожалению, мест не было. Договорились, что буду готовиться и потом сам свяжусь с ним. Проконсультировался у aml на счёт необходимой глубины знаний в python, но решил, что не готов.
Этой весной, занимаясь подготовкой инфраструктуры для повторного прохождения QSA-аудита для получения сертификации PCI, выяснилось, что у k8s с этим всё очень плохо. Немного подумав, я решил, что если и заниматься k8s, то лучше сразу в Google, о чем и было написано в сопровождающем письме к отклику на вакансию SRE через careers.google.com.
Через несколькой дней позвонил HR с просьбой подтвердить намерения, позадавал уточняющие вопросы (в какой офис хотите? и т.д.), после чего прислал письмо со ссылкой на google calendar, где необходмо было выбрать удобный мне слот для первого телефонного интервью.
В процессе поиска информации о формате данных интервью, я натыкался на типичные вопросы, которые там задают… и назначил интервью через 4 дня, решив, что если не смогу пройти первичную отсеевалку, то явно мне дальше делать нечего. Звонок прошёл хорошо, и меня попросили зарегистрироваться на Coding Coaching Session, для подготовки ко второму телефонному звонку.
На CSS было человек десять: трое не досидело до середины, уточняющие вопросы задавали очень вяло.
Смысл CSS ровно один — у них есть анкета, которую заполняет интервьювер по ходу собеседования и чтобы умозаключения более последовательные, а оценки о них более приближенны к реальности — есть манифест о том, как надо себя вести.
CSS прошёл, написал письмо.
Назначили нового HR из Сингапура.
Начал звонить первый HR и спрашивать в каком офисе я хочу работать и когда можно назначить дату телефонного звонка. Ок, накладочка вышла.
Я уезжал в отпуск в Европу, о чем уточнил в письме, поэтому второй звонок назначили через неделю.
Готовиться к интервью с особым усердием я не стал, посмотрел несколько типовых задач, да и только.
Во-первых, вместо обещанной сессии по программированию на 45 минут, я получил сессию по nix internals & programming.
Минут через 10 после начала разговора, когда мы еще не с головой залезли в дебри файловой системы, я уточнил что ожидал вообще-то сессии по python. "Сорян", — сказали с той стороны монитора, и пообещали отметить это в анкете.
30 минут мы общались по теории, после чего перешли к практике.
Сначала я и второй рекрутер не видели текст задачи, потому что основной интервьювер писал не в тот документ, после чего у меня отвалился интернет: 10 минут драгоценного времени потрачены зря, но резервный канал под боком и едем дальше: пытаемся обсудить как можно хранить и процессить данные по задаче. Ок, договорились — наконец-то начинаем писать код… на 45 минуте.
И тут же первая (и последняя) сложность:
— Я не знаю какие параметры принимает функция (из стандартной библиотеки) и что она возвращает
— Да мы тоже не знаем, в гугле стандартную библиотеку не юзают, у нас все своё
— Эээ, давай откроем документацию?
— Нет времени, пофантазируй
— унылая_двухминутная_фантазия_о_возможных_методах_и_функциях.jpg
— Время закончилось
Фидбэк за второй звонок: solid knowlege за unix internals и "больше фокусируйтесь на программировании" за вторую часть.
HR уточнила согласен ли я с оценками, на что я ответил: согласен, ведь задача не решена, но организация интервью была очень странная — я так и не понял чего я не знаю и как готовиться дальше (ха-ха!). "Я ж вам присылала список литературы для подготовки… не получали? Странно."
В итоге могу сказать, что каких-то откровений не увидел, обычный собес и обычный человеческий фактор.
Просто компания очень большая, и людей, которые собеседуют, и которые собеседуются — очень много, поэтому не все с первого раза заходят на нужный круг.
Собственно, именно поэтому так много и горят по негативу: много месяцев готовился, а попал на интервью к бро, который не очень хорошо интервьюирует.
Учитывая, что они полностью переехали на Kubernetes и все приложения у них stateless, то не такая уж это и большая задача. Интереснее послушать как они обеспечивают консистентность персистентных данных в базах и инвалидацию кэшей при тех же факапах в регионе.
aml, ты же не так давно получил повышение до Senior? Можешь рассказать из первых рук что там внутри гугловских KPI и о чем действительно хотел сказать автор?
Данное ограничение выдается в том случае, если выдали национальную визу одной из стран (чаще всего так делают французы и немцы), но после въезда вы каким-либо образом попали под проверку документов в другой стране шенгенского соглашения.
Финляндия, Эстония и другие государства, с которым у нас есть общая государственная граница, могут накладывать ограничения на посещения по понятным причинам, а летать в Рим или Лиссабон напрямую — никто вас заставить не может. Кроме того, пограничники всегда уточняют куда именно вы едете, а на выезде могу уточнить как прошла поездка. Будете тупить или врать — попадёте под проверку: попросят предъявить брони отелей, выписки с карты или чеки, доказывающие, что вы были именно в той стране, куда собиралсь.
Прям классика из серии "Кратко о том, почему не стоит работать в ...".
К парням, которые пытались в силу знаний и умений, но хоть как-то решить текучку — вопросов нет: работает и ладно.
А вот чем занимались тим лид и пм по внутренним разработкам? Если их не было, то почему? В крупнейшем интеграторе не хватает специалистов по катанию серверов на оленях? А если были, то почему поделка на уровне фриланса за 3$/час?
Планирует ли автор выложить полный исходный код приложения на гитхаб? Будут ли рассматриваться пулл-рекввесты сообщества? Готовы ли юнит-тесты для полноценной интеграции?
Нужные десктопные уведомления, где интерефейс доступа? Или это бэкенд? А какие базы данных поддерживаются? Очень нужна %database_name%!!1
Как и обещал — всё очень просто.
Рассматривает ли автор возможность миграции на более производительную платформу разработки?
Есть готовые наработки для bash :-P
Я вам ровно об этом и писал: не может нанять, потому что нельзя из /dev/urandom сгенерировать инженера.
Кроме того, любой техногигант — это в первую очередь множество legacy, которое надо поддерживать. Об это разбилась ни одна сотня, а может и тысячи инженеров, которые приходили двигать индустрию вперёд, но бизнес говорил им делать другое :-P
Даже если это — их подсознательное желание, оно не соответствует действительности.
Рынок говорит нам о том, что соотношение спрос/предложение на инженера с опытом 10+ лет улетает в комос по экспоненте. И имеется тенденция увеличение стартовой скорости ;-)
Вот Facebook даёт з/п в 1.5 раза больше в кэше, Microsoft лоббирует возможность завозить разрабов из стран третьего мира пачками, кто-то открывает офисы разработки не в it-долинах, и отвоёвывет локальные рынки труда. Все пытаются доставить своих космонавтов на орбиту по-разному.
Касательно же самого Google… по моим личным наблюдениям, у них явно прослеживаются циклы закручивания и откручивания гаек при найме.
Но компании с некоторой задержкой понимают, что нельзя нанимать интернов пачками на работу, иначе они через 3-4 года сгорят и всем отрядом уедут на острова пить ром. (нет, ну круто же в 25 лет быть миллионером?), и что если не нанять толкового человека, который a little bit below the line, то потеря времени просто чудовищная, и значительно лучше дообучить сотрудника в контексте компании, потому что так или иначе, но синдром самозванца начинает жрать всех, кому за ..
Короче, посомтрите замечательный доклад Growing the Site Reliability Team at LinkedIn: Hiring is Hard
PS. Почему-то большинство людей думает, что в %big_company_name% всё сложно-сложно и ничерта не понятно. Но это же не так, потому что сложные системы сложно деббажить и разрабатывать, а на сотнях и тысячах банок — это вообще ад и погибель, поэтому системы состоят из более мелких и максимально тупых подсистем. Об этом говорят на каждой конфе.
Тема на самом деле скользкая, потому что если вы забыли, то совет ваших рекрутеров по подготовке к этому интервью — изучение соответствующей главы в "Cracking the coding interview".
То есть, вы сами закладываете возможность пройти интервью с синтетическими знаниями. Плохого в этом ничего нет, но из этого вытекает занимательный артефакт: человека без релевантного опыта на интервью гоняют по синтетике, потому что он глубже не может, и в итоге он успешно решает верхнеуровневую задачу, а человека с реальным опытом, который первичную задачу решает быстно, начинают возить по деталям, которые он наизусть не помнит и не хочет помнить. Ну, дальше вы знаете: отсутствие softskills и щит-шторм постфактум в бложиках.
Занимательно другое: все, кто хотели пройти интервью — прошли его с n-раза.
Но вопрос то был не про это.
Вы говорите про технический онбординг, а в us жалуются, что после всех компанейских тимбилдингов, тренингов и прочих митингов, люди не хотят принимать специфику конкретных команд и просят трансфер. И так целый год по кругу, пока тонкая творческая личность не найдет себя, ну или до performace review. (тут показания разделяются, но почти все говорят о том, что тех, кто ходит в офис, в первый год не увольняют). Но это про совсем клинических персон.
В более общем же поле зрения — люди с математичекой базой, алгоритмами и одним GC языком.
То есть: там ноль по сетям, ноль по кишкам, ноль по system design. И это беда-печаль в SRE.
Со стороны судить тяжело, но вот по SRE book и псто на medium создаётся впечатление, что Google работает по схеме, схожей с AWS, где есть сервисы со своим SLA, которые можно использовать для построения конечного продукта, — это простой и понятный подход с многоуровневой архитектурой, где явно разделены уровни ответственности, а сложности скрыты за реализацией API.
Не очень-то и сложно, учитывая handbooks :-P
Как-то тихо в комментариях, к прошлой статье за день кучу насыпали :-}
Лучше расскажите, как
через терни к звёздамв SRE прорываются прикладные python/java разработчики с академическими знаниями в алгоритмах? И как с ними работать?US офисы страдают (по-крайней мере, они об этом пишу) от непрофильного найма и последующейго онбординга длинной в полгода-год.
Главное, чтобы не сломали G+ oAuth на мобилках.
Первый человек собеседует, второй молчит, может быть что-то отмечает у себя.
По крайней мере, у меня на интервью второй парень сделал ровно два действия:
А какова мотивация собеседовать людей в другие команды?
Это стандартный ответ при коммерческом использовании zfs не от Oracle.
При определенной нагрузке начинают проседать iops, в том числе из-за компрессии.
Я уже писал, и ещё раз скажу: вполне себе обычный собес. Как обычно, многое зависит от умения конкретного человека проводить собеседования, но не все могут, увы :-}
datacompboy а как вас готовят к проведению интервью? Понятно, что какое-то время вы ходите на второй позиции, а дальше? Есть ли возможонсть отказаться от проведения интервью в принципе, или это обязательно?
Чтобы ZFS не била по CPU и MEM, надо отключать deduplication и compression.
Но лучше её вообще не использовать, кроме того случая, когда у вас vendor-lock от Oracle :-}
Там используются одинаковые системные инстурменты для создания окружений.
И точно так же там есть поддержка и overlayfs, и blockdevices.
И как в Swarm, там можно управлять удалённо кластером нод и контейнерами.
"Другой идеологи" там нет, этот тот же Swarm, только от Cannonical.
Мне года четыре назад написал рекрутер из Google на Linkedin, но я ему честно сказал тогда, что проходить собеседование не готов. Просил стажировку, — к сожалению, мест не было. Договорились, что буду готовиться и потом сам свяжусь с ним. Проконсультировался у aml на счёт необходимой глубины знаний в python, но решил, что не готов.
Этой весной, занимаясь подготовкой инфраструктуры для повторного прохождения QSA-аудита для получения сертификации PCI, выяснилось, что у k8s с этим всё очень плохо. Немного подумав, я решил, что если и заниматься k8s, то лучше сразу в Google, о чем и было написано в сопровождающем письме к отклику на вакансию SRE через careers.google.com.
Через несколькой дней позвонил HR с просьбой подтвердить намерения, позадавал уточняющие вопросы (в какой офис хотите? и т.д.), после чего прислал письмо со ссылкой на google calendar, где необходмо было выбрать удобный мне слот для первого телефонного интервью.
В процессе поиска информации о формате данных интервью, я натыкался на типичные вопросы, которые там задают… и назначил интервью через 4 дня, решив, что если не смогу пройти первичную отсеевалку, то явно мне дальше делать нечего. Звонок прошёл хорошо, и меня попросили зарегистрироваться на Coding Coaching Session, для подготовки ко второму телефонному звонку.
На CSS было человек десять: трое не досидело до середины, уточняющие вопросы задавали очень вяло.
Смысл CSS ровно один — у них есть анкета, которую заполняет интервьювер по ходу собеседования и чтобы умозаключения более последовательные, а оценки о них более приближенны к реальности — есть манифест о том, как надо себя вести.
CSS прошёл, написал письмо.
Назначили нового HR из Сингапура.
Начал звонить первый HR и спрашивать в каком офисе я хочу работать и когда можно назначить дату телефонного звонка. Ок, накладочка вышла.
Я уезжал в отпуск в Европу, о чем уточнил в письме, поэтому второй звонок назначили через неделю.
Готовиться к интервью с особым усердием я не стал, посмотрел несколько типовых задач, да и только.
Во-первых, вместо обещанной сессии по программированию на 45 минут, я получил сессию по nix internals & programming.
Минут через 10 после начала разговора, когда мы еще не с головой залезли в дебри файловой системы, я уточнил что ожидал вообще-то сессии по python. "Сорян", — сказали с той стороны монитора, и пообещали отметить это в анкете.
30 минут мы общались по теории, после чего перешли к практике.
Сначала я и второй рекрутер не видели текст задачи, потому что основной интервьювер писал не в тот документ, после чего у меня отвалился интернет: 10 минут драгоценного времени потрачены зря, но резервный канал под боком и едем дальше: пытаемся обсудить как можно хранить и процессить данные по задаче. Ок, договорились — наконец-то начинаем писать код… на 45 минуте.
И тут же первая (и последняя) сложность:
— Я не знаю какие параметры принимает функция (из стандартной библиотеки) и что она возвращает
— Да мы тоже не знаем, в гугле стандартную библиотеку не юзают, у нас все своё
— Эээ, давай откроем документацию?
— Нет времени, пофантазируй
— унылая_двухминутная_фантазия_о_возможных_методах_и_функциях.jpg
— Время закончилось
Фидбэк за второй звонок: solid knowlege за unix internals и "больше фокусируйтесь на программировании" за вторую часть.
HR уточнила согласен ли я с оценками, на что я ответил: согласен, ведь задача не решена, но организация интервью была очень странная — я так и не понял чего я не знаю и как готовиться дальше (ха-ха!). "Я ж вам присылала список литературы для подготовки… не получали? Странно."
В итоге могу сказать, что каких-то откровений не увидел, обычный собес и обычный человеческий фактор.
Просто компания очень большая, и людей, которые собеседуют, и которые собеседуются — очень много, поэтому не все с первого раза заходят на нужный круг.
Собственно, именно поэтому так много и горят по негативу: много месяцев готовился, а попал на интервью к бро, который не очень хорошо интервьюирует.
Привет! Смотри их доклады на SREcon, видео есть в свободном доступе на youtube.
Учитывая, что они полностью переехали на Kubernetes и все приложения у них stateless, то не такая уж это и большая задача. Интереснее послушать как они обеспечивают консистентность персистентных данных в базах и инвалидацию кэшей при тех же факапах в регионе.
Спасибо за развёрнутый ответ!
aml, ты же не так давно получил повышение до Senior? Можешь рассказать из первых рук что там внутри гугловских KPI и о чем действительно хотел сказать автор?
Данное ограничение выдается в том случае, если выдали национальную визу одной из стран (чаще всего так делают французы и немцы), но после въезда вы каким-либо образом попали под проверку документов в другой стране шенгенского соглашения.
Вы вообще не обязаны въезжать в шенгенскую зону через ту страну, которая вам выдала визу.
Вы должны получить визу той страны, в которой собираетесь пребывать максимальное количетсво времени: https://eeas.europa.eu/sites/eeas/files/frequently_asked_questions_en.pdf
Финляндия, Эстония и другие государства, с которым у нас есть общая государственная граница, могут накладывать ограничения на посещения по понятным причинам, а летать в Рим или Лиссабон напрямую — никто вас заставить не может. Кроме того, пограничники всегда уточняют куда именно вы едете, а на выезде могу уточнить как прошла поездка. Будете тупить или врать — попадёте под проверку: попросят предъявить брони отелей, выписки с карты или чеки, доказывающие, что вы были именно в той стране, куда собиралсь.
http://joeduffyblog.com/2015/11/03/blogging-about-midori/
Эта ссылка есть у твиттере у Russ.
Прям классика из серии "Кратко о том, почему не стоит работать в ...".
К парням, которые пытались в силу знаний и умений, но хоть как-то решить текучку — вопросов нет: работает и ладно.
А вот чем занимались тим лид и пм по внутренним разработкам? Если их не было, то почему? В крупнейшем интеграторе не хватает специалистов по катанию серверов на оленях? А если были, то почему поделка на уровне фриланса за 3$/час?
Планирует ли автор выложить полный исходный код приложения на гитхаб? Будут ли рассматриваться пулл-рекввесты сообщества? Готовы ли юнит-тесты для полноценной интеграции?
Нужные десктопные уведомления, где интерефейс доступа? Или это бэкенд? А какие базы данных поддерживаются? Очень нужна %database_name%!!1
Рассматривает ли автор возможность миграции на более производительную платформу разработки?
Есть готовые наработки для bash :-P