Здравствуйте, Lazy Bear, Вы писали:
LB>$>проблема с синьерами обычно в том, что их код плоховат в плане скорости, дизайна и надёжности
LB>Кто ж тогда пишет нормальный код? Никто?
В отрыве от конкретной компании ничего не значит. Это просто ярлыки. Как этими ярлыками пользоваться — каждый решает по-своему, каких-то стандартов тут нет. Где-то это лычка, чтобы платить меньше денег/привязать сотрудника к компании. Где-то это просто часть табели о рангах, согласно которой будет назначаться зарплата и прочие плюшки. То же и с обязанностями, где-то разницы никакой не будет, где-то будут назначаться конкретные обязанности.
Если говорить о том, как мне хотелось бы видеть это разделение, я разделяю общую точку зрения: за джуниором надо смотреть, за миддлом смотреть не надо, но задачи ему всё равно выдают конкретные и не со всеми он может справиться, синьор делает любую задачу с любой постановкой, при необходимости делегируя части на миддлов и джуниоров.
G>Джуниор — не может решать задачи самостоятельно, может писать код по готовым примерам (копипастить с испралением имен функций и переменных)
Что-то слишком низкая планка.
ИМХО, способный джун может решить практически любую задачу (если не обращать внимания на сроки и качество).
По моему скромному опыту проблема с дужунами обычно в том, что их код плоховат в плане дизайна и надёжности (гонки, утечки ресурсов). Ещё бывает, что они вместо поиска подходящей функции в используемых библиотеках пишут свои велосипеды. Вообще, быстро решить задачу, выдав на гора кучу кода одним коммитом — это у них запросто.
Здравствуйте, prakop, Вы писали:
>> До Facebook у меня не было опыта, кроме стажировок, и путь от junior до senior занял два года. >> ... >> Мой приятель перешел с junior на senior за полтора года, так что быстрое продвижение возможно, как и медленное. P>Я думал что с такой скоростью выдавать лычки способны лишь СНГ-шные галеры (индуские, может и ещё быстрее, но там не работал). P>Что для вас значит Senior? Опыт работы? Способ платить больше ценному сотруднику, т.к. зарплата привязана к Level-у? Что-то ещё? Или может Senior уже давно ничего не значит?
Так быстро выдают лычки галеры, которые раскиданы по разным странам. Бывает так, что некто с 5ю годами опыта в одной стране не может справиться с задачей, которую в другой стране решает студент.
По уму надо вводить не сеньорства, а градации вида 1, 2, 3, 4...n и ориентироваться на определенные качественные признаки.
Сеньор это вобщем естественное выделение старшего сотрудника. Этот подход есть практически в любом коллективе, будь то медики, инженеры или бухгалтеры.
За наполнение отвечает сама контора, но в целом конторе обычно выгодно идти в ногу с рынком.
Все это сильно условно, т.к. стандарта от индустрии пока нет. Есть несколько различных фремворков + каждая контора вводит отличия самостоятельно.
В мелких конторах/подразделениях границы размыты, в крупных — четко обозначены.
Из моего опыта обычно так
Джун это сотрудник который осваивает технологию, разработку, коммуникацию. Опыт от 0 до года.
Мидл — поглощает рутину, пилит 80% фич и багов. Основная роль — линейный разработчик. Опыт от 1 года до 4х лет. Критический скил — умение кодить и знать основной фремворк.
На мой взгляд сеньор это от 4 лет фулл-тайм опыта на конкретно взятом стеке в продакшне. Есть конторы где сеньоры это уже 1-2 года опыта. На мой взгляд это неадекватная попытка выдавить бОльшие рейты у заказчика.
Сеньоры это все позиции начиная с Сеньор и заканчивая тимлидами, лид-девелоперами, принсипалами, чифами и тд.
Сеньор — отвечает за остальные 20% фич, имеет выделеную зону ответственности, в которой определяет правила — дизайн, подход к тестированию, структуру и тд. Так же сеньор может являться ситуационным руководителем, например, для реализации сложной фичи может взять двух мидлов. Основная роль — Key Developer. Кроме того, помогает архитектору внедрять архитекуру приложения. Соответсвенно у сеньора коммуникация это уже критический скилл, технический — проектирование среднего уровня. Должны быть оба этих условия.
Дальше складывается по всякому — Сеньор может перейти в тим-лида, или двигаться в направлении архитектора. Эти две позиции обычно называются как попало. Чаще всего так — Team Lead и Tech Lead(условно, т.к. часто так называют и тим-лида). Разница между ними в соотношении времени на технические и менеджерские активности. Примерно 1/2 и 2/1. Соответственно, один растет в менеджера, другой растет в архитектора.
При этом Tech Lead так же является маленьким менеджером, например, тащит небольшой стрим, т.ч. часть команды, но занят в основном техническими вопросами. Он же обычно является маленьким софтваре архитектором для конкретно взятого приложения. Не всего проекта, а той малой части, что лежит на команде. Вклад в фичи и баги у него небольшой, он занят более масштабными вещами. Team best practices лежат на нём.
Далее обычно переход архитекторы, но могут быть и всякие Chief Developer, Principal и тд. Это тоже сеньорские позиции. В разных конторах тут может быть вообще все что угодно. Обычно это уже Technology best practices, Technology Expert и тд.
Архитектор, имеется ввиду выделеный, уже не сеньор — это менеджерская позиция.
Здравствуйте, RedUser, Вы писали:
G>>Джуниор — не может решать задачи самостоятельно, может писать код по готовым примерам (копипастить с испралением имен функций и переменных)
RU>Что-то слишком низкая планка. RU>ИМХО, способный джун может решить практически любую задачу (если не обращать внимания на сроки и качество). RU>По моему скромному опыту проблема с дужунами обычно в том, что их код плоховат в плане дизайна и надёжности (гонки, утечки ресурсов).
Это только джун- суперстар, который через 3-5 лет станет тимлидом. А так, типичный джун вообще нихрена не может, ждёт, чтобы ему сказали, откуда куда скопипастить. Типичный синьер может решить несложную задачу. проблема с синьерами обычно в том, что их код плоховат в плане скорости, дизайна и надёжности (фейспалмы от bigO, гонки, утечки ресурсов). Мидл- может не только копипастить, но всё ещё ждёт помощи от синьера.
Здравствуйте, Ikemefula, Вы писали:
AG>>Сразу уточним — специалист с 5-ю годами может, но не хочет (за эту оплату) справляться с этой задачей.
I>Телепатия или это ты про себя пишешь Уровень специалиста определяется прежде всего образованием. Вот здесь во многих странах провал ниже плинтуса. Это факты.
I>Отсюда ясно, почему одному крайне затруднительно писать простенький многозадачный код, а у другого это получается само собой.
I>Более того — даже безо всякой многозадачности у одного мешанина в которой чорт ногу сломит, обилие багов и отсутствие результата месяцами, а у другого внятная структура, ожидаемый результат и адекватные сроки — недели вместо месяцев.
AG>>У студента же — горят глаза и он готов сделать просто за так! Просто чтобы доказать своё рвение и способности. AG>>Тем более — за еду...
I>В разных странах уровень образования разный, ЗП отличается в разы.
I>Простой пример — в одном университете есть курс типа "Алгоритмы и структуры данных" или его эквивалент, а в другом — нет. Опаньки!
Если человек работает программистом (а не просто кодером), он алгоритмы_и_структуры, паттерны_проектирования, сетевые_протоколы, базы_данных и т.д. — использует практически ежедневно.
В этом случае, если такого именно курса в универе не было, то освоить его самостоятельно — когда возможно пользоваться и литературой, и интернетом, и подсказками коллег —
достаточно просто. Даже намного проще чем в универе, где человек часто не понимает ответ на вопрос "для_чего_это_нужно"?
Более того, только человек не умеющий мыслить — не сможет освоить нужную ему профессиональную тему. Но такой и после универа в программерах долго не задержится.
Именно поэтому свежего выпускника на собеседовании спрашивают об изученном в универе, а вот опытного специалиста — уже о том, что было освоено самостоятельно.
P.S. Мы вообще-то начали разговор о решении задачи.
Но ты, уважаемый земляк, свёл тему к знаниям университетского курса, забыв, что решение задачи — понятие комплексное.
Это не зачет, не экзамен, не лабораторка...
Здравствуйте, RedUser, Вы писали:
G>>Джуниор — не может решать задачи самостоятельно, может писать код по готовым примерам (копипастить с испралением имен функций и переменных)
RU>Что-то слишком низкая планка. RU>ИМХО, способный джун может решить практически любую задачу (если не обращать внимания на сроки и качество). RU>По моему скромному опыту проблема с дужунами обычно в том, что их код плоховат в плане дизайна и надёжности (гонки, утечки ресурсов). Ещё бывает, что они вместо поиска подходящей функции в используемых библиотеках пишут свои велосипеды. Вообще, быстро решить задачу, выдав на гора кучу кода одним коммитом — это у них запросто.
Вот поэтому они и джуны. Известно, что один джун каждый год создает 2-3 новых рабочих места. За это им большое человеческое спасибо!
Здравствуйте, prakop, Вы писали:
P>Что для вас значит Senior? Опыт работы? Способ платить больше ценному сотруднику, т.к. зарплата привязана к Level-у? Что-то ещё? Или может
Senior в рамках большой компании (если ты не великий гуру) — это способность к маркетингу себя. Тебя должно быть везде видно, ты должен много говорить на митингах, задавать много вопросов. Должен делать пул-реквесты в проекты, которые видно всем.
Здравствуйте, Larvef, Вы писали:
L>Здравствуйте, prakop, Вы писали:
P>>Что для вас значит Senior? Опыт работы? Способ платить больше ценному сотруднику, т.к. зарплата привязана к Level-у? Что-то ещё? Или может
L>Senior в рамках большой компании (если ты не великий гуру) — это способность к маркетингу себя. Тебя должно быть везде видно, ты должен много говорить на митингах, задавать много вопросов. Должен делать пул-реквесты в проекты, которые видно всем.
Это скорее про PM-а, нежели насчёт разработчика Senior-а.
На самом деле — сеньору маркетинг себя не очень важен. Его заметят даже и без этого.
Вот менеджер проекта — это как раз тот, кто должен много говорить на митингах.
Здравствуйте, Larvef, Вы писали:
P>>Что для вас значит Senior? Опыт работы? Способ платить больше ценному сотруднику, т.к. зарплата привязана к Level-у? Что-то ещё? Или может
L>Senior в рамках большой компании (если ты не великий гуру) — это способность к маркетингу себя. Тебя должно быть везде видно, ты должен много говорить на митингах, задавать много вопросов. Должен делать пул-реквесты в проекты, которые видно всем.
Не совсем понятно, при чем здесь сеньор? В каждой области деятельности, если есть более одного человека рано или поздно появляется старший. Старший научный сотрудник, старшая медсестра, старший солдат-сержант-лейтенант, старший администратор, старший инженер и тд.
Это было всегда и во все времена. Даже подмастерья и мастера были младшими и старшими В колхозе и то есть старшие — старший пастух, старший полевод. Скажу страшное — и старший разнорабочий
Качественные признаки взде немного разные, но в целом, это уже работа не на себя, а на команду. И ответственность не только за свою работу, но и за работу других людей.
То есть, сеньор это просто старший инженер, от него ожидается, что он уже освоил основные подходы, технологии и тд, обладает достаточным опытом, что бы отвечать за некоторый участок работ.
Соответсвенно можно ожидать, что сеньор будет проводить собеседования, может супервайзить, менторить и даже брать на себя ситуационную роль руководителя. А в целом от него требуется коммуникация и проектирование среднего уровня.
Это не значит, что сеньор знает всё, умеет всё, бегает быстрее пули и стреляет лучше снайпера
Есть неочевидные парадоксы — продуктивность сеньора на рядовых фичах, коих в проекте около 80% обычно снижается по сравнению с мидлом.
Здесь нет ничего удивительного — наибольшая продуктивность в тех вещах, которые
1 человек выполняет чаще всего
2 осознанно тренирует
Поскольку сеньор перешел от строгания рядовых фич к проектированию и коммуникации, то и продуктивность надо мерять именно на этих вещах, а не на рядовых фичах.
Здравствуйте, prakop, Вы писали:
P>Что для вас значит Senior?
Джуниор — не может решать задачи самостоятельно, может писать код по готовым примерам (копипастить с испралением имен функций и переменных)
Мдил — может решать задачи самостоятельно, если решение задачи нельзя нагуглть за 15 минут
Сеньор — может решать задачи самостоятельно, могут видоизменить задачу для более удачного решения если достигаются те же цели, могут обучать джуниора и миддла.
К грейдам\разрядам и оплате относится опосредованно. Потому что человек может быть сенором в одном языке\технологии, и джуном в другом.
Это зависит скорее даже не от того, сколько вы знаете, а о того, сколько вы готовы взять на себя ответственности за большие проекты, как вы можете общаться с людьми, работать с другими командами, строить взаимоотношения, договариваться, идти на компромиссы. В большей степени это soft skills.
Есть разные архетипы. Некоторые люди самостоятельно создают сложные фичи, но у меня такого не было. Мне больше нравится общение с людьми, совместная работа, задавание пути развития продукта.
Мой архетип — гибрид между product manager и инженером, хотя в большей степени я инженер. У всех людей путь проходит по-разному, но у нас есть внутреннее правило:
Здравствуйте, Ikemefula, Вы писали:
I>Так быстро выдают лычки галеры, которые раскиданы по разным странам. Бывает так, что некто с 5ю годами опыта в одной стране не может справиться с задачей, которую в другой стране решает студент.
Сразу уточним — специалист с 5-ю годами может, но не хочет (за эту оплату) справляться с этой задачей.
У студента же — горят глаза и он готов сделать просто за так! Просто чтобы доказать своё рвение и способности.
Тем более — за еду...
Здравствуйте, $$, Вы писали:
I>>Вот пример: http://blogs.rsdn.ru/ikemefula/7422412
>Зачем далеко ходить- тут у пол форума полыхали ануса на кложуру. При этом все себя считают синьорами помидорами.
> До Facebook у меня не было опыта, кроме стажировок, и путь от junior до senior занял два года. > ... > Мой приятель перешел с junior на senior за полтора года, так что быстрое продвижение возможно, как и медленное.
Я думал что с такой скоростью выдавать лычки способны лишь СНГ-шные галеры (индуские, может и ещё быстрее, но там не работал).
Что для вас значит Senior? Опыт работы? Способ платить больше ценному сотруднику, т.к. зарплата привязана к Level-у? Что-то ещё? Или может Senior уже давно ничего не значит?
Здравствуйте, bnk, Вы писали:
vsb>>синьор делает любую задачу с любой постановкой.
bnk>Как-то это немного экстремально bnk>Известный пример: 7 красных линий.
Ну выполнимую задачу, конечно, в рамках своего отдела и каких-то разумных возможностей.
Здравствуйте, VladiCh, Вы писали:
VC>Здравствуйте, prakop, Вы писали:
>>> До Facebook у меня не было опыта, кроме стажировок, и путь от junior до senior занял два года.
VC>Это специфика Фейсбука, там все Software Engineer. Есть конечно внутренний ранкинг от E3 до E9, но title у всех один.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, prakop, Вы писали:
P>>Что для вас значит Senior? G>Джуниор — не может решать задачи самостоятельно, может писать код по готовым примерам (копипастить с испралением имен функций и переменных) G>Мдил — может решать задачи самостоятельно, если решение задачи нельзя нагуглть за 15 минут G>Сеньор — может решать задачи самостоятельно, могут видоизменить задачу для более удачного решения если достигаются те же цели, могут обучать джуниора и миддла.
Ну да, согласен. Сеньор должен быть способен самостоятельно решать задачи уровня бизнеса (спроектировать и реализовать фичу), а не уровня кода, в том числе и нечетко сформулированные заказчиком.
Кстати у тебя лычка MVP в подписи что-то не кликается?
Здравствуйте, vsb, Вы писали:
vsb>В отрыве от конкретной компании ничего не значит. Это просто ярлыки. Как этими ярлыками пользоваться — каждый решает по-своему, каких-то стандартов тут нет. Где-то это лычка, чтобы платить меньше денег/привязать сотрудника к компании. Где-то это просто часть табели о рангах, согласно которой будет назначаться зарплата и прочие плюшки. То же и с обязанностями, где-то разницы никакой не будет, где-то будут назначаться конкретные обязанности.
vsb>Если говорить о том, как мне хотелось бы видеть это разделение, я разделяю общую точку зрения: за джуниором надо смотреть, за миддлом смотреть не надо, но задачи ему всё равно выдают конкретные и не со всеми он может справиться, синьор делает любую задачу с любой постановкой, при необходимости делегируя части на миддлов и джуниоров.
Не, делегирование это больше к руководству относится. Часто сеньёоры в какой-то степени руководят. Но бывают случаи, что человек очень толковый, но подпускать его к джуниорам нельзя, всех распугает. Обычно такое происходит с очень требовательными, конфликтными, либо просто не общительными людьми. Но по всем остальным параметрам они уже давно не мидлы.
Мне так не кажется.
RU>>ИМХО, способный джун может решить практически любую задачу (если не обращать внимания на сроки и качество).
AVV>подразумевает отсутствие
RU>> код плоховат в плане дизайна и надёжности (гонки, утечки ресурсов).
AVV>если сервис постоянно вылетает по аут оф мемори или не работает изза гонки потоков, какое ж это решение задачи
Если постоянно не работает, то да, тут всем видно, что плохое.
Но оно вполне может на первый взгляд работать. Проблемы будут только иногда. Например, два клиента одновременно прислали запрос определённого типа. Или что-то размером побольше, чем обычно.
Вообще, далеко не везде и не всегда планка качества высокая. Ну, упало, рестартнётся, делов-то.
Здравствуйте, prakop, Вы писали:
P>Что для вас значит Senior? Опыт работы? Способ платить больше ценному сотруднику, т.к. зарплата привязана к Level-у? Что-то ещё? Или может Senior уже давно ничего не значит?
Ничего особо не значит. Где то это вариант забесплатно мотивировать работника "сейчас мы тебе поднимать зарплату не будем, зато дадим тебе новую лычку" — и все довольны. В бодишопах другая мотивация — сеньора можно продать подороже. На мой взгляд, только уровень компенсации/зарплаты говорит о твоей значимости, все остальное обычные психологические уловки что бы меньше платить.
Здравствуйте, $$, Вы писали:
LB>>Кто ж тогда пишет нормальный код? Никто?
$>Как много синьёров могут пройти в Гугл? Но кто-то проходит. Вот они пишут нормальный код.
Критерии найма в больших конторах покрыты тайной. Факт работы в гугле и других больших конторах никак не гарантирует качества. Так что мимо.
Например, моя большая контора аутсорсит один из компонентов системы в другую большую контору. Надежность работы их поделия? Ха-ха два раза.
Здравствуйте, Lazy Bear, Вы писали:
LB>Критерии найма в больших конторах покрыты тайной.
Это не секрет, если поискать
LB>Факт работы в гугле и других больших конторах никак не гарантирует качества.
Сперва пройди в гугл.
Здравствуйте, AlexGin, Вы писали:
I>>Так быстро выдают лычки галеры, которые раскиданы по разным странам. Бывает так, что некто с 5ю годами опыта в одной стране не может справиться с задачей, которую в другой стране решает студент.
AG>Сразу уточним — специалист с 5-ю годами может, но не хочет (за эту оплату) справляться с этой задачей.
Телепатия или это ты про себя пишешь Уровень специалиста определяется прежде всего образованием. Вот здесь во многих странах провал ниже плинтуса. Это факты.
Отсюда ясно, почему одному крайне затруднительно писать простенький многозадачный код, а у другого это получается само собой.
Более того — даже безо всякой многозадачности у одного мешанина в которой чорт ногу сломит, обилие багов и отсутствие результата месяцами, а у другого внятная структура, ожидаемый результат и адекватные сроки — недели вместо месяцев.
AG>У студента же — горят глаза и он готов сделать просто за так! Просто чтобы доказать своё рвение и способности. AG>Тем более — за еду...
В разных странах уровень образования разный, ЗП отличается в разы.
Простой пример — в одном университете есть курс типа "Алгоритмы и структуры данных" или его эквивалент, а в другом — нет. Опаньки!
Что бы это чем то компенсировать, необходимо сознательно потратить на самообразование сравнимое количество времени,а скорее всего намного бОльшее. По факту получаем обычную картину — мало кто этим занимается. Более того, все этогт зависит от культурных особенностей.
Скажем, ощущение, что в СНГ и вообще бывший СССР подход "мне все должны" — дайте работу, дайте зп, заинтересуйте, обеспечьте жильём и тд.
Итого, получается так — за 5 лет только небольшой процент удосуживается хотя бы почитать про алгоритмы. Соответственно в норме обилие ошибок на ровном месте в тривиальных алгоритмах типа фильтра, группировки на линейных структурах.
Соответсвенно, за 5 лет это никак не улучшается, более того — становится хуже, т.к. база то отсутствует. То есть, проваливаться можно до бесконечности.
Следствие — на более менее сложных задачах, типа реализации несложного протокола оба кандидата худо-бедно справляются. А если задача усложняется, то из за обилия детских ошибок у одного, и отсутстия таких ошибок у другого игра идет в одни ворота.
Аналогично картина обстоит и с другими вещами. У одни ООП это управление сложностью решений, парадигма решения задач, у других — "три кита". Вторые гарантировано не понимают ООП, потому что все задачи пытаются решать наследованием. Не от куда наследоваться — фейл, и дальше идет простыня безо всякой структуры. Есть фремворк — худо бедно еще можно чего то в лоб делать. Нету фремворка — адская пропасть между первыми и вторыми.
Следствие — задача спроектировать АПИ для модуля/системы получается у одних, и не получается у других.
Аналогично и с функциональным программированием. У одних легко заходит функциональщина, в других хорошо если колбек получится передать, и то не всегда.
Здравствуйте, Ikemefula, Вы писали:
I>Аналогично и с функциональным программированием. У одних легко заходит функциональщина, в других хорошо если колбек получится передать, и то не всегда.
I>Вот пример: http://blogs.rsdn.ru/ikemefula/7422412
Зачем далеко ходить- тут у пол форума полыхали ануса на кложуру. При этом все себя считают синьорами помидорами.
Здравствуйте, AlexGin, Вы писали:
I>>В разных странах уровень образования разный, ЗП отличается в разы.
I>>Простой пример — в одном университете есть курс типа "Алгоритмы и структуры данных" или его эквивалент, а в другом — нет. Опаньки! AG> AG>Если человек работает программистом (а не просто кодером),
Программист и кодер это одно и то же. Просто тебе почему то удобно называть так своих коллег.
>он алгоритмы_и_структуры, паттерны_проектирования, сетевые_протоколы, базы_данных и т.д. — использует практически ежедневно.
Необязательно. Чтото одно — часто, а другое — может и раз в год. Для развития "раз в год" недостаточно.
У одного много задач тривиальных, у другого — мало, но сложных. Тривиальных задач для развития недостаточно.
На самом деле проекты можно вписать в некоторый куб — цена ошибки, степень востребованности компьютер саенса, трудоемкость.
Например, вагон проектов, где цена ошибка низкая, компьютер саенса почти нет и трудоемкость хорошо если неделями.
Люди на таких проектах развиваются совсем не в технологиях, и совсем не программировании.
Есть проекты, где цена ошибки высокая. Здесь люди качаются в процессах, документировании и тд.
Если компьютер саенс востребован, например, обработка видео, то очевидно, здесь развитие будет именно в этих алгоритмах, и то, только у тех, кто непосредтсвенно их майнтейнит.
AG>В этом случае, если такого именно курса в универе не было, то освоить его самостоятельно — когда возможно пользоваться и литературой, и интернетом, и подсказками коллег — достаточно просто.
Факт в том, что только небольшой процент занимается самообразованием.
AG>Более того, только человек не умеющий мыслить — не сможет освоить нужную ему профессиональную тему. Но такой и после универа в программерах долго не задержится.
Слишком категорично, что бы можно было хоть как то использовать на практике. См выше.
Более того, даже в одном направлении градаций слишком много.
Не один черное-белое типа "умею думать — не умею" , а гораздо больше.
Например,
Простые задачи, где все гуглится
Задачи посложнее, где надо придумывать по схеме
Еще посложнее, где схема неопределена
Еще сложнее, где до кучи и результат неопределен
Еще сложнее, где еще и условие неопределено
AG>Именно поэтому свежего выпускника на собеседовании спрашивают об изученном в универе, а вот опытного специалиста — уже о том, что было освоено самостоятельно.
Какое еще собеседование? Алё — я про разницу в результатах на проекте.
AG>P.S. Мы вообще-то начали разговор о решении задачи.
А ты, нечитатель Пример то посмотри по ссылке в моем предыдущем сообщении.
AG>Но ты, уважаемый земляк, свёл тему к знаниям университетского курса, забыв, что решение задачи — понятие комплексное. AG>Это не зачет, не экзамен, не лабораторка...
Именно с этого я и начинал — с реальных проектов, а не каких то абстрактных собеседований или проверки зазубреных знаний.
Здравствуйте, RedUser, Вы писали:
RU>Ещё бывает, что они вместо поиска подходящей функции в используемых библиотеках пишут свои велосипеды. Вообще, быстро решить задачу, выдав на гора кучу кода одним коммитом — это у них запросто.
Походу, я джун!
Не сказать, чтобы я был сильно расстроен Потому что какие-то велосипеды всё-таки кто-то в мире делает первым. Почему бы не я? Не боги велосипеды обжигают. И про кучу кода тоже не совсем понятно... вспоминая "ислам" — если у вас проект в среднем весит 100К строк кода, у вас только один способ сделать его за реальные сроки...
Здравствуйте, RedUser, Вы писали:
G>>Джуниор — не может решать задачи самостоятельно, может писать код по готовым примерам (копипастить с испралением имен функций и переменных)
RU>Что-то слишком низкая планка. RU>ИМХО, способный джун может решить практически любую задачу (если не обращать внимания на сроки и качество).
Если некто может решить практически любую задачу то это точно не джун и даже не мидл и даже не сеньор.
RU>По моему скромному опыту проблема с дужунами обычно в том, что их код плоховат в плане дизайна и надёжности (гонки, утечки ресурсов).
Это значит, что они не решили задачу. "работает" это не решение.
Здравствуйте, Ikemefula, Вы писали:
RU>>По моему скромному опыту проблема с дужунами обычно в том, что их код плоховат в плане дизайна и надёжности (гонки, утечки ресурсов).
I>Это значит, что они не решили задачу. "работает" это не решение.
А бизнес считает, что решили: соответствие ТЗ есть, проверка QA пройдена (т.е. не падает на глазах у тестера).
Правда, потом оно начнет рандомно падать у клиентов, но тогда все делается по аджайлу — происходит новая итерация.
Когда код становится совсем падучим спагетти, тогда меняют условных индусов на более правильных специалистов, которые восстановят работоспособность изделия.
И так далее...
CEM>Походу, я джун!
CEM>Не сказать, чтобы я был сильно расстроен Потому что какие-то велосипеды всё-таки кто-то в мире делает первым. Почему бы не я? Не боги велосипеды обжигают. И про кучу кода тоже не совсем понятно... вспоминая "ислам" — если у вас проект в среднем весит 100К строк кода, у вас только один способ сделать его за реальные сроки...
ИМХО, для велосипеда должна быть какая-то причина. Например, уже существующее решение что-то не может или чем-то неудобно. Или не хочется тянуть большую зависимость.
Насчёт кучи кода. Бывает, что количество кода можно уменьшить, если немного подумать.
Здравствуйте, Lazy Bear, Вы писали:
I>>Это значит, что они не решили задачу. "работает" это не решение.
LB>А бизнес считает, что решили: соответствие ТЗ есть, проверка QA пройдена (т.е. не падает на глазах у тестера).
Странно команда организована — джун имеет право в обход всех остальных показывать черновик бизнесу и уговаривать того, что де черновик это законченое решение
LB>Правда, потом оно начнет рандомно падать у клиентов, но тогда все делается по аджайлу — происходит новая итерация.
Проверка QA пройдена но софт почему то падает? Очень странный подход к тестированию.
Здравствуйте, Ikemefula, Вы писали:
I>Странно команда организована — джун имеет право в обход всех остальных показывать черновик бизнесу и уговаривать того, что де черновик это законченое решение
В обход не может. Code review обязательно должно иметь от нескольких человек.
LB>>Правда, потом оно начнет рандомно падать у клиентов, но тогда все делается по аджайлу — происходит новая итерация.
I>Проверка QA пройдена но софт почему то падает? Очень странный подход к тестированию.
Мне кажется, история с 737 Max — очень хороший аналог: нельзя, но очень нужно.
Здравствуйте, Lazy Bear, Вы писали:
I>>Странно команда организована — джун имеет право в обход всех остальных показывать черновик бизнесу и уговаривать того, что де черновик это законченое решение
LB>В обход не может. Code review обязательно должно иметь от нескольких человек.
Тогда это низкая инженерная культура.
LB>>>Правда, потом оно начнет рандомно падать у клиентов, но тогда все делается по аджайлу — происходит новая итерация.
I>>Проверка QA пройдена но софт почему то падает? Очень странный подход к тестированию.
LB>Мне кажется, история с 737 Max — очень хороший аналог: нельзя, но очень нужно.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Lazy Bear, Вы писали:
I>>>Странно команда организована — джун имеет право в обход всех остальных показывать черновик бизнесу и уговаривать того, что де черновик это законченое решение
LB>>В обход не может. Code review обязательно должно иметь от нескольких человек.
I>Тогда это низкая инженерная культура.
Согласен.
Вопрос только в том, как из этого вырулить так, чтобы не навредить ни ранимым инженерам с низкой культурой ни их не менее ранимому мудрому руководству.
При этом известно, что уволить — не вариант, время/деньги практически неограничены в разумных пределах, а где-то там наверху в принципе есть понимание, что с этим надо что-то делать
Здравствуйте, AlexGin, Вы писали:
AG>Это скорее про PM-а, нежели насчёт разработчика Senior-а. AG>На самом деле — сеньору маркетинг себя не очень важен. Его заметят даже и без этого. AG>Вот менеджер проекта — это как раз тот, кто должен много говорить на митингах.
К сожалению роль сеньера и менеджера проекта во многих больших хипстерских компаниях имеет сейчас тенденцию к слиянию. Я все больше вижу, что скилы проджект-менеджера все более воспринимаются у девелопера как сами-собой разумеющиеся.
Здравствуйте, AlexGin, Вы писали:
AG> Это скорее про PM-а, нежели насчёт разработчика Senior-а. AG> На самом деле — сеньору маркетинг себя не очень важен. Его заметят даже и без этого.
Уровень специалиста определяется прежде всего образованием. Вот здесь во многих странах провал ниже плинтуса. Это факты. 
Какое еще собеседование? Алё — я про разницу в результатах на проекте.
от нескольких человек.
