Привет, меня зовут Диана, я iOS-разработчица в KODE. Но ещё пару лет назад я была вне IT, без проектов, без офферов, без GitHub-портфолио. Я конспектировала статьи про многопоточность, разбирала сложные кейсы GCD и заучивала паттерны проектирования, думая: «Пока не освою всё это идеально — нет смысла откликаться на вакансии».
Оглядываясь назад, понимаю: это была ловушка. Классическая и коварная. Я застряла в иллюзии подготовки. Только когда рискнула выйти из зоны комфорта и сделать первый шаг — несмотря на страх и неуверенность — что-то наконец сдвинулось с мёртвой точки.
Теперь, пройдя путь с нуля до работы в коммерческом проекте, я хочу честно поделиться опытом. Без абстрактных мотиваций. Только тем, что реально сработало. И главное — показать: soft skills могут быть не менее важны, чем знание языка программирования. Особенно в самом начале.
Техническая база — важна. Но не самодостаточна
Начнём с очевидного: базовые знания всё же нужны. Swift, Xcode, Git, понимание архитектур, асинхронности и т.д. Их можно получить на курсах, в вузе, в процессе самообучения. Это фундамент, без которого сложно ориентироваться в коде и разговаривать с командой на одном языке.
Но вот что важно: никто не ждёт от джуна, что он будет ходячей документацией по iOS SDK. Однажды на собеседовании мне дали реализовать поиск по локальной базе. Я честно сказала: «Сейчас делаю через UserDefaults, но понимаю, что для реального проекта это не оптимально. Думаю, здесь нужен Core Data, но мне нужно время на его изучение». Вместо минуса это стало плюсом: оценили моё критическое мышление и готовность развиваться, и так я получила свой первый оффер.
Так что да, знание хардов — это ваша база. Но то, как вы ведёте себя в неопределённости, как реагируете на незнание и как ищете решение — вот что будет по-настоящему ценным.
Soft skills: что реально спасает в первые месяцы
На собеседованиях и в вакансиях часто говорят о технических требованиях. Swift, Git, CI/CD, архитектуры — всё это, безусловно, важно. Но если посмотреть на статистику от IT-рекрутеров и отчёты команд, становится видно: увольняют чаще всего не за плохой код.
Один из HR-отчетов Hays показал: до 70% джунов не проходят испытательный срок, особенно в крупных и технологически зрелых компаниях. Причины? Ошибки в коммуникации, неумение работать в команде, отказ воспринимать фидбек и пассивная позиция в процессе. Технический пробел — лишь на четвёртом месте.
Я видела это на практике, и заметила интересную закономерность: джуны, которые задерживались надолго, вели себя по-особенному.
Вот что их отличало:
Они не боялись сказать: «Я не разобрался — объясните», вместо того чтобы неделю делать не то.
Сразу спрашивали: «Правильно ли я понял, что здесь нужно кеширование?», а не узнавали об этом после дедлайна.
На код-ревью не спорили, а интересовались: «Почему лучше так?» — и применяли это впоследствии.
Я осталась в числе тех, кто «прижился». Не потому, что была технарём от бога — а потому, что научилась признавать, что не знаю. Спрашивать. Переспрашивать. И исправлять. Это и стало моим soft skills-щитком, который помог выжить.
Умение задавать вопросы: не демонстрация слабости, а навык роста
Боязнь признаться, что ты чего-то не знаешь — это, пожалуй, самый частый стопор у начинающих. Кажется, что если ты задашь вопрос, все сразу поймут: «Ага, он некомпетентен!». Но правда в обратном: умение задавать вопросы — признак зрелости и профессионального мышления.
Когда ты новичок, твоё незнание естественно. Но если ты молчишь, гадаешь, стесняешься, тратишь часы на тупняк вместо того, чтобы уточнить у тимлида или на ревью — ты тормозишь не только себя, но и команду. В итоге страдают все.
Я тоже через это проходила. Сидела над задачей полдня, пока в один момент не решилась написать: «Вот стек, вот что пробовала, не сработало. Думаю, дело в вот этом. Подскажешь, куда копать?». Ответ пришёл через 3 минуты. Не только с решением, но и с благодарностью за чёткий и понятный вопрос.
Как задавать вопросы, которые хочется читать
Секрет в трёх составляющих: контекст, попытки, суть. Не просто «SwiftGen сломался», а: «SwiftGen не генерирует код для новых ассетов, хотя конфиг вроде правильный. Проверил пути, чистил DerivedData — не помогло. В логе вот такая ошибка: [прикладываю]. Гуглил, но решения не нашёл — куда копать дальше?»
Такой вопрос не вызывает раздражения. Он экономит время тем, кто отвечает. И показывает, что ты не просишь тушить пожары, а просишь разобраться — вместе.
Прямо сейчас можно начать с малого: возьми любую свою задачу и попробуй сформулировать к ней вопрос так, как будто бы пишешь на Stack Overflow. Только не для галочки, а реально: с логом, контекстом, своими догадками и гипотезами. Ты удивишься, как это упражнение прокачает твоё мышление — даже если задавать вопрос некуда.
Обратная связь — не враг, а инструмент роста
На старте карьеры фидбек воспринимается как угроза. Кажется, что любой комментарий — это обвинение, а любое замечание — приговор. Я через это проходила. После первого код-ревью мне хотелось провалиться сквозь землю. А как-то, получив 90 комментов на ревью, я и вовсе подумала: «Наверное, я вообще не подхожу для этой профессии».
Но позже поняла простую вещь: обратная связь — это не оценка личности. Это индикатор роста. Это не «тебя ругают», а «тебе показывают, где ты можешь стать сильнее». Если начать относиться к фидбеку как к навигатору, а не как к судье — ты внезапно начнёшь расти гораздо быстрее, чем ожидал.
Да, первое время тяжело. Но я заметила: каждый раз, когда я не спорила, не оправдывалась, а вслушивалась — на следующем ревью мне указывали уже совсем другие, более сложные вещи. Это значит, что базу я начала закрывать. А значит, прогресс!
Как превратить фидбек в ускоритель, а не тормоз
Хорошая привычка — после каждого собеседования просить обратную связь. Не просто «как я справился?», а конкретно: «Что я сделала хорошо? Что можно улучшить?». Иногда вам не ответят. Иногда ответят уклончиво. Но иногда — дадут именно ту мысль, которая заставит пересобрать весь подход к подготовке.
То же самое с код-ревью. Вместо обиды спросите: «А как бы вы переписали этот блок?» или «Что тут главное — читаемость или скорость?». Такие вопросы показывают, что вы готовы к диалогу, а не просто копируете решение.
Это не всегда комфортно. Но именно в этих моментах — когда хочется защититься, но ты открываешься — и происходят главные точки роста. Фидбек — не враг. Фидбек — ваш первый тимлид, если научиться его слушать.
Коммуникация в команде: ты не только пишешь код, ты работаешь с людьми
В начале кажется, что главное — хорошо написать код. Всё остальное — вторично. Но очень быстро выясняется: код — только половина работы. Вторая половина — это люди.
Ни одна задача не существует в изоляции. Даже если ты джун, ты всё равно взаимодействуешь с дизайнером, тимлидом, аналитиком, QA, продактом. Ты получаешь контекст, уточняешь детали, рассказываешь, что и почему делаешь. Коммуникация — фундамент, на котором держится всё остальное.
Тимлиды, кстати, это прекрасно понимают. На собеседованиях и в процессе работы они оценивают не только знание технологий, но и то, как ты ведёшь себя в обсуждении: умеешь ли задавать уточняющие вопросы, доносишь ли свои мысли ясно, способен ли аргументированно отстаивать решение или соглашаешься, когда неправ.
Я видела, как джуна с неплохими знаниями отстранили от задачи просто потому, что он постоянно «уходил в туман»: не объяснял свои решения, не уточнял, если что-то было непонятно, и избегал общения. Это тормозило всех. А джун, который знал меньше, но чётко обозначал статус, не боялся спрашивать и был понятен в общении — оставался и получал всё более сложные и интересные задачи.
Как прокачивать навык командной коммуникации
Самый доступный способ — участие в обсуждениях pet-проектов. Даже если это просто Telegram-чат или GitHub-проект с друзьями. Чем больше ты проговариваешь решения, обсуждаешь варианты, объясняешь, почему сделал именно так — тем быстрее растёт твой навык «внятности».
Попробуй ещё одну простую технику: проговаривай свои мысли вслух, даже если просто решаешь задачу в одиночку. Или объясни решение другу, который далёк от IT. Это помогает тренировать способность формулировать мысли так, чтобы они были понятны другим — и это умение почти важнее, чем точное знание синтаксиса.
Командная работа начинается не с pull request'а. Она начинается с умения быть понятым.
Умение презентовать себя: честность как стратегия, а не оправдание
Для джуна самопрезентация — это не просто «пара слов о себе». Это инструмент. Причём один из ключевых: от того, как ты рассказываешь о себе, зависит, увидят ли в тебе потенциал. И тут важно понять: презентация — это не попытка казаться круче, чем ты есть. Это умение показать, куда ты движешься и как ты уже действуешь.
Одна из частых ошибок новичков — пытаться натянуть «опыт» там, где его нет. Придумывать проекты, приукрашивать знания, использовать шаблонные фразы. Но опытные тимлиды чувствуют фальшь за секунды. А вот честная подача — наоборот, может сработать на тебя.
Я, например, на одном из собеседований открыто сказала: «Я пока не работала с архитектурами глубоко, но вот pet-проект, в котором я пробовала MVVM. И вот с какими сложностями столкнулась. Сейчас изучаю подходы к масштабируемости, могу показать, как именно». И это сработало. Потому что фокус был не на том, что я знаю идеально, а на том, что я уже делаю, чтобы стать лучше.
Как прокачать умение говорить про себя
Первый шаг — перестать думать, что никто не захочет слушать про тебя и твой опыт. Даже если ты только начал путь — ты уже принимаешь решения, делаешь выбор, изучаешь что-то самостоятельно. Это уже ценно.
Попробуй проговорить это вслух. Например, на митапе, стажировке или собеседовании. Не выученный текст, а искренний рассказ: «Меня зовут так-то, я учусь вот этому, вот что уже попробовал, вот что меня заинтересовало». Это и есть твой живой elevator pitch — короткий рассказ, который отражает не «кто ты на бумаге», а «как ты растешь». Если трудно, запиши видео или потренируйся с друзьями.
Проактивность и самостоятельность: вы не обязаны знать всё, но обязаны двигаться
Когда ты джун, тебе многое прощается: неопытность, ошибки в логике, неуверенность. Но есть одна вещь, которую не прощают почти никогда — пассивность. Если ты сидишь и ждёшь, пока тебе объяснят задачу, дадут инструкцию, расскажут, что делать — в команде начнут задаваться вопросом: «А зачем нам человек, который не двигается сам?»
Парадокс в том, что никто не ждёт, что ты всё знаешь. Но все ждут, что ты будешь пытаться. Что ты скажешь: «Я не понимаю вот это — уже гуглил, нашёл вот такие варианты, но пока не уверен, что подойдёт». Или: «Сделал фичу, могу дополнительно: добавить логирование ключевых событий или обновить readme — как думаете, будет полезно?»
Это и есть проактивность. Не «сделал — жду следующую задачу», а «сделал — подумал, где ещё могу помочь». Это не про переработки и не про показную активность. Это про то, что ты — не беспомощный ученик, а человек, который пришёл решать задачи и расти.
Как тренировать проактивность в условиях, когда опыта мало
Хорошая привычка — завершая задачу, всегда задавать себе вопрос: «А что ещё может быть улучшено?». Иногда это будут очевидные штуки: добавить логирование, уточнить поведение у дизайнера, проверить граничные случаи. Иногда — просто привести в порядок коммиты. Но сам подход «всегда немного шире рамки» делает джуна заметным.
Вторая ключевая вещь — самостоятельный ресёрч. Если ты чего-то не понял — гугли. Почитай документацию. Посмотри на Stack Overflow. А если уже пробовал — зафиксируй это и потом задай вопрос. Формат «я искал, вот к чему пришёл, но всё ещё неясно» — вызывает уважение даже у самого загруженного ментора.
В командах ценят людей, которые умеют сами двигаться, но не стесняются остановиться и спросить, когда уперлись. Такой джун — это инвестиция. И поверь, ты почувствуешь это сразу по тону общения, уровню доверия и качеству задач, которые тебе начнут поручать.
Soft skills — это не просто «приятный бонус», а основной стек джуна
Не позволяй страху «недостаточности» парализовать твое движение. Ты не один такой — нас, «неготовых», были тысячи. Многие из нас всё ещё не знают «всё про ARC» и иногда путаются в архитектурах. Но это не мешает нам писать код, решать задачи, расти и получать удовольствие от работы.
Тебя не возьмут в IT за строчку в резюме. Но возьмут за то, что ты умеешь думать, слышать, учиться и честно смотреть на свои слабые стороны.
P.S. Если вы тоже недавно прошли путем джуна — напишите в комментарии, что помогло вам войти и остаться в IT. Приободрим тех, кому это еще предстоит!
