Время шло, росли гонорары. Индустрия породила подходы к разработке, позволяющие понять, сколько времени/сил нужно потратить на ту или иную задачу. Индустрия породила новый рынок и новые зарплаты. Возникла необходимость понять, кому именно их платить.
Собеседование — это игра. Иногда игра бывает интересной и в чём-то продуктивной, иногда она превращается в фарс. Иногда оценивают прошлое, иногда — настоящее. Есть некоторое общее понимание того, что нужно спрашивать, и нет совершенно никакого материального обоснования, почему необходимо спрашивать именно это. «Потому что мы будем как Гугл», «потому что не ясно, что вообще делать», «ведь нужно что-то спрашивать».
В статье мы приведём подход к оценке уровня профессионального развития. Покажем на пальцах, как горящие глаза и неумелые руки превращаются в шерстяной свитер и все эти «ты по-русски мне объясни, чем ты занимаешься». Покажем, как сесть за пианино и тыкать в клавиши на «Собачий вальс» превращается в «Полёт Валькирии», когда рояль исчезает и остаётся только музыка.
Будет больно. Потому что будет правда.
Почему то, что есть сейчас это уже кое-что
В компьютерных науках есть общие, необходимые вещи. Математическо-информатический склад ума, представление об алгоритмах, знание платформ и языков программирования. В целом, оценивая профессиональный уровень кандидата, смотрится несколько основных направлений: что делал, что знает, знает ли именно то, что нам нужно.
Чтобы не умереть со скуки, буду краток. Иногда важно, чтобы «ты у меня не первый». Иногда важно, что «он всё видел, он всё знал». Почти всегда важно, чтобы «ты могёшь как мы».
В общем, это всё здорово, но это от безделья. Опыт — в резюме; общие знания проверить не получится (они почти все не осознаваемы — кандидат просто не будет знать, что рассказывать, начнёт повторять резюме), а к стэку технологий при некотором «среднем уровне» можно подготовиться теоретически, и снова оценить не удастся. Или вы просто хотите убедиться, что он не врёт?
Если с «что делал» всё ясно,«как у нас» можно быстро выяснить, то весь l'amour de trua — в оценке «всех» знаний. Тут каждый сам за себя и кто во что горазд. На выбор инквизиции инструменты с малым дамагом, типа «гугловских задачек», увесистые среднячки вроде «расскажите принцип D из SOLID», и BFG «как именно работает volatile», «как в jvm происходит сложение», «что произойдёт, если в TreeSet добавить null». В третью категорию попадают любые малоизвестные особенности систем, о которых сам недавно прочитал и пока не успел забыть.
Почему это используется? Потому что при ответе на вопрос, кандидат может раскрыться, показать реальный уровень своих знаний. А может не раскрыться. Потому что может заклинить память, не вспомнится какая-нибудь особенность, будет названо неправильное слово, авитаминоз и клонит в сон, расстался с девушкой и переживает потерю, беспокоится, потому что нравится фирма… Но тут война и каждый сам за себя — «зачем нам в компании неудачники?».
Важно ли это всё? Важно. Практично? В целом, работает. Эффективно? Скорее, иллюзорно.
Чтобы иллюзий не было, нужна материя, законы её проявления и правильная линейка для оценки высоты столба писающего мальчика.
Размышления о материи и её законах
Ничего вульгарного. Материя — не вещество. Материя это то, из чего состоит Мир. На данный момент Материя открыты вещество, энергия, информация, время и пространство; а также переходы между ними. В китайской традиции это У-Син — 5 первоэлементов и переходы.
Для нас практический смысл состоит в том, что мы можем эту самую материю пощупать. Пока мы не выделили элемент, не научились его регистрировать — не ясно, есть ли он вообще. Хороший пример — радиоволны. Нет антенн — нет волн. Плохой пример — пространство. Попробуйте его не-зарегистрировать.
В общем. Материальный элемент в нашем случае — умение выполнять операции [определённого уровня]. Ща поясню.
Советский (психо)физиолог Николай Александрович Бернштейн ввёл в науку понятие уровней организации движения. Не вдаваясь в технические подробности, всё происходит так. Сначала ставим пальцы на клавиши пианино, потом гаммы играем и всякие «пусть бегут неуклюже», а через три года уже какие-никакие мелодии. Когда консерватория окончена, и даже успел забыть, где проходил твой второй настоящий концерт — если повезло и был талант — рояль, наконец, исчезает, остаётся только музыка.
На каждом этапе человек меняет уровень организации деятельности. Сначала — положение руки, моторика. Потом включение двух рук, одновременное чтение нот с листа. Потом так, чтобы мелодия узнавалась. Потом научиться не забывать бемоли…
В программировании вместо «изменения уровня организации» принято говорить «абстрагирование». Но такой термин не отражает суть, это раз, и там нет явной линейки — два. Кажется, что термин используется неправильно, но еще нужно подумать.
Крутая особенность в том, что с верхних уровней всегда можно спуститься вниз, а с нижних очень тяжело пониматься наверх. Это свойство [разной сложности при выполнении операций определённого уровня] мы и будем использовать для ранжирования.
Очень важный момент. «Изменение уровня» это изменение закона функционирования. Убедитесь, что понимаете это. Дёргать пальцами ручку и писать этой ручкой фразу — разная деятельность, и она подчиняется разным законам.
Что за операции?
В психологии есть «человек, который изменил всё» — это Жан Пиаже. Такое влияние, какое он оказал на психологию не сделал ни Зигмунд Фройд, ни кто-либо другой. Его главное достижение было в том, что он показал развитие детей в уровневой перспективе. Он показал, что ребёнок проходит в строгой последовательности уровни от сенсомоторного до стадии формальных операций.
Жан Пиаже померил когнитивное — умственное — развитие через выполнение операций определённого уровня. Это — гениально. Гениально потому, что оказалось работающим. Представляете? Догадка о том, что существуют именно уровни развития мышления, а не просто «натолчём, и как-нибудь всё поймёт». Гениально.
Стадии Пиаже заканчиваются на 12 годах. Его теорию продолжили препарировать, мусолить и развивать другие исследователи. L.M. Commons и F. Richards показали, что уровней в два раза больше, и они могут меняться и после 30-40 лет. Об этом будет ниже, сейчас еще пример про уровни и операции.
Математика — тоже уровневая система. Есть арифметика. Там есть числа и действия над ними. Сложение, вычитание там… В школе мы это делаем сначала в яблоках (чтобы сенсомоторный уровень задействовать), а потом в настоящих числах и даже буквах как следующему уровню абстракции.
А потом появились функции и зависимость одной «буквы» от другой. Осознайте, как это круто. Насладитесь тем, что меняется уровень операций. От простого 1+1=2 мы идём к a+b=c, а потом f(x) = k*x+b. Функциям безразличны сами «буквы». Что бы в неё ни попало (как в мясорубку — мясо, помидоры, ягоды), функция будет проводить одни и те же действия (будет делать «рубку»). Причём, иногда функция будет «выключаться», так как в некоторых местах она не будет существовать (попробуйте в мясорубку зафигачить мясо с гвоздями — в какой-то момент это безобразие съест ваши нервы, но не сдвинется ни на миллиметр гвоздя).
А потом приходит матан-но-джитсу. И мы исследуем «со следующего уровня», как ведут себя функции. Нам не надо вычислять их значения, нам надо понимать, как они себя ведут… Это как пьяным идти домой, сверяясь по указателям. Не важно, как именно вы поднимаете ноги, важно, чтобы дорога сходилась к вашему дому.
Программирование — уровневая система. И её материальную базу составляют операции.
Уровни операций
Коммонс и Ричардс выделяют такие операции (сложность растёт сверху вниз):
- сенсомоторные операции,
- конкретные,
- формальные,
- абстрактные,
- системные,
- метасистемные,
- парадигмальные,
- кросс-парадигмальные
Подробнее, применительно к нам.
Блаблабла: На примере ООП типа джавы, список довольно общий, две основные линии проверки — «архитектурная» и «базовая». «Архитектурная» это как бы «внешняя сторона», как соединять сущности, укрупнять, масштабировать. «Базовая» — «внутренняя», как устроено, что быстрее, какие особенности.
Сенсомоторный уровень означает прикосновение
В архитектурном плане это умение скачать и установить IDE, компилятор, научиться всё это запускать.
В базовом — какое-никакое математическое («информатическое») мышление, умозрительное, теоретическое представление об алгоритме, о сложности вычислений. Думаю, что «задачи гугла» относятся к этому уровню.
Конкретных операций уровень
Архитектура. Освоение примитивов языка, написание элементарных хеллоуворлдов, освоение понятия функции, умение создания класса как такового — в целом, односложные операции, которые приводят к видимым результатам.
В «базе» — cтруктуры данных. Уровень погружения — их применение, отличие друг от друга, вычислительная сложность, реализация простых алгоритмов, типа сортировки.
Это еще не уровень Junior — он возникнет позже. Это уровень стажёра. Теперь можно брать «в ружьё», но само ружьё давать еще рано.
Формальных операций
Архитектура. Между элементами появляется взаимодействие. Основа формального мышления — научиться видеть примитивные связи, зависимости, функции. На этом этапе осваивают интерфейсы, общение между классами на их основе. Внутренние классы, абстрактные — в целом, более сложные особенности языка.
База. Многопоточность, ошибки, файлы, сеть — уровень внешнего использования, не надо сразу лезть в дебри.
Стажёр двигается к тому, чтобы написать первое полноценное приложение, уже получается работать со связями между модулями, но еще не ясно, как делать правильно.
Если освоил — Junior.
Абстрактных операций
Архитектура. Формирование абстрактных и независимых друг от друга модулей. Принципы SOLID. Шаблоны проектирования. Еще не понятно, что лучше, но уже понятно, как делать.
База. Это — этап начала анализа. «Почему именно так?», «Что будет быстрее?», «Как именно это работает?». Осваиваются нормы работы с языком и платформой.
Привет, Middle.
Системный уровень
Архитектура. Система — элементы, объединенные общей целью. Цель — предоставление обработанных данных пользователю, за адекватное время, с минимальной нагрузкой ресурсов. Создаётся некоторый коридор действий, «как всё работает». MVC, MVP, MVVM, Clean и другие слова — отсюда. Но важнее другое.
На устойчивом системном уровне, человек может видоизменять коридор. Потому что это становится легко. Чувствуется, что имеющихся инструментов недостаточно, пальцы гудят из-за того, что мелодия в голове звучит гораздо лучше.
То, что рождается на этом уровне, эти яркие всполохи программерского света, назовём «системными альфа-операциями», или просто — «альфа». В джаве это было, например, добавление функциональщины, rxjava. В котле, например, extension functions.
В базе — изучает то, как организован сам язык, платформа. На jvm начинают лезть в байткод, смотрят, как всё преобразуется, перенастраивают виртуальную машину. Короче, тут начинается смак и удовольствие. На самом деле, только тут начинаешь чувствовать, что ты творец.
На этом этапе рояль начинает мешать. Пришел Senior.
Метасистемный
Это ребята другого пошиба. Обычно напрочь лишены чувства собственной важности и понтов типа «я знаю, что строки надо начинать сравнивать хешами только, если эти сравнения делаются чаще двух раз». Распознать просто — знает, как устроен стэк технологий минимум на один уровень «вниз» (иногда и «вверх»), обычно — на несколько уровней.
Рояль мешает как родители влюбленным подросткам, пальцы перенапрягаются стучать по музыкальной зебре, лицо синеет, очки превращаются в телескопы. Так рождается музыка Баха и код чуваков, которые делают OpenBsd.
Дальше по уровням «одни черепахи». Различия стираются. Их всех огульно называют «old school». Их редко принимают на работу по объявлению. Их редко по объявлениям ищут.
В целом, это вымирающий вид. Как Ландау считается последним физиком, который знал всю физику, эти ребята могут стать последним поколением, кто прошел путь от паяльника и борьбы за память до «эджайл и блокчейн».
К чему всё это?
Мы можем дорабатывать и конкретизировать всю линейку. Чтобы не пользоваться мифическими Junior, Senior, Mudakior, которые отличаются в зависимости от места работы, региона и страны. Это добавит прозрачности, облегчит поиск работы и найм.
Хотите нанимать «как раньше» — нет проблем, но теперь можно договориться. Чтобы стало ясно, к чему готовиться, как оценивать себя и других, и почему может не получиться. Просто будет понятнее, без всяких мексиканских эмигрантов.
Карфаген иллюзий при оценке уровня профессионального развития должен быть разрушен.
Важные уточнения
«Уровень» это «уровень». Его очень тяжело потерять. Но еще бывают «состояния». Переехал в другую страну, погиб близкий человек, неделю мучает бессонница — это всё уважительные причины, из-за которых «состояние» может временно снижать «уровень». «Состояние» это когда будучи на некотором уровне развития, человек начинает больше концентрироваться на другом, обычно, более низком. Когда у человека горе — его состояние падает на один-два уровня, иногда вплоть до самого низа, когда он открывает студию и втыкает в монитор, не понимая, что там написано.
Это — человек, это — бывает. Не оставайтесь к этому равнодушными.
Это — диалог, автор не выступает «самым умным» и не рассказывает другим, как жить. Ему кажется, что сотворчество более продуктивно. Кажется, что люди для того и выдумали сетевое взаимодействие, чтобы могли оцениваться, обсуждаться и дополняться Идеи, а не их авторы или авторство. Кажется, что мы стоим на пороге глобальных изменений, как в индустрии, так и в нашей жизни. Остаётся понять, какое место мы там займём.
Комментарии (88)
sshmakov
17.12.2017 23:13По-моему, единственный адекватный способ оценки кандидата — это дать ему тестовую задачу, похожую на те, что он будет решать в дальнейшем. И внимательно смотреть, как он ее будет решать.
то весь l'amour de trua — в оценке «всех» знаний.
Знания не важны, важны умения.
swh Автор
17.12.2017 23:19Согласен с тестовым, пока это лучшее в практическом плане, что я видел. Но не всегда подходит. Кому-то не нравится выполнять тестовые, кто-то делаем неадекватные тестовые. А насчёт внимательно смотреть — можно конкретнее? Например, я меланхолик, и мне нужно какое-то время, чтобы обдумать задачу, а потом я начну делать. А какой-нибудь сангвиник сразу быстро включится в работу, потом перестраивать и тд. Как выбирать в таком случае?
Про умения тоже можно подробнее? Это знание, которые уже применял? А если, например, сменились условия? Скажем, долго писал на Spring, а теперь проект гораздо меньше, и нужно использовать что-то другое, тогда как оценить умения?sshmakov
18.12.2017 09:55Меланхолик vs. сангвиник — вам с ним работать, смотрите на то, сможете ли.
Умения — это то, что он уже может делать из того, что вам надо. Если у вас в требованиях вакансии явно написан Spring, а он в нем ни разу не умеет, даже в рамках тестового задания, то пусть сначала научится, дома, да. Иначе непонятно, зачем пришел. Я могу подсказать какие-то мелочи, если вижу, что человек имеет близкий опыт, просто задачи у него были другие. Но учить с нуля — извините. Учить тоже возможно, но на совсем других условиях.
Dessloch
18.12.2017 10:00А разве сейчас важно что человек УЖЕ может делать? Технологии меняются настолько быстро что мне кажется на первое место давно вышло умение осваивать новое.
Один УЖЕ умеет и учился этому 5 лет, другой это УЖЕ освоил за пол-года. Кто круче? Риторический вопрос.sshmakov
18.12.2017 10:02Раз вопрос риторический, то он ответа не требует, по определению.
Dessloch
18.12.2017 10:27Вы невнимательны. Если бы я был HR'ом а Вы кандидатом то считайте что собеседование провалено). Риторическим был второй вопрос. На всякий случай повторяю первый:
А разве сейчас важно что человек УЖЕ может делать? Технологии меняются настолько быстро что мне кажется на первое место давно вышло умение осваивать новое.Druu
18.12.2017 17:17Ваш первый вопрос — тоже риторический. Вы не только совершенно явно подразумевали на него некоторый ответ («не важно»), но даже привели определенную аргументацию в пользу этого ответа.
Риторическим бы он не был в том случае, если бы вы явно указали на мнение собеседника. В данном же случае — вы именно что высказали свое мнение (в виде риторического вопроса) и предложили оппоненту подискутировать с этим мнением (приведя сразу начальный аргумент).
Druu
18.12.2017 17:09> Согласен с тестовым, пока это лучшее в практическом плане, что я видел. Но не всегда подходит. Кому-то не нравится выполнять тестовые, кто-то делаем неадекватные тестовые.
Можно предложить кандидату проанализировать вместе с вами уже сделанные коммиты по какой-нибудь несложной таске из недавних.swh Автор
18.12.2017 17:29А почему по несложной? А если сеньёра принимаете?
Druu
18.12.2017 17:39Потому что надо за разумное время «въехать» в задачу, чтобы суметь о ней предметно поговорить.
Речь, в общем, о том, чтобы посмотреть, как человек будет вести себя с вашим кодом — это, вроде, и не тестовое задание, с другой же стороны, максимально близко к тому, чем он будет заниматься на работе. В каком виде это будет устроено — уже вопрос другой, все зависит от ситуации. Может, мы хотим именно на то посмотреть, как человек «въезжает», какие задаст вопросы и т.д…
Тогда сложная будет даже лучше.
Можно держать несколько тасок разного рода и выбирать в зависимости от того, как шло собеседование в начале и что именно мы хотим узнать о кандидате.swh Автор
18.12.2017 17:59Конечно, интересный опыт. Но выглядит как частное решение. Сложно сделать задачки для «миддла» и «сеньера», которые покажут его уровень и одновременно будут несложными. А если он настоящий сеньёр, но не работал, например, с этим инструментом? Оценить сложно.
«Как въезжает» оценивать не стоит, наверное. Лучше оценивать результат, а не процесс. Кандидат может круто въезжать и всё может нравиться, а результативность может оказаться нулевой :(
Возможно, есть перечень задач, где «въезжаемость» имеет больший приоритет. Но пока — выглядит частным решением.
Как думаете?sshmakov
18.12.2017 19:54Любой способ оценки будет частным решением, поэтому не стоит чересчур заморачиваться. Выберите способ, оцените кандидата, и примите его на работу.
И у вас еще будет три месяца испытательного срока.
Druu
19.12.2017 04:55> выглядит как частное решение.
Конечно, я же говорил выше о том, что все зависит от ситуации. В любом случае, проведение собеседования — это работа, и как и для любой другой работы — качество результата зависит от квалификации исполнителя, в первую очередь, а уже во вторую (в третью или дальше) от используемых им методов.
А мидлов да сениоров в любом случае трудно оценивать (и чем выше возможная квалификация кандидата — тем труднее ее верно оценить).swh Автор
19.12.2017 04:59Конечно, в целом я согласен, оценивать трудно. Думаю, что именно потому, что не существует объективной единицы оценки, и линейки. Мне, например, сложно оценить меня или моих коллег по уровню J-M-S. Им самим трудно. Не понятно. Senior в Ростове и Е-бурге — ОБЫЧНО (но не всегда) — не то же самое, что в Москве или Питере.
Так что, я согласен, потому и ищу некоторую меру.
kayan
17.12.2017 23:24Тоже как-то категорично. Верстальщикам, изо дня в день делающим одну и ту же работу — возможно.
Специалистам "креативных" направлений — не думаю.
Мне бы было интересно задавать таковым вопросы в духе "как сварить яйцо, имея только пластиковую линейку в 40 см?"
А вообще разные требования. На студенческий уровень важнее личные качества (ответственность, соображалка и прочее). На уровень начальника отдела — опыт в аналогичной деятельности. На уровень технического эксперта — знания.
swh Автор
17.12.2017 23:30А как тогда становиться начальником отдела, если без опыта никак?)
В остальном, согласен.
dimkrayan
18.12.2017 15:16Я полагаю, левелап до начальника происходит не «с улицы».
А работая в коллективе, вполне реально несколько десятков раз выполнить обязанности начальника: взять шефство над джуном, поруководить коллегами в рамках краткосрочного подпроекта, на уровнях повыше — позамещать начальника в отпуске; в конце концов — просто подойти к начальнику и попросить дать соответствующую задачку.
nikolayv81
19.12.2017 08:19Из того что чаше встречается — занятие должности то при уходе начальника или формальный "руководитель группы" с последующим закреплением у другого работодателя.
Cromathaar
18.12.2017 09:18Важен баланс. Я бы даже иногда предпочел теоретика, который, зная как надо, быстро наработает навык, чем умельца, который со скоростью света бездумно копипастит сниппеты со StackOverflow.
swh Автор
18.12.2017 15:18Полностью согласен, спасибо.
А у Вас был подобный опыт? Показалось, что Вы в теме )Cromathaar
18.12.2017 18:13Да в принципе релевантный опыт — это пересадка готового специалиста с одной платформы на смежную. Скажем, с дотнета на руби. По началу он, как собака — все понимает, но сказать не может :) А там месяц-другой, и, глядишь, уже продуктивность почти на прежнем уровне.
swh Автор
18.12.2017 18:15А разработчик был опытный до пересадки? Middle, Senior?
Cromathaar
19.12.2017 11:52Не суть важно, на самом деле. Важно, что опыт и знания остаются релевантными при смене инструмента, и идет просто как бы натягивание инструмента на имеющийся каркас и, как следствие, довольно быстрое возвращение на прежний уровень.
VolCh
19.12.2017 12:16По опыту, скорость возвращения сильно зависит от схожести платформ на уровне парадигм и паттернов, а также способности отделять общие парадигмы и паттерны от деталей реализации, которая сильно положительно коррелирует с количеством знакомых платформ, парадигм и паттернов. Грубо, перейти с Java на C# когда ещё знаешь C++ и PHP, гораздо быстрее, чем с Java на Haskell, когда ничего кроме Java не знаешь, да и при работе с ней с её реализацией ФП не сталкивался. При это во втором случае опыт и знания платформы могут в целом заметно бОльшие, чем совокупно в первом.
swh Автор
19.12.2017 22:44У меня была проблема переключения с чистого Си на Java :)
Мне кажется, что высокоуровневые языки какие-нибудь есть, то тот же Haskell понимается очень быстро. Кроме деталей, конечно.
Cromathaar
20.12.2017 11:48Поэтому я и написал «смежную». Скакнуть с одной парадигмы на другую, конечно, посложнее будет.
kayan
17.12.2017 23:15Идея перенести уровни Бернштейна в программирование очень интересна, но, без реальных данных, наблюдений, статистики — останется только идеей; в текущем виде, я считаю, её описание некорректно. Я выборочно по пунктам придерусь:
В общем, это всё здорово, но это от безделья.
Ну и всё вот это вот. Я скажу за себя: вопросы "по резюме" я задаю, чтобы зацепиться за какую-то конкретику, узнать субъективную и профессиональную оценку того или иного этапа деятельности, проекта и т.п. Резюме — это план сочинения, которое мне рассказывает собеседуемый.
Вопросы "по знаниям" — да, чтобы понять, насколько адекватна его самооценка, насколько он умеет рассуждать и искать ответы.
две основные линии проверки — «архитектурная» и «базовая»
В отсутствие объективных данных — высосано из пальца. Эти две вещи как минимум растут совместно и дополняют друг друга. Так же, как и умение музицировать (по своему опыту): сначала слушаешь песни, потом делаешь простейшие действия с инструментом, совмещаешь опыт и понимаешь, как в простейшем случае переложить песню на инструмент, потом, пользуясь опытом, на более сложных песнях прокачиваешь инструментальный скилл…
Почему не объединить в одну линейку или не подвыделить в рамках "архитектурной" линии подветки "голой теории" и "практической декомпозиции", ведь, например, очень многие математики сильны в теории, но не могут нормально сконструировать простейшие программы?
Соответственно, сами уровни тоже вызывают вопросы — почему так, а не иначе? Где тот практический критерий, который с большой долей вероятности позволяет поделить кандидатов по уровням? В статье описан "образ мышления" программиста, а не критерии — как их отличить.
Идея, повторюсь, интересная, применима не только к программистам, а к любым областям с широким стеком научения — но текущее описание на практике пока бесполезно. Любой здравый собеседующий и делит субъективно людей по похожим уровням.
swh Автор
17.12.2017 23:28Спасибо большое.
Полностью согласен с тем, что это пока большими мазками. Попробую исследовать критерий подробнее.
Линии «архитектурная» и «базовая» это от того, что использование модуля не то же самое, что его построение, различаются законы. Названия так себе, конечно. «Базовая», потому что вроде как относится к базе информатики и программирования — алгоритмы, особенности языка и т.д. Ну и «архитектурная» — определяет связь модулей и всё такое.
Постараюсь применить Ваши предложения насчёт «голой теории» и «практической декомпозиции».kayan
18.12.2017 00:02Постараюсь применить Ваши предложения насчёт «голой теории» и «практической декомпозиции».
Это не предложение, а пример-наблюдение, почему недоработан принцип деления. :) Т.е. можно в равной степени и объединить всё это дело, и разделить ещё на кучу вариантов. А ответов на "почему именно так" и "как этот способ деления поможет" — не получается всё равно.
Моё самое главное предложение — просуммировать практический опыт реальных людей-кандидатов. Опять же, каким образом, какими исследованиями собрать эти данные — я не знаю.
SbWereWolf
18.12.2017 00:47«Системный уровень» — ни когда не полезу под капот, что бы оптимизировать свой код, принципиально не буду тратить время на эту суету, если что то тормозит надо сам алгоритм менять, а не шлифовать его напильником, наждачкой и пастой ГОИ.
Всегда полно больших задач, а тюнить лучше Васе поручить, ему нравиться, а у меня душа к этому не лежит.
Видимо буду вечный Middle.swh Автор
18.12.2017 06:13Как думаете, это только у Вас, или такое чувство характерно «системному»?
SbWereWolf
18.12.2017 09:28я не знаю как правильно. я высказал своё отношение.
есть два аспекта — тактический и стратегический, тактический мне бесконечно скучен, потому что область его применения очень узкая, это знание не переноситься с платформы на платформу и устаревает в течении нескольких лет, поэтому мне жалко на это тратить свою жизнь.
Тем не менее когда у тебя 1000 шардов какого то сервиса, экономия в миллисекунду уже даст экономию в энергопотреблении ЦОДа, но пока это не мой масштаб, и надеюсь у меня всегда будет Вася на которого я эти заботы смогу переложить.
есть мастер кодер, есть мастер проектировщик, оба нужны и кодеров надо больше :)
third112
18.12.2017 02:33Почему такой странный заголовок «Рояль должен быть исчезнут...», меня в школе учили «Рояль должен исчезнуть»?
swh Автор
18.12.2017 06:14Это парафраз на «Карфаген должен быть разрушен» :)
DocJester
18.12.2017 15:19С каких пор издевательство над русским языком с целью «похожести» стало парафразом?
Парафраз — изложение текста своими словами.
swh Автор
18.12.2017 15:21Странно, мне казалось, что термин правильный…
Это не издевательство, это народная воля, если хотите. К слову, фраза укладывается в рамки норм русского языка.
Germanets
18.12.2017 16:34Тут ещё изменяется смысл — рояль во втором случае исчезает сам по себе, а в первом явно указывается, что он исчезает благодаря кому-то)
tyomitch
18.12.2017 20:00Переходное употребление глагола «исчезнуть» особенно характерно для израильского русского.
sbnur
18.12.2017 07:31Больно не было — было недоумение.
Но если это публикуют, значит это кому-нибудь надо.
PoisonousJohn
18.12.2017 09:08+1В моем понимании, упущен один из важных уровней развития — понимание, что программирование не только про код, архитектуру и разработку.
Говоря в терминах статьи — это еще более высокий уровень. Уровень осознания задачи и понимания ее значения в бизнесе. Именно это понимание останавливает человека от того, чтобы писать код ради самого кода.
Этот этап становления программиста, мне кажется одним из самых ключевых.
А в остальном — идея статьи очень интересна, спасибо.swh Автор
18.12.2017 15:14Понял, спасибо большое.
Вы думаете это связано с навыком программирования, «выполнением операций», или это больше про развитие профессионала вообще? Можно ли пункт про «нужно ли это вообще» отнести к другой линии становления человека как профессионала? Скажем «исполнитель» — «средний менеджер» — «управляющий разработкой, который понимает, нужно ли это бизнесу»?
Или это всё же относится к профессиональному развитию именно «компьютерных навыков»?VolCh
18.12.2017 18:51Это один из основных навыков именно коммерческого разработчика уровня от типичного миддла (в моём понимании :) ), наверное. Чувство экономической целесообразности применения тех или иных решений для конкретной задачи. На тот же SOLID не всегда нужно тратить время — пока будешь выделять ответственности, разделять интерфейсы и инвертировать зависимости, бизнес может быть ликвидирован по решению налоговой или конкуренты займут рынок. С одной стороны. А с другой, если решения задач будут в виде "плоских" скриптов на тысячи строк, то очень быстро простейшие изменения будут осуществляться очень долго без всяких гарантий, что ничего нужного не сломалось.
При разработке для души можно создавать сколь угодно сложные архитектуры или оптимизированные до последнего тика процессора, не имея ограничений на сроки и бюджеты. А коммерческий разработчик должен уметь составить пускай примитивное, пускай из пальцы высосанное, но технико-экономическое обоснование для выбранного пути решения поставленной задачи (желательно с как минимум одной альтернативой). рассматриваться должны в том числе и такие варианты как "найти бесплатную систему", "купить платную", а не только "напишем это как писали всё остальное" или "для этой задачи надо полностью переписать всё"
heleo
18.12.2017 09:09Не соглашусь с привязкой уровней Бернштейна, особенно по верхним уровням, да и как упоминали выше — без конкретных наблюдений перевод уровней на область программирования не совсем корректно, хотя первые уровни на мой взгляд сложились верно. Так же не согласен и с цитатой о Ландау. Мир развивается и знать всё не возможно, может в своё время Ландау и знал «всю физику», но это было именно в то время. До него был пласт времени когда не было чёткого деления на физиков, математиков и прочих «чистых» учёных, были естествоиспытатели. Со временем области науки расширяются так, что невозможно быть знатоком всего, но можно знать одну область и затрагивать смежные. А Ваш последний пункт оооочень (на мой взгяд конечно) сильно напоминает современный DevOps.
swh Автор
18.12.2017 15:16Мне кажется, что DevOps немного другая ветка. Может быть, я как-то неудачно сформулировал. Можете уточнить, что имеете ввиду?
Electrohedgehog
18.12.2017 09:34Эта статья для меня как увлекательная игра. Кто же автор? Бот? Человек в состоянии наркотического опьянения? Их совокупность?
Текст беспощадно перекручен. Логические конструкции словно пришли к нам из ассемблера, язык пестрит нарушением привычного порядка членов предложения, отсылки к чему угодно, переходы лица и числа автора, предложение в 46 слов длиной… Продолжать можно долго, но отличия от обычной речи видны невооружённым глазом.
Что характерно, информационная ценность близка к нолю.NeverIn
18.12.2017 10:59Может быть и «погнали» человека с предыдущего места из-за того, что больше теоретизировал, нежели приносил практическую пользу. С такими людьми трудно сотрудничать, под любой вопрос они подводят фундаментальную базу и тем уводят вопрос из простоты в системность.
Сейчас, увы, технологии в IT слишком быстро меняются чтобы делать все «правильно», системно. На это просто нет времени, или быстрый результат или уже вылетаешь с рынка.
strangeraven
18.12.2017 13:31У меня от стиля изложения сложилось впечатление, что автор просто хочет выпендриться.
Накрутить слова так, чтобы с одной стороны было плохо понятно, а с другой выглядело по «философски», и читатели пытались выловить смысл из глубины её глубин. Ну и как водится, винегрет из терминов, жаргонизмов и отсылок ко всему попало.
> «Будет больно. Потому что будет правда.»
Вот она, попытка сорвать покровы.
swh Автор
18.12.2017 15:24Жаль, что Вы не нашли там ничего ценного для себя. Только время зря потеряли :(
greabock
18.12.2017 12:05За последний год была тьма материалов в духе «нахрен круглые люки». Это, пожалуй, самый годный.
Sinatr
18.12.2017 12:31Вас не взяли на работу? Уволили? Какая-то депрессивная статья об какой-то «оценке»
Цель собеседования — убедится, что человек подходит. Вы, видимо, просто не подошли.
Люди всегда руководствуются своим опытом, учатся на ошибках. Тот, кто ранее учавствовал в значимых проектах, будет спрашивать/требовать того же, видимо потому, что считает это важным. Тот, кто однажды нанял/посоветовал плохого работника — будет стараться не повториться.
Например, я меланхолик, и мне нужно какое-то время, чтобы обдумать задачу, а потом я начну делать
У меня очень простой и эффективный подход: я даю простую задачу на базовые знания плюс много опциональных заданий. Времени — с достатком на базовую часть. Я не ожидаю, что кандидат выполнит все. Выполнит — круто. Важно, чтобы был готов некий код, написанный/скопированный из гугла, а потом начинается самое важное — мы его вместе смотрим и обсуждаем. И вот это главное, это то, что мы будем делать каждый день, если его наймут. Для обсуждения не нужна подготовка: это его код, он его написал, он может ответить на любой вопрос об этом коде и ему не нужно думать (он уже думал, пока писал его).
Меланхолик, дегенерат, блондинка (простите мои -измы) — неважно, если вы провалили такое собеседование, то «работать» вы уж точно не сможете.
Чтобы не пользоваться мифическими Junior, Senior, Mudakior
На 100% согласен с «мифическими». Есть стаж, просто и понятно, сколько лет и кем работал. Есть опыт работы и стек технологий. В какой момент из Junior-а становятся вдруг Senior — не понятно и главное — ничего не говорит. Отработал я 10 лет и что, стал Senior-ом? Старый чтоли стал?
Но еще бывают «состояния»
Извините, но это плохая отмазка для собеседований. Если человек уже в команде — то да, все делают скидку на болезни, это и ежу понятно.NeverIn
18.12.2017 13:23Есть сейчас еще критерий — возраст. Как ни крути, но более молодого работодатель при прочих равных возьмет охотнее. А этих прочих равных и нет как раз. Молодой реже болеет, более обучаем, перспективен, зачастую не обременен семьей, т.е. мобилен итп. Поэтому некоторые работодатели явно указывают возраст коллектива как ориентир ожиданий.
Зачем работодателю монстры, видевшие ЕС ЭВМ, Агат и дискеты 5,25 ?!
Более взрослый = более опытный, даже это не работает, старый опыт не востребован, а скорее наоборот давит.
swh Автор
18.12.2017 15:41Про возраст есть еще особенность.
Еще есть тенденция перехода в ИТ с других специальностей в зрелом возрасте. В итоге, на позиции начинающего разработчика оказываются уже вполне зрелые люди. Обычно это воспринимается довольно тяжело.
samizdam
18.12.2017 19:30+1Позвольте не согласится.
По моим наблюдениям, молодежь чаще болеет.
Обратная сторона мобильности — готовность после первой конференции убежать куда позовут хайповыми словами, молодой меньше проектов довёл до конца, и не просто в it, но и по жизни. При прочих равных, у более взрослого этот навык лучше развит, и спектр задач, которые он не профакапит по юнешеским максимализму и неусидчивости, и которые ему можно поручить — шире.
Семейный — значит прокачена коммуникация и навык управления людьми, и лучше понимает что людям по жизни надо, и какие они вообще, люди эти бывают.
И т.д. Могу долго продолжать…
А молодой что? Жизни то не видел ещё))
swh Автор
18.12.2017 15:39С Вашим подходом согласен, конечно. Правда, кажется, что его тяжело масштабировать. Вы сможете определить, подходит он лично Вам или нет, но не его уровень. Уверен, что это один из лучших подходов в плане конкретного приёма на работу, но не в целом, оценки уровня.
«Состояние» это больше не про собеседование, а про профессиональные навыки в целом. Не в коем случае не говорил про отмазки. На приёме на работу — как на войне — кто лучше подготовился, тот и молодец.
Это попытка немного абстрагироваться от самого приёма — к оценке уровня.
(просто в качестве оффтопа — с работой всё в порядке, это попытка найти материальную базу в уровне профессионального развития.)
evseev
18.12.2017 22:18+1Статья интересная. Но есть но. Как все устроено так и не рассказано. И на это есть причина. По большому счету никто этого не знает. Никто не может сказать как правильно и эффективно выбирать. Никто не может дать гарантий, что решение задачек или знание технологий даст хороший результат. К тому-же у каждого человека есть свои наклонности. Одному ближе одно, другому- другое. Например в Системном уровне вы упоминаете функциональный подход. Моей дочке 12 лет и я с ней занимаюсь программированием. Ей до Системного уровня как до луны. Но именно эту часть она понимает. Просто это ее. Она сама предпочитает этот подход. Не смотря на то, что мы с ней занимаемся Python она достаточно неплохо читает мой код на Haskell не зная его синтаксиса. Что-то я ей подсказываю, но идею она видит очень быстро. Так что я бы сказал, что структура должна быть менее линейная.
Я проходил собеседования и сам их проводил. И из своего опыта могу сказать, что понять что-то очень сложно. Тот, кто казался подходящим, на деле оказывался не очень-то и хорош, а тот, кто был с натяжкой через полгода-год становился настоящим гуру. И, по-моему, единственный путь- пробовать.swh Автор
19.12.2017 00:55Спасибо большое. Полностью согласен, пробовать — единственный правильный путь. Но он дорогой, и не облагается теорией. Хотелось бы более-менее представлять, что происходит (хотя бы для себя, оценить по линейке себя, понять, куда двигаться), и понять до того, как взять на работу. В целом. Но, повторюсь, что я с Вами полностью согласен, единственный здравый путь — пробовать.
Немного не точно про функциональный подход. Суть в том, что будучи на системном уровне, можно воспроизводить альфа-операции, которые изменяют систему, привносят в неё новые элементы. Ваша дочь (то, что она делает, бесспорно — круто) использует инструменты, а не порождает их — и в этом отличие. Видимо, я как-то не точно описал этот момент, простите :)evseev
19.12.2017 12:50С дороговизной тут все сложно. Во-первых у меня сложилось впечатление, что сеньоры тупо закончились. Они все уже где-то работают и получают очень приличные деньги. Переманивать их — дело хлопотное и очень дорогое. Накинуть нужно будет немало что бы соблазнить. И совсем не факт, что вы друг-другу подойдете. А деньги уже текут рекой. А если пробовать стартеров и джунов, то это уже совсем другие деньги. И если брать хотя-бы вменяемых и в меру тупящих уже есть большой шанс через год получить толкового мидла. Безусловно есть шанс, что мидлы будут уходить, но с другой стороны и поработать успеют. К тому-же есть очень интересный феномен. Если джун пишет код совместно с сеньором, то они вдвоем пишут как 1.5 сеньора. По сути ученик разгружает учителя от того, что для него рутина и в результате он больше делает того, за что ему платят такие деньжищи. Но не все готовы учить молодняк и не все на это способны.
Но разве компоновка существующих средств не порождает новые функции? И если нет, то как тогда из средств, предоставляемых языком программирования создать новые элементы? Где грань? В общем с описанием нужно что-то делать ;)Druu
19.12.2017 13:24+1> Во-первых у меня сложилось впечатление, что сеньоры тупо закончились. Они все уже где-то работают и получают очень приличные деньги.
Чтобы стать сеньором — надо где-то работать, представьте себе. По-этому вполне логично, что почти все сеньоры уже трудоустроены, как и мидлы :)
Меня поражает это удивление тому факту, что серьезных специалистов на рынке мало. Ну конечно их мало — они ведь уже работают, иначе бы не стали серьезными специалистами. Это в любой отрасли так, не только IT (на самом деле в других отраслях даже сильнее выражено, т.к. в IT текучка откровенно выше).evseev
19.12.2017 18:04Так я вроде бы и написал, что сеньоры работают. Прямо так и написал :«Они все уже где-то работают...». Это как бы и значит, что они трудоустроены. Вы видите в моих словах какие-то противоречия?
Серьезных специалистов действительно мало. Но когда директор R&D говорит, что они ищут специалиста уже второй год это уже как-то перебор. И это не единственный случай.
Druu
20.12.2017 01:47> Но когда директор R&D говорит, что они ищут специалиста уже второй год это уже как-то перебор.
Что значит «ищут»? Ищут просто такого человека в принципе? Ищут безработного? Ищут того, кто согласится на определенную зарплату? Это все разные «ищут» и результат по ним будет разный. Просто найти специалиста — очевидно, никакой проблемой не является. Зайдите в соседнюю контору и вон они там сидят — нашли!
swh Автор
19.12.2017 22:58С текучной в ит есть прям большие проблемы, думаю, оттуда и ожидание, что сеньёра найти должно быть проще. Всё же, среднее время работы в одном месте, например, в мобильном направлении — 2-3 года. Да и в базовой джаве — примерно такое же.
Единственное, думаю, что сеньёры уходять работать на Запад в основном — зарплаты всё равно выше.
swh Автор
19.12.2017 22:50С джунами и «взять на вырост» — полностью согласен. При неплохих входных данных (базовое техническое + усидчивость) можно быстро получать весьма существенные результаты.
Про совместную работу с сеньёром очень интересно. Если есть позитивный опыт и возможность описать, можно немного больше про это? Было бы здорово.
Отчасти, это компоновка, но такая, которая меняет процесс мышления. Думаю, что добавления функциональщины — неплохой пример. В дизайне альфа операции более наглядны — когда «была консоль», а стал «рабочий стол».
Да, с описанием нужно :) Спасибо)
j-ker
19.12.2017 22:50Я метасистемный бородач. Не ищите меня, да и я вас искать не стану. Статья ни о чём. Враньё одно, бред. Да и про раздутое Наше ЧСВ и эгоцентризм тоже наврано, равно как и про постоянно преследующие галлюцинации и выдумки с домыслами относительно прочитанного текста, например. В топку, однозначно, хоть это и не второй том "Мёртвых Душ", написанный метасистемным пейсателем с псевдонимом Mykola Hohol
swh Автор
19.12.2017 22:52Если возможно, опишите, пожалуйста, своё видение проблемы — было бы очень интересно.
Snow-ghost
21.12.2017 04:28С точки зрения русского языка фраза «Рояль должен быть исчезнут» составлена некорректно. рояль можно разрушить, сломать, растворить, перенести, но нельзя его «исчезнуть». Слово исчезнуть можно применить к неодушевленному предмету, когда непонятно, что произошло — вещь исчезла, пропала из видимости. Идем дальше, правильная форма — они исчезнут, то есть будущее время, множественное число. Как это соотносится к слову рояль (единственное число)?
По теме.
Все попытки квалифицировать программистов, как к примеру, деление на 2 общие группы — профессионалы и любители (как в спорте) обычно всегда применимы к конкретному месту работы. Тоже самое происходит в школах и ВУЗах, когда ставят оценки за знания/умения — одна и та же отметка может означать совершенно разный уровень подготовленности. И неважно, столица это или провинция. Также и с программированием — здесь ты сеньор, потому что решаешь весь необходимый спектр задач и вполне удовлетворяешь своими знаниями и работоспособностью работодателя — а там ты не больше, чем джуниор, потому что не умеешь пользоваться какими-то инструментами и т.д. и т.п. Все оценки относительны.
ibes
Может все-таки можно детализировать *парадигмальные уровни или в этом даже нет смысла?
swh Автор
Постараюсь сделать немного позже. Выложу сюда, в комментарии.
PavelMSTU
Не надо в комментарии — отдельный пост!..
Если я вас правильно понял, swh, то парадигмальный — это выход на «бизнес»?
А вот что есть для нас, айтишников, кросс-парадигмальный, это не понятно…
swh Автор
Мне бы хотелось сначала обдумать и изучить, прежде, чем предполагать :)
Слишком непростая тема, кажется. Было бы очень интересно поговорить-поисследовать с теми, кто «давно в деле» и мог бы оказаться на этих уровнях… Попробую найти.