Я начал активно искать работу на позицию 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 или специализированных форумах). Это может помочь найти подходящие вакансии и получить рекомендации или фидбэк по тестовым заданиям. Следуя этим рекомендациям, вы сможете оптимизировать процесс поиска работы и, возможно, повысить свои шансы на получение желаемой должности. Удачи!
<blockquote>когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно</blockquote> <br/> Это действительно грустно, позор этим компаниям. Но боюсь, что сделать с этим вряд ли что-то можно. Разве что пытаться вежливо, но настойчиво переспрашивать фидбек. <br/> <br/> <blockquote>Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?</blockquote> <br/> Можно написать базовую версию, а потом сделать ветку и навертеть в неё сверху всякого, что показывает глубокое знание языка, владение абстракциями и шаблонами, знание тонкостей фреймворка, умение писать масштабируемые системы и т.д. и т.п. <br/> <br/> Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.
Был фидбек, не был фидбек, не нужно воспринимать все это на свой счет. Больше, активности. Представь себе, следующую ситуацию, баскетбол. Тебе нужно забить <b>три трех очковых подряд</b> , это не просто. Чем больше попыток, зайти на страйк, тем больше шансы. Рецепт один, больше откликаться, выполнять тестовые задания, пытаться удивить в тестовых заданиях и т.д. <br/> <br/> Твоя цель - оффер, и все посторонние мысли о справедливости, какая компания, какое тестовое и т.д. Они только отвлекают и мешают.
<blockquote>Не то чтобы у начинающих разработчиков в России есть какой-то выбор</blockquote> <br/> Вот на этом останавливаетесь и все. Выбора нет, если нужна работа. Если бы вы были гением - тогда ладно, но это маловероятно. <br/> <br/> <blockquote>Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?</blockquote> <br/> Я бы сказал что это даже вредно. Выполнять задачи надо по ТЗ