Чего мне ожидать, если я буду нанят старшим разработчиком, а не младшим разработчиком? [закрыто]

Я был фрилансером и программистом по ночам некоторое время, а недавно меня наняли после нескольких уровней собеседований в хорошей нью-йоркской компании, хотя у меня есть некоторые недостатки в определенных областях. Это обычное дело для компаний нанимать пожилых людей с меньшим опытом? Будут ли они ждать несколько недель, чтобы соблюдать определенную кривую обучения?

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

Кто-нибудь здесь уже получил менее опытного старшего члена в своей команде? Это приемлемо?

Я планирую встретиться с моим боссом, чтобы перестать беспокоиться об этом. Звучит как хорошая идея?

[РЕДАКТИРОВАТЬ]

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

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

1. С опытом разработки программного обеспечения (минимум 3-5 лет),
2. Может работать без постоянного надзора (часто без надзора),
3. Знаком со средой разработки и инструментами,
4. Способный контролировать или обучать младших разработчиков,
5. Способен разрабатывать и реализовывать малые и средние проекты.

Трудно говорить о вашей конкретной ситуации, но обычно, когда вы вступаете в новую команду, вам нужно учиться.

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

Я бы тогда попросил соединиться с существующим старшим разработчиком . Обычно это самый быстрый способ узнать, что ожидается и как все работает. Как они решили эту проблему? Сколько усилий они потратили на юнит-тесты и обзоры? Почему они сделали это так, а не так? Убедитесь, что другой разработчик поможет вам настроить среду разработки и проведет вас через процесс выпуска .

Дайте им понять, что вы знаете язык и инструменты, а не их методы. Например, если вы делали вещи иначе, и думаете, что это лучше, чем они, предварительно и уважительно предложите это.

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

Наконец, осознайте, что вы не поймете полностью большой проект в течение недели, поэтому начните исправлять мелкие ошибки или функции . Убедитесь, что ваш приятель рассматривает их, и вы получите все отзывы. Вы будете скучать по вещам. Вы будете делать ошибки. Ничего страшного. Учитесь у них, не повторяйте их и усердно работайте. Если ты хорош в том, что ты делаешь, ты доберешься до этого.

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

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

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

Я хорошо разбираюсь в математике, физике, алгоритмах, но все же мне нужно узнать обо всех шаблонах, используемых в этой компании.

Это вполне нормально и может занять месяцы. Попробуйте сначала поработать над очень маленькими кусочками приложения, а затем вы узнаете и сможете получить глобальное представление о коде, процессах (это, возможно, так же важно, как о коде), методологии (даже если она не формальная) и т. Д.

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

Становится легче Работая с большой кодовой базой, следует ожидать, что вам понадобится время, чтобы ознакомиться с ее тонкостями. У меня было более десяти часов на работе в ряде компаний, прежде чем я переключился на разработку (чуть более года назад), и у меня все еще есть моменты неуверенности в себе, когда приходится сталкиваться со сложными проблемами или огромными объемами кода (наш код количество базовых строк исчисляется многими миллионами), но я просто продолжаю, оставляю Google, StackOverflow и этот здесь открытый веб-сайт работающим, и я не слишком горжусь, чтобы попросить о помощи. Вы - часть команды, уже не одинокий программист на вашем домашнем столе. Воспользуйтесь опытом и знаниями ваших коллег.

Вас наняли после нескольких уровней собеседований , это означает, что они сделали осознанный выбор, наняв вас. Будь крутым, ты получил работу. Это означает, что уже есть уровень доверия к вашим способностям, и вы уже некоторое время программируете. У тебя все будет хорошо.