Как пережить испытательный срок

Психологическое состояние начинающего программиста на испытательном сроке похоже на настроения студента-первокурсника, который ещё не сдал ни одной сессии и больше всего на свете боится вылететь из универа.

Вид Нубус студентикус (лат. — Noobus studenticus — прим.ред.) хорошо заметен по выпученным глазищам и привычке перемещаться стайками — им кажется, что так безопаснее. После первой сессии оказывается, что выжить можно. На втором курсе появляется вера в себя, которая крепнет с каждым годом вплоть до самого выпуска.

Подобные метаморфозы происходят и в рядах начинающих программистов: первый испытательный срок — самый волнующий. Когда человек достигает определенного профессионального уровня (aka высокий программист), такие вопросы волнуют его куда меньше. У него всё довольно предсказуемо: въезжаешь в проект, начинаешь потихоньку делать таски — и даже сам момент успешного завершения испытательного срока проходит почти незаметно. Это ли не мечта джуна?

Но испытательный срок может завалить не только новичок. Ведь уровень технических скилов не играет решающую роль. Сколько уж я видел толковых, но пафосных программистов, которых просили уйти уже через месяц, или тех мозговитых самородков, которые сами понимали, что им не место в этой компании, и сваливали уже через пару недель — и это при высоких зарплатах и традиционной нехватке спецов на рынке IT! И столько же я видел программистов и тестировщиков, которые объективно «не тянут», но их обучают и вытаскивают, потому что:
— они хотят учиться,
— с ними комфортно работать.

Это важное правило, которое иногда забывают даже маститые челябинские ковбои: «Нанимают не самых умных, но тех, с кем приятно иметь дело». Причем, это «приятно» у каждой команды своё.

Выжать максимум

Первый испытательный срок каждый проживает по-своему, как первую сессию. Кто-то нервничает, кто-то пытается понравиться, все стараются, но далеко не каждый понимает все преимущества испытательного срока. Я уж не говорю о преимуществах позиции джуна. Тогда как весь смысл — в том, чтоб выжимать максимум из своего положения. Пойдем по порядку.

Кредит доверия

В самом начале можно много ошибаться — это не зависит от лычки «джун» или «мидл». И это хороший способ набить шишки и чему-нибудь научиться. Но, конечно, если не поддерживать кредит доверия выполненными заданиями или, в случае джуна, хотя бы надеждами на эффективную работу в ближайшем будущем, с каждой неделей его будет всё меньше.

Следует также использовать кредит доверия, чтобы наладить контакты с программистами, тестировщиками, сисадминами и даже уборщицами — со всеми людьми, с которыми придется взаимодействовать. К новичкам относятся снисходительно и добросердечно, грех этим не пользоваться.

Вопросы

Одно из главных упущений многих молчунов или особо стеснительных новичков — они не задают вопросов. В те первые дни на работе, которые следует посвятить выяснению положения дел и архитектуры проекта, они стараются выглядеть умными и делать вид, что все под контролем. А ведь это золотая жила для джуна — там, где мидлу было бы уже стыдно спрашивать, у джуна есть фора: ему дозволены самые глупые вопросы.

Так что принцип «молчание — золото» здесь только мешает. Многие очевидные для «дедов» вещи на проекте или принятые в команде code conventions могут не совпадать с тем, что себе навоображал наш подающий надежды клавиатурный ковбой. Чем раньше всё выяснить, тем меньше потом придется переписывать.

Если что-то непонятно, спрашивать нужно любого человека, который потенциально может дать ответ. Даже если он из другой команды, даже если он на другом проекте и даже если он — кондиционерщик. Никогда не знаешь, кто, где и над чем работал.

Кстати, поскольку в первые дни обычно собирается много информации, неплохо бы записывать ключевые моменты в тетрадочку.

Ментор

Не в каждой команде можно найти мегамозга с навыками и желанием преподавать, но если он там есть, к нему стоит прижаться, как Ди Каприо к Кейт Уинслет в фильме «Титаник». Нет ничего лучше, чем увлеченный своим делом фанат, у которого есть ответы на все вопросы. И хотя, человек, который живет своим делом — это, конечно, находка, но не стоит зацикливаться на нём одном: вокруг полно людей, которые, может, и менее фанатичны и опытны, но зато точно умнее вас, а значит, могут стать вашими менторами хотя бы на пару минут. Если же вы — самый умный человек в комнате, значит, вы не в той комнате.

Разногласия

Человек на испытательном сроке может чувствовать себя неполноценным членом команды, в его словах меньше веса. Поэтому в спорах нужно вынести за скобки все звания и пытаться вести конструктивный диалог, даже если этого не хочется. Потому что спор — это также и провокация, которая позволяет не только выудить полезную информацию, но и натолкнуть собеседника на определенные мысли. Лучше показаться идиотом, чем угодливо промолчать и не предупредить потенциальный баг, который самому же придется потом фиксить. Так что следует помнить о народных традициях: на рынке торгуются, у whiteboard’а спорят.

Нервы

В первые дни/недели на работе может быть стрёмно. Я знаю одного джуна, который и через полгода продолжал сильно нервничать, если его код не работал на продакшине или если выполнение таски затягивалось. Иногда с этим можно что-то сделать — например, пойти к главному и сказать: «так, мол, и так, я не знаю, как быть». Если ходишь в погонах джуна, то тебя не только простят и предложат несколько решений, но и накормят, напоят чаем, ещё и книжку умную дадут. Если же кредит доверия уже исчерпан, то, по крайней мере, босс заценит честность и прямоту и либо поможет, либо передаст задачу другому человеку. В любом случае, это будет уже его проблема.

Настроение

Положительный настрой улучшает производительность — это факт. Но у новичков бывает ситуация порочного круга, когда всё скверно, и поэтому портится настроение, и поэтому дела идут плохо. Это ужасное, тоскливое чувство, когда вечером уходишь с работы ни с чем (живешь жизнь зря). Разорвать этот заколдованный круг поможет военная хитрость, для которой нужно взять какую-нибудь мелкую таску, сделать её и закомитить. Даже если для этого нужно будет самостоятельно её придумать. Даже если это будет пара дополнительных комментариев, переформатированная запись в логи или переименованная переменная. Любая полезная, работающая и закомиченная мелочь поднимет настроение. Снова появится ощущение рабочего потока, и на этой волне, с хорошим настроением, уже можно будет заниматься чем-нибудь более серьезным. Оптимизм (постоянное хорошее настроение) особенно важен для джунов, которым на первых этапах предстоит выгребать тонны досадных ошибок.

Сначала пробовать, потом просить помощи

Так называемое правило 15 минут не только облегчает жизнь новичку, но и экономит для компании многие человеко-часы. Суть в том, чтоб не залипать слишком долго над неразрешимой задачей. Если за 15 минут не удается найти решение, стоит записать или запомнить все испробованные подходы, и только затем идти к старшему. Зачем записывать? Он вас спросит: «А это ты делал?», «Логи смотрел?», «Через другой интерфейс пробовал?». Так вот, чтоб по два-три раза не бегать туда-сюда и не нервировать людей, у которых и так есть своя работа, стоит сделать прошения о гуманитарном кодинг-прибежище максимально эффективными. Подходишь к столу, шаркаешь ножищей по ковру, щелкаешь каблуками и докладываешь — «Так, мол, и так, такой-то такой-то попробовал первое-десятое и застрял. Имею честь просить о помощи».

Это вообще одна из типичных проблем новичков. Они не всегда умеют просить о помощи, когда она им нужна. Стесняются, боятся. «Как так? Я герой-одиночка, который сам всё сделает и порешает». В итоге теряется одно из важнейших преимуществ работы в офисе — возможность спросить совета у другой головы, которая думает иначе, чем твоя.

Поэтому любому программисту-самураю, каким бы крутым он ни был, все же следует держать в голове глобальную картинку миссии команды и помнить, что самое важное — конечный результат именно команды, а не отдельного человека-гения. Понимая это, новички не стремились бы во что бы то ни стало доказать свою компетентность, выбрасывая десятки и сотни человеко-часов на свалку неудачных тупиковых решений.

Но испытательный срок — это не только хорошая возможность завалить всю команду кучей глупейших вопросов и, тем самым, оставить о себе память на века. Это также отличный шанс узнать, что почем в новом коллективе. То, чего было не уловить во время собеседования с HR, в эти пару месяцев всплывет на поверхность и станет заметным. Интриги и сплетни, знакомства и связи — кто знает что пригодится в дальнейшей жизни. Но самое главное — это, конечно, опыт. Нет ничего лучше, чем посидеть в связке с другим программистом и поучиться тому, как он думает. И если в компании не принято использовать pair-programming, то на испытательном сроке можно попытаться прогнуть свою линию под соусом «передачи знаний о проекте». Тогда получится выжать из этой ситуации максимум — и уже не будет страшно, даже если в конце срока вас попрут из компании волшебными мётлами. Но ведь не попрут? Экий вы удалец.


P.S. Посвящаю эту статью комсомолке-спортсменке Оле, у которой сегодня первый день на позиции Junior Java developer. Оля, помни про правило 15-ти минут!

LinkedIn

Лучшие комментарии пропустить

Я и по сей день нервничаю, если код не работает на продакшене.

“Почему прод лежит 2 день?” — s1.developerslife.ru/...c6a3f45610a.gif

Достойная статья, я бы добавил еще несколько советов:
1) Первый испытательный срок (вход в IT) — самое сложное испытание в вашей профессиональной жизни в IT, будьте готовы работать на 100-200%, по вечерам и дома по выходным, чтобы выполнить задания. Потому что объем материала достаточно большой и сроки поджимают. Я не шучу. 30% пришедших со мной неофитов отсеялись именно по этой причине.

2) Несмотря на достаточно плотный график, старайтесь понять откуда дует ветер, кто из будущих коллег более отзывчивые, а каких лучше пока не беспокоить.

3) Никогда не спорьте с senior-ом, лидом, техлидом, начальником отдела или вашим куратором на обучении, просто делайте как они говорят, уточнив что непонятно. Ваша цель сейчас: учиться и делать как говорят по максимуму. Во-первых спорящие trainee это смешно, во-вторых набивать себе очки склочности не есть хорошо. Рядом с senior-ом вы никогда не будете равным в споре, даже не пытайтесь.

4) Составьте себе четкий план, добавьте 30% запаса на redline и следуйте ему. В некоторых организациях выдается scope задач, которые надо сделать скажем за месяц, так вот в начале можно застрять и с треском вылететь. Чтобы такого не случилось, распланируйте себе план работ на месяц, если выбиваетесь из графика — надо работать по вечерам и на выходных, иначе не успеете все сделать.
Допустим 10 задач на 20 рабочих дней. Добавьте 2-3 дня резерва, распишите по 8 часов, принимая во внимание, что следующие задания обычно всегда сложнее.

5) Совет для любого грейда: «Работу надо работать». Не преподносите никому сюрпризов, делайте то, что от вас ожидают, в требуемом объеме и качестве. Недоумение часто переходит в раздражительность, особенно на реальных проектах. Приучайтесь с самого нуля работать правильно. В идеале делать как указано в задании, если не получается, говорить почему сделали по-другому. Но как правило это самое «по-другому» выливается в велосипеды и костыли, после чего задание вполне закономерно не принимается.

хаха! отличная статья и написана легко

Якщо продакшен валиться, бо джуніор тупий — тупий не джуніор ©

96 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Интересная статья.Спасибо.

Возможно опять мой комментарий будет в пустоту, и всё же.
Почему весь ДОУ пропитан духом, «иди паши на дядю!!!». Ну вот серьёзно, ещё одна статья посвящена тому, что амбиции нужно убрать, а начальник всегда прав. Ну не возьмут вас на работу, ну и что? Ну работайте сами, попробуйте поискать заказы, попробуйте элементарно потусить, выучите кое-какие основы предпринимательства. До пенсии кодить это очень глупо!

амбиции нужно убрать, а начальник всегда прав
Где это есть в статье? Цитаты плз.
P.S. Статья про испытательный срок. Логично предположить, что когда человек работает на себя, у него нет испытательных сроков.

Немає сенсу «предпринимать в ИТ», коли ти сам не можеш написати ні стрічки коду.

Спасибо за статью. Но меня вот все время беспокоит такой вопрос: Нужно ли подстраиваться под темпы работы коллег? Чтоб не быть ни хуже, ни луче — дабы на тебя косо не смотрели... Например когда дают тестовое задание, дают сроки — я делаю его быстрее в 10 раз чем надо, как поступить? Отправить сразу готовое задание или же подождать дедлайна и отправить уже потом?

Нужно ли подстраиваться под темпы работы коллег?
от команды зависит.
лично мне было бы не приятно работать с человеком, который «уже все сделал на сегодня и может позволить себе смотреть кино». хотя б потому, что при таком подходе буду подозревать его в завышенных эстимейтах.
а вот «ребят, я закончил со своими тасками, кому я могу помочь» — наоборот, разделяю и поддерживаю.
с другой стороны, есть проекты/команды-"болота«, где лучше не «высовываться». это когда уже сложившаяся команда «сделал все, что планировал на сегодня». и любое отклонение воспринимается как угроза порядку вещей.
дают тестовое задание, дают сроки — я делаю его быстрее в 10 раз чем надо, как поступить
ну, это речь не о темпе коллег.
хинт: скорость выполнения тестового задания может учитываться, но, скорее всего, его просто не заметят — то есть, рекрутер пересылая решение технарю на «а, скажи, как у этого парня со скиллами» не будет также пересылать дату отправки и дату получения ответа.

Ну это было 2 разных вопроса :) Наверное не так выразился.
Спасибо.

лично мне было бы не приятно работать с человеком, который «уже все сделал на сегодня и может позволить себе смотреть кино». хотя б потому, что при таком подходе буду подозревать его в завышенных эстимейтах. а вот «ребят, я закончил со своими тасками, кому я могу помочь» — наоборот, разделяю и поддерживаю.
вот интересный подход, может человеку чтобы быстро работать отдых нужен, а начнет помогать другим и не поможет особо потому что времени мало, а надо разбираться и себе навредить и потом помощь и ему понадобится

я считаю что такому человеку нужно просто дать больше работы и денег, если он согласен; в итоге и сотрудник, и фирма в плюсе, а не лично тебе приятно

может человеку чтобы быстро работать отдых нужен, а начнет помогать другим и не поможет особо потому что времени мало, а надо разбираться и себе навредить и потом помощь и ему понадобится
вы ща говорите про конкретную ситуацию или «в общем»?
я говорю про «в общем». и я считаю, что для джуна нормально «ждать, пока дадут задачи».
а если синьор относится к процессу «не нагрузили — так и не попрошу» и «от работы кони дохнут», как можно рассчитывать на его инициативу в вопросах разработки или сбора требований? «как сказали, так и сделал», «как платят, так и работаю» и прочие прелести.
а не лично тебе приятно
прости, чувак, я высказываю собственное мнение. на форуме.
если интересно послушать мнение СЕО и ответы «от лица фирмы» — не по адресу.
вы ща говорите про конкретную ситуацию или «в общем»?
в общем
а если синьор относится к процессу «не нагрузили — так и не попрошу» и «от работы кони дохнут», как можно рассчитывать на его инициативу в вопросах разработки или сбора требований? «как сказали, так и сделал», «как платят, так и работаю» и прочие прелести.
тут два варианта либо его такого и наняли что ему ничего не надо и тогда вопросы к собеседователям нафига они такие нужны, либо ему отбили инициативу, тогда вопросы к непосредственному начальству, ни с того, ни с сего инициатива иссякнуть не могла

у меня нет вопросов. вы считаете, что ситуация нормальна. я с этим не согласен и мне в нашем обсуждении пофиг, кто «виноват»

Например когда дают тестовое задание, дают сроки — я делаю его быстрее в 10 раз чем надо, как поступить?
Это довольно редкий случай. Здесь следует понимать, что «ждать дедлайна и отправить потом» = соврать. Это как минимум непрофессионально.

Интересное мнение, я как то об это не думал. Я предполагал что давая задание в компании ориентируются на скорость работы своих сотрудников, и если ты примерно работаешь в том же темпе — то более подходящая кандидатура, ежели выскочка или копуша.

выскочка или копуша
Это зависит от самого человека. Если сотрудник не хвалится своей мегаскоростью, то его никто и не будет считать выскочкой. Разве он виноват, что такой умный и быстрый?
«ждать дедлайна и отправить потом» = соврать. Это как минимум непрофессионально.
врать — это плохо, а не непрофессионально, да и с подходом, что отправить потом это соврать далеко не уедешь, вообще не понимаю кто там на время ориентируется, дают неделю с расчетом на то что человек работает и ему особо делать задание некогда, как будет время так и сделает, а не скорость замерить, скорость в офисе замеряют

Дякую автору за статтю. Дуже цікаво і пізнавально.

Якщо можна питання : Як сприймаються «ініціативні овертайми» під час випробувального терміну? Наприклад : новачок розуміє, що не встигає виконати поставлену задачу, або відчуває, що потрібно більше часу аби розібратися в проекті, залишається в офісі поза робочим часом або взагалі приходить в офіс на вихідних (якщо він звичайно відкритий). Звичайно, без вимоги додаткової оплати за витрачений час.
Дякую.

По своему опыту джунства могу сказать, что начальство положительно относится к тому, что человек хочет поработать вечером или на выходных. Но важно, чтобы это было чистосердечное решение, а не только лишь желание понравиться. И ещё лучше, если после таких «посиделок» на выходных к понедельнику будет какой-нибудь, пусть и маленький, но результат. Тогда начальник посмотрит и подумает про себя — «О, да этот парень реально конвертирует время в таски, да ещё и бесплатно. Идейный. Хорошо».

ну, надо еще себе рекламу давать. про овертаймы, о которых никто не узнает, никто не узнает. ваш КО :)

этот парень реально конвертирует время в таски, да ещё и бесплатно
А разве овертаймы не оплачиваются в двойном размере?

Я таких не видел, но слышал, что они в теории бывают.
Как и программисты в Минске, что $10K в месяц зарабатывают. Правда их никто не видел, но рассказывают, что слышали о таком. Как суслики.

Ну я видела такие конторы)
И это хорошо. Потому что, в таком случае, работодатель будет стараться адекватно спланировать работу, не надеясь на овертаймы.

П.С. Понятия не имею сколько получают программисты в Минске

Средняя $1.5K.
Ты видела таких, что умеют планировать, а не работают по принципу «Надо вчера». Тебе повезло — это редкость.

Обычно, начальник вбегает с криком «Просрали все полимеры» и затем «Будем работать на выходных». Понятно все вышестоящее начальство в курсе и положительно оценивает деятельность такого начальника. Да, если ты откажешься, то на тебя начальство косо посмотрит. Но есть и этого решение, надо сказать начальнику: «теща срочно рожает, а мне роды принимать надо». И все тебя понимают и сочуствуют и ты освобождаешься от трудовой повинности.

Бывало что не вкладывались в сроки, но это были исключения.

Тебе повезло — это редкость.
буду знать.
Я таких не видел, но слышал, что они в теории бывают.
прям конторы-конторские тоже не видел.
зато видел отдельные проекты.
аргументы(графоманский трактат, ха ха ха)
причины бывают разные:
1. исполнитель профакапил с планированием и ради сохранения клиента готов платить из своего кармана(когда берут в проект, называют малореальные сроки, но соблазняют баблом — обычно, такая ситуация).
2. клиент профакапил с планированием или анализом рынка(если рыночный продукт), готов платить много(ради призрачного «срубить куш») и искренне считает, что «9 женщин родят ребенка за месяц» — мол, доберем кучу людей, и за полтора.
3. такая хитрая система мотивации, мол, овертаймишь — значит, работаешь больше — значит, стараешься — на тебе, печеньку. но про такое как раз реально не слышал :)

так вот, мне представляется маловероятной, чтоб вся компания(не важно, аутсорс или продукт — есть разделения на отделы-команды) работала по схеме 1 или 2. слишком много бабла всем подряд платить по повышенному рейту, даже если не требуется такое «самопожертвование».
и не эффективно это в среднесрочной перспективе. зато провоцирует симуляцию работы: «а что, я ж в субботу выходил, давайте деньги мне».

много бабла всем подряд платить по повышенному рейту
Во-во.

Овертаймы о которых идет речь — это именно «волонтёрские часы». И это больше относится к джунам, чем к мидлам и сеньорам. Было бы дико представить себе джуна, который ничего толком не умеет, но уже за овертаймы получает двойной тариф.

это именно «волонтёрские часы»
В таком случае согласна
Як сприймаються
ким саме сприймаються?
менеджером? колегами? замовником?
зазвичай сприймається, як належне. при чому тут не лише про тих, що на випробувальному.
можливо, є такі, що відсутність овертаймів сприймають як лінощі. не можу знати напевно — ви назвіть ПІБ конкретної особи. можливо, хтось знає.

Скажімо менеджером і колегами. Замовник наврядче дізнається, про такий інцидент, принаймні мені так здається, я можу помилятися.

Вибачте, ПІБ особи назвати не можу:)

вибач за іронію. я мав на увазі, що це сугубо особисте.
можуть навіть сприйняти негативно. не в плані «дурень! нащо?», а в плані «краще б попередив, а я б тебе відмовив» — у овертаймів насправді досить багато негативних побічних ефектів. тож і колеги, і менеджер можуть бути не задоволені.
але не спробуєш — не дізнаєшся :)

Один из побочных эффектов — выгорание.

Перепрошую, забув про маленьку деталь — в цьому випадку швидше нечасті овертайми, наприклад 2-3 на місяць максимум. Тому, що якщо програміст постійно овертаймить по власному бажанню то тут два варіанти : або йому дуже проект подабається (або просто фанатик своєї справи) або у нього дійсно проблеми, що вже погано.

Є ще чудовий варіант коли людина овертаймить як проклята кілька тижнів поспіль і кожен день чи тиждень видає потрібний результат. Це значить що вона взялась з самого початку за завдання, що їй не по зубах, але докладає надзусиль і виконує роботу вчасно. Скоріш за все її навички за ці тижні виростуть суттєво. Але тут по-перше треба вчасно зупинити такого фанатика :) Бо психологічне виснаження ніхто не відміняв. А по-друге треба переконатись, що це не шкодить його сімейним стосункам, бо тоді буде гірше усім.

Перепрошую, не зрозумів спочатку про іронію.

Спробувати можна, але питання : Чого мені такий експеримент коштуватиме? Якщо сприймуть негативно — це може коштувати роботи, в крайньому випадку. З іншої сторони невиконана вчасно задача на випробувальному терміні так само може коштувати роботи.

Вибачте, це вже мене у роздуми понесло:)

Якщо сприймуть негативно — це може коштувати роботи, в крайньому випадку
та ну. це як «жарти можуть коштувати мені роботи». якщо будуть претензії — майже напевно озвучать. навіть якщо змовчать, я не уявляю, до чего треба дойти з овертаймами, що це стало причиною звільнення.
З іншої сторони невиконана вчасно задача на випробувальному терміні так само може коштувати роботи.
не знаю.
якщо брали як сіньора, а людина навіть сама код нормально писати не може — мабуть.
про який рівень(задачи, відповідальність) мова?

Наприклад рівень мідл дев. Задачі, як для новенького — нічого особливо критичного, що варто було б давати досвідченим людям на проекті.

в таком случае не выполненная работа в первый раз — повод для подколок :)
во второй раз — подспорье для анализа. «ну, как же так?» и поиск системных проблем.
в третий раз — лучше расходиться, пожалуй.

Главное, чтобы овертаймы не вошли в привычку.
Скорее всего, в командах не очень жалуют овертаймщиков. Особенно если в этом нет такой уж необходимости. И вообще, овертаймы для мидла и сеньора должны быть исключением. Их наличие говорит о том, что хромает планирование задач или что программист забивает на работу, после чего пытается наверстать упущенное и это выливается в овертаймы.
Но вот для джуна на испытательном сроке без овертаймов по-моему никак. По крайней мере вначале.

без овертаймов по-моему никак. По крайней мере вначале
лично мое наблюдение — способность вовремя сказать «ребята, я запнулся, помогите» + «правило 15 минут» намного лучше для результата, чем неделю овертаймить.
если грубо — предсказуемость результата важнее скорости.
если джун(даже джун) ровно попадает в собственные эстимейты, это лучше, чем гений, который раз в неделю непредсказуемо подставляет всю команду, хотя до этого все делал слёту.
«ребята, я запнулся, помогите» + «правило 15 минут» намного лучше для результата, чем неделю овертаймить.
зато овертаймить с рекламой гораздо важнее с точки зрения начальства — у какой старательный и трудолюбивый, берем и неважно что в результате овертаймов выхлоп нулевой, главное начальство знает.
с точки зрения начальства
начальство — это СЕО? так, ему пофиг.
или речь о непосредственном менеджменте?
лично я такого отношения не встречал.
а если б встретил, свалил бы нафиг — наверняка, там и других тараканов хватает.
небось, и качество кода по количеству открытых багов оценивают

Очень много начальников попадают в эту ловушку оценки подчиненных. Я знавал чела, который уходил с работы всегда на 5 мин позже начальника и всегда засвечивался начальнику, когда тот уходил. Чел был на хорошем счету у того начальника — во какой трудолюбивый.

Это камень в огород начальника, раз он не сечёт такое банальное пылепускание в глаза.

А где ты видел людей, что не рады обманывать сами себя?

Нигде. Все рады обманываться в большей или меньшей степени. Да иногда это даже полезно.

а как у него с выполнением задач?
если только рассказывал, а на деле ничего не успевал — разве это не всплывало регулярно?
PS я охотно верю в такое развитие событий, если чё. пытаюсь понять.

Очень часто можно долго дурить мозги начальству, было бы желание, особенно, елси начальство безграмотно.
Грамотному обычно не подуришь.
Знавал еще одного, которые толком ничего не делал, но у него было чутье, когда за повышением к начальству идти. В итоге, конечно он крупно зафейлил и его уволили, но до этого 3 года прошло.
Это я рассказываю самые эффектные случаи, 80% програмеров так обычно не работают — они честно делают свою работу и часто их начальство даже не замечает.

Эпичные вам коллеги попадались, я смотрю )

За 20 лет можно много разного увидеть.

Просто делайте свою работу и не будьте ушлепком. Оставьте пафос на потом.

так статью же тогда не написать

Класна стаття!

Щодо нервів, то інколи допомагає задуматись над тим, що усі колись були джунами. Навіть найматьоріший сеньйор. В більшості випадків люди вас, як початківця, зрозуміють ;-)

Спасибо за статью. Помню себя начинающим VoIP Инженером. Был таким же как написано. Но потом научился всем хитростям. Скоро начинаю все сначала, буду Junior iOS. Так что будем по новой учиться спрашивать :)

Достойная статья, я бы добавил еще несколько советов:
1) Первый испытательный срок (вход в IT) — самое сложное испытание в вашей профессиональной жизни в IT, будьте готовы работать на 100-200%, по вечерам и дома по выходным, чтобы выполнить задания. Потому что объем материала достаточно большой и сроки поджимают. Я не шучу. 30% пришедших со мной неофитов отсеялись именно по этой причине.

2) Несмотря на достаточно плотный график, старайтесь понять откуда дует ветер, кто из будущих коллег более отзывчивые, а каких лучше пока не беспокоить.

3) Никогда не спорьте с senior-ом, лидом, техлидом, начальником отдела или вашим куратором на обучении, просто делайте как они говорят, уточнив что непонятно. Ваша цель сейчас: учиться и делать как говорят по максимуму. Во-первых спорящие trainee это смешно, во-вторых набивать себе очки склочности не есть хорошо. Рядом с senior-ом вы никогда не будете равным в споре, даже не пытайтесь.

4) Составьте себе четкий план, добавьте 30% запаса на redline и следуйте ему. В некоторых организациях выдается scope задач, которые надо сделать скажем за месяц, так вот в начале можно застрять и с треском вылететь. Чтобы такого не случилось, распланируйте себе план работ на месяц, если выбиваетесь из графика — надо работать по вечерам и на выходных, иначе не успеете все сделать.
Допустим 10 задач на 20 рабочих дней. Добавьте 2-3 дня резерва, распишите по 8 часов, принимая во внимание, что следующие задания обычно всегда сложнее.

5) Совет для любого грейда: «Работу надо работать». Не преподносите никому сюрпризов, делайте то, что от вас ожидают, в требуемом объеме и качестве. Недоумение часто переходит в раздражительность, особенно на реальных проектах. Приучайтесь с самого нуля работать правильно. В идеале делать как указано в задании, если не получается, говорить почему сделали по-другому. Но как правило это самое «по-другому» выливается в велосипеды и костыли, после чего задание вполне закономерно не принимается.

Кхм... на счёт 3-го пункта может быть это хорошо работает для программеров, но в моей, сисадминской практике, моя «сеньорита» не послушав меня, мега-джуна по их понятиям — я только пришёл, но таки где-то уже среднего мидла по знаниям, угробила RAID с пачкой AD профилей. Капитан был крайне не рад, хочу я вам заметить, посреди-то оперейшина на другом конце Европы от офиса. Кстати в вопросе восстановления она тоже налажала, но там я уж даже и не лез даже с советами, всё равно не слушали.
Так что нет, спросить может и не нужно, но позволить себе сделать предложение всё таки стоит, а дальше уже пусть «сеньор куратор» сам своей головой думает.

По № 1 — або набрали слабких джунів, або у вас на проекті відверто сумно.

будьте готовы работать на 100-200%, по вечерам и дома по выходным, чтобы выполнить задания.
Не розумію такого — якщо є очікування від джуна, що він має перформити як міддл — беріть міддла або коректуйте очікування.

Я говорил про trainee/джунов на тестовых заданиях или обучении. Имхо миддлу и выше вообще не нужен испытательный срок в традиционном понимании. Ну если человек trainee/junior не может выполнить тестовые задания в срок, то я вижу 2 выхода: работать больше или уходить. На production прикрепляют уже тех, в ком уверены на 80-100%.

Поддерживаю Алексея, даже будучи первый раз на испытательном сроке и сразу приступив к работе на проекте, получалось все и сразу, иногда даже быстрее чем требовалось... Какие-то слабые джуны рядом с вами были

Щира подяка за статтю.

Все верно, но нужно быть готовым к тому, что на вопрос ответа не будет. Человек, воспитывающий специалиста не будет давать готовое решение (ну разве — в дедлайне, и то сомневаюсь), он даст «волшебного пендаля» в нужном направлении. И это правильно, потому, что это путь к профессионализму.

Как пережить испытательный срок
:
1. Працювати, бажано по максимуму, але так щоб тобі було комфортно і щоб ти міг ± підтримувати такий такий рівень.

2. Не бикувати і не випробовувати компанію “на міцність” черезмірно.

Особливо потішила фраза

наш подающий надежды клавиатурный ковбой
та відсилка до фільму “Титанік”.

Задавать вопросы джунам нужно поучится)))) Помню сначала тяжело было правильно ставить вопрос — но потом быстро адаптировался.
Говорить — «не знаю» — нельзя ни в коем случае! Лучше сказать — еще ищу ответ.
Ну и задавать вопросы получится не всегда, так как есть люди, которые не любят обучать джунов.

Лучше сказать — еще ищу ответ.
И так 3 месяца. А тут и срок прошел и не уволили. Можно дальше искать.

если за 3 месяца не нашел ответ, то думаю что уволят))) Дальше искать бесполезно :)

Проверял? Предполагать-то можно много чего.

Смотрел как проверяли )))) Дело то индивидуальное для каждого человека и компании.

Я и грю, главное начальнику понравиться, а там можно искать хоть вечно.

Правильно заданный вопрос — 50% ответа.

Если за 15 минут не удается найти решение, стоит записать или запомнить все испробованные подходы, и только затем идти к старшему. Зачем записывать? Он вас спросит: «А это ты делал?», «Логи смотрел?», «Через другой интерфейс пробовал?». Так вот, чтоб по два-три раза не бегать туда-сюда и не нервировать людей, у которых и так есть своя работа, стоит сделать прошения о гуманитарном кодинг-прибежище максимально эффективными. Подходишь к столу, шаркаешь ножищей по ковру, щелкаешь каблуками и докладываешь — «Так, мол, и так, такой-то такой-то попробовал первое-десятое и застрял. Имею честь просить о помощи».
How To Ask Questions The Smart Way

Желательно уметь формулировать вопросы:
1. они должны быть не слишком длинными
2. если возможно, нужно использовать вопросы на которых можно ответить «да» или «нет»

Не нужно сконцентрироваться на одном коллеге и добивать вопросами. Можно использовать всех коллег, которые теоретически могут помочь. Иногда даже интересно услышать ответ на тот же вопрос от разных людей, потому что решений может быть несколько; и даже если вы используете только одно решение, у вас будет несколько вариантов решения в другой раз.

Я и по сей день нервничаю, если код не работает на продакшене.

Это называется «похер». И это очень плохо, видел, когда людям пофиг на таск или вообще на проект, делают кое-как и вообще не нервничают как это будет работать( яркий пример — последние две недели перед увольнением ).
Как по мне, если ты заинтересован, то в любом случае будешь переживать как работает твой продукт.

Вы путаете теплое с мягким. Работа должна быть работой, а не чем-то из-за чего тебя плющит и в могилу толкает раньше срока.

Частично согласен, нужно не убивать себя, но я не могу представить стартапщика, которому было бы пофиг на свой стартап.

«Пофиг» — это в любом случае плохо. Но умение по-философски относиться к траблам — дорогого стоит. Если проблему можно пофиксить, ты её пофиксишь. Если её нельзя пофиксить, значит нужно искать другое решение. Сможешь найти — найдешь. Не сможешь — попросишь помощи зала. Но каждый раз эмоционировать «все пропало» — губить здоровье.

тада. а если еще при этом и продакшн лежит, то главное не нервничать

Если научитесь, то станете соответствовать любимому критерию HR’ов — «стрессоустойчивость».
Странно, вроде бы все знают истину «только без паники», но как дело доходит до работы, то «без паники» почему приравнивается к «похер».

“Почему прод лежит 2 день?” — s1.developerslife.ru/...c6a3f45610a.gif

это тот самый пм из соседней темы?

Да нет, это то самый джун, что положил прод. Но испытательный срок все равно пройдет (вероятность высока) :)

Так может он тот «прод» и не нужен никому, что 2 дня валяется и никто не поднимает.

Якщо продакшен валиться, бо джуніор тупий — тупий не джуніор ©

Совершенно верно. Мудрые боссы дают джунам менее ответственные задания с возможностью зафакапить.

А ведь это золотая жила для джуна — там, где мидлу было бы уже стыдно спрашивать, у джуна есть фора: ему дозволены самые глупые вопросы.

Тупі питання, на які очікується коротка відповідь повинні задавати і сіньйори. Звісно, мова не про загальні питання, на які відповідь можна за хвилину в гуглі, а про ті що стосуються конкретного проекту чи продукту.
ІМХО, розробник, це не та людина, яка повинна здогадуватись з пів слова і від десятка тупих уточнювальних запитань біди не буде.

хаха! отличная статья и написана легко

Подписаться на комментарии