#собеседования #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. И помните, что джун это тот, кто гуглит. Синьор это тот, кто уже давно все нагуглил))
Forwarded from Sysadmin Tools 🇺🇦
Вот целый плейлист даже появился https://news.1rj.ru/str/tech_b0lt_Genona/2151
Telegram
Технологический Болт Генона
Выложены доклады с DevConfUS 2020. Куча интересных, как по мне, докладов на разные тематики.
https://www.youtube.com/playlist?list=PLU1vS0speL2b0fPKGvJ5asKOvNPkrCHC7
Программа
https://devconfus2020.sched.com/
https://www.youtube.com/playlist?list=PLU1vS0speL2b0fPKGvJ5asKOvNPkrCHC7
Программа
https://devconfus2020.sched.com/