Комментарии 90
Если я вас правильно понял, swh, то парадигмальный — это выход на «бизнес»?
А вот что есть для нас, айтишников, кросс-парадигмальный, это не понятно…
то весь l'amour de trua — в оценке «всех» знаний.Знания не важны, важны умения.
Про умения тоже можно подробнее? Это знание, которые уже применял? А если, например, сменились условия? Скажем, долго писал на Spring, а теперь проект гораздо меньше, и нужно использовать что-то другое, тогда как оценить умения?
Умения — это то, что он уже может делать из того, что вам надо. Если у вас в требованиях вакансии явно написан Spring, а он в нем ни разу не умеет, даже в рамках тестового задания, то пусть сначала научится, дома, да. Иначе непонятно, зачем пришел. Я могу подсказать какие-то мелочи, если вижу, что человек имеет близкий опыт, просто задачи у него были другие. Но учить с нуля — извините. Учить тоже возможно, но на совсем других условиях.
Один УЖЕ умеет и учился этому 5 лет, другой это УЖЕ освоил за пол-года. Кто круче? Риторический вопрос.
А разве сейчас важно что человек УЖЕ может делать? Технологии меняются настолько быстро что мне кажется на первое место давно вышло умение осваивать новое.
Риторическим бы он не был в том случае, если бы вы явно указали на мнение собеседника. В данном же случае — вы именно что высказали свое мнение (в виде риторического вопроса) и предложили оппоненту подискутировать с этим мнением (приведя сразу начальный аргумент).
Можно предложить кандидату проанализировать вместе с вами уже сделанные коммиты по какой-нибудь несложной таске из недавних.
Речь, в общем, о том, чтобы посмотреть, как человек будет вести себя с вашим кодом — это, вроде, и не тестовое задание, с другой же стороны, максимально близко к тому, чем он будет заниматься на работе. В каком виде это будет устроено — уже вопрос другой, все зависит от ситуации. Может, мы хотим именно на то посмотреть, как человек «въезжает», какие задаст вопросы и т.д…
Тогда сложная будет даже лучше.
Можно держать несколько тасок разного рода и выбирать в зависимости от того, как шло собеседование в начале и что именно мы хотим узнать о кандидате.
«Как въезжает» оценивать не стоит, наверное. Лучше оценивать результат, а не процесс. Кандидат может круто въезжать и всё может нравиться, а результативность может оказаться нулевой :(
Возможно, есть перечень задач, где «въезжаемость» имеет больший приоритет. Но пока — выглядит частным решением.
Как думаете?
И у вас еще будет три месяца испытательного срока.
Конечно, я же говорил выше о том, что все зависит от ситуации. В любом случае, проведение собеседования — это работа, и как и для любой другой работы — качество результата зависит от квалификации исполнителя, в первую очередь, а уже во вторую (в третью или дальше) от используемых им методов.
А мидлов да сениоров в любом случае трудно оценивать (и чем выше возможная квалификация кандидата — тем труднее ее верно оценить).
Так что, я согласен, потому и ищу некоторую меру.
Тоже как-то категорично. Верстальщикам, изо дня в день делающим одну и ту же работу — возможно.
Специалистам "креативных" направлений — не думаю.
Мне бы было интересно задавать таковым вопросы в духе "как сварить яйцо, имея только пластиковую линейку в 40 см?"
А вообще разные требования. На студенческий уровень важнее личные качества (ответственность, соображалка и прочее). На уровень начальника отдела — опыт в аналогичной деятельности. На уровень технического эксперта — знания.
В остальном, согласен.
А работая в коллективе, вполне реально несколько десятков раз выполнить обязанности начальника: взять шефство над джуном, поруководить коллегами в рамках краткосрочного подпроекта, на уровнях повыше — позамещать начальника в отпуске; в конце концов — просто подойти к начальнику и попросить дать соответствующую задачку.
А у Вас был подобный опыт? Показалось, что Вы в теме )
По опыту, скорость возвращения сильно зависит от схожести платформ на уровне парадигм и паттернов, а также способности отделять общие парадигмы и паттерны от деталей реализации, которая сильно положительно коррелирует с количеством знакомых платформ, парадигм и паттернов. Грубо, перейти с Java на C# когда ещё знаешь C++ и PHP, гораздо быстрее, чем с Java на Haskell, когда ничего кроме Java не знаешь, да и при работе с ней с её реализацией ФП не сталкивался. При это во втором случае опыт и знания платформы могут в целом заметно бОльшие, чем совокупно в первом.
Идея перенести уровни Бернштейна в программирование очень интересна, но, без реальных данных, наблюдений, статистики — останется только идеей; в текущем виде, я считаю, её описание некорректно. Я выборочно по пунктам придерусь:
В общем, это всё здорово, но это от безделья.
Ну и всё вот это вот. Я скажу за себя: вопросы "по резюме" я задаю, чтобы зацепиться за какую-то конкретику, узнать субъективную и профессиональную оценку того или иного этапа деятельности, проекта и т.п. Резюме — это план сочинения, которое мне рассказывает собеседуемый.
Вопросы "по знаниям" — да, чтобы понять, насколько адекватна его самооценка, насколько он умеет рассуждать и искать ответы.
две основные линии проверки — «архитектурная» и «базовая»
В отсутствие объективных данных — высосано из пальца. Эти две вещи как минимум растут совместно и дополняют друг друга. Так же, как и умение музицировать (по своему опыту): сначала слушаешь песни, потом делаешь простейшие действия с инструментом, совмещаешь опыт и понимаешь, как в простейшем случае переложить песню на инструмент, потом, пользуясь опытом, на более сложных песнях прокачиваешь инструментальный скилл…
Почему не объединить в одну линейку или не подвыделить в рамках "архитектурной" линии подветки "голой теории" и "практической декомпозиции", ведь, например, очень многие математики сильны в теории, но не могут нормально сконструировать простейшие программы?
Соответственно, сами уровни тоже вызывают вопросы — почему так, а не иначе? Где тот практический критерий, который с большой долей вероятности позволяет поделить кандидатов по уровням? В статье описан "образ мышления" программиста, а не критерии — как их отличить.
Идея, повторюсь, интересная, применима не только к программистам, а к любым областям с широким стеком научения — но текущее описание на практике пока бесполезно. Любой здравый собеседующий и делит субъективно людей по похожим уровням.
Полностью согласен с тем, что это пока большими мазками. Попробую исследовать критерий подробнее.
Линии «архитектурная» и «базовая» это от того, что использование модуля не то же самое, что его построение, различаются законы. Названия так себе, конечно. «Базовая», потому что вроде как относится к базе информатики и программирования — алгоритмы, особенности языка и т.д. Ну и «архитектурная» — определяет связь модулей и всё такое.
Постараюсь применить Ваши предложения насчёт «голой теории» и «практической декомпозиции».
Постараюсь применить Ваши предложения насчёт «голой теории» и «практической декомпозиции».
Это не предложение, а пример-наблюдение, почему недоработан принцип деления. :) Т.е. можно в равной степени и объединить всё это дело, и разделить ещё на кучу вариантов. А ответов на "почему именно так" и "как этот способ деления поможет" — не получается всё равно.
Моё самое главное предложение — просуммировать практический опыт реальных людей-кандидатов. Опять же, каким образом, какими исследованиями собрать эти данные — я не знаю.
Всегда полно больших задач, а тюнить лучше Васе поручить, ему нравиться, а у меня душа к этому не лежит.
Видимо буду вечный Middle.
есть два аспекта — тактический и стратегический, тактический мне бесконечно скучен, потому что область его применения очень узкая, это знание не переноситься с платформы на платформу и устаревает в течении нескольких лет, поэтому мне жалко на это тратить свою жизнь.
Тем не менее когда у тебя 1000 шардов какого то сервиса, экономия в миллисекунду уже даст экономию в энергопотреблении ЦОДа, но пока это не мой масштаб, и надеюсь у меня всегда будет Вася на которого я эти заботы смогу переложить.
есть мастер кодер, есть мастер проектировщик, оба нужны и кодеров надо больше :)
Больно не было — было недоумение.
Но если это публикуют, значит это кому-нибудь надо.
Говоря в терминах статьи — это еще более высокий уровень. Уровень осознания задачи и понимания ее значения в бизнесе. Именно это понимание останавливает человека от того, чтобы писать код ради самого кода.
Этот этап становления программиста, мне кажется одним из самых ключевых.
А в остальном — идея статьи очень интересна, спасибо.
Вы думаете это связано с навыком программирования, «выполнением операций», или это больше про развитие профессионала вообще? Можно ли пункт про «нужно ли это вообще» отнести к другой линии становления человека как профессионала? Скажем «исполнитель» — «средний менеджер» — «управляющий разработкой, который понимает, нужно ли это бизнесу»?
Или это всё же относится к профессиональному развитию именно «компьютерных навыков»?
Это один из основных навыков именно коммерческого разработчика уровня от типичного миддла (в моём понимании :) ), наверное. Чувство экономической целесообразности применения тех или иных решений для конкретной задачи. На тот же SOLID не всегда нужно тратить время — пока будешь выделять ответственности, разделять интерфейсы и инвертировать зависимости, бизнес может быть ликвидирован по решению налоговой или конкуренты займут рынок. С одной стороны. А с другой, если решения задач будут в виде "плоских" скриптов на тысячи строк, то очень быстро простейшие изменения будут осуществляться очень долго без всяких гарантий, что ничего нужного не сломалось.
При разработке для души можно создавать сколь угодно сложные архитектуры или оптимизированные до последнего тика процессора, не имея ограничений на сроки и бюджеты. А коммерческий разработчик должен уметь составить пускай примитивное, пускай из пальцы высосанное, но технико-экономическое обоснование для выбранного пути решения поставленной задачи (желательно с как минимум одной альтернативой). рассматриваться должны в том числе и такие варианты как "найти бесплатную систему", "купить платную", а не только "напишем это как писали всё остальное" или "для этой задачи надо полностью переписать всё"
Текст беспощадно перекручен. Логические конструкции словно пришли к нам из ассемблера, язык пестрит нарушением привычного порядка членов предложения, отсылки к чему угодно, переходы лица и числа автора, предложение в 46 слов длиной… Продолжать можно долго, но отличия от обычной речи видны невооружённым глазом.
Что характерно, информационная ценность близка к нолю.
Сейчас, увы, технологии в IT слишком быстро меняются чтобы делать все «правильно», системно. На это просто нет времени, или быстрый результат или уже вылетаешь с рынка.
Накрутить слова так, чтобы с одной стороны было плохо понятно, а с другой выглядело по «философски», и читатели пытались выловить смысл из глубины её глубин. Ну и как водится, винегрет из терминов, жаргонизмов и отсылок ко всему попало.
> «Будет больно. Потому что будет правда.»
Вот она, попытка сорвать покровы.
Цель собеседования — убедится, что человек подходит. Вы, видимо, просто не подошли.
Люди всегда руководствуются своим опытом, учатся на ошибках. Тот, кто ранее учавствовал в значимых проектах, будет спрашивать/требовать того же, видимо потому, что считает это важным. Тот, кто однажды нанял/посоветовал плохого работника — будет стараться не повториться.
Например, я меланхолик, и мне нужно какое-то время, чтобы обдумать задачу, а потом я начну делатьУ меня очень простой и эффективный подход: я даю простую задачу на базовые знания плюс много опциональных заданий. Времени — с достатком на базовую часть. Я не ожидаю, что кандидат выполнит все. Выполнит — круто. Важно, чтобы был готов некий код, написанный/скопированный из гугла, а потом начинается самое важное — мы его вместе смотрим и обсуждаем. И вот это главное, это то, что мы будем делать каждый день, если его наймут. Для обсуждения не нужна подготовка: это его код, он его написал, он может ответить на любой вопрос об этом коде и ему не нужно думать (он уже думал, пока писал его).
Меланхолик, дегенерат, блондинка (простите мои -измы) — неважно, если вы провалили такое собеседование, то «работать» вы уж точно не сможете.
Чтобы не пользоваться мифическими Junior, Senior, MudakiorНа 100% согласен с «мифическими». Есть стаж, просто и понятно, сколько лет и кем работал. Есть опыт работы и стек технологий. В какой момент из Junior-а становятся вдруг Senior — не понятно и главное — ничего не говорит. Отработал я 10 лет и что, стал Senior-ом? Старый чтоли стал?
Но еще бывают «состояния»Извините, но это плохая отмазка для собеседований. Если человек уже в команде — то да, все делают скидку на болезни, это и ежу понятно.
Зачем работодателю монстры, видевшие ЕС ЭВМ, Агат и дискеты 5,25 ?!
Более взрослый = более опытный, даже это не работает, старый опыт не востребован, а скорее наоборот давит.
Еще есть тенденция перехода в ИТ с других специальностей в зрелом возрасте. В итоге, на позиции начинающего разработчика оказываются уже вполне зрелые люди. Обычно это воспринимается довольно тяжело.
Позвольте не согласится.
По моим наблюдениям, молодежь чаще болеет.
Обратная сторона мобильности — готовность после первой конференции убежать куда позовут хайповыми словами, молодой меньше проектов довёл до конца, и не просто в it, но и по жизни. При прочих равных, у более взрослого этот навык лучше развит, и спектр задач, которые он не профакапит по юнешеским максимализму и неусидчивости, и которые ему можно поручить — шире.
Семейный — значит прокачена коммуникация и навык управления людьми, и лучше понимает что людям по жизни надо, и какие они вообще, люди эти бывают.
И т.д. Могу долго продолжать…
А молодой что? Жизни то не видел ещё))
«Состояние» это больше не про собеседование, а про профессиональные навыки в целом. Не в коем случае не говорил про отмазки. На приёме на работу — как на войне — кто лучше подготовился, тот и молодец.
Это попытка немного абстрагироваться от самого приёма — к оценке уровня.
(просто в качестве оффтопа — с работой всё в порядке, это попытка найти материальную базу в уровне профессионального развития.)
Я проходил собеседования и сам их проводил. И из своего опыта могу сказать, что понять что-то очень сложно. Тот, кто казался подходящим, на деле оказывался не очень-то и хорош, а тот, кто был с натяжкой через полгода-год становился настоящим гуру. И, по-моему, единственный путь- пробовать.
Немного не точно про функциональный подход. Суть в том, что будучи на системном уровне, можно воспроизводить альфа-операции, которые изменяют систему, привносят в неё новые элементы. Ваша дочь (то, что она делает, бесспорно — круто) использует инструменты, а не порождает их — и в этом отличие. Видимо, я как-то не точно описал этот момент, простите :)
Но разве компоновка существующих средств не порождает новые функции? И если нет, то как тогда из средств, предоставляемых языком программирования создать новые элементы? Где грань? В общем с описанием нужно что-то делать ;)
Чтобы стать сеньором — надо где-то работать, представьте себе. По-этому вполне логично, что почти все сеньоры уже трудоустроены, как и мидлы :)
Меня поражает это удивление тому факту, что серьезных специалистов на рынке мало. Ну конечно их мало — они ведь уже работают, иначе бы не стали серьезными специалистами. Это в любой отрасли так, не только IT (на самом деле в других отраслях даже сильнее выражено, т.к. в IT текучка откровенно выше).
Серьезных специалистов действительно мало. Но когда директор R&D говорит, что они ищут специалиста уже второй год это уже как-то перебор. И это не единственный случай.
Что значит «ищут»? Ищут просто такого человека в принципе? Ищут безработного? Ищут того, кто согласится на определенную зарплату? Это все разные «ищут» и результат по ним будет разный. Просто найти специалиста — очевидно, никакой проблемой не является. Зайдите в соседнюю контору и вон они там сидят — нашли!
Единственное, думаю, что сеньёры уходять работать на Запад в основном — зарплаты всё равно выше.
Про совместную работу с сеньёром очень интересно. Если есть позитивный опыт и возможность описать, можно немного больше про это? Было бы здорово.
Отчасти, это компоновка, но такая, которая меняет процесс мышления. Думаю, что добавления функциональщины — неплохой пример. В дизайне альфа операции более наглядны — когда «была консоль», а стал «рабочий стол».
Да, с описанием нужно :) Спасибо)
Я метасистемный бородач. Не ищите меня, да и я вас искать не стану. Статья ни о чём. Враньё одно, бред. Да и про раздутое Наше ЧСВ и эгоцентризм тоже наврано, равно как и про постоянно преследующие галлюцинации и выдумки с домыслами относительно прочитанного текста, например. В топку, однозначно, хоть это и не второй том "Мёртвых Душ", написанный метасистемным пейсателем с псевдонимом Mykola Hohol
По теме.
Все попытки квалифицировать программистов, как к примеру, деление на 2 общие группы — профессионалы и любители (как в спорте) обычно всегда применимы к конкретному месту работы. Тоже самое происходит в школах и ВУЗах, когда ставят оценки за знания/умения — одна и та же отметка может означать совершенно разный уровень подготовленности. И неважно, столица это или провинция. Также и с программированием — здесь ты сеньор, потому что решаешь весь необходимый спектр задач и вполне удовлетворяешь своими знаниями и работоспособностью работодателя — а там ты не больше, чем джуниор, потому что не умеешь пользоваться какими-то инструментами и т.д. и т.п. Все оценки относительны.
Рояль должен быть исчезнут: уровни профессионального развития и их оценка, у программистов