Не секрет, что во время испытательного срока на позиции разработчика оценивают не только твои технические навыки, но и софт-скиллы. Видел примеры, когда разработчики с хорошей технической экспертизой не проходили дальше из-за недостаточных софт-скиллов. В то же время ребята с технической экспертизой похуже, но коммуникабельные и позитивные шли дальше. Кстати, из-за недостатка таких скиллов я тоже чуть не вылетел с первого испытательного срока на фронтенд-разработчика. В этом посте хочу привести примеры софт-скиллов, обладая которыми вы покажете себя с лучшей стороны. Это круто, если разработчик: Если было полезно, приведу список негативных качеств, которые нужно фиксить.
Не секрет, что во время испытательного срока на позиции разработчика оценивают не только твои технические навыки, но и софт-скиллы. Видел примеры, когда разработчики с хорошей технической экспертизой не проходили дальше из-за недостаточных софт-скиллов. В то же время ребята с технической экспертизой похуже, но коммуникабельные и позитивные шли дальше. Кстати, из-за недостатка таких скиллов я тоже чуть не вылетел с первого испытательного срока на фронтенд-разработчика. В этом посте хочу привести примеры софт-скиллов, обладая которыми вы покажете себя с лучшей стороны.
Это круто, если разработчик:
- Умеет организовать работу. Сюда включаются такие навыки, как самостоятельность, умение управлять своим временем и умение поддерживать связь с коллегами. Например, ты выполняешь задачу по фронтенду, но для нее еще не готова бекенд-часть. Можно, конечно, ждать, пока она будет готова и терять время. А можно уточнить у бекендера примерный json, который он будет присылать с сервера на фронт. Сделать задачу, а потом поправить. Это займет меньше времени, чем начинать задачу с нуля.
- Активно участвует в обсуждениях с командой. В обсуждениях с командой смело делись своими мыслями по теме, предлагай идеи. Есть момент, который остальные не заметили? Скажи об этом команде. Это большой плюс в копилку.
- Задает уточняющие вопросы. Это полезный навык, который экономит время. Во время обсуждения задачи, нужно оценить, всё ли на 100% понятно. Если нет - нужно уточнять до тех пор, пока не станет понятно. Бывает и такое, что вопросы появляются во время разработки по задаче. В этом случае нужно уточнить у команды, а не делать по-своему.
- Воспринимает идеи коллег. Например, при обсуждении задачи твой тимлид рекомендует способ, как быстро сделать задачу. В этом случае лучше не изобретать велосипед, а прислушаться. Но, может быть, что ты увидел в его способе проблемы и он кажется неудачным. Тогда обсудите это еще раз.
- Говорит как есть, ничего не скрывает. Например, во время разработки возникла проблема, которую долго не можешь решить. Тут есть два варианта. На обсуждениях с командой ничего не говорить про этот момент, пытаться разобраться самому. Если разобраться не получилось, задача не будет выполнена в срок и к вам возникнут вопросы. Или второй, более удачный, вариант: если что-то не получается и не понимаешь, что делать дальше, посоветуйся с тимлидом или командой. Вместе найдёте решение.
Если было полезно, приведу список негативных качеств, которые нужно фиксить.