Pull to refresh

Comments 90

Может все-таки можно детализировать *парадигмальные уровни или в этом даже нет смысла?
Постараюсь сделать немного позже. Выложу сюда, в комментарии.
Не надо в комментарии — отдельный пост!..
Если я вас правильно понял, swh, то парадигмальный — это выход на «бизнес»?

А вот что есть для нас, айтишников, кросс-парадигмальный, это не понятно…
Мне бы хотелось сначала обдумать и изучить, прежде, чем предполагать :)
Слишком непростая тема, кажется. Было бы очень интересно поговорить-поисследовать с теми, кто «давно в деле» и мог бы оказаться на этих уровнях… Попробую найти.
По-моему, единственный адекватный способ оценки кандидата — это дать ему тестовую задачу, похожую на те, что он будет решать в дальнейшем. И внимательно смотреть, как он ее будет решать.
то весь l'amour de trua — в оценке «всех» знаний.
Знания не важны, важны умения.
Согласен с тестовым, пока это лучшее в практическом плане, что я видел. Но не всегда подходит. Кому-то не нравится выполнять тестовые, кто-то делаем неадекватные тестовые. А насчёт внимательно смотреть — можно конкретнее? Например, я меланхолик, и мне нужно какое-то время, чтобы обдумать задачу, а потом я начну делать. А какой-нибудь сангвиник сразу быстро включится в работу, потом перестраивать и тд. Как выбирать в таком случае?

Про умения тоже можно подробнее? Это знание, которые уже применял? А если, например, сменились условия? Скажем, долго писал на Spring, а теперь проект гораздо меньше, и нужно использовать что-то другое, тогда как оценить умения?
Меланхолик vs. сангвиник — вам с ним работать, смотрите на то, сможете ли.

Умения — это то, что он уже может делать из того, что вам надо. Если у вас в требованиях вакансии явно написан Spring, а он в нем ни разу не умеет, даже в рамках тестового задания, то пусть сначала научится, дома, да. Иначе непонятно, зачем пришел. Я могу подсказать какие-то мелочи, если вижу, что человек имеет близкий опыт, просто задачи у него были другие. Но учить с нуля — извините. Учить тоже возможно, но на совсем других условиях.
А разве сейчас важно что человек УЖЕ может делать? Технологии меняются настолько быстро что мне кажется на первое место давно вышло умение осваивать новое.
Один УЖЕ умеет и учился этому 5 лет, другой это УЖЕ освоил за пол-года. Кто круче? Риторический вопрос.
Раз вопрос риторический, то он ответа не требует, по определению.
Вы невнимательны. Если бы я был HR'ом а Вы кандидатом то считайте что собеседование провалено). Риторическим был второй вопрос. На всякий случай повторяю первый:
А разве сейчас важно что человек УЖЕ может делать? Технологии меняются настолько быстро что мне кажется на первое место давно вышло умение осваивать новое.
Ваш первый вопрос — тоже риторический. Вы не только совершенно явно подразумевали на него некоторый ответ («не важно»), но даже привели определенную аргументацию в пользу этого ответа.
Риторическим бы он не был в том случае, если бы вы явно указали на мнение собеседника. В данном же случае — вы именно что высказали свое мнение (в виде риторического вопроса) и предложили оппоненту подискутировать с этим мнением (приведя сразу начальный аргумент).
> Согласен с тестовым, пока это лучшее в практическом плане, что я видел. Но не всегда подходит. Кому-то не нравится выполнять тестовые, кто-то делаем неадекватные тестовые.

Можно предложить кандидату проанализировать вместе с вами уже сделанные коммиты по какой-нибудь несложной таске из недавних.
А почему по несложной? А если сеньёра принимаете?
Потому что надо за разумное время «въехать» в задачу, чтобы суметь о ней предметно поговорить.
Речь, в общем, о том, чтобы посмотреть, как человек будет вести себя с вашим кодом — это, вроде, и не тестовое задание, с другой же стороны, максимально близко к тому, чем он будет заниматься на работе. В каком виде это будет устроено — уже вопрос другой, все зависит от ситуации. Может, мы хотим именно на то посмотреть, как человек «въезжает», какие задаст вопросы и т.д…
Тогда сложная будет даже лучше.
Можно держать несколько тасок разного рода и выбирать в зависимости от того, как шло собеседование в начале и что именно мы хотим узнать о кандидате.
Конечно, интересный опыт. Но выглядит как частное решение. Сложно сделать задачки для «миддла» и «сеньера», которые покажут его уровень и одновременно будут несложными. А если он настоящий сеньёр, но не работал, например, с этим инструментом? Оценить сложно.
«Как въезжает» оценивать не стоит, наверное. Лучше оценивать результат, а не процесс. Кандидат может круто въезжать и всё может нравиться, а результативность может оказаться нулевой :(
Возможно, есть перечень задач, где «въезжаемость» имеет больший приоритет. Но пока — выглядит частным решением.
Как думаете?
Любой способ оценки будет частным решением, поэтому не стоит чересчур заморачиваться. Выберите способ, оцените кандидата, и примите его на работу.
И у вас еще будет три месяца испытательного срока.
> выглядит как частное решение.

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

А мидлов да сениоров в любом случае трудно оценивать (и чем выше возможная квалификация кандидата — тем труднее ее верно оценить).
Конечно, в целом я согласен, оценивать трудно. Думаю, что именно потому, что не существует объективной единицы оценки, и линейки. Мне, например, сложно оценить меня или моих коллег по уровню J-M-S. Им самим трудно. Не понятно. Senior в Ростове и Е-бурге — ОБЫЧНО (но не всегда) — не то же самое, что в Москве или Питере.
Так что, я согласен, потому и ищу некоторую меру.

Тоже как-то категорично. Верстальщикам, изо дня в день делающим одну и ту же работу — возможно.
Специалистам "креативных" направлений — не думаю.
Мне бы было интересно задавать таковым вопросы в духе "как сварить яйцо, имея только пластиковую линейку в 40 см?"


А вообще разные требования. На студенческий уровень важнее личные качества (ответственность, соображалка и прочее). На уровень начальника отдела — опыт в аналогичной деятельности. На уровень технического эксперта — знания.

А как тогда становиться начальником отдела, если без опыта никак?)

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

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

Важен баланс. Я бы даже иногда предпочел теоретика, который, зная как надо, быстро наработает навык, чем умельца, который со скоростью света бездумно копипастит сниппеты со StackOverflow.
Полностью согласен, спасибо.
А у Вас был подобный опыт? Показалось, что Вы в теме )
Да в принципе релевантный опыт — это пересадка готового специалиста с одной платформы на смежную. Скажем, с дотнета на руби. По началу он, как собака — все понимает, но сказать не может :) А там месяц-другой, и, глядишь, уже продуктивность почти на прежнем уровне.
А разработчик был опытный до пересадки? Middle, Senior?
Не суть важно, на самом деле. Важно, что опыт и знания остаются релевантными при смене инструмента, и идет просто как бы натягивание инструмента на имеющийся каркас и, как следствие, довольно быстрое возвращение на прежний уровень.

По опыту, скорость возвращения сильно зависит от схожести платформ на уровне парадигм и паттернов, а также способности отделять общие парадигмы и паттерны от деталей реализации, которая сильно положительно коррелирует с количеством знакомых платформ, парадигм и паттернов. Грубо, перейти с Java на C# когда ещё знаешь C++ и PHP, гораздо быстрее, чем с Java на Haskell, когда ничего кроме Java не знаешь, да и при работе с ней с её реализацией ФП не сталкивался. При это во втором случае опыт и знания платформы могут в целом заметно бОльшие, чем совокупно в первом.

У меня была проблема переключения с чистого Си на Java :)
Мне кажется, что высокоуровневые языки какие-нибудь есть, то тот же Haskell понимается очень быстро. Кроме деталей, конечно.
Поэтому я и написал «смежную». Скакнуть с одной парадигмы на другую, конечно, посложнее будет.

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


В общем, это всё здорово, но это от безделья.

Ну и всё вот это вот. Я скажу за себя: вопросы "по резюме" я задаю, чтобы зацепиться за какую-то конкретику, узнать субъективную и профессиональную оценку того или иного этапа деятельности, проекта и т.п. Резюме — это план сочинения, которое мне рассказывает собеседуемый.
Вопросы "по знаниям" — да, чтобы понять, насколько адекватна его самооценка, насколько он умеет рассуждать и искать ответы.


две основные линии проверки — «архитектурная» и «базовая»

В отсутствие объективных данных — высосано из пальца. Эти две вещи как минимум растут совместно и дополняют друг друга. Так же, как и умение музицировать (по своему опыту): сначала слушаешь песни, потом делаешь простейшие действия с инструментом, совмещаешь опыт и понимаешь, как в простейшем случае переложить песню на инструмент, потом, пользуясь опытом, на более сложных песнях прокачиваешь инструментальный скилл…
Почему не объединить в одну линейку или не подвыделить в рамках "архитектурной" линии подветки "голой теории" и "практической декомпозиции", ведь, например, очень многие математики сильны в теории, но не могут нормально сконструировать простейшие программы?
Соответственно, сами уровни тоже вызывают вопросы — почему так, а не иначе? Где тот практический критерий, который с большой долей вероятности позволяет поделить кандидатов по уровням? В статье описан "образ мышления" программиста, а не критерии — как их отличить.


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

Спасибо большое.
Полностью согласен с тем, что это пока большими мазками. Попробую исследовать критерий подробнее.

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

Постараюсь применить Ваши предложения насчёт «голой теории» и «практической декомпозиции».
Постараюсь применить Ваши предложения насчёт «голой теории» и «практической декомпозиции».

Это не предложение, а пример-наблюдение, почему недоработан принцип деления. :) Т.е. можно в равной степени и объединить всё это дело, и разделить ещё на кучу вариантов. А ответов на "почему именно так" и "как этот способ деления поможет" — не получается всё равно.


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

Интересно)
Попробую сделать )
«Системный уровень» — ни когда не полезу под капот, что бы оптимизировать свой код, принципиально не буду тратить время на эту суету, если что то тормозит надо сам алгоритм менять, а не шлифовать его напильником, наждачкой и пастой ГОИ.
Всегда полно больших задач, а тюнить лучше Васе поручить, ему нравиться, а у меня душа к этому не лежит.
Видимо буду вечный Middle.
Как думаете, это только у Вас, или такое чувство характерно «системному»?
я не знаю как правильно. я высказал своё отношение.
есть два аспекта — тактический и стратегический, тактический мне бесконечно скучен, потому что область его применения очень узкая, это знание не переноситься с платформы на платформу и устаревает в течении нескольких лет, поэтому мне жалко на это тратить свою жизнь.
Тем не менее когда у тебя 1000 шардов какого то сервиса, экономия в миллисекунду уже даст экономию в энергопотреблении ЦОДа, но пока это не мой масштаб, и надеюсь у меня всегда будет Вася на которого я эти заботы смогу переложить.
есть мастер кодер, есть мастер проектировщик, оба нужны и кодеров надо больше :)
Понял, спасибо :)
Почему такой странный заголовок «Рояль должен быть исчезнут...», меня в школе учили «Рояль должен исчезнуть»?
Это парафраз на «Карфаген должен быть разрушен» :)
С каких пор издевательство над русским языком с целью «похожести» стало парафразом?
Парафраз — изложение текста своими словами.
Странно, мне казалось, что термин правильный…
Это не издевательство, это народная воля, если хотите. К слову, фраза укладывается в рамки норм русского языка.
Это не издевательство над языком, а грамматический окказионализм.
Класс, спасибо :)
Тут ещё изменяется смысл — рояль во втором случае исчезает сам по себе, а в первом явно указывается, что он исчезает благодаря кому-то)
Всегда хотел знать и идиш тоже :)

Больно не было — было недоумение.
Но если это публикуют, значит это кому-нибудь надо.

Подскажите, пожалуйста, в чём недоумение?

А то что не было больно, значит вы согласны?
Не больно означает нет правды
Это и вызвало недоумение

У Вас клёвая логика :)
Больно бывает, если это значимо для человека лично. Здорово, что Вам было легче :)

Вы свой текст хоть помните — "Будет больно. Потому что будет правда."

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

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

Этот этап становления программиста, мне кажется одним из самых ключевых.

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

Это один из основных навыков именно коммерческого разработчика уровня от типичного миддла (в моём понимании :) ), наверное. Чувство экономической целесообразности применения тех или иных решений для конкретной задачи. На тот же SOLID не всегда нужно тратить время — пока будешь выделять ответственности, разделять интерфейсы и инвертировать зависимости, бизнес может быть ликвидирован по решению налоговой или конкуренты займут рынок. С одной стороны. А с другой, если решения задач будут в виде "плоских" скриптов на тысячи строк, то очень быстро простейшие изменения будут осуществляться очень долго без всяких гарантий, что ничего нужного не сломалось.


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

А, уловил, спасибо. Очень интересно. Надо подумать :)
Не соглашусь с привязкой уровней Бернштейна, особенно по верхним уровням, да и как упоминали выше — без конкретных наблюдений перевод уровней на область программирования не совсем корректно, хотя первые уровни на мой взгляд сложились верно. Так же не согласен и с цитатой о Ландау. Мир развивается и знать всё не возможно, может в своё время Ландау и знал «всю физику», но это было именно в то время. До него был пласт времени когда не было чёткого деления на физиков, математиков и прочих «чистых» учёных, были естествоиспытатели. Со временем области науки расширяются так, что невозможно быть знатоком всего, но можно знать одну область и затрагивать смежные. А Ваш последний пункт оооочень (на мой взгяд конечно) сильно напоминает современный DevOps.
Мне кажется, что DevOps немного другая ветка. Может быть, я как-то неудачно сформулировал. Можете уточнить, что имеете ввиду?
Эта статья для меня как увлекательная игра. Кто же автор? Бот? Человек в состоянии наркотического опьянения? Их совокупность?
Текст беспощадно перекручен. Логические конструкции словно пришли к нам из ассемблера, язык пестрит нарушением привычного порядка членов предложения, отсылки к чему угодно, переходы лица и числа автора, предложение в 46 слов длиной… Продолжать можно долго, но отличия от обычной речи видны невооружённым глазом.
Что характерно, информационная ценность близка к нолю.
Может быть и «погнали» человека с предыдущего места из-за того, что больше теоретизировал, нежели приносил практическую пользу. С такими людьми трудно сотрудничать, под любой вопрос они подводят фундаментальную базу и тем уводят вопрос из простоты в системность.

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

> «Будет больно. Потому что будет правда.»
Вот она, попытка сорвать покровы.
Да вроде другие цели преследовал :(
Жаль, что Вы не нашли там ничего ценного для себя. Только время зря потеряли :(
За последний год была тьма материалов в духе «нахрен круглые люки». Это, пожалуй, самый годный.
Вас не взяли на работу? Уволили? Какая-то депрессивная статья об какой-то «оценке»

Цель собеседования — убедится, что человек подходит. Вы, видимо, просто не подошли.

Люди всегда руководствуются своим опытом, учатся на ошибках. Тот, кто ранее учавствовал в значимых проектах, будет спрашивать/требовать того же, видимо потому, что считает это важным. Тот, кто однажды нанял/посоветовал плохого работника — будет стараться не повториться.
Например, я меланхолик, и мне нужно какое-то время, чтобы обдумать задачу, а потом я начну делать
У меня очень простой и эффективный подход: я даю простую задачу на базовые знания плюс много опциональных заданий. Времени — с достатком на базовую часть. Я не ожидаю, что кандидат выполнит все. Выполнит — круто. Важно, чтобы был готов некий код, написанный/скопированный из гугла, а потом начинается самое важное — мы его вместе смотрим и обсуждаем. И вот это главное, это то, что мы будем делать каждый день, если его наймут. Для обсуждения не нужна подготовка: это его код, он его написал, он может ответить на любой вопрос об этом коде и ему не нужно думать (он уже думал, пока писал его).

Меланхолик, дегенерат, блондинка (простите мои -измы) — неважно, если вы провалили такое собеседование, то «работать» вы уж точно не сможете.
Чтобы не пользоваться мифическими Junior, Senior, Mudakior
На 100% согласен с «мифическими». Есть стаж, просто и понятно, сколько лет и кем работал. Есть опыт работы и стек технологий. В какой момент из Junior-а становятся вдруг Senior — не понятно и главное — ничего не говорит. Отработал я 10 лет и что, стал Senior-ом? Старый чтоли стал?
Но еще бывают «состояния»
Извините, но это плохая отмазка для собеседований. Если человек уже в команде — то да, все делают скидку на болезни, это и ежу понятно.
Есть сейчас еще критерий — возраст. Как ни крути, но более молодого работодатель при прочих равных возьмет охотнее. А этих прочих равных и нет как раз. Молодой реже болеет, более обучаем, перспективен, зачастую не обременен семьей, т.е. мобилен итп. Поэтому некоторые работодатели явно указывают возраст коллектива как ориентир ожиданий.

Зачем работодателю монстры, видевшие ЕС ЭВМ, Агат и дискеты 5,25 ?!
Более взрослый = более опытный, даже это не работает, старый опыт не востребован, а скорее наоборот давит.

Про возраст есть еще особенность.
Еще есть тенденция перехода в ИТ с других специальностей в зрелом возрасте. В итоге, на позиции начинающего разработчика оказываются уже вполне зрелые люди. Обычно это воспринимается довольно тяжело.
Воспринимается кем?
Работодателями. Вы бы взяли 30-летнего начинающегося разработчика? До этого работал, например, юристом, потом окончил магистратуру в Бауманке или Физтехе, и хочет работать программистом.
Я почти такой начинающий.
Если не секрет, как Ваши успехи в плане устройства на работу?

Позвольте не согласится.
По моим наблюдениям, молодежь чаще болеет.
Обратная сторона мобильности — готовность после первой конференции убежать куда позовут хайповыми словами, молодой меньше проектов довёл до конца, и не просто в it, но и по жизни. При прочих равных, у более взрослого этот навык лучше развит, и спектр задач, которые он не профакапит по юнешеским максимализму и неусидчивости, и которые ему можно поручить — шире.
Семейный — значит прокачена коммуникация и навык управления людьми, и лучше понимает что людям по жизни надо, и какие они вообще, люди эти бывают.
И т.д. Могу долго продолжать…
А молодой что? Жизни то не видел ещё))

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

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

(просто в качестве оффтопа — с работой всё в порядке, это попытка найти материальную базу в уровне профессионального развития.)
Статья интересная. Но есть но. Как все устроено так и не рассказано. И на это есть причина. По большому счету никто этого не знает. Никто не может сказать как правильно и эффективно выбирать. Никто не может дать гарантий, что решение задачек или знание технологий даст хороший результат. К тому-же у каждого человека есть свои наклонности. Одному ближе одно, другому- другое. Например в Системном уровне вы упоминаете функциональный подход. Моей дочке 12 лет и я с ней занимаюсь программированием. Ей до Системного уровня как до луны. Но именно эту часть она понимает. Просто это ее. Она сама предпочитает этот подход. Не смотря на то, что мы с ней занимаемся Python она достаточно неплохо читает мой код на Haskell не зная его синтаксиса. Что-то я ей подсказываю, но идею она видит очень быстро. Так что я бы сказал, что структура должна быть менее линейная.

Я проходил собеседования и сам их проводил. И из своего опыта могу сказать, что понять что-то очень сложно. Тот, кто казался подходящим, на деле оказывался не очень-то и хорош, а тот, кто был с натяжкой через полгода-год становился настоящим гуру. И, по-моему, единственный путь- пробовать.
Спасибо большое. Полностью согласен, пробовать — единственный правильный путь. Но он дорогой, и не облагается теорией. Хотелось бы более-менее представлять, что происходит (хотя бы для себя, оценить по линейке себя, понять, куда двигаться), и понять до того, как взять на работу. В целом. Но, повторюсь, что я с Вами полностью согласен, единственный здравый путь — пробовать.

Немного не точно про функциональный подход. Суть в том, что будучи на системном уровне, можно воспроизводить альфа-операции, которые изменяют систему, привносят в неё новые элементы. Ваша дочь (то, что она делает, бесспорно — круто) использует инструменты, а не порождает их — и в этом отличие. Видимо, я как-то не точно описал этот момент, простите :)
С дороговизной тут все сложно. Во-первых у меня сложилось впечатление, что сеньоры тупо закончились. Они все уже где-то работают и получают очень приличные деньги. Переманивать их — дело хлопотное и очень дорогое. Накинуть нужно будет немало что бы соблазнить. И совсем не факт, что вы друг-другу подойдете. А деньги уже текут рекой. А если пробовать стартеров и джунов, то это уже совсем другие деньги. И если брать хотя-бы вменяемых и в меру тупящих уже есть большой шанс через год получить толкового мидла. Безусловно есть шанс, что мидлы будут уходить, но с другой стороны и поработать успеют. К тому-же есть очень интересный феномен. Если джун пишет код совместно с сеньором, то они вдвоем пишут как 1.5 сеньора. По сути ученик разгружает учителя от того, что для него рутина и в результате он больше делает того, за что ему платят такие деньжищи. Но не все готовы учить молодняк и не все на это способны.

Но разве компоновка существующих средств не порождает новые функции? И если нет, то как тогда из средств, предоставляемых языком программирования создать новые элементы? Где грань? В общем с описанием нужно что-то делать ;)
> Во-первых у меня сложилось впечатление, что сеньоры тупо закончились. Они все уже где-то работают и получают очень приличные деньги.

Чтобы стать сеньором — надо где-то работать, представьте себе. По-этому вполне логично, что почти все сеньоры уже трудоустроены, как и мидлы :)

Меня поражает это удивление тому факту, что серьезных специалистов на рынке мало. Ну конечно их мало — они ведь уже работают, иначе бы не стали серьезными специалистами. Это в любой отрасли так, не только IT (на самом деле в других отраслях даже сильнее выражено, т.к. в IT текучка откровенно выше).
Так я вроде бы и написал, что сеньоры работают. Прямо так и написал :«Они все уже где-то работают...». Это как бы и значит, что они трудоустроены. Вы видите в моих словах какие-то противоречия?

Серьезных специалистов действительно мало. Но когда директор R&D говорит, что они ищут специалиста уже второй год это уже как-то перебор. И это не единственный случай.

> Но когда директор R&D говорит, что они ищут специалиста уже второй год это уже как-то перебор.

Что значит «ищут»? Ищут просто такого человека в принципе? Ищут безработного? Ищут того, кто согласится на определенную зарплату? Это все разные «ищут» и результат по ним будет разный. Просто найти специалиста — очевидно, никакой проблемой не является. Зайдите в соседнюю контору и вон они там сидят — нашли!

С текучной в ит есть прям большие проблемы, думаю, оттуда и ожидание, что сеньёра найти должно быть проще. Всё же, среднее время работы в одном месте, например, в мобильном направлении — 2-3 года. Да и в базовой джаве — примерно такое же.
Единственное, думаю, что сеньёры уходять работать на Запад в основном — зарплаты всё равно выше.
С джунами и «взять на вырост» — полностью согласен. При неплохих входных данных (базовое техническое + усидчивость) можно быстро получать весьма существенные результаты.

Про совместную работу с сеньёром очень интересно. Если есть позитивный опыт и возможность описать, можно немного больше про это? Было бы здорово.

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

Да, с описанием нужно :) Спасибо)

Я метасистемный бородач. Не ищите меня, да и я вас искать не стану. Статья ни о чём. Враньё одно, бред. Да и про раздутое Наше ЧСВ и эгоцентризм тоже наврано, равно как и про постоянно преследующие галлюцинации и выдумки с домыслами относительно прочитанного текста, например. В топку, однозначно, хоть это и не второй том "Мёртвых Душ", написанный метасистемным пейсателем с псевдонимом Mykola Hohol

Если возможно, опишите, пожалуйста, своё видение проблемы — было бы очень интересно.
С точки зрения русского языка фраза «Рояль должен быть исчезнут» составлена некорректно. рояль можно разрушить, сломать, растворить, перенести, но нельзя его «исчезнуть». Слово исчезнуть можно применить к неодушевленному предмету, когда непонятно, что произошло — вещь исчезла, пропала из видимости. Идем дальше, правильная форма — они исчезнут, то есть будущее время, множественное число. Как это соотносится к слову рояль (единственное число)?
По теме.
Все попытки квалифицировать программистов, как к примеру, деление на 2 общие группы — профессионалы и любители (как в спорте) обычно всегда применимы к конкретному месту работы. Тоже самое происходит в школах и ВУЗах, когда ставят оценки за знания/умения — одна и та же отметка может означать совершенно разный уровень подготовленности. И неважно, столица это или провинция. Также и с программированием — здесь ты сеньор, потому что решаешь весь необходимый спектр задач и вполне удовлетворяешь своими знаниями и работоспособностью работодателя — а там ты не больше, чем джуниор, потому что не умеешь пользоваться какими-то инструментами и т.д. и т.п. Все оценки относительны.
Выше уже обсуждалось же. Глагол «исчезнут» — в этой фразе — грамматический окказионализм (авторское слово). Автором была додумана глаголу переходная форма, в которой он приобрел значение «сделать так чтобы объект исчез».
UFO just landed and posted this here
Sign up to leave a comment.

Articles