Я начал активно искать работу на позицию junior backend разработчика примерно два месяца назад. За это время я отправил множество откликов и получил 5 тестовых заданий. Однако после их проверки я получил отказы. В частности: <br/> <br/> - Фидбэк я получил только по одному заданию. <br/> - По одному заданию был дан странный и сухой фидбэк, после чего компания удалила вакансию и была заблокирована на hh.ru. <br/> - Два задания вообще прошли без фидбэка, просто пришел отказ. <br/> - На одно задание мне отказали, потому что я изначально не прошел по резюме, но все равно дали ТЗ. <br/> <br/> В связи с этим у меня возникает вопрос: как быть в данной ситуации? Не то чтобы у новых разработчиков в России был большой выбор, кроме как тратить время на выполнение ТЗ для малознакомых компаний, откуда вероятность отказа составляет 80%, но мне хотелось бы получить рекомендации по оптимизации этого процесса. Очевидно, что было бы полезно, если бы давали фидбэк, но если я выполняю ТЗ, которое не представляет для меня сложности и занимает всего час, а в итоге не получаю никакого ответа, это довольно печально. У меня есть несколько основных вопросов: <br/> <br/> - Стоит ли стараться "удивить" проверяющего? Есть ли польза от того, если я, например, в задании, где просят написать короткий код, добавлю в него использование Celery, изменю базу данных с локальной на более подходящую и упакую приложение в Docker образ? <br/> - Какие есть рекомендации, чтобы избежать ситуации, когда мне изначально не подходит позиция, но все равно дают ТЗ?
Поиск работы в IT-сфере, тем более на позиции junior, может быть сложным и иногда разочаровывающим процессом. Вот несколько рекомендаций по оптимизации выполнения тестовых заданий и взаимодействию с потенциальными работодателями: ### 1. Выбор тестовых заданий - **Уточнение требований:** Перед началом работы над заданием постарайтесь выяснить, что именно ожидает от вас компания. Задайте вопросы, если что-то неясно. Это не только поможет вам лучше понять задание, но и покажет вашу заинтересованность и активность. - **Ограничение количества тестовых заданий:** Не стоит выполнять тестовые задания для всех компаний подряд, особенно если у вас есть сомнения о их репутации. Попробуйте сосредоточиться на компаниях, которые вам действительно интересны и чьи вакансии соответствуют вашему уровню. ### 2. Как "удивить" проверяющего? - **Правильный баланс:** Удивить проверяющего можно, но важно не переборщить. Если задание простое и его цель — оценить базовые навыки, не стоит вносить слишком много сложностей. Например, если вам просят написать REST API, улучшение с использованием Docker может быть уместным, но добавление Celery может отвлечь внимание от основной части задания. - **Чистота и простота кода:** Помните, что качество кода, читаемость и следование принципам разработки (задачи, решение, комментарии) важнее избыточного функционала. Убедитесь, что ваши решения понятны даже в отсутствии дополнительной функциональности. ### 3. Фидбэк и работа с отказами - **Запрос фидбэка:** Если вы не получили обратной связи, не бойтесь сами обратиться к рекрутерам или менеджерам. Вежливо спросите, что можно улучшить и почему был получен отказ. - **Используйте отказы как уроки:** Проанализируйте отклики или отсутствие фидбэка. Возможно, стоит пересмотреть портфолио или резюме, чтобы они лучше соответствовали ожидаемому уровню. ### 4. Избежание неподходящих TЗ - **Четкие ожидания перед тестом:** Когда предлагаете выполнить тестовое задание, уточняйте, какой уровень кандидата им нужен. Вы можете запросить дополнительную информацию о навыках, которые проверяются. - **Фильтрация вакансий:** При резюме обращайте внимание на описание вакансии и заранее оцените, насколько ожидаемые требования соответствуют вашим навыкам. Это снизит вероятность получения задания, если вы не соответствуете минимальным требованиям. ### 5. Общее отношение к процессу - **Терпение и упорство:** Процесс поиска работы может занять время. Постарайтесь не терять уверенности в себе и продолжайте развиваться. Участие в проектах (даже в качестве волонтера или на фрилансе) может добавить полезного опыта и улучшить резюме. - **Сетевые связи:** Попробуйте участвовать в сообществах, где общаются разработчики и работодатели (например, на платформе GitHub, в группах на LinkedIn или специализированных форумах). Это может помочь найти подходящие вакансии и получить рекомендации или фидбэк по тестовым заданиям. Следуя этим рекомендациям, вы сможете оптимизировать процесс поиска работы и, возможно, повысить свои шансы на получение желаемой должности. Удачи!
когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно
Это действительно грустно, позор этим компаниям. Но боюсь, что сделать с этим вряд ли что-то можно. Разве что пытаться вежливо, но настойчиво переспрашивать фидбек.
Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?
Можно написать базовую версию, а потом сделать ветку и навертеть в неё сверху всякого, что показывает глубокое знание языка, владение абстракциями и шаблонами, знание тонкостей фреймворка, умение писать масштабируемые системы и т.д. и т.п.
Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.
Был фидбек, не был фидбек, не нужно воспринимать все это на свой счет. Больше, активности. Представь себе, следующую ситуацию, баскетбол. Тебе нужно забить три трех очковых подряд , это не просто. Чем больше попыток, зайти на страйк, тем больше шансы. Рецепт один, больше откликаться, выполнять тестовые задания, пытаться удивить в тестовых заданиях и т.д.
Твоя цель - оффер, и все посторонние мысли о справедливости, какая компания, какое тестовое и т.д. Они только отвлекают и мешают.
Не то чтобы у начинающих разработчиков в России есть какой-то выбор
Вот на этом останавливаетесь и все. Выбора нет, если нужна работа. Если бы вы были гением - тогда ладно, но это маловероятно.
Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?
Я бы сказал что это даже вредно. Выполнять задачи надо по ТЗ