Я тут последние два месяца не вылезал с собеседований ибо работу менял. Причина простая - наш многообещающий продукт не пережил проверку коронавирусом. Думаю вот написать пост о том, как проходили собеседования, какие были тестовые задания?
Anonymous Poll
96%
Yes
4%
No
#собеседования #IT #рекрутинг
Итак, как я обещал, пишу про свой опыт собеседований этим летом.
В апреле стало известно, что наш перспективный продукт скорее мертв,
чем жив и делов дальше не будет. Появились первые слухи, когда нас всех отпустят
на волю, а потом уже появилась информация, что работать я буду до конца лета и все.
Естественно всяких активитис становилось все меньше и летом стало почти ноль.
Примерно с июля месяца я обновил CV, аккаунт на djini, linkedIN и поставил статус
Open to work. Посыпались сразу и много предложений от рекрутеров. И тут возникает первая проблема - их реально много и надо как-то это отсеивать, потому что ответить всем и перечитать каждое предложение нереально, а там много несовпадений еще и по стеку и некоторые предлагают еще позиции какого-нибудь фронтендера. Тогда на djini я сразу задрал планку по зарплате и писать стали в разы меньше(а те, кто пишет значит готовы такую сумму предложить и это хорошо). И таким образом появились первые интересные проекты, на которые были засетаплены интервью. Скажу честно, вначале искал только продуктовую компанию, в аутсорсе не работал и чот не хотелось начинать. Потому сразу отметал весь аутсорс.
Первое же интервью дало хороший результат и на меня свалилось тестовое задание. Не сильно одобряю тестовые при процессе хайринга, но тут интересный продукт и я согласился. Тестовое было довольно объемным. Надо было поднять автоматически однонодовый кластер k8s с вагрантом и ансиблом и чтоб автоматически туда надеплоилась аппка, которую надо сделать самому и запхать в докер (аппка уровня hello world) и ci/cd использовать kubernetes-native, а точнее ArgoCI и ArgoCD. Я сразу же написал, что ArgoCI давно протух и не разрабатывается(видимо тестовое не менялось с 2018 года) и мне сказали юзать на выбор что хочу. В итоге получилась связка github actions + ArgoCD в кубере. После этого я прохожу интервью с СЕО и вроде бы все ок, рекрутер ликует. Ждем офер и получаю отказ по причине, что тестовое сделано хорошо, но не production ready. Сказать что я охуел, значит ничего не сказать. Продакшн? С вагрантом и миникубом? Ебанулись? Видимо я просто не понравился тому СЕО и меня решили слить. Ну ничего, продукт отвалился и хер с ним.
Дальше я задумался еще и поводу аутсорсинга, все таки там паблик клауды, а я как раз туда и хочу. Надоело ковыряться уже в опенстеке и k8s on-premise. Хочется поменять немного стек. Ну тогда начал принимать предложения рекрутеров от аутсорса тоже. И тогда начался у меня интервьюшный ад. В день у меня было по 1-3 интервью! Это каждый день, кроме выходных. Везде однотипные вопросы, многие вещи я уже выучил, даже которые не знал. Одно интервью запомнится надолго. Прошел интервью на один интересный проект. Осталось пройти кастомерское интервью, но кастомер с новым контрактом, перепуганный и меня предупредили что там будут проверять по полной программе. Знаете мемную картинку с мелкой блондинкой и кучей негров вокруг? Вот такое интервью у меня было. Три с лишним часа!
Более трех часов меня гоняли разные команды по разным вопросам. За интервью поменялось 4 команды на звонке. Плюс была кодинг сессия на 40 минут, где я писал херня всякую на питоне - задачи уровня универа(частично выкрутился на баше).
Все прошло успешно вроде, менеджер проекта уже радовался, но пришел отказ)) На этот раз из-за AWS, в котором у меня минимальная экспертиза. Я конечно немного расстроился, но пошел дальше. После такого собеса далее было уже ничего не страшно.
Дальше я проходил интервью уже легко и как-то ждал уже несколько оферов - хороших и не очень. Но выбирать что-то надо было. В итоге, принял офер в неплохой аутсорс. На собесах понравилась команда и тимлид и выглядело все неплохо.
Сейчас пока прохожу процесс онбординга, ждать много доступов и всякого такого, но проект интересный.
Итак, как я обещал, пишу про свой опыт собеседований этим летом.
В апреле стало известно, что наш перспективный продукт скорее мертв,
чем жив и делов дальше не будет. Появились первые слухи, когда нас всех отпустят
на волю, а потом уже появилась информация, что работать я буду до конца лета и все.
Естественно всяких активитис становилось все меньше и летом стало почти ноль.
Примерно с июля месяца я обновил CV, аккаунт на djini, linkedIN и поставил статус
Open to work. Посыпались сразу и много предложений от рекрутеров. И тут возникает первая проблема - их реально много и надо как-то это отсеивать, потому что ответить всем и перечитать каждое предложение нереально, а там много несовпадений еще и по стеку и некоторые предлагают еще позиции какого-нибудь фронтендера. Тогда на djini я сразу задрал планку по зарплате и писать стали в разы меньше(а те, кто пишет значит готовы такую сумму предложить и это хорошо). И таким образом появились первые интересные проекты, на которые были засетаплены интервью. Скажу честно, вначале искал только продуктовую компанию, в аутсорсе не работал и чот не хотелось начинать. Потому сразу отметал весь аутсорс.
Первое же интервью дало хороший результат и на меня свалилось тестовое задание. Не сильно одобряю тестовые при процессе хайринга, но тут интересный продукт и я согласился. Тестовое было довольно объемным. Надо было поднять автоматически однонодовый кластер k8s с вагрантом и ансиблом и чтоб автоматически туда надеплоилась аппка, которую надо сделать самому и запхать в докер (аппка уровня hello world) и ci/cd использовать kubernetes-native, а точнее ArgoCI и ArgoCD. Я сразу же написал, что ArgoCI давно протух и не разрабатывается(видимо тестовое не менялось с 2018 года) и мне сказали юзать на выбор что хочу. В итоге получилась связка github actions + ArgoCD в кубере. После этого я прохожу интервью с СЕО и вроде бы все ок, рекрутер ликует. Ждем офер и получаю отказ по причине, что тестовое сделано хорошо, но не production ready. Сказать что я охуел, значит ничего не сказать. Продакшн? С вагрантом и миникубом? Ебанулись? Видимо я просто не понравился тому СЕО и меня решили слить. Ну ничего, продукт отвалился и хер с ним.
Дальше я задумался еще и поводу аутсорсинга, все таки там паблик клауды, а я как раз туда и хочу. Надоело ковыряться уже в опенстеке и k8s on-premise. Хочется поменять немного стек. Ну тогда начал принимать предложения рекрутеров от аутсорса тоже. И тогда начался у меня интервьюшный ад. В день у меня было по 1-3 интервью! Это каждый день, кроме выходных. Везде однотипные вопросы, многие вещи я уже выучил, даже которые не знал. Одно интервью запомнится надолго. Прошел интервью на один интересный проект. Осталось пройти кастомерское интервью, но кастомер с новым контрактом, перепуганный и меня предупредили что там будут проверять по полной программе. Знаете мемную картинку с мелкой блондинкой и кучей негров вокруг? Вот такое интервью у меня было. Три с лишним часа!
Более трех часов меня гоняли разные команды по разным вопросам. За интервью поменялось 4 команды на звонке. Плюс была кодинг сессия на 40 минут, где я писал херня всякую на питоне - задачи уровня универа(частично выкрутился на баше).
Все прошло успешно вроде, менеджер проекта уже радовался, но пришел отказ)) На этот раз из-за AWS, в котором у меня минимальная экспертиза. Я конечно немного расстроился, но пошел дальше. После такого собеса далее было уже ничего не страшно.
Дальше я проходил интервью уже легко и как-то ждал уже несколько оферов - хороших и не очень. Но выбирать что-то надо было. В итоге, принял офер в неплохой аутсорс. На собесах понравилась команда и тимлид и выглядело все неплохо.
Сейчас пока прохожу процесс онбординга, ждать много доступов и всякого такого, но проект интересный.
#собеседования #IT #рекрутинг
А теперь несколько советов. Для тех, кто собирается проходить интервью.
- Подготовьтесь тщательно к вопросам. Спрашивать будут по всему, что написано в CV.
Нужно обновить информацию в голове по теории. Можно несколько лет работать, но потом на простые вопросы тупить. Типа что такое LA в linux? Или что такое inodes?
- Тестовые задания. Тут каждый сам решает делать или нет. Если задание на 8-10 часов, то я б не делал. Был проект с тестовым, я когда увидел там dotnet + винду + докер, то сразу понял с чем придеться работать и отказался.
- Английский язык. Часть интервью или весь процесс может быть на английском, потому нужно показать кастомеру нормальный уровень языка. Не используйте только симпл времена) Подготовьте как минимум речь о себе, про свои проекты, таски, хобби и пр. Это придется рассказывать не один раз. Так же рассказывать придется о том, что вы ждете от проекта и все такое, это тоже все можно заранее подготовить.
- Не ставьте подряд на день по 2-3 интервью как я)) Это тяжело и надо больше отдыхать.
А еще перед большим техническим интервью надо хорошо выспаться.
- Если есть возможность провести интервью дома, то конечно это хорошо. Но если дома может что-то помешать, а еще дома может отключится инет или что-то в это роде, то найдите место для интервью. Возможно рядом есть хороший коворкинг и там есть митинг-румы, то идеальный вариант.
- Второй монитор. Да, очень полезная штука особенно на кодинг сессиях) Можно хоть немного подглядывать в доки.
P.S. Кстати, вопросы для интервью я подготовил на гитхабе. Но нужно в ближайшее время добавить вопросы, которые часто были на моих интервью. Удачных поисков и собеседований!
А теперь несколько советов. Для тех, кто собирается проходить интервью.
- Подготовьтесь тщательно к вопросам. Спрашивать будут по всему, что написано в CV.
Нужно обновить информацию в голове по теории. Можно несколько лет работать, но потом на простые вопросы тупить. Типа что такое LA в linux? Или что такое inodes?
- Тестовые задания. Тут каждый сам решает делать или нет. Если задание на 8-10 часов, то я б не делал. Был проект с тестовым, я когда увидел там dotnet + винду + докер, то сразу понял с чем придеться работать и отказался.
- Английский язык. Часть интервью или весь процесс может быть на английском, потому нужно показать кастомеру нормальный уровень языка. Не используйте только симпл времена) Подготовьте как минимум речь о себе, про свои проекты, таски, хобби и пр. Это придется рассказывать не один раз. Так же рассказывать придется о том, что вы ждете от проекта и все такое, это тоже все можно заранее подготовить.
- Не ставьте подряд на день по 2-3 интервью как я)) Это тяжело и надо больше отдыхать.
А еще перед большим техническим интервью надо хорошо выспаться.
- Если есть возможность провести интервью дома, то конечно это хорошо. Но если дома может что-то помешать, а еще дома может отключится инет или что-то в это роде, то найдите место для интервью. Возможно рядом есть хороший коворкинг и там есть митинг-румы, то идеальный вариант.
- Второй монитор. Да, очень полезная штука особенно на кодинг сессиях) Можно хоть немного подглядывать в доки.
P.S. Кстати, вопросы для интервью я подготовил на гитхабе. Но нужно в ближайшее время добавить вопросы, которые часто были на моих интервью. Удачных поисков и собеседований!
IT мемы, гайды.
Подписывайтесь @itiyumor.
Здесь выходят каждый день мемы.
Автор старается. Лучшие мемы вы найдете здесь @itiyumor.
#ВзаимоПиар
Подписывайтесь @itiyumor.
Здесь выходят каждый день мемы.
Автор старается. Лучшие мемы вы найдете здесь @itiyumor.
#ВзаимоПиар
Уже скоро в онлайн формате пройдет ежегодная конфа Devops World 2020
Full Agenda тут
https://sessions.devopsworld.com/sessions
Full Agenda тут
https://sessions.devopsworld.com/sessions
Напомню, что открылась регистрация на Hacktober Fest 2020
https://hacktoberfest.digitalocean.com/?utm_medium=email&utm_source=hacktoberfest&utm_campaign=main_&utm_content=interest
https://hacktoberfest.digitalocean.com/?utm_medium=email&utm_source=hacktoberfest&utm_campaign=main_&utm_content=interest
Hacktoberfest
Hacktoberfest 2025
Hacktoberfest: a month-long celebration of open-source projects, their maintainers, and the entire community of contributors.
#devops #советы_для_джунов
Чем отличается джун от синьора. Советы для джунов.
1. Эффективно работайте над задачами. Для каждой задачи вы должны
обозначить конечный результат и двигаться именно к этому результату.
Если задача не предполагает конечного результата, а например нужно сделать
инвестигейшн и выбрать нужный инструмент для работы, то все равно
должна быть понятная цель.
2. Оценка времени для задач. Очень трудная штука.
Бывает, что кажется задача займет от силы два дня, потом вылезают
подводные камни, потом коллеги на код ревью насуют комментариев и надо
сделать много исправлений и потом ждешь когда апрувнут твой пулл-реквест.
Так что, реально оценивайте задачи и не бойтесь говорить менеджеру, что задача
займет пару недель, даже если вы оцениваете ее на одну неделю. Но делайте это
обоснованно.
3. Принятие решений, ответственность и склонность к действию.
Не бойтесь ответственности за принятие решений. Решения должны быть конечно обдуманными.Если вам доверили выбрать технологию или архитектуру, то не бойтесь принять решение и обосновать почему решили так то. В случае факапа, так же не бойтесь принять ответственностьи признать ошибки.
4. Автоматизация всего и вся. Ну тут как бы понятно, особенно тем кто работал
сисадмином=) Любые таски, любые работы с конфигами автоматизируйте, чтоб не пришлосьпотом опять делать руками. Например, надо развернуть QA окружение в клауде - можно сделатьза полчаса-час вручную, а можно сделать пайплайн, который автоматом все развернет. Потом будете реюзать его для всего остального. А если иногда кажется, что можно один раз сделать ионо больше не пригодится, то это иллюзия - потом все может пригодится.
5. Документация. Пишите доки и импрувайте документацию.
Вся команда скажет спасибо. Иногда на это тупо не хватает времени, но это надо.
Как только появилась минутка, то займитесь последними доками, которые хотели сделать или недоделали. Дайте почитать и проверить документацию вашу коллегам. Если это ранбуки или мануалы по настройке чего-то, то пусть проверят и попробуют сделать как написано в доке - иногда вылезают проблемы))
6. Коммуникации с людьми. Тут про софтскиллы. Надо общаться с другими командами.
Знаю ситуации, когда команда девелоперов гонит на девопса, типа он такой сякой, не может намнормально докеры сделать, при этом девопс не в курсе, что у них не работает и что они хотят. Они приходят на митинги и говорят, что у них все хорошо, а сами гонят потом просто за спиной. Потому общайтесь с командами и сабкомандами и узнавайте как у них дела.
7. Задавайте вопросы
Всегда лучше переспросить несколько раз и уточнить задачу, прежде чем начать что-то
делать. От этого зависит конечный результат и возможно меньше придется переделывать.
Никаких недопониманий не должно быть, всегда уточняйте любые вопросы.
8. Проектируйте на бумаге или whiteboard
Если приступаете к серьезной задаче, то соберитесь с командой возле вайтборда и
порисуйте как все должно выглядеть. Если работаете как сингл-юнит, то сделайте тоже
самое просто на бумаге, нарисуйте архитектуру, которая кстати говоря потом пойдет уже в документацию. Возможно при этом возникнут еще вопросы по задачам и тогда все это надо будет уточнить еще раз.
9. Изучайте другие области и технологии
Проще говоря, развивайтесь всесторонне. Даже если вы devops инженер и пишите немного кода, то попробуйте изучить ООП или другие языки программирования. Если есть пробелы в других областях, то необходимо тоже все это подтягивать по мере сил и времени. Можно еще выучить дополнительно язык -
хорошо знаете английский, то попробуйте выучить немецкий, например. Ну и больше читайте, не только техническую литературу, но и всякие полезные книги по менеджменту и так далее.
10. И помните, что джун это тот, кто гуглит. Синьор это тот, кто уже давно все нагуглил))
Чем отличается джун от синьора. Советы для джунов.
1. Эффективно работайте над задачами. Для каждой задачи вы должны
обозначить конечный результат и двигаться именно к этому результату.
Если задача не предполагает конечного результата, а например нужно сделать
инвестигейшн и выбрать нужный инструмент для работы, то все равно
должна быть понятная цель.
2. Оценка времени для задач. Очень трудная штука.
Бывает, что кажется задача займет от силы два дня, потом вылезают
подводные камни, потом коллеги на код ревью насуют комментариев и надо
сделать много исправлений и потом ждешь когда апрувнут твой пулл-реквест.
Так что, реально оценивайте задачи и не бойтесь говорить менеджеру, что задача
займет пару недель, даже если вы оцениваете ее на одну неделю. Но делайте это
обоснованно.
3. Принятие решений, ответственность и склонность к действию.
Не бойтесь ответственности за принятие решений. Решения должны быть конечно обдуманными.Если вам доверили выбрать технологию или архитектуру, то не бойтесь принять решение и обосновать почему решили так то. В случае факапа, так же не бойтесь принять ответственностьи признать ошибки.
4. Автоматизация всего и вся. Ну тут как бы понятно, особенно тем кто работал
сисадмином=) Любые таски, любые работы с конфигами автоматизируйте, чтоб не пришлосьпотом опять делать руками. Например, надо развернуть QA окружение в клауде - можно сделатьза полчаса-час вручную, а можно сделать пайплайн, который автоматом все развернет. Потом будете реюзать его для всего остального. А если иногда кажется, что можно один раз сделать ионо больше не пригодится, то это иллюзия - потом все может пригодится.
5. Документация. Пишите доки и импрувайте документацию.
Вся команда скажет спасибо. Иногда на это тупо не хватает времени, но это надо.
Как только появилась минутка, то займитесь последними доками, которые хотели сделать или недоделали. Дайте почитать и проверить документацию вашу коллегам. Если это ранбуки или мануалы по настройке чего-то, то пусть проверят и попробуют сделать как написано в доке - иногда вылезают проблемы))
6. Коммуникации с людьми. Тут про софтскиллы. Надо общаться с другими командами.
Знаю ситуации, когда команда девелоперов гонит на девопса, типа он такой сякой, не может намнормально докеры сделать, при этом девопс не в курсе, что у них не работает и что они хотят. Они приходят на митинги и говорят, что у них все хорошо, а сами гонят потом просто за спиной. Потому общайтесь с командами и сабкомандами и узнавайте как у них дела.
7. Задавайте вопросы
Всегда лучше переспросить несколько раз и уточнить задачу, прежде чем начать что-то
делать. От этого зависит конечный результат и возможно меньше придется переделывать.
Никаких недопониманий не должно быть, всегда уточняйте любые вопросы.
8. Проектируйте на бумаге или whiteboard
Если приступаете к серьезной задаче, то соберитесь с командой возле вайтборда и
порисуйте как все должно выглядеть. Если работаете как сингл-юнит, то сделайте тоже
самое просто на бумаге, нарисуйте архитектуру, которая кстати говоря потом пойдет уже в документацию. Возможно при этом возникнут еще вопросы по задачам и тогда все это надо будет уточнить еще раз.
9. Изучайте другие области и технологии
Проще говоря, развивайтесь всесторонне. Даже если вы devops инженер и пишите немного кода, то попробуйте изучить ООП или другие языки программирования. Если есть пробелы в других областях, то необходимо тоже все это подтягивать по мере сил и времени. Можно еще выучить дополнительно язык -
хорошо знаете английский, то попробуйте выучить немецкий, например. Ну и больше читайте, не только техническую литературу, но и всякие полезные книги по менеджменту и так далее.
10. И помните, что джун это тот, кто гуглит. Синьор это тот, кто уже давно все нагуглил))