Comments 80
Мне даже сам термин «про-джуниор» категорически не нравится. Он не отражает суть. Человек, который состоялся в какой-либо технологии разработки, в принципе не будет джуниором при смене платформы. Это имеет смысл, только если кто-то с пайтона и хаскеля ушёл в хирургию или там в пчеловодство. Человек, который с одной платформы, будучи там хотя бы миддлом, перешёл на другую, уже де-факто не джуниор, его вливание в полноценную работу занимает дни и недели, а не месяцы и годы. И тем более не
Для того, чтобы ответить на эти вопросы у респондентов-разработчиков уходило от года до пяти с момента начала изучения новой технологии.
Полностью с вами согласен. Паттерны программирования никуда не денутся же (умение применение того же многострадального MVC и т.д.). Да, в зависимости от стека они могут немного измениться, но вот чтобы разработчик прям из мидла в джуна, как то я себе это не представляю, он же не поглупел сразу на порядок.
Да и профессия разработчика подразумевает постоянную учебу и изучение нового стека и технологий, как он может стать джуном?
Да и профессия разработчика подразумевает постоянную учебу и изучение нового стека и технологий, как он может стать джуном?
Если бросаться в крайности, то сениор c десятками лет опыта на условном Cobol может совершенно не ориентироваться в паттернах, принятых при современной разработке. Более того, «человек, который писал на фортране, на любом другом языке будет писать на фортране» — такое тоже наблюдал.
Тут тоже спорно. На мой взгляд.
Человек с опытом разработки уже обладает как минимум навыками алгоритмического мышления.
Кроме того, имея опыт разработки на условном cobol, человек знает как его сильные, так и слабые стороны. И, переходя на новый стек, такой человек найдет там для себя то, чего ему не хватало в старом. И будет этим пользоваться.
Человек с опытом разработки уже обладает как минимум навыками алгоритмического мышления.
Кроме того, имея опыт разработки на условном cobol, человек знает как его сильные, так и слабые стороны. И, переходя на новый стек, такой человек найдет там для себя то, чего ему не хватало в старом. И будет этим пользоваться.
Вот я начал с PHP, потом ушёл в C# и JS (Sencha), потом нырнул в ABAP и всё шло хорошо. В SAP появились нормальные интерфейсы на JS, ABAP закрыли одатой и тоже всё хорошо. Потом стали переносить логику в БД и пришлось перестраиваться, тоже прошло относительно безболезненно. В конце концов, как говорили в университете: «есть всего два типа программистов — те, которые понимают как работают указатели и те, которые не закончат третий курс.»
Но вот пришёл день и я стал по ночам писать для себя вспомогательные штуки на Vapor и мозг сдался: надо в цикле достать файл из внешнего сервиса (асинхронность), распарсить (асинхронность) и вернуть результат. Я уже три дня (а вернее ночи) не могу понять как мне дождаться результата перед тем, как завершить запрос. возможно, если бы я работал в команде, — мне бы показал сеньор как делать такую штуку и я бы всё понял за пять минут. Но текущая перестройка САМАЯ болезненная из всех что у меня были. Паттерны, наверное, никуда не делись, просто они другие!
PS: да, у Vapor есть Discord где реально быстро отвечают даже на глупые вопросы. Просто я люблю сначала сам попробовать понять.
PPS: я нашёл, надо собрать массив ELF и вызвать .flatten
Но вот пришёл день и я стал по ночам писать для себя вспомогательные штуки на Vapor и мозг сдался: надо в цикле достать файл из внешнего сервиса (асинхронность), распарсить (асинхронность) и вернуть результат. Я уже три дня (а вернее ночи) не могу понять как мне дождаться результата перед тем, как завершить запрос. возможно, если бы я работал в команде, — мне бы показал сеньор как делать такую штуку и я бы всё понял за пять минут. Но текущая перестройка САМАЯ болезненная из всех что у меня были. Паттерны, наверное, никуда не делись, просто они другие!
PS: да, у Vapor есть Discord где реально быстро отвечают даже на глупые вопросы. Просто я люблю сначала сам попробовать понять.
PPS: я нашёл, надо собрать массив ELF и вызвать .flatten
Не многие работодатели с вами согласятся. Поэтому у таких работодателей работают условные senior React developer'ы, и у них всегда трудности с наймом людей, потому что «если у человека нет 5 лет опыта в реакте, то он не сеньор, и если он работал эти 5 лет с ангуляром, то он нам не подходит. Ну, или мы можем его нанять забесплатно интерном, ведь он никогда не работал с реактом!»
У нас просто не готовы нанимать настоящих инженеров и платить им настоящие деньги. А так дали лычку сеньора и человек рад.
У каждого работодателя свой подход. Некоторые психологически не готовы инвестировать в только что пришедшего сеньора.
Ну и в ту же копилку человек проработавший 2-3+ года на определенном стэке знает все ограничения и неочевидные места фреймворка.
Я очень давно интересуюсь вопросами и подходами найма, но внятной статистике мне найти не удалось. Может быть у вас есть корреляция условий найма и скорости?
DrPass, спасибо за комментарий!
Мне кажется, что вы правы в том, что наработанные за годы базовые скиллы не теряют ценности достаточно долго. По крайней мере, это очень похоже на то, что я слышал от респондентов. Но цитата, которую вы использовали относилась к тому, как много времени уходило у респондентов-разработчиков для того, чтобы разобраться в самих себе.
Для того, чтобы проиллюстрировать ваш пример лучше подойдет цитата
Разница между двумя фрагментами в том, что в первом случае речь шла о самоощущении разработчиков-респондентов (на что я могу претендовать?), а во втором — о том, как быстро прогрессировали разработчики, меняющие стек (по оценке представителей работодателя).
Мне кажется, что вы правы в том, что наработанные за годы базовые скиллы не теряют ценности достаточно долго. По крайней мере, это очень похоже на то, что я слышал от респондентов. Но цитата, которую вы использовали относилась к тому, как много времени уходило у респондентов-разработчиков для того, чтобы разобраться в самих себе.
Для того, чтобы проиллюстрировать ваш пример лучше подойдет цитата
И если первое прохождением пути от трейни до мидла занимало 2-4 года, то повторное движение по тому же маршруту обычно занимало полгода-год.
Разница между двумя фрагментами в том, что в первом случае речь шла о самоощущении разработчиков-респондентов (на что я могу претендовать?), а во втором — о том, как быстро прогрессировали разработчики, меняющие стек (по оценке представителей работодателя).
Мне даже сам термин «про-джуниор» категорически не нравится. Он не отражает суть. Человек, который состоялся в какой-либо технологии разработки, в принципе не будет джуниором при смене платформы. Это имеет смысл, только если кто-то с пайтона и хаскеля ушёл в хирургию или там в пчеловодство. Человек, который с одной платформы, будучи там хотя бы миддлом, перешёл на другую, уже де-факто не джуниор, его вливание в полноценную работу занимает дни и недели, а не месяцы и годы
Это с точки зрения тупой кадровчики, и не менее тупого манагера, человек при смене не то что языка, а даже просто фреймворка становится «джуниором».
Это ТУПОЙ термин, подразумевающий менее ТУПОЙ подход, как в известном анекдоте про найм столяра:
Интервьюер: Итак, вы считаете себя столяром?
столяр: Всё верно. Это именно то, чем я занимаюсь.
Интервьюер: Как долго вы занимаетесь этим?
столяр: Десять лет.
Интервьюер: Очень хорошо. А теперь я бы хотел задать вам несколько технических вопросов, чтобы оценить, насколько вы впишетесь в нашу команду. Договорились?
столяр: Конечно, было бы неплохо.
Интервьюер: Должен вам сказать, что мы работаем в подразделении, занимающимся постройкой большого количества коричневых домов. Доводилось ли вам строить множество коричневых домов?
столяр: Ну, я же столяр — я строю дома, а люди уже красят их так, как пожелают.
Интервьюер: Да, я понимаю, но не могли бы вы подсказать мне, сколько у вас опыта именно с коричневыми? Ну, плюс-минус.
столяр: Я действительно понятия не имею. С того момента, как дом построен, меня не волнует, в какой цвет его покрасят. Может, шесть месяцев?
Интервьюер: Шесть месяцев? Вообще-то мы ищем кого-нибудь с гораздо большим опытом коричневого, но позвольте мне задать вам ещё несколько вопросов.
столяр: Ладно. Но, знаете, покраска — это покраска.
Интервьюер: Да-да, хорошо. Что насчёт Ореха?
столяр: А что с ним?
Интервьюер: Много ли вы работали с ореховым деревом?
столяр: Конечно. Ореховое дерево, сосна, дуб, красное дерево — всё, что угодно.
Интервьюер: Но сколько лет вы работали с Орехом?
столяр: Да не знаю я, чёрт возьми. Я что, должен считать каждую доску?
Интервьюер: Ну хотя бы примерно?
столяр: Хорошо, тогда я бы сказал, что у меня есть полтора года опыта работы с ореховым деревом.
Интервьюер: Но вы не ореховый гуру?
столяр: Ну, я же столяр — я работаю с любыми типами дерева, которые, конечно, имеют некоторые отличия, но я считаю, что если ты хороший столяр…
Интервьюер: Да, да, но мы используем ореховое дерево. Это нормально?
столяр: Ореховое дерево — это прекрасно! Всё, чего пожелаете — я же столяр.
Интервьюер: Что насчёт чёрного Ореха?
столяр: А с ним что?
Интервьюер: У нас было несколько ореховых столяров, но потом случайно выяснилось, что они не были столярами по чёрному Ореху. Имеется ли у вас опыт с ним?
столяр: Конечно, немного. Полагаю, было бы хорошо иметь больше опыта для моего резюме.
Интервьюер: Ладно. Позвольте мне свериться со списком вопросов.
столяр: Да пожалуйста.
Интервьюер: Итак, последний вопрос на сегодня. Мы используем Камень 5.1 для забивания гвоздей. Использовали ли вы Камень 5.1?
столяр: [бледнея...] Ну, я знаю, что множество столяров начали использовать камни, чтобы забивать гвозди, когда Craftsman купил каменоломню, но, честно говоря, у меня это получается гораздо лучше с моим гвоздомётом. Или молотком, если хотите. Мне кажется, что, когда я использую камень, то слишком часто ударяю себя по пальцам, в то время, как другая рука сильно болит, потому что камень слишком тяжёлый.
Интервьюер: Но другие компании используют камни. Вы хотите сказать, что камни не работают?
столяр: Нет, я вообще-то не говорю, что камни не работают. Я лишь считаю, что гвоздомёты работают лучше.
Интервьюер: Все наши архитекторы начинали использовать камни и им понравилось.
столяр: Не спорю, но я забиваю гвозди целый день и — ладно, слушайте, мне нужна работа, так что я определённо готов к использованию камней, если вы захотите.
Интервьюер: Ок. У нас есть ещё несколько кандидатов; мы свяжемся с вами, когда примем решение.
столяр: Что ж, спасибо за ваше время. Было приятно поговорить.
СЛЕДУЮЩИЙ ДЕНЬ
Звонок…
Интервьюер: Алло?
столяр: Здравствуйте! Помните меня? Я тот столяр, которого вы собеседовали для работы с чёрным ореховым деревом. Хотел лишь узнать, приняли ли вы решение.
Интервьюер: Вообще-то приняли. В целом, нам нравится ваш опыт, но мы решили взять кого-то, кто больше работал с коричневым.
столяр: Правда? И это всё? Меня не взяли на работу, потому что у меня недостаточно опыта с коричневым?
Интервьюер: Ну, это только наполовину так. Отчасти, мы взяли другого парня, потому что он намного дешевле.
столяр: Серьёзно? И сколько же у него опыта?
Интервьюер: Ладно, он не совсем столяр, он продавец машин. Однако он продал много коричневых машин и работал с отделкой из орехового дерева.
столяр: [короткие гудки]
UFO just landed and posted this here
А есть данные "Senior X -> Senior Y"?
Пока, по моему общению с рекрутерами, которые "спамили" вакансиями, картинка выглядит так: если повезёт, то миддловская позиция со средней по рынку ЗП (~50% от текущей). Через год возможно сеньорская со средней по рынку (~85% от текущей), ещё года-два до текущей (последний квартиль) и дальше "жир" в виде +5-10% к текущей :)
VolCh, сеньор как грейд чаще относится к конкретным навыкам, наработанным в конкретной технологии, чем к человеку.
Но вот чтобы человеку сразу приписывали сеньорный грейд за предыдущие заслуги без единого дня работы на новой технологии — такого в ходе сбора данных не встретил. Возможно, так происходит, если человек меняет стек внутри одной компании, но это не совсем кейс исследования — меня больше интересовали те, кто меняли и стек, и место работы.
Вот случаи перехода с той же или с большей ЗП были — про них написал.
Но вот чтобы человеку сразу приписывали сеньорный грейд за предыдущие заслуги без единого дня работы на новой технологии — такого в ходе сбора данных не встретил. Возможно, так происходит, если человек меняет стек внутри одной компании, но это не совсем кейс исследования — меня больше интересовали те, кто меняли и стек, и место работы.
Вот случаи перехода с той же или с большей ЗП были — про них написал.
VolCh, сеньор как грейд чаще относится к конкретным навыкам, наработанным в конкретной технологии, чем к человеку.
Вот не сказал бы. То есть как минимум по моему опыту можно быть супер-экспертом в куче технологий, но при этом всё равно оставаться мидлом.
То есть знания технологий тоже нужны, но одних их недостаточно чтобы быть сеньором.
Но вот чтобы человеку сразу приписывали сеньорный грейд за предыдущие заслуги без единого дня работы на новой технологии — такого в ходе сбора данных не встретил.
Это очень сильно зависит от конкретных технологий. То есть если скажем переходишь с плюсов на джаваскрипт это одно. А если скажем с джавы на сишарп, то совсем другое.
Ну тут от компании зависит.
У нас сеньор кроме технологий разработки еще должен неплохо понимать тонкости платформы под которую идет разработка и еще неплохо ориентироваться в предметной области и понимать бизнес-процесс.
Иными словами, джуниор пишет строго по FSD, а сеньор может сам вносить корректировки в FSD. И при разработке FSD к нему как минимум могут обратиться за советом.
FSD в нашем случае это не только ТЗ, но и документация по задаче. Если задача потом кому-то придет на доработку, то FSD поможет человеку быстрее вникнуть в чужой код.
У нас сеньор кроме технологий разработки еще должен неплохо понимать тонкости платформы под которую идет разработка и еще неплохо ориентироваться в предметной области и понимать бизнес-процесс.
Иными словами, джуниор пишет строго по FSD, а сеньор может сам вносить корректировки в FSD. И при разработке FSD к нему как минимум могут обратиться за советом.
FSD в нашем случае это не только ТЗ, но и документация по задаче. Если задача потом кому-то придет на доработку, то FSD поможет человеку быстрее вникнуть в чужой код.
UFO just landed and posted this here
Профессионал водитель на 50 тонном грузовике сможет на уровне профессионала водителя проехать круг на ф1? Нет? Как нет, он ведь водитель и профессионал!
Стэк для разработчика пишущего код имеет значение.
Само утверждение, что стэк значения не имеет — показывает что у соискателя уровень еще даже не миддла, т.к. он просто не понимает в чем важность знания стэка.
Если говорить про позиции уровня тим-лида или архитектора — там да, там стэк значения решающего уже не имеет. Там уже работает более общий принцип типа того
Но это совершенно отдельная история и всё равно — знать стэк все равно надо, просто что бы не пытаться забивать гвозди пассатижами.
Стэк для разработчика пишущего код имеет значение.
Само утверждение, что стэк значения не имеет — показывает что у соискателя уровень еще даже не миддла, т.к. он просто не понимает в чем важность знания стэка.
Если говорить про позиции уровня тим-лида или архитектора — там да, там стэк значения решающего уже не имеет. Там уже работает более общий принцип типа того
более общий принцип
Жили-были мыши и все их обижали. Как-то пошли они к мудрому филину и говорят:
— Мудрый филин, помоги советом. Все нас обижают, коты разные, совы. Что нам делать?
Филин подумал и говорит:
— А вы станьте ежиками. У ежиков иголки, их никто не обижает.
Мыши обрадовались и побежали домой. Но по дороге одна мышка сказала:
— Как же мы станем ежиками? — и все побежали обратно, чтобы задать этот вопрос мудрому филину.
Прибежав, они спросили:
— Мудрый филин, а как же мы станем ежиками?
И ответил филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.
— Мудрый филин, помоги советом. Все нас обижают, коты разные, совы. Что нам делать?
Филин подумал и говорит:
— А вы станьте ежиками. У ежиков иголки, их никто не обижает.
Мыши обрадовались и побежали домой. Но по дороге одна мышка сказала:
— Как же мы станем ежиками? — и все побежали обратно, чтобы задать этот вопрос мудрому филину.
Прибежав, они спросили:
— Мудрый филин, а как же мы станем ежиками?
И ответил филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.
Но это совершенно отдельная история и всё равно — знать стэк все равно надо, просто что бы не пытаться забивать гвозди пассатижами.
UFO just landed and posted this here
Про смену стека моя аналогия будет как — пересесть с 50 тонного грузовика Volvo на такойже грузовик, только от Mersedes.Если у Вас задача доехать из точки А в точку Б — Ваша аналогия отчасти верна.
Но такая задача уровень джуниора, который разницу между разными грузовиками просто не понимает.
Поэтому мы согласны с nikitaag термином «про-джуниор» при переходе в новый стэк.
Если же речь о миддле или сеньере (но все еще о кодере, а не тимлиде), то ситуация меняется.
Т.к. от миддла уже требуется не просто доехать, а доехать быстро, экономично и без проишествий. И здесь уже нужно знать особенности конкретной модели.
Обратите внимание на фразу в статье
С учетом инвестиций в обучение, менторство, и общие расходы на онбординг нового сотрудника, подобный дисконт составлял 10-15% от стоимости найма готового мидла на рынке, или одной месячной зарплате специалиста за год.
Эти 10-15% как раз и есть затраты на переход «про джуниора» в «миддла/сеньера».
Можете взять просто человеческие языки если будет проще.
Знание языка без «стэка» это по сути просто словарь. Можно объясниться, но даже речи не идет о том, что бы переводить профессионально. Идиомы, фразеологические обороты, уместность применения слов в зависимости от контекста. Где это всё без знания самого «стэка»? Нету. И в чем тогда «сеньерность» применительно к конкретному языку?
Различие между двумя стеками технологий конечно больше чем между двума моделями грузовиков, но и не такое кардинальное как между тягачём и болидом ф1.Vadem
Допустим, сеньер ява прогер берет алгоритм отлично работавший на яве, перекладывает его напрямую на питон и получаете адские тормоза и адское потребление памяти.
В обоих случаях все работает и 2*2=4, всё корректно, тесты отрабатывают, вопросов нет.
Рядом сидящий миддл питонщик ту же задачу решает так, что работает оно за 2 секунды вместо 4 и жрет 128мб вместо 1гб.
Вот так вот незнание стэка и проявляется. И первое решение, какой бы сеньер его не реализовал, как по нам, выше чем на джуниора не тянет.
Допустим, сеньер ява прогер берет алгоритм отлично работавший на яве, перекладывает его напрямую на питон и получаете адские тормоза и адское потребление памяти. В обоих случаях все работает и 2*2=4, всё корректно, тесты отрабатывают, вопросов нет.
Рядом сидящий миддл питонщик ту же задачу решает так, что работает оно за 2 секунды вместо 4 и жрет 128мб вместо 1гб.
А теперь главный вопрос нашей викторины: давайте уберём слово «допустим» и вообще все фантазии и допущения, и попробуем привести пример вот такого кейса, где сеньор-джавист на пайтоне сделает что-то настолько неправильное, что на джаве работает хорошо, на пайтоне плохо, и при этом не объясняется в первом же букваре, когда он там синтаксис пайтона смотрел. СлабО? Вот и мне слабо. Такие кейсы существуют только в фантазиях, на практике опытный джавист просто посмотрит, как такие задачи принято решать на пайтоне, и решит.
СлабО? Вот и мне слабо.Очень мило что Вы пытаетесь взять нас на слабо, да еще и за нас решили что нам слабо. Прям не хабр, а пикабу:)
Посмотрите — ZF2, который писали отъявленные явисты со всеми вытекающими. Тут на хабре была пара стетей на эту тему.
Посмотрите drupal тех версий (вроде в районе 6-ки и до нее), где реализовывали ООП без использования конструкций языка для ООП. Тоже на хабре пара стетей была.
Посмотрите статьи тут же на хабре о том, как команды начинали переписывать часть кода на гоу и им обязательно в наставники выделялись сеньеры в гоу, что бы они не накосячили… хотя с Вашей точки зрения это на фиг нужно, ведь можно «просто посмотреть».
на практике опытный джавист просто посмотрит, как такие задачи принято решать на пайтоне, и решит.Несомненно, а опытный переводчик с англ на русский если ему надо перевести с англ на японский — просто посмотрит как этот текст принято переводить на японский и переведет.
Вы так смешно говорите, как будто «просто посмотрит» не занимает времени и усилий, а результат так же хорош, как при полноценном знании вопроса.
А ведь разница между сеньером и джуниором в том и состоит, что в то время как джуниор «ищет как решается задача» — сеньер пишет это решение, что бы джуниор мог его «просто посмотреть».
Это разница между «знанием языка» и «знанием языка со словарем».
Да и в принципе, как только Вы открываете этот ящик пандоры с «можно просто посмотреть», то Вы убиваете вообще весь смысл найма знающего человека. В гугле можно посмотреть что угодно для решения какой угодно задачи. Давайте вообще тогда с улицы кого попало нанимать, ведь они всё «смогут просто посмотреть»©
Очень мило что Вы пытаетесь взять нас на слабо, да еще и за нас решили что нам слабо.
А мне наоборот, понравился ваш приём, когда вы вместо себя лично записали мне в оппоненты остальных читателей этой статьи. Ну примерно как пионервожатый, отчитывающий хулигана: «Ты опозорил всех нас, своих товарищей!» :) Пожалуйста, пишите не «нас», а «меня». У вас за спиной никого нет, и слабо — вам лично ;)
Посмотрите — ZF2, который писали отъявленные явисты со всеми вытекающими.
Я не лез в ZF2, но зато копался в ZF1. Там макросы восьмиуровневой вложенности. Ну причём тут явисты, господи?
Посмотрите drupal тех версий (вроде в районе 6-ки и до нее), где реализовывали ООП без использования конструкций языка для ООП.
… и это тоже были явисты? Или всё-таки Друпал писали PHPшники? Вы же не подтягивайте под банальный непрофессионализм байки про людей с других платформ :)
В случае Друпала как раз наверняка писали РНРшники, учитывая, что во времена выхода Друпал 6 вот эти самые «конструкции языка для ООП» в РНР завезли не так чтобы и давно, и вполне логично, что там было навалом легаси-кода предыдущих версий, где ООП приходилось эмулировать.
Вы так смешно говорите, как будто «просто посмотрит» не занимает времени и усилий, а результат так же хорош, как при полноценном знании вопроса.
А сколько времени и усилий оно занимает? Ну вот серьезно? Массовые платформы — они все примерно похожи по возможностям.
А ведь разница между сеньером и джуниором в том и состоит, что в то время как джуниор «ищет как решается задача» — сеньер пишет это решение, что бы джуниор мог его «просто посмотреть».
Нет. Разница в том, что сеньор знает, какие есть методы решения задач, а джун не знает. Хренушки вы найдёте сеньора, который вот так себе в уме держит всё, что ему может понадобиться по его платформе. Ну бывают, конечно, такие гики, но это один на тыщу обычных сеньоров. На практике помнить кучи библиотек и особенностей их юзания почти никто не способен, да и не нужно оно. Сеньор должен знать, что тут подходит такой-то метод решения, а помнить его наизусть, чтобы вот так сесть и сделать без гуглёжки, отнюдь не требуется.
то Вы убиваете вообще весь смысл найма знающего человека. В гугле можно посмотреть что угодно для решения какой угодно задачи
Так и не надо искать именно «знающих». Для подавляющего большинства задач в нашей работе необходимо и достаточно найти «думающих». Их не так уж и много, с улицы кого попало тут не взять.
Вы вместо себя лично записали мне в оппоненты остальных читателей этой статьи.Мы этого не делали. Сначала Вы попробовали взять на слабо, теперь просто фантазируете.
слабо — вам личноМы-то привели три примера. Так что слабо — только Вам, как Вы сами же и сказали.
зато копался в ZF1. Там макросы восьмиуровневой вложенности. Ну причём тут явисты, господи?А при чем тут ZF1, если мы писали про ZF2?
и это тоже были явисты? Или всё-таки Друпал писали PHPшники?Это были профи пришедшие из языка где не было ООП реализации ООП методов.
А сколько времени и усилий оно занимает?Тут в соседнем топике недавно был пост перешедшего на ява сеньера, который говорил что за 5 лет изучения явы сих пор не считает что знает его хорошо.
А у Вас это так легко «просто посмотреть» и все знаешь, ага.
Разница в том, что сеньор знает, какие есть методы решения задач, а джун не знает.Так джун же «может просто посмотреть»© Ваш же аргумент, куда он тут вдруг пропадает у Вас же? Двойные стандарты-с.
Для подавляющего большинства задач в нашей работе необходимо и достаточно найти «думающих»Даже если они ничего не знают, потому что могут «просто посмотреть», окей, мы поняли Вашу точку зрения.
Мы-то привели три примера.
Не привели, а придумали.
А при чем тут ZF1, если мы писали про ZF2?
Его писали другие люди? Вот так всех уволили и наняли джавистов?
Это были профи пришедшие из языка где не было ООП реализации ООП методов.
Из какого языка? В команду Друпала брали не РНРшников? Что вы несёте?
Тут в соседнем топике недавно был пост перешедшего на ява сеньера, который говорил что за 5 лет изучения явы сих пор не считает что знает его хорошо.
Ну так и вы говорите (с). Я за 22 года работы сменил пяток основных платформ и десяток не основных. И при этом не одну из них я не знал хорошо. Хорошо знаешь только то, с чем работаешь непосредственно. А непосредственно никакой проект не включает все фичи/подсистемы/библиотеки платформы, поэтому все равно досконально изучаешь лишь какую-то часть, которая вот сейчас юзается в проекте.
Но при этом не было ни одной задачи, которую я бы не смог решить в установленные сроки. И то же самое могу сказать и про всех моих коллег.
Так джун же «может просто посмотреть»© Ваш же аргумент, куда он тут вдруг пропадает у Вас же? Двойные стандарты-с.
Не у меня двойные стандарты, а вы просто читаете одну строку через две. Повторюсь: основная разница между джуном и опытным разработчиком в том, что опытный разработчик знает, какие есть способы решения. Джун не знает, что ему искать.
Повторюсь: основная разница между джуном и опытным разработчиком в том, что опытный разработчик знает, какие есть способы решения. Джун не знает, что ему искать.Вы говорили не так, Вы говорили, цитируем «сеньор знает, какие есть методы решения задач, а джун не знает»©
И вот так Вы постоянно, то на слабо берете, то фантазируете, то от своих слов отказываетесь. Это не конструктивный метод ведения дискуссии.
Я за 22 года работы сменил пяток основных платформ и десяток не основных. И при этом не одну из них я не знал хорошо.Тогда понятно почему Вы защищаете точку зрения, что стэк знать не нужно.
Вы говорили не так, Вы говорили, цитируем «сеньор знает, какие есть методы решения задач, а джун не знает»©
А, извините. Я же не знал, что для вас замена «способы» на «методы» меняет смысл выражения.
И вот так Вы постоянно, то на слабо берете, то фантазируете, то от своих слов отказываетесь. Это не конструктивный метод ведения дискуссии
Не уходите в стандартный троллинг, это вам баллов не добавляет, и слишком уж бросается в глаза. У вас вся ваша аргументация — троллинг:
— Приведите кейс, где разработчики с другого стека могут там налажать
— А посмотрите на систему X!
— Почему вы решили, что систему Х писали разработчики с другого стека, и вообще, где там подобная лажа?
— Аааа, я вам привёл аргументы, а вы фантазируете, бла-бла-бла.
Тьфу на вас, в общем :)
Тогда понятно почему Вы защищаете точку зрения, что стэк знать не нужно.
Да. Это называется «знание, полученное из собственного опыта и наблюдений». Самое надёжное знание, к слову. И опять же, вы снова переворачиваете мои слова. Я защищаю точку зрения, что опытный разработчик легко и безболезненно сможет сменить стек, а не то, что его знать вообще не нужно. Естественно, что при прочих равных чувак, который уже знает стек, получит некоторую фору. Но с другой стороны, этой форой можно легко пренебречь, если вам нужен на проект опытный программист, и под рукой есть опытные, но с другим бэкграундом.
А, извините. Я же не знал, что для вас замена «способы» на «методы» меняет смысл выражения.И опять врете.
В изначальной фразе у Вас было «сеньор знает, какие есть методы решения задач, а джун не знает».
На что мы резонно возразили, что джун «может посмотреть», согласно Вашему же утверждению.
И Вы тут же переврали свою фразу на «Джун не знает, что ему искать», хотя никаких «искать» изначально не было.
Мало того, чего это джун не знает что ему искать Вы никак не обосновали, так же как то, с чего бы сеньер знал что ему искать.
это вам баллов не добавляетПонятно на чем Вы сфокусированы и почему так активно отвечаете, спасибо что прояснили.
Мы не за баллы пишем, вот в чем штука.
Я защищаю точку зрения, что опытный разработчик легко и безболезненно сможет сменить стек, а не то, что его знать вообще не нужно. Естественно, что при прочих равных чувак, который уже знает стек, получит некоторую форуИ Вы опять врете.
Вы сказали, цитируем «вообще разницы нету. Фрейворки одинаковые, библиотеки одинаковые»© и все в таком духе. Эта Ваша легко ищется по комментам выше по топику и именно подобные утверждения об «отсутствии разницы» у нас вызвали возражения.
При чем мы нигде не утверждали что «разработчик не сможет сменить стэк», хотя Вы пытаетесь приписать нам это.
Мы не более чем ссылаясь на автора статьи достаточно внятно сказали «дисконт составлял 10-15%»©, т.е. как раз говоря о форе.
И эта наша фраза легко ищется по комментам выше по топику.
Теперь когда Вы поняли, что Вы не правы, Вы пытаетесь переврать дискуссию и присвоить защищаемую нами точку зрения о форе себе, попутно снимая с себя утверждение об отсутсвии разницы.
Очешуенно.
Но по крайней мере мы рады, что удалось привить Вам толику здравого смысла, пусть даже не удалось научить вести дискуссию корректно, поэтому свою роль считаем здесь законченной.
UFO just landed and posted this here
Опытный джавист, если он действительно опытный — сначала напишет так, чтобы просто работало. А потом, если что-то пойдет не так в смысле производительности — возьмет профайлер и починит самые критические места.
на практике опытный джавист просто посмотрит, как такие задачи принято решать на пайтоне, и решит.
На практике это означает что его опыт не пригодился и он не лучше джуниора ;)
То есть, опытный джавист/php-шник/etc. сможет разобраться в то, "как такие задачи принято решать" в новом для него стеке, не быстрее джуниора?
наверняка быстрее, если мозг не закостенел, но это уже вопрос обучаемости. Джуниор с опытом а 100500 стеках сможет разобраться ещё быстрее.
А тут уже вопрос классификации — где провести границу. Я, к примеру, сам себя ощущаю именно что "джуниором широкого профиля", поскольку специалистом в каком-то конкретном языке или технологии мне себя назвать язык ну никак не поворачивается. По принятой в нашей фирме должностной сетке, тем не менее, считаюсь твёрдым мидлом — за счёт общих компетенций разработчика. И уверен, что мой случай далеко не уникальный.
Ну… А как отличить джуна от мидла? У нас в конторе джун — прежде всего то, кто пишет строго по FSD во-первых и требует обязательного кодревью во-вторых.
Мидл уже может более творчески подходить к FSD (он способен увидеть решение более оптимальное, нежели написано в FSD) и не требует столь жесткого контроля в плане кодревью.
Сеньор уже сам может участвовать в разработке FSD (как в плане алгоритмирования, так и в оценке), сам проводить кодревью и вообще быть наставником для джунов.
Деление несколько условное, но примерно так.
Мидл уже может более творчески подходить к FSD (он способен увидеть решение более оптимальное, нежели написано в FSD) и не требует столь жесткого контроля в плане кодревью.
Сеньор уже сам может участвовать в разработке FSD (как в плане алгоритмирования, так и в оценке), сам проводить кодревью и вообще быть наставником для джунов.
Деление несколько условное, но примерно так.
UFO just landed and posted this here
Ой, а почему вы с одного аккаунта пишете? Или почему вы говорите за двоих?
Допустим, сеньер ява прогер берет алгоритм отлично работавший на яве, перекладывает его напрямую на питон и получаете адские тормоза и адское потребление памяти.
В обоих случаях все работает и 2*2=4, всё корректно, тесты отрабатывают, вопросов нет.
Рядом сидящий миддл питонщик ту же задачу решает так, что работает оно за 2 секунды вместо 4 и жрет 128мб вместо 1гб.
Вот так вот незнание стэка и проявляется. И первое решение, какой бы сеньер его не реализовал, как по нам, выше чем на джуниора не тянет.
Конечно такое может случиться. Вопрос в том как часто и насоклько трудно хорошему инженеру будет разобраться с этой проблемой.
Я не утверждаяю, что конкретный стек не важен совсем, но мне кажется, что это лишь верхушка айсберга от всего того что должен знать хороший инженер.
Вот далеко неполный список того что желательно знать инженеру ПО:
Железо: CPU(базовые принципы, прерывания, конвеер, режимы, треды, кэши, векторизация, виртуализация и т.д.), RAM, диск, сеть и т.д.
ОС: управление памятью, планировщики процессов, потоков, системные вызовы, IPC, IO, файловые системы, eBPF, libuv/epoll и т.д.
Сети: OSI, Ehternet, IP, UDP, TCP, DHCP, DNS, BGP, HTTP(S), TLS, и т.д.
Базы данных: реляционные, документоориентированные, колоночные, графовые и т.д. Архитектура, внутреннее предаставление страниц данных, кэшей и т.д. Реляционная алгебра, нормальные формы, типы транзакций, SQL, гарантии согласованности, доступности и т.д.
Очереди сообщений, системы кэширования, вебсервера, контейнеры, оркестраторы, системы CI/CD, логирования, трассировки, мониторинга и т.д.
Алгоритмы и структуры данных, ООП, ФП, паттерны, системы типов, тестирование и т.д.
Распределённые системы: алгоритмы выбора лидера, консенсуса, распределённые транзакции, отказоустойчивость, масштабирование и т.д.
Хочется продолжать этот сумбурный и плохоструктурированный список, но я уже устал, а продолжать можно ещё очень и очень долго.
Но не в это суть. Суть в том, что знание прикладного стека технологий(Java, Python, etc.) — это лишь малая часть от того что вообще нежно знать.
Конечно, никто не знает всего, но при найме стоит обращать внимание на разные качаства и навыки кандидата.
Иначе у вас получится команда, в которой все отличные питоничты, но никто не знает как Linux работает.
Ну как-то так, да…
Вообще, по-хорошему, грамотный разработчик должен еще неплохо себе представлять что внутри у того или иного фреймворка. А также ориентироваться в чисто архитектурных вопросах — где выгоднее использовать многопоточность, а где удобнее разделить выполнение на процессы. В каком случае выгоднее использовать синхрон в разных потоках/процессах, а в каком асинхрон в одном. Какие бывают транспорты и протоколы обмена данными между потоками и процессами и их плюсы и минусы.
При многопоточной/многопроцессоной работе как правильно распределить функции (нагрузку) между потоками/процессами.
Во всем этом неплохо хотя бы просто ориентироваться, а не упираться в возможности конкретной библиотеки.
Вообще, по-хорошему, грамотный разработчик должен еще неплохо себе представлять что внутри у того или иного фреймворка. А также ориентироваться в чисто архитектурных вопросах — где выгоднее использовать многопоточность, а где удобнее разделить выполнение на процессы. В каком случае выгоднее использовать синхрон в разных потоках/процессах, а в каком асинхрон в одном. Какие бывают транспорты и протоколы обмена данными между потоками и процессами и их плюсы и минусы.
При многопоточной/многопроцессоной работе как правильно распределить функции (нагрузку) между потоками/процессами.
Во всем этом неплохо хотя бы просто ориентироваться, а не упираться в возможности конкретной библиотеки.
Профессионал водитель на 50 тонном грузовике сможет на уровне профессионала водителя проехать круг на ф1? Нет? Как нет, он ведь водитель и профессионал!
Скорее так:
Профессионал водитель на 50 тонном грузовике от Вольво сможет на уровне профессионала водителя управлять грузовиком от Мерседесс?
Различие между двумя стеками технологий конечно больше чем между двума моделями грузовиков, но и не такое кардинальное как между тягачём и болидом ф1.
Само утверждение, что стэк значения не имеет — показывает что у соискателя уровень еще даже не миддла, т.к. он просто не понимает в чем важность знания стэка.
Именно так. Потому что правильный ответ — стэк не имеет существенного значения при найме миддла, и тем более сеньора. Чтобы не пытаться забивать гвозди пассатижами, необходимо и достаточно научиться задавать себе и гуглу вопрос: «Как на платформе Х обычно принято делать фичу Y?»
Потому что правильный ответ — стэк не имеет существенного значения при найме миддла, и тем более сеньора.Согласны.
Но при условии, что Вы нанимаете его на должность «про-джуниора» с целью перевести в миддлы или сеньеры, когда он изучит стэк.
nikitaag в статье пишет
, основные усилия про-джуниоров уходили на то, чтобы “набивать руку” на новом стеке, и решать проблемы, специфические для осваиваемой технологии
повторное движение по тому же маршруту обычно занимало полгода-год.
Если Вы хотите нанять именно миддла или сеньера «здесь и сейчас», то нанимать «про-джуниора» просто не вариант, т.к. у Вас нет этих «полгода-года» на то, что бы они подтянули знание стэка.
Мне кажется, что аналогия не самая удачная. Я бы сравнил профессионала-механика, обслуживающего 50-тонные грузовики, и профессионала-механика, обслуживающего болиды F1. Специфика должна быть разная, однако переучиться в разы проще, чем начинать с нуля.
Ваша аналогия тоже не особо удачная. 50-тонные грузовики — это надежность в первую очередь, а болиды F1 мощность при минимальном весе. Надежность достигается как раз увеличением веса (например коленвал), мощность же у болидов достигается всякими композитными материалами и углами (угол клапанов, угол кулачков на распредвале).
И для того чтобы быть механиком болида, надо способностей намного больше чем для механика грузовиков (например знать физику надо на хорошем уровне).
При таком переходе нету в разы проще, а наоборот сложнее (так как некоторые практики в новых условиях будут только мешать). Например, двигатель грузовика можно завести без системы охлаждения, ненадолго, но можно и часто такое делают. В случае же с двигателем болида это клин, деформация блока цилиндров и в железо на мусорку.
Ваша аналогия хорошо бы подошла, если менять стабильный PostgreSQL на kdb+ где в нагрузку надо выучить q :)
И для того чтобы быть механиком болида, надо способностей намного больше чем для механика грузовиков (например знать физику надо на хорошем уровне).
При таком переходе нету в разы проще, а наоборот сложнее (так как некоторые практики в новых условиях будут только мешать). Например, двигатель грузовика можно завести без системы охлаждения, ненадолго, но можно и часто такое делают. В случае же с двигателем болида это клин, деформация блока цилиндров и в железо на мусорку.
Ваша аналогия хорошо бы подошла, если менять стабильный PostgreSQL на kdb+ где в нагрузку надо выучить q :)
Я и говорю, что специфика должна быть разная, понятное дело, что привычные практики, которые работают для 50-тонных грузовиков, могут не работать и даже быть вредными для гоночных болидов. Однако физика остаётся одна и та же, механика (как раздел физики) — тоже, общие принципы — те же, и если сравнивать время, необходимое для переучивания и для обучения с нуля — я уверен, что будет серьёзная разница.
На самом деле не обязательно так усложнять. Если человек, положим, несколько лет делал движок для САПР, а теперь переквалифицировался в web-dev и шлёпает круды (пока что) — я не думаю что у него возникнут серьёзные проблемы с обучением, хотя разница как раз как с гоночным болидом и грузовиком :)
Ваша аналогия хорошо бы подошла, если менять стабильный PostgreSQL на kdb+ где в нагрузку надо выучить q :)
На самом деле не обязательно так усложнять. Если человек, положим, несколько лет делал движок для САПР, а теперь переквалифицировался в web-dev и шлёпает круды (пока что) — я не думаю что у него возникнут серьёзные проблемы с обучением, хотя разница как раз как с гоночным болидом и грузовиком :)
С одной стороны вы правы — на вхождение в проект с малознакомым стеком требуется время. С другой — на вхождение в любой проект, если он не на 300 строк, требуется время чтобы разобраться с зоопарком уже используемых технологий и подходов и главный вопрос — насколько это время отличается от первого случая. Более того, поскольку все люди разные — в каких-то случаях это время может быть не в пользу знатока уже существующей технологии, хотя риски тут побольше.
Конечно есть и специфические случаи типа разработчика на Visual Basic под Excel, который хочет освоить распределенные системы, но тут уже скорее вопрос почему человек ждал столько лет, чтобы стек сменить и насколько он вообще senior с таким подходом.
Конечно есть и специфические случаи типа разработчика на Visual Basic под Excel, который хочет освоить распределенные системы, но тут уже скорее вопрос почему человек ждал столько лет, чтобы стек сменить и насколько он вообще senior с таким подходом.
Может быть при очень похожих языках и аналогичных фреймворках/либах (по ощущениям Java<->C#) время перехода на новый проект с новым стэком различаться и будет минимально, но вот на полноценный переход с, например, с дефолтной многопоточной синхронной модели одного стэка на дефолтную однопоточную асинхронную другого, может потребовать заметно больше времени чем на освоение синтаксиса. Причём это время сравнимо будет, наверное, с переходом на новую модель без смены стэка, если брать мэйнстримовые мультипарадигменные (читай — ООП :)) языки.
Грубо говоря, гораздо сложнее начать нормально писать на PHP асинхронно в одном процессе, чем нормально писать на Node.js синхронно, форкая процессы внешним оркестратором по мере необходимости. А в случае перехода на "дефолтный" nodejs бОльшую часть времени займёт именно переход на асинхронную однопоточную модель, плюс широкое использование ФП, а не на освоение нового синтаксиса и стандартной/популярных библиотек.
Наверное, именно смены в "дефолтных" парадигмах (ООП <-> ФП, например) и вычмоделях (распределенные/централизованные, синхронные/асинхронные и т. п.) вызывает бОльшую часть проблем.
К сожалению, некоторые рекрутеры именно так и считают. Точнее, они ищут готового разработчика под конкретный стек и начальную позицию в компании определяют именно исходя из того, насколько человек знает этот стек
Безотносительно выводов отмечу, что "31 интервью с разработчиками, рекрутерами и HR-ами продуктовых и сервисных IT-компаний" абсолютно ничего не говорит о репрезентативности выборки.
Интервью с HR совсем не то же самое, что и интервью с разработчиком. HR наверное будет говорить о каком-то множестве кандидатов, а разработчик — о себе.
akryukov спасибо за комментарий!
Критерий репрезентативности вряд ли можно применить к качественным исследованиям (результаты которого выше).
В первую очередь, было важно соответствие базовым условиям. Например, для разработчика — это опыт смены стека и параллельной смены работы, а для рекрутеров и HR-ов — это опыт найма таких разработчиков.
Но мне тоже было бы интересно перейти от историй к статистически значимым данным. Как раз для этого я и разместил опрос.
Критерий репрезентативности вряд ли можно применить к качественным исследованиям (результаты которого выше).
В первую очередь, было важно соответствие базовым условиям. Например, для разработчика — это опыт смены стека и параллельной смены работы, а для рекрутеров и HR-ов — это опыт найма таких разработчиков.
Но мне тоже было бы интересно перейти от историй к статистически значимым данным. Как раз для этого я и разместил опрос.
Никита, Вы тут нас не путайте. Мало того, что нас делят на касты, да ещё некоторые форсят дедовщину. Уже есть стронг-миддлы, ещё про-джуниоры. Затем, видимо, последуют лоу-серьёры. Я конечно понимаю, что в индустрии кризис управления и система, где из должностей сделали слоты для людей, чтобы заменять одного на другого, начинает иногда сбоить. Но право же, всё же...
Как по мне, так менеджмент сильно увлёкся таксономией разработчиков. Это приводит к путанице на рынке, когда сеньёрство дают взамен повышения оплаты или чтобы выгоднее продать заказчику. Каждый сам решит, к чему это приведёт в долгосрочной перспективе.
Это всё была моя отсебятина. Если ближе к статье, то
- Исходное понятие размыто. Состоялся ли сотрудник условного Jet-Brains за условные 2 года? Состоялся ли вестальщик сайтов в региональной студии за 10 лет? Тварь он дрожащая или экспертизу имеет?
- Мотивация эфемерна и неопределима.
- HRы нужны. Но вовлекать их в сколько-нибудь серьёзную оценку знания стека кого-либо мне видится опасным
- Речь вроде о технологиях, а в тесте сплошь языки. В статье технология=язык? Если да, почему употребляется слово "технология", если нет — в чём отличие?
За 17 лет профессиональной деятельности у меня в названии должности никогда не было ни одного из слов «junior, middle, senior». Наверное, это какая-то очень локальная (московская?) зацикленность на таксономии и лычках.
А младший/старший? :)
Тоже нет. (А мидлам в трудовую книжку записывают «средний программист»?)
В большинстве стран такого являния как трудовая книжка просто нет.
И скажем у меня в контрактах тоже всегда было просто прописано что-то вроде «software developer» или «software engineer». Но при этом описании вакансий обычно содержали что-то из серии джун/миддл/сениор. Ну и зарплаты естественно заметно отличались.
И скажем у меня в контрактах тоже всегда было просто прописано что-то вроде «software developer» или «software engineer». Но при этом описании вакансий обычно содержали что-то из серии джун/миддл/сениор. Ну и зарплаты естественно заметно отличались.
в большинстве стран трудовая книжка — это стопка certificate of (past) employment свободной формы с указанием должности и контакта конторы. Отличие от трудовой книжки только в том, что стопка не подшита и оформление чуть-чуть отличается на каждой странице.
Ну да свободное оформление, не подшита, ты не обязан это хранить и показывать новому работодателю, а старый работодатель вроде бы даже не везде/всегда обязан тебе эти бумажки выдавать.
Я бы сказал что это заметно отличается от трудовой книжки :)
Я бы сказал что это заметно отличается от трудовой книжки :)
Ну вот у нас:
стажер
разработчик
старший разработчик
ведущий разработчик
главный разработчик
ну и далее еще более размыто:
консультант направления
архитектор направления
руководитель направления
И кто из них кто?
стажер
разработчик
старший разработчик
ведущий разработчик
главный разработчик
ну и далее еще более размыто:
консультант направления
архитектор направления
руководитель направления
И кто из них кто?
стажер, видимо, у вас джуниор или трейни
разработчик — миддл
старший — сеньор
ведущий — лид
главный, наверное, принципал
Фактически это всего лишь должности.
Скорее так
стажер — ? работает 20 часов в неделю. Обычно или человек совсем без опыта или студенты старших курсов
разработчик — джуниор
старший разработчик может быть как джуниором, так и мидлом
ведущий — мидл или сеньор (у нас тимлид долго был ведущим — не было ставок главных)
главный — сеньор
Так что все эти деления достаточно условны на самом деле.
Скорее так
стажер — ? работает 20 часов в неделю. Обычно или человек совсем без опыта или студенты старших курсов
разработчик — джуниор
старший разработчик может быть как джуниором, так и мидлом
ведущий — мидл или сеньор (у нас тимлид долго был ведущим — не было ставок главных)
главный — сеньор
Так что все эти деления достаточно условны на самом деле.
UFO just landed and posted this here
Из собственной практики: конкретно сейчас нахожусь в примерно таком же положении, как описано в статье, только без смены компании, сменился только проект — было веб-приложение на React + Node.js, стало веб-приложение на Java EE. Никаких формальных "вертикальных" перемещений при этом не было, как был по всем внутренним критериям мидлом, так им же и остался. Вникать в контекст, безусловно, надо (что дополнительно усложняется тем, что новый проект — дремучее легаси, да ещё и изначально от другой фирмы), но не сказал бы, что я себя из-за смены стека чувствую прямо совсем уж джуном — в конце концов, общие навыки никуда не делись, подтянуть на их основе частные — время требуется, но не так, чтобы я прямо выпадал из процесса на месяцы.
Cerberuser, спасибо!
Лет пять назад такие статьи вызывали у меня страх. Я училась в университете, и мои любимые языки программирования постепенно менялись. Я боялась застрять на уровне вечного перебежчика между технологиями.
Но потом стала замечать некоторые нестыковки:
— Даже формулировки некоторых вакансий не предполагают, что вы работали над чем-то конкретным. Вот фрагмент из реальной вакансии:
— Из общедоступных интервью и личных вопросов к разработчикам FAANG-компаний становится ясно, что они меняют языки внутри компании. И их собеседования изначально представляют собой написание алгоритмов на почти любом нравящемся языке, который для интервьюирующего может быть не главным.
— Даже в компании, где я работаю, на 2000+ человек у вас могут быть два разных проекта на двух разных языках, и если проектов нет, вас попытаются приложить к любому. Что со мной происходило. А так же просить выучить Perl или Go.
— Опыт pet-проектов или, тем более, вклада в чужие open source прооекты, может оказаться полезнее, чем production-опыт в своей фирме. Особенно если нет ревью кода или вы — единственный человек на проекте.
Но потом стала замечать некоторые нестыковки:
— Даже формулировки некоторых вакансий не предполагают, что вы работали над чем-то конкретным. Вот фрагмент из реальной вакансии:
Мы ожидаем, что вы:
• имеете опыт разработки на серверных языках не менее 3-х лет;
• умеете программировать на Python или хотите его изучить;
— Из общедоступных интервью и личных вопросов к разработчикам FAANG-компаний становится ясно, что они меняют языки внутри компании. И их собеседования изначально представляют собой написание алгоритмов на почти любом нравящемся языке, который для интервьюирующего может быть не главным.
— Даже в компании, где я работаю, на 2000+ человек у вас могут быть два разных проекта на двух разных языках, и если проектов нет, вас попытаются приложить к любому. Что со мной происходило. А так же просить выучить Perl или Go.
— Опыт pet-проектов или, тем более, вклада в чужие open source прооекты, может оказаться полезнее, чем production-опыт в своей фирме. Особенно если нет ревью кода или вы — единственный человек на проекте.
eridium, спасибо за комментарий. Если правильно понимаю, вы говорите о T-Shape инженерах. Можете уточнить, по личным ощущениям/отзывам коллег, вам одинаково комфортно работать с обоими языками?
Ну вот у меня 4 года опыта в разработке под android, но мобильная разработка порядком поднадоела, занимаюсь перепрофилированием во фронтенд. И ваш термин "про-джуниор" звучит довольно обидно. Как-то надо было выкатить проект на React Native в сжатые сроки командой из пары человек, пару недель поплевался от JS и дальше в обнимку з гуглом и доками пилил фичи практически в нормальном темпе. Сейчас на карантине устаканиваю свои разрозненные знания технологий, используемых на фронте (которые за несколько лет в IT появляются при минимальном уровне любопытства), и дальше с доступом к интернету смогу на реакте спокойно что-то делать, и надо мной не надо будет сидеть, как над джуном. Код на новом языке постепенно у разработчика становится более-менее идиоматичным через вполне вменяемое время. Особенно если проект делает не один человек или не с нуля — смотришь по сторонам и впитываешь общепринятые подходы.
Да всё, просто, заказчик хотел красные носки, а ему предлагают белые и флакон красной краски, типа покрасишь на досуге, понятно он не очень рад и красить будет, только если чёрных нет или если те что нашёл, вообще никуда не годятся и понятно, что он скидку захочет,
так что приходится постоянно парсить, то что в тренде, ну а то что в этот тренд частенько попадает не то, что хотелось бы уже издержки реальности, таков путь.
так что приходится постоянно парсить, то что в тренде, ну а то что в этот тренд частенько попадает не то, что хотелось бы уже издержки реальности, таков путь.
UFO just landed and posted this here
Я руковожу разработкой достаточно долгое время. И уверен, что стек практически не играет никакой роли уже через месяц после найма для настоящего senior-разработчика. Важно другое: понимание устройств СУБД, понимание того как вобще работает репликация, понимание, как строить отказоустойчивые системы, знание паттернов, умение строить масштабируемые системы. Вот это навыки, которые от стека не зависят.
Я спокойно консультирую компании, которые живут на монге, хотя монги у меня не было ни в одном проекте. Просто я знаю, как устроены СУБД, как работает железо, как работает ОС.
Я спокойно консультирую компании, которые живут на монге, хотя монги у меня не было ни в одном проекте. Просто я знаю, как устроены СУБД, как работает железо, как работает ОС.
А вот тут позвольте с Вами согласиться. На личном опыте.
Долгое время занимался разработкой в области, близкой к промавтоматизации — распределенная гетерогенная система на микроядерной архитектуре. Получил большой опыт в области многопоточной обработки и межпроцессного обмена данными. Просто на уровне понимания как надо такие вещи строить. От протоколов и до распределения функционала по нагрузке.
Потом пришел в финтех. Абсолютно другая платформа (AS/400 это вам не винда или никсы какие), другой язык (точнее, другая концепция — ILE — Integrated Language Environment где можно написать несколько модулей на разных языках и собрать все в единую программу), другие сущности.
И попалась мне задача, где нужно было обработать в сжатое время существенный объем данных. Решается путем распараллеливания обработки на несколько заданий (job). Одно задание — мастер — раздает пачки десяти исполнителям, получает и фиксирует результаты.
Очень мог предыдущий опыт. Достаточно было просто разобраться с транспортами, которые предоставляет платформа (а их несколько — unixsocket, socketpair, pipe, dataqueue, userqueue) и использовать те, что наиболее подходят для реализации данной конкретной задачи.
Все это по большей части от стеков не зависит, вещи скорее архитектурные. Стеки уже на уровне конкретной реализации задействуются. Когда знаешь что и как реализовывать.
Долгое время занимался разработкой в области, близкой к промавтоматизации — распределенная гетерогенная система на микроядерной архитектуре. Получил большой опыт в области многопоточной обработки и межпроцессного обмена данными. Просто на уровне понимания как надо такие вещи строить. От протоколов и до распределения функционала по нагрузке.
Потом пришел в финтех. Абсолютно другая платформа (AS/400 это вам не винда или никсы какие), другой язык (точнее, другая концепция — ILE — Integrated Language Environment где можно написать несколько модулей на разных языках и собрать все в единую программу), другие сущности.
И попалась мне задача, где нужно было обработать в сжатое время существенный объем данных. Решается путем распараллеливания обработки на несколько заданий (job). Одно задание — мастер — раздает пачки десяти исполнителям, получает и фиксирует результаты.
Очень мог предыдущий опыт. Достаточно было просто разобраться с транспортами, которые предоставляет платформа (а их несколько — unixsocket, socketpair, pipe, dataqueue, userqueue) и использовать те, что наиболее подходят для реализации данной конкретной задачи.
Все это по большей части от стеков не зависит, вещи скорее архитектурные. Стеки уже на уровне конкретной реализации задействуются. Когда знаешь что и как реализовывать.
Сначала внушат, что программирование это романтика и всякая там математика. А потом даже строку в число преобразовать не могут и бегут на /b/.
Я часто менял стек, начинал с С и ассемблера, потом были Perl, C++, Haskell, Scheme. Для отдельных задач использовал Fort, Erlang и Elm. Сейчас слегка подзастрял (6 лет) на Scala, но останавливаться не собираюсь, изучаю Coq и TLA+, и посматриваю на Rust (и ATS).
Но мне как-то странно применять к себе термин джуниор. Со сменой стека в зарплате я обычно не терял.
Но мне как-то странно применять к себе термин джуниор. Со сменой стека в зарплате я обычно не терял.
Sign up to leave a comment.
Про-джуниоры, или полмиллиона «потерянных» разработчиков