Denis_m1stЧего не хватает в документе?


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

Какие ресурсы Вам помогли в поиске работы и ее продвижению?


Хорошее образование, выступления на профильных конференциях.

Как Вы добились успеха на работе?

Э, работал, а как еще?

Denis_m1st"ВМЕСТО ВСТУПЛЕНИЯ", 3 параграф.

Хм, это как раз хороший пример того, чем вменяемый senor отличается от junior. Сеньору не надо объяснять, почему третий параграф бессмысленен и непрактичен.
Как, собственно, и весь документ.

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

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

Ну, например, я на одну и ту же (высокооплачиваемую) позицию зачастую предпочту вчерашнего студента (формально - джуниора), нежели человека с 10летним опытом работы в EPAM (по всем признакам - сеньора).

DPH3Э, работал, а как еще?

Denis_m1stБольше интересуют "истории успеха".

А какого типа истории успеха? Работал в одном месте, потом в другом месте, потом в третьем месте и т.д. На каждом месте узнавал что-то новое (и я не про технологии). Потом почти перестал быть сеньором и стал больше тим-лидом. Ну и что это даст - если изначально в описании "траектории развития" выбраны неправильные ориентиры и параметры?

_newcomer_1. Знаю нескольких людей там работающих, чем они вас так не устраивают? :)

Просто работа в "рабофабриках" (EPAM, Luxsof и иже с ним) довольно специфическая. Редко требуется качество кода, предпочтение к сверхнавороченным фреймворкам, любовь к "разработке на XML". Это имеет смысл с точки зрения бизнеса аутсорсера, но плохо совместимо с продуктовой разработкой, например.
Просто работа в подобных компаниях дает существенный отпечаток на работника. Ну и синдром "без подробного ТЗ ничего делать не буду" - тоже часто встречается у сотрудников из подобных мест. А во многих моих проектах навык самостоятельной работы весьма существенен.

_newcomer_2. А чего, там кто-то 10 лет задерживается? :)

Воот... Если человек задерживается в EPAM - то значит у него нет стимула к росту, например. Или что-то еще )

забыл никDPH3 Ну и синдром "без подробного ТЗ ничего делать не буду"
Вообще, довольно разумная практика.

Смотря для чего. Если нужно выкачать с клиента побольше бабла - то разумная.
Если нужно сделать продукт за минимальные сроки и с максимальным результатом - то идиотская. Я обычно предпочитаю продукт делать. А по подробному ТЗ пусть кодогенераторы работают, они для того и придуманы.

P.S. Вообще задача оптимального выбора уровня детализации постановки - весьма нетривиальна и для каждого проекта/команды должна определятся отдельно. Но вот только уровень детализации не должен зависеть только от капризов разработчика, там хватает и других критериев. И сеньор должен уметь работать с нечеткими задачами, иначе какой он сеньор )