Пособеседуем...

Добавил немного «желтого-Alizar-style» в заголовок.

С подачи Макса Ищенко, термин «сеньор» может вскорости обрести новое семантическое значение и стать широко известным в узких круга, а также занять достойное место среди таких нарицательных как КотЭ, Капитан Очевидность, Мопед, Гном и пр. И будет он означать не что иное, как «сеньор 80 уровня в 23 года».

Но пост не об этом. Ниже я бы хотел поделиться с уважаемыми читателями ДОУ личным опытом проведения собеседований.

Фото: Shutterstock

За свою карьеру я успел поработать в трёх городах (Донецк, Харьков, Киев) и в различных компаниях: бухгалтерское ПО, торговые и финансовые инструменты, игрострой, аутсорс, авиа-симуляторы, промышленное 3D. Много раз интервьюировал и был интервьюируемым, видел много схем и различных подходов. И на текущий момент всё это «синергетировалось» и «выпало в сухой остаток» в форме следующего алгоритма работы с соискателями ( С ).

Первый этап — очное или заочное общение

(желательный, но не обязательный этап)

«Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень».

Оценка:

  1. Объем (строки, количество файлов)
  2. Структурная организация (папки, файлы, именование)
  3. Комментарии кода.
  4. Соглашения по именованию.

Что позволяет узнать/оценить:

  1. Подходы С в части командного взаимодействии — погружение «стороннего» человека (интервьюера) в свой программный код.
  2. «Стиль» программирования.
  3. Используемые технологии/фреймворки/библиотеки/велосипеды.

Второй этап — очное общение

«Набросайте схему программного продукта, в разработке которого Вы принимали участие»

Оценка:

  1. Слаженность в движении мысли, последовательность изложения.
  2. Умение слушать и слышать собеседника/оппонента.

Что позволяет узнать/оценить:

  1. Уровень владения UML, количество типов диаграмм в арсенале С.
  2. Владение паттернами проектирования.
  3. Способность перемещаться по архитектуре вниз-вверх, вправо-влево, вперёд-назад, переход от общего к частному и наоборот.
  4. Реакцию С критику со стороны и как следствие стадию «звёздной болезни».

В процессе обсуждения заостряю внимание на технических деталях и прощупываю базу: «А почему здесь наследование, а не композиция?», «Здесь не появится срезка?», «Почему не использовали boost::bind?» и пр.

Плюсы:

  1. Мы разговариваем о том, что соискатель знает, а не о том что он не знает. Пусть 1 — универсум, который, Вы хотите проверить q — это то, что С знает, n — то что, не знает. Как следствие q + n = 1. Я всегда предпочитаю общаться на тему q.
  2. Разговор идёт «естественным» путём, который подходит обоим участникам.
  3. «Симулятор/Эмулятор» командной работы.
  4. Возможность в любой момент поставить логическую точку в собеседовании, без необходимости выполнения «30 тестов за 1 час».

Минусы:

  1. Недостаточный уровень формализма. Для большИх компаний количество бумажных артефактов должно быть больше и они должны быть структурированы, так как они могут/будут использоваться для повторного интервьюирования и/или как входные данные для эвалюэйшенов.
  2. Данный подход трудно (но можно) адаптировать для интервьюирования Junior/Middle разработчиков, для которых важным критерием оценки являются всё-таки именно «энциклопедические знания».

Время:

Через 30 минут ясно каков уровень С.

USP:

Выявление асимптоты, верхней границы знаний и потенциала С. И даже если под кривой есть полости (они есть у всех), это корректируемо и восполняемо, но если граница низкая или не прощупывается, то часто это, к сожалению, диагноз.
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube

Лучшие комментарии пропустить

Пусть тут полежит: yourstartupsucks.com/...hire-developers

“When you ask people to write programs or solve programming riddles in front of you, you’re testing thousands of irrelevant skills at the same time... there’s a huge difference between coding and coding on a dirty whiteboard in front of a manager as she breathes down your neck...”

“You know who’s good at brainteasers? People who are good at brainteasers. That’s about it. The rest of us spend our time writing awesome code, learning about system architecture, and having a life instead of trying to figure out how many blind prisoners on a desert island ate green pudding last Tuesday.”

«Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень».

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

Уровень владения UML, количество типов диаграмм в арсенале С.

В 20 лет прекрасно знал. В 23 уже забыл немного, сейчас — тем более.

Владение паттернами проектирования.

Применял еще до прочтения разных GoFов. Названий не знал. В 22-21 уже знал названия, к 23 начал забывать.

Комментарии кода.

Не пишу в 99% кода(Если явно не оговорено), просто нет необходимости. Почти весь код со сложной и непонятной логикой предназначен для себя любимого и интересен только в процессе написания. Если надо будет писать в команде что-то из rocket science, то комментировать буду. Код, который идет жить в продакшен просто обязан быть настолько прост для понимания, что комментарии излишни. На текущем проекте, например, джавадоки явно указанны как излишество. Если поведение вашего кода непонятно — переписывайте код.

Итог — методика претендует на роль быть silver bullet, при этом не вписываясь в реальную жизнь

Статья класс. Будем считать что это конец флудофых статеек на ДОУ :)

По второму пункту (про архитектуру):
— тут одна сложность есть люди которые очень хорошо рассказывают, но при этом делать ничего не умеют;

— УМЛ — далеко не все, даже в энтерпрайзе, им владеют хорошо, большинство «читать могу, пишу с ошибками»; кроме того сомнительна ценность данной технологии (но это уже другая история);

Более интересен первый пункт (про код):

Не у всех есть возможность показать свой код, тем более промышленный (а не домашние поделки). Судя по пунктам оценки, которые вы написали — оценка кода взяла на себя большую часть (да и на ее основе можно поспрашивать «про архитектуру»)

Из написанного следует только один вывод: Собеседующий желает увидеть в собеседуемом совпадение мировозрения с собственным. Вот например в вышеизложенном случае, автор завёрнут на UML, ООП и паттернах, хотя и то и другое и третье — вымирающие и/или вредные тенденции. А заворот автора на матане особенно доставляет. :)

Приведенная методика спорна по всем пунктам без исключения, в чём сильно контрастирует с методикой ребе Кацмана для джунов, которая ну просто на удивление кристально адекватна. dou.ua/...ums/topic/5260

137 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В общем хорошая статья

Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень

Я задал этот вопрос себе. И оказалось что тот код который отражает мой уровень максимально — код моих домашних проектов. Но там я пишу research и пишу для себя. Если его начнут оценивать с точки зрения enterprise головного мозга, то я думаю им не понравится. Нет 3 паттернов для одной кнопки. Это конечно шутка, но если лучший мой код с инновационной и технической точки зрения был код для себя?

Используемые технологии/фреймворки/библиотеки/велосипеды.

Это вообще жесть. Тоесть оценивать будут в зависимости от того, находимся ли мы с собеседующим с одной стороны холивара

«Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень»

...

«Набросайте схему программного продукта, в разработке которого Вы принимали участие»

И после этого с человеком будут подписывать NDA. :-)

Из написанного следует только один вывод: Собеседующий желает увидеть в собеседуемом совпадение мировозрения с собственным. Вот например в вышеизложенном случае, автор завёрнут на UML, ООП и паттернах, хотя и то и другое и третье — вымирающие и/или вредные тенденции. А заворот автора на матане особенно доставляет. :)

Приведенная методика спорна по всем пунктам без исключения, в чём сильно контрастирует с методикой ребе Кацмана для джунов, которая ну просто на удивление кристально адекватна. dou.ua/...ums/topic/5260

UML, ООП и паттернах, хотя и то и другое и третье — вымирающие и/или вредные тенденции.

Извините, ШО?

Гы :) Я думал холивар начнётся сразу, а провисело месяц без ответа.

ШО?
UML направляется в Лету: www.itjobswatch.co.uk/jobs/uk/uml.do
ООП как правило вреден. Например вот одно неплохое объяснение: thread.gmane.org/...643/focus=57918
и ещё www.devx.com/...icle/26776/1954
Вкратце: Раскладка методов по классам — как правило хорошо, хоть и не всегда. Но в реале ООП наращивает непредметную сложность, снижает эффективность, снижает маинтайнабельность и реюзабельность — в противоположность заявленным целям.
Паттерны — апофеоз фанатичного, карго-культного ООП. Даже не читал критику, видел лишь несколько гранд фаилур.
Противоположность ООП — Data Oriented Design.
www.asawicki.info/...d_thoughts.html
research.scee.net/...ing_GCAP_09.pdf
Если дизайн системы начинается с анализа потоков данных — у системы есть шанс стать успешной и даже эффективной, если с рисования иерархий классов — нет. А если с первых строк начинают фигурировать словечки типа обджект фектори и синглетон — запасайтей попкорном, будет эпик фейл.

Вы просто не умеете готовить. Я не представляю как писать комплексный проект в команде с использованием DOD. Этот подход гораздо уже чем ООD. Он попросту игнорирует «взаимоотношения» сущностей. Представляя их в функциональном стиле. Такой дизайн годится для линейных, потоковых систем. Увы далеко не все ПО укладывается в эти ограничения.

О, коллега, Вы заблуждаетесь. :)
DOD исходит из потоков данных, а значит
— не создаёт лишних сущностей
— вбрасывает код только в необходимых количествах
— масштабируемость у него в крови
OOD же полностью игнорирует наличие данных, что привордит к катастрофической неэффективности, и фокусируется на построении Object Model, которая, как правильно заметил товарищ Линус Торвальдс, разваливается как карточный домик от малейшего изменения.

На позапрошлом проекте одна часть была сделана на DOD, другая на OOD/Patterns. Одна стала эпик вином, другая эпик фейлом. Угадайте какая. :)

Я не представляю как писать комплексный проект в команде с использованием DOD.

Ну это, видимо, ввиду Вашей специфики. Распределённые системы и какие-нибудь SOA — это по определению DOD.

Этот подход гораздо уже чем ООD

Наоборот. OOD игнорирует потоки данных, он однобок.

Он попросту игнорирует «взаимоотношения» сущностей.

Опять же, наоборот, он помогает из выявить.

Такой дизайн годится для линейных, потоковых систем.

DOD годится для систем где есть ограничения ресурсов. OOD же наоборот приводит к расточительству ресурсов.

Увы далеко не все ПО укладывается в эти ограничения.

Это не ограничения, а нечто обратное — более полноценный подход. DOD никоим образом не запрещает структурировать код на области видимости назывваемые «классами», и более того, весь код оказывается в нужной точке карты потоков данных, оттого его легче структурировать. OOD же не видит потоков данных в упор, а зацикливается на красоте воздушных замков из кода, при этом процветают карго-культизм и создание ненужных сущностей.

Вот как то так.

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

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

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

ООП как правило вреден

Нет, но обычно его ярые фанаты, не знакомые ни с чем другим — страшные люди

Надо создать топик — протестировать компании на соответствие КзОТ =) Будет ха-ха... Ну все поняли =) 99% компаний не пройдет =)

Думаю не пройдет 1%, а 99% соблюдают КзОТ для своих сотрудников (Директор и Бухгалтер), контрактеры (СПД) работают по контракту и сами отвечают за соблюдения собою кзота

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

Джуны очень хорошо танцуються

Можно обозвать не «собеседование», а «тендер» на разработку доли кода в проекте, от веселуха )))

кто заказывает музыку? то-то

И что предложите показывать лучшему программисту МегаКомпании работавшего 3 года в команде из 20 человек над проектом, который длиться больше 30 лет?

Если написанные им файлы после 20 чужих ченджей он сам не узнает

Проекты своих первых лет, когда он был юнцом?

И где он возьмет эти исходники, если он там уже не работает? И какой хрен ему утаскивать с работы код? Придет ли ему в голову мысль об этом до вопроса на собеседовании?

Для себя вывод: все субъективно, каждый покупает себе тот товар (людей), которые ему понравиться. Критерии выбора хорошей машины/шоколадки/кетчупа у всех свои.

Клеймить удобнее определенными категориями, например, ценой

Пусть тут полежит: yourstartupsucks.com/...hire-developers

“When you ask people to write programs or solve programming riddles in front of you, you’re testing thousands of irrelevant skills at the same time... there’s a huge difference between coding and coding on a dirty whiteboard in front of a manager as she breathes down your neck...”

“You know who’s good at brainteasers? People who are good at brainteasers. That’s about it. The rest of us spend our time writing awesome code, learning about system architecture, and having a life instead of trying to figure out how many blind prisoners on a desert island ate green pudding last Tuesday.”

Насчёт первой части не соглашусь. Я могу не просить написать какой-то код разве что человека у которого на github, bitbucket уж очень большой профиль из которого можна принять решение может человек писать код или нет. С другой стороны если вы такой ранимый что написание кода во время интервью для вас стрес, то как вы будет действовать в экстремальной ситуации: перед релизом находят критичесний баг и над вашей душой висят менеджер, начальний отдела, вице-президент и ещё чёрт знает кто. Лучше такого не взять чем потом в критической ситуации искать замену.
Из моего опыта проведенных мною интервью и когда меня интервьюировали никто не считал что написать простой пример из каждодневной практики есть неправильно. Даже больше, при собеседовании в одну большую контору я имел три интерьвью и все с написанием кода и повышением сложности и это был для меня повод попробовать что-то новое, освежить знания в области которуя я подзабыл.

За всю мою практику написать код отказался только один trainee, которого мы не взяли, а я зато взял trainee который с заданием справился очень хорошо и сейчас на позиции junior он пишет лучше некоторых senior.

@Петро
то как вы будет действовать в экстремальной ситуации: перед релизом находят критичесний баг и над вашей душой висят менеджер, начальний отдела, вице-президент и ещё чёрт знает кто. Лучше такого не взять чем потом в критической ситуации искать замену.

Такі ситуації можуть говорити лише про погано поставлені процеси, та слабкий менеджмент. А це причина того задуматися, задля чого варто іти в таку контору, заради пригод та екстріму?

Код можна і пописати, але це мало про що говорить.
Для цього є випробувальний термін, на ньому людина і розкриється.

Можете мені паказати компанію з добре поставленими процесами? Бо раз за разом цей сферичний кінь у вакумі вспливає на форумі, а я от чогось не бачив такої компанії і знайомі чомусь не згадають.
Які б ви не ставили процеси в себе, овертайми це є швидше норма для індустрії розробки ПЗ і у нас і на Заході. І овертайми є і в google, microsoft і в Fog Creek. А більшість стартапів це взагалі робота по 60 годин на тиждень. І тільки в нас бачите хочуть сидіти на дупі 40 годин на тиждень з яких 20 займатися фігнею, получати високу зряплату і розповідати про погано поставлені процеси. Який би не був у вас процес, але розробник який звик пів дня сидіти на хабрі, чверть на перекурах і в решту часу щось намагатися закодити ви не закінчите проекту з поставленими цілями. Бо для того ж SCRUM вимагається maturity команди. Багато таких команд бачили? Я на жаль дуже мало і буває достатньо включити одну паршиву вівцю з гнилими замашками, щоб вся ота maturity випарувалася. З другого боку той же SCRUM в наших реаліях нагадує стаханівщину, більше, вище, сьогодні 50 сторійонтів, а давайте завтра 55, ну ви ж можете. Не процес — процес. Процес який не передбачає непередбачуваних обставин виведе ваз з гри і ви втратите клієнта, ринок. Покажіть мені процес який убезпечить вас від того що ВСЯ команда розробників зляже на два тижні від грипу?
Випробувальний термін кажете? І що мені потім через місяць якщо людина не підійде брати нового, якщо тільки місяць піде на те щоб людина включилася в команду, це якраз поганий процес взяти абищо, а потім з отим мучитися. Та й зрештою тут ще й КЗоТ є, якого в нас ніби й не принято дотримуватися, але який каже, що взяти легко, але відмовитися значно важче.

Я розумію що зараз попит на розробників великий і дехто хапає всіх, а потім не може дати собі ради, але якщо ви якраз не хочете собі потім овертаймів , бо приходиться підгрібати за деким, то все ж проявіть перебірливість на початку, воно потім вам окупиться сторицею.

Петре, зрозумій, життя не настільки довге, щоб гробити здоров«я через те, що сейли щось пообіцяли клієнту, а менеджери це підтвердили, а бідний розробник

будет действовать в экстремальной ситуации: перед релизом находят критичесний баг и над вашей душой висят менеджер, начальний отдела, вице-президент и ещё чёрт знает кто

У певний момент це стає схожим на «анальне рабство», бо перетворюється на систему, а не винятковою ситуацією.

Нема проблем ми самі «ковалі свого щастя». Насправді компанії які пропонують розмірений цикл розробки небагато, але вони є, шукаєш і працюєш.
Але на жаль моя практика показує, що є більшість які не хочуть і не звикли працювати самостійно і які б початкові оцінки вони не заявили вони ніколи не вкладуться, бо привикли ні за що не відповідати і працювати з під кнута. В такому випадку робота все одно виливається в овертайми й переробки, бо навіть якщо ти сам будеш супер організований і відповідальний, сам за всіх всю роботу не зробиш. Чи винен в такому випадку менеджер? Що робити з отією паршивою вівцею/ями? (До речі враховуючи кадровий голод, вони першими звалять з проекту і споганять найкращі компанії)
Чому я таке зустрічаю довкола всюди(до речі це не дивина й серед американців)?

А Agile техніки які вимагають maturity від команди тут виходить що підходять лише для команд з розробниками вище середнього рівня(і тут більше не професійний рівень маю на увазі, а мінімальну дисципліну та відповідальність за свій шмат роботи), бо для роздолбаїв це перетворюється на оте згадане тобою рабство «спочатку комітаємся під роботу, потім розслабляємося, а потім овертаймаємо».

Чому я таке зустрічаю довкола всюди(до речі це не дивина й серед американців)?

тому що така природа людей і менеджмент це є мистецтво управління.
Хоча якщо досі побутує правило, що «будь-яка секретарка може бути менеджером», то не дивно, що такі наслідки. Перша проблема, що менеджери в основному набраються із «своїх», «лояльних» а не з тих, хто до цього має хист.
До чого тут

maturity команди

взагалі?

що є більшість які не хочуть і не звикли працювати самостійно і які б початкові оцінки вони не заявили вони ніколи не вкладуться, бо привикли ні за що не відповідати і працювати з під кнута

Знову питання, а чим займається менеджмент і куди він дивиться, і чим вні займається крім того, що ублажає обіцянками клієнта, топів та розробників?

Чи винен в такому випадку менеджер?

Винен, бо не справляється з роботою.

Що робити з отією паршивою вівцею/ями?

Є ж «тонкі психологи — хрюші», коучери, кар"єр авізори.
Якщо пропустили вівцю через ряд співбесід і це видно під час випробувального терміну, то звільняти. Якщо спаршивилась після закінчення випробувального терміну, тут тре шукати причини в оточенні вівці, які довели її до цього, може наобіцяли багато.. може загнали її бідну і вона напівжива. Може вона не годована, обділена ласкою або увагою, причин море, а для цього є цілий штат, який би мав дивитись за тарганами в голові працівників.
п.с.

Видно ще мабуть не працювали із работягами, там 90% несвідомий елемент, який ні защо не відповідає, линяє від роботи, намагається щось вкраси і при першій же нагоді буде напівбухий. А так, маєте ботанів — напівінтелегентів, і ще розказуєте, які вони хренові працівники.

є більшість які не хочуть і не звикли працювати самостійно

Хто хоче і звик працювати самостійно, тому працювати на дядю особливо нема потреби.
Парадокс?
Ви берейте в найм раб.силу а не артіль співласників проекту.

Тому тре керувати, а не «рукамі водіть».

Випробувальний термін кажете? І що мені потім через місяць якщо людина не підійде брати нового, якщо тільки місяць піде на те щоб людина включилася в команду, це якраз поганий процес взяти абищо, а потім з отим мучитися.

А Ви не думали, що до Вас приходить людина, а не бот.

20 років після розвалу СРСР пройшло, а менеджмент все хоче бачити «гвинтиків і шпунтиків» і не хоче розуміти, що таке ринок. І що довижимали з населення соки так, що отримали демографічну яму, а тепер плачуться, що нема кому працювати.

До чого тут взагалі демографічна яма?
Бачу бесіда відійшла від оригінальної теми.
Моя оригінальна думка:
1. Розробнику при співбесіді ТРЕБА давати писати код. Це основний його навик і вибачте ми не дівчину на виданні співбесідуємо що людина має соромитися, чи хвилюватися. Інше питання що давати, я даю відносно прості завдання з щоденної практики, які показують не чи памятає людина бібліотеки, а саме як пише код, чи перевіряє вхідні параметри, чи всі умови покриті, чи є коментарі, як структурується код і взагалі цікаво подивитися динаміку як вирішується задача, до чого приступає спочатку і що робить потім, вже тільки це говорить про людину значно більше, ніж 100500 абревіатур які він чи завчив чи десь прочитав, але реальне володіння технологіями за цими абревіатурами за час співбесіди перевірити неможливо.

2. Брати аби-кого в надії авось запрацює це гарантований шлях до проблем.

І тільки в нас бачите хочуть сидіти на дупі 40 годин на тиждень з яких 20 займатися фігнею, получати високу зряплату і розповідати про погано поставлені процеси

Я бы вас себе не нанял следуя такой логике — если и писать посты по странице А4 изо дня в день в рабочее время, то с пользой для работы

До речі цікаво в якості авторитету приводити думку школяра, досягнень якого в галузі розробки нема ніяких. Стартапські навики і досвід роботи розробником в команді над технічно складним проектом — це надто різні навички.

пан Мартиненко (можливо помиляюсь з авторством) дав визначення вiд супротивного:
«Якщо ти не заробляеш 2к5 — ти не сенйор».
п.с.

А що це останнiм часом пiдняли гвалт про з/пл та сейоритнiсть?

«Якщо ти не заробляеш 2к5 — ти не сенйор».

Это по типу: «Если у тебя размер полового члена менее 25 см. — ты не мужик»

Довжину (dnovhorodovр, думаю мав ii на увазi), досить легко помiряти лiнiйком/штангельом.
Ще раз питання, чому тема синйорiв пре?

Она всегда «перла», просто раньше в основном на форуме, сейчас перебралась еще в оди раздел.

«У кого нет миллиарда, могут идти в ж..у» ? Автор этой фразы потом съел галстук.

Автор этой фразы, кажись, увалил в Париж.

Автор этой фразы Сергей Полонский (он в России), и он уже не миллиардер... :))) Но мужик толковый... :))

Я про 2,5К.

Автор этой фразы Сергей Полонский

А галстук он таки съел?

Ел конечно, даже видео есть: www.youtube.com/...h?v=dMPq77PCibs

Не тру! Всего один маленький кусочек :)

Любая тема со словом «сеньор» перерастает в перепалку :-). Причем зачастую люди даже не представляют, что может быть какая-то еще, иная, но пригодная точка зрения. Мнения подаются безаппеляционно с претензией на вселенскую истину. Это начало срача.

По ходу дискуссии я заметил, что половина аудитории понимает под словом сеньор того, кто плавает мелко, но широко (сегодня пишем на java, завтра под iPhone), а другая половина — того, кто ныряет в глубину. Первые сеньоры хороши для аутсорсеров, вторые — для продуктовых компаний.

Тут ранее говорили о том, что не плохо бы показать какой либо пример своего кода. Меня интересует, а что не стыдно показать в качестве примера? Я имею ввиду «объемистость» проекта, если можно так выразиться. Что это должно быть? Какой нибудь «хеловорд» или «калькулятор», или что-то более серьезное, или гораздо более серьезное? Или это может быть кусочек (набор классов) какой либо системы? Что обычно люди показывают в качестве примера своих творений?

Как правило, в коде больше всего интересует стиль написания (code convention), чистота, лаконичность. Так что подойтет любой кусок кода где отчетливо видны эти вещи. Как говорится: Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ~Martin Fowler

Как автору поста, мне и ответ держать :)

Построение строкового эквивалента типу С++, используется во время интеграции скомпилированного кода С++ и интерпретируемого С\С++ через CInt:

z3d/type_name.hpp

Вариации на тему boost::mpl::vector и Loki::GenLinearHierarchy для построение связей между объектами (compile time + smart pointers)
z3d/slot.hpp
z3d/scope.hpp

z3d/node.hpp

Реализация паттреная «Chain of responsibility»

z3d/chain_of_resp.hpp

Кода тут очень много, но вот диаграмму классов я бы показал

Zoom3d.Engine architectural visualization

Мой собственный проект, который вскоре выйдет под shareware, как пример «средней» программы

Paintball.Editor

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

Особисто мені здається що починати треба з прохання прочитати сторінку-дві хорошого тексту і прохання коротко переказати про що текст.

Якщо людина здатна це зробити вже +50 до оцінки...

Или просто начать с теста IQ.
Ну а если честно, то мне вспоминается моя группа в универе, где были ботаны, которые все сдавали на 5, и те кто понимали о чем идет речь и сдавали на 5/4 в зависимости от ленивости. Как вы думаете, кого преподы уважали больше?

Это я провожу аналогию с тем, что знания и способность их обработать не являются хорошим критерием в работе. Это конечно большой плюс, но ...

Читаю тут не первую статью на тему синьор в 23/25 лет. Хочу поделится своими наблюдениями.

Волей случая попал в оутсортс. Стаж работы 8 лет с RDBMS, Спустя пару месяцев начали привлекать к интервьюрированию... За год провел около 30, и.. ни один кандидат по моему мнению не заслуживал звания синьора! Были TL, Начальники, кто угодно. Многие в желаемой позиции указывали позицию синьор и выше, и зп просили соответствующую. Но оценка реальных знаний расставляла все на свое места.

И мое убеждение, что:
1. синьоров мало,
2. с уменьшением возраста их попросту нет

3. желающих джуников заявить о себе как о синьоре хоть отбавляй

По крайней мере в области знаний RDBMS/OLAP это так.

Все ес-но ИМХО.

А если посмотреть на сайт вакансий, то в большинстве требуются сеньоры, вот люди и начинают думать, что это обычный средненький уровень, а каждый себя, как минимум, на средненького оценит. И плюс чем меньше опыта, тем меньше знаешь, что ты не знаешь.

Сколько копий уже сломано вокруг «сеньоров».
В инфляции слова «сеньор» виноваты как наниматели, так и наемные. Есть спрос на «сеньоров» и джуниоров, вакансий на мидлов не густо «почему-то». А если есть спрос, то есть и предложение — чай не дураки на рынке труда с обоих сторон: одним надо перепродать «товар» подороже (наклеить более дорогую этикетку «сеньор»), другим — продаться перекупщикам без переклейки этикетки(вспоминаем капиталистическую добавленную стоимость, минимизация издержек и т.д.). Рынок есть рынок.
Основным же катализатором осеньоривания, по моему мнению, является повальное желание нанимателей заполучить «звезд-разрабочиков c 10 годами опыта на iOS» и чтобы «много и дешево», а всякая психология из разряда «я два года отработал, я теперь синьор» не более чем следствие — неокрепшие умы студентов впитывают новое мировоззрение на рынок, что вызывает ворчание «старичков», потому что им эти титулы достались совсем другими усилиями.

Лично я уже давно эти ранги расцениваю не более как позиционирование разработчика в каком-либо ценовом сегменте, которые не имеют почти ничего общего с уровнем знаний и навыков.

одним надо перепродать «товар» подороже (наклеить более дорогую этикетку «сеньор»)

Не совсем пойму, а что при этом мешает на внутреннем рынке труда «товар» покупать подешевле, как мидлов? :)

Ну это скользкая дорожка весьма, сознательно обманывать заказчика, потом же отвечать придеться, возможно со скандалом :)

Был свидетелем такой ситуации, так что это не теоретическое измышление.

Вот как раз у аутсорсеров часто висят вакансии в духе:
Middle Developer от 3-х лет опыта работы
Senior Developer от 5-ти лет опыта работы
соответственн, любой с пятилетним опытом вполне справедливо считает себя сеньором — он ведь не сам придумал, ему об этом прямым текстом сказали: 5 лет = сеньор, 3 года = миддл.

Весьма интересная информация

Да, еще было бы интересно почитать про то как быстро заканчивать интервью с неадекватами.

так же, как с адекватами, но без объяснения причин, почему «нет» :)

Унифицированный подход. Хотя в тех же продуктовых компаниях чаще встречаются варианты собеседования «под проект/продукт», когда претендент собеседуется в рамках технологий и фич конкретного проекта/продукта.

Хотя в тех же продуктовых компаниях чаще встречаются варианты собеседования «под проект/продукт»

Рылии?!

Что-то я такое только в гуано-аутсорсе встречал (!)Важно: не просто в аутсорсе а в гуано-аутсорсе.

Рыли :) По крайней мере я в одной такой продуктовой компании некоторое время работал. Требовались знания конкретных компонентов, конкретно T-SQL, OLAP и т.п. заточка под продукт. Да и коллеги из других продуктовых компаний примерно тоже самое описывали. Понятно дело что есть исключения, но все же...

Требовались знания конкретных компонентов

Это каких?

конкретно T-SQL, OLAP и т.п. заточка под продукт.

Это не «заточка под проект» — это специализация ОЛАП и просто РСУБД — немного отличаются; Т-СКЛ, как и ПЛ/СКЛ — это немного разные языки и выехать на АНСИ СКЛ вряд ли получитсо.

Это очевидные вещи, так же как и «заточка под проект». Ведь был бы другой проект, где использовался бы Oracle, понадобились бы знания PL/SQL например. В данном случае проект определял навыки которыми должен обладать разработчик для успешного принятия на должность и это были T-SQL,OLAP, компоненты RxLib, ComponentOne (C++ Builder > 5.0). Это были одни из необходимых знаний, помимо принципов ООП и C++.

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

«заточка под проект» включает в себя минимизацию времени от старта до первого качественного результата

Это только подтверждает то, что компания хотела сразу брать человека с сетом навыков, а не тратить время на его вникание в компоненты + технологии. Явная минимизация времени от старта до первого качественного результата

Ведь был бы другой проект, где использовался бы Oracle, понадобились бы знания PL/SQL например.

Я знаю джаву, проект на дотНете. Требование в вакансии знания дотНета — это «заточка под проект»?

компоненты RxLib, ComponentOne (C++ Builder > 5.0).

Это было «маст хев», или «хорошо бы знать»? Сомневаюсь что знание этих фишек было решающим.

ваша методика частный случай:
blog.gamedeff.com/?p=64

вот тру собеседование для синьора.

уточнение: C++

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

Ну а про частное vs общее спорить не буду, диалектика :)

А я б на такую работу не пошел: уж больно напыщенный текст.

Спасибо что поделились. На мой взгляд — это адекватная, информативная и вежливая форма собеседования. За полчаса общения вполне можно разглядеть разработчика и сделать выводы (для этого, конечно, сам интервьюер должен быть равного или большего опыта, чем испытуемый). Часто приходится слышать о 5-8 часовых интервью — вероятно, этот кошмар разработчика происходит в больших компаниях, когда интервьюер не может адекватно оценить соискателя, и нужен тяжелый формальный процесс прохождения интервью.

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

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

От того, что собеседуют будущие коллеги, а не абстрактные люди, собеседование короче не станет :) повторюсь, если вы выбираете многоборца СЕБЕ в команду — он у вас на квалификационном тесте побегает и попрыгает будь здоров :) вам же потом легче будет — меньше неожиданностей. разве нет?

Нет :)

Будущие коллеги (начальники) как раз ищут разработчика под себя, они знают над чем, с кем и как будет работать новичок. Поэтому время на собеседование сокращается в разы и растет качество результата.

Если же компания большая и поток новичков большой, если никто толком не знает, на каком проекте и в какой команде окажется новобранец, если решение принимается «где-то наверху», а не в комнате для собеседования, если наконец рекрутер думает что PHP это сокращение от «рок-н-ролл», то соответственно нужен формальный и долгий, бумагоемкий процесс собеседования.

если коллеги делают сложное что-то и общаются с человеком, который будет на высокой позиции... вряд-ли сеньор будет делать что-то одно. прокачать по многим направлениям зрелого спеца другим зрелым спецам за 30 мин не получится — им надо сначала понять друг друга :) иначе две крутотеньских позиции столкнутся и разлетятся в стороны :)

если же в команде нанимателей есть телепаты — даже меньше 30 мин надо

Поэтому время на собеседование сокращается в разы и растет качество результата

все зависит. но то, что сокращается в разы или до нуля количество бесполезного времени — никто и не спорит :)

Полчаса лично для меня достаточно, чтобы сделать выводы и в большинстве случаев принять свое решение. Дальше имеет смысл продолжать, если есть сомнения или если просто интересно узнать, насколько глубоки и разнообразны знания кандидата.

Отличная статья — думаю такой подход позволит выявить как раз только хорошего джуниора и не плохого мидла, для сеньора это семочки :) .
Хотя ваше замечание о том что для джуна и мидла «энциклопедия» важнее извините это нонсенс !
Неужели для сеьора эти знания менее важны?

А кто же тогда будет строить работу так что бы у джуниора и мидла даже вопросов не возникало: «А могу ли я написать это по другому ?»

для сеньора это семочки :)

тут я с Вами не соглашусь, но холиварить не буду.

Хотя ваше замечание о том что для джуна и мидла «энциклопедия» важнее извините это нонсенс !

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

Можем перебраться в личку — мне правда интересно, Макс говорит что Сеньор это мега-фигура — вы судя по описанию Архитектор . Так что же из себя представляет тогда этот мифический зверь Сеньор Разработчик ?
Если старший специалист в команде не умеет читать а главное писать на UML то как он тогда будет ощаться с Архитектором? Как работать с заказчиком, как составить диаграмму процессов и как он вообще работает, кто ему выдал погоны сеньора?
Кто эти люди Менеджер Проекта , Архитектор Системы,Руководитель команды, Старший разработчик ? Как они работают в одной команде если они общаются на сленге и жаргоне малогрматного заказчика ? Ведь UML был как раз и создан чтобы вся эта команда взаимодействовала на одном языке , напрашивается аналогия с вавилонской башней ...
Или из-за жадности это как раз о нем «И швец и жнец и на дуде игрец »?! И ему самому с собой можнй разговаривать на одному ему понятному языке ?
П.С.если будет такая статья на ДОУ буду признателен.
П.С.С. Читал «Мифический человеко-месяц » много думал, если честно не могу понять где все эти люди в украинском ИТ.

Опять семантическая перегруженность терминов :) Сеньёр-Архитектор.
Выяснение распределение ролей и погонов, как Вы правильно заметили, другая тема.

И ответ на все Ваши вопросы может быть дан только в конкретной среде и времени, а умные книги дают ориентиры.

А у нас в компании есть Сеньйор Проджект Мэнеджэр.

«Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень».

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

Уровень владения UML, количество типов диаграмм в арсенале С.

В 20 лет прекрасно знал. В 23 уже забыл немного, сейчас — тем более.

Владение паттернами проектирования.

Применял еще до прочтения разных GoFов. Названий не знал. В 22-21 уже знал названия, к 23 начал забывать.

Комментарии кода.

Не пишу в 99% кода(Если явно не оговорено), просто нет необходимости. Почти весь код со сложной и непонятной логикой предназначен для себя любимого и интересен только в процессе написания. Если надо будет писать в команде что-то из rocket science, то комментировать буду. Код, который идет жить в продакшен просто обязан быть настолько прост для понимания, что комментарии излишни. На текущем проекте, например, джавадоки явно указанны как излишество. Если поведение вашего кода непонятно — переписывайте код.

Итог — методика претендует на роль быть silver bullet, при этом не вписываясь в реальную жизнь

Сорри за отсутствующие местами пробелы — клавиатура дрянь

Действительно «Смешно» — поверьте это возможно, писать всегда хорошо и выдавать всегда хороший код .
Сроки не могут идти впереди Качества :).

По поводу джавадоков — это может быть не нужно вам, но очень выручит того кто без знания всего ТЗ и всего кода, сможет быстро разобраться именно с этим функционалом.

поверьте это возможно, писать всегда хорошо и выдавать всегда хороший код .
Сроки не могут идти впереди Качества :).
Это что, тонкая шутка? Если нет, то вы наверное сразу бросаете работу если там нет ТЗ, бизнес аналитика и установлены жесткие сроки, в которые вы гарантированно не уложитесь?
По поводу джавадоков — это может быть не нужно вам, но очень выручит того кто без знания всего ТЗ и всего кода, сможет быстро разобраться именно с этим функционалом.
Да 90% жаводоков не помогают, в том то и дело. Текущая проект — реальный пример того, как компания требовавшая доки ранее, сделала их опциональными. Просто было принято решение что этот тип документирования себяне оправдывает

Кинь сюда пример своего кода, думаю тебе быстро покажут что нет предела совершенству ;-)

Если поведение вашего кода непонятно — переписывайте код.

Спорное утверждение. Допустим, что есть код, написанный 5 лет назад неким программистом, который уже не работает над проектом, и вам необходимо что-то исправить в этом коде. Комментарии очень облегчают введение в суть дела.

Да, верно. То что чей-то коде непонятен вовсе не значит что это правильно. Комментарий не особо поможет, в программировании сходу могут быть непонятными либо редкоприменяемые алгоритмы, либо что-то из бизнес-рилэйтед. Второе должно быть описанно не в комментариях, первое можно и прокомментировать. Только вот я почем-то не вижу часто в продакшене методов подбора градиентным спуском, всё какое-то приземленное.

Не буду вступать в полемику, а приведу ещё один пример к пословице «Когда за деревьями не видно леса».
У Вас есть задача: перенести гору камней.
Этот красный — легко, вот это мне не нравится и он будет лежать здесь, этот в виде груши мы с напарником перетащим за два дня и т.д. Короче неделя-две и все дела.

Да уж нет — вес кучи 50 тонн.

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

Но Вы забыли, какая задача решается. Целое это не просто сумма частей.

Описанная здесь задача — интервьюирование, а не знание UML и паттернов и пр..

Не спорю, возможно и удается узнать человека задавая эти вопросы, но сами элементы на мой взгляд подобраны неудачно. К элементам и «придрался». Естественно «горящие глаза» можно увидеть и начав разговор с таких вопросов, но от этого они не станут лучшей темой для собеседования. То что у вас получается просто значит что вы начали лучше разбираться в людях, чем это было в начале вашей карьеры интервьюера

элементы на мой взгляд подобраны неудачно. К элементам и «придрался»

С интересом познакомился бы с Вашим сабсетом. В этом-то и суть поста, как этого так и других, поделиться знаниями, услышить критику и улучшить систему.

You suck at interviewing. Srsly. You do.

www.humbledmba.com/...iewing-everyone

30 минут? тоже сомнительно. вы реперов на работу набираете?

если серьезно: набор слов с претензией. «Выявление асимптоты, верхней границы знаний и потенциала С». даже звучит грустно.

30 минут хватит, чтобы увидеть сильные и слабые стороны интервьюера. Никто не запрещает Вам проводить собеседование дальше и уточнять оценку.

мне также никто не запрещает проводить интервью совсем не так, верно?
но речь ведь о статье, которая утверждает: «Через 30 минут ясно каков уровень С.»
На что я возражаю: невозможно, потому что вы не берете про по разрезанию хлеба — или режет или нет. вы берете про «по всему». 30 минут tends to be insufficient amount of time.

кроме того. со всем уважением, вот поговорили вы о том как надо делать. а результаты?
«используя такой метод, я в среднем трачу на _успешное_ интервью __ минут, после этого со мной __ процент продолжает хотеть работать, __ процентов набранных таких сотрудников отлично справляются с задачами, __ процент хорошо входит в команду, .... всего интервью __, из них успешных __»
ну, это если конечно такая информация доступна.

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

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

Прямо таки магия «30 минут».

Попробую ещё раз проговорить позицию: в течении этог периода очень просто коснуться нескольких ключевых моментов, как например Pimpl или пообщаться на тему Адаптер, Прокси, Декоратор. Правило 80\20 работает на ура. За 20% времени, можно узнать 80% ключевой, именно ключевой информации.

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

могу с определенной увереностью сказать, кто чем занимается

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

я еще и на машинке могу, и еще много чего. но вы ведь не думаете, что мне так уж интересно, какое у вас от меня впечатление? я-то не сеньором к вам пришел устраиваться.

по сути: опять много слов ни о чем + фиксация на определенном сете технологий.

и не поймите меня неправильно. я хоть и критикую, но у меня ни одной причины не верить вам, что такой подход работает _конкретно-для-вас_ нет. с другой стороны я сомневаюсь, что изложенный материал совершенно точно описывает вашу практику и не содержит приукрашиваний. кроме того, вряд ли является эффективно применимым вне описанного вами выше набора технологий и как общая практика не годиться period.

ну на этом и закончим, дальше уже толко holy wars.

Вообще с опытом интуитивно понятно уже через 5-10 минут общения,
дальше просто уточняются детали, где собеседуемый силён, а где не очень.
Я бы даже так сказал: после 10 минут общения — начинается процесс проверки первоначального впечатления, пытаешься переубедить себя в противном. В 95% случаев — первоначальное мнение не меняется.

Мды... По такой схеме и я не пройду :-) :-) :-)

Минутка троллига на ДОУ

Вам наверное 23 года :)

Скоро будет... только если цифры местами поменять.

Я вот «жертв» так не мучаю. Если видно что человек говорит уверенно (и правильно), не сбивается, не прячет глаза при ответах, то брать можно :-)

«Для нас намного важнее, что вы сможете сделать, чем то, что вы уже сделали» ©How Would You Move Mount Fuji?

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

И еще вот интересно, какая была бы реакция, если бы соискатель с солидными фирмами в резюме на оба вопроса ответил, что программный код и архитектура продукта это собственность предыдущих работодателей и коммерческая тайна? Ведь на самом деле, если рассматривать IT как бизнес, именно такой ответ является правильным :)

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

«Для нас намного важнее, что вы сможете сделать, чем то, что вы уже сделали»

Извините, но опять обсуждать диалектический материализм нет сил :). Это взаимосвязанные вещи. То, что Вы сможете сделать базируется на ваших умениям, основанных на том что Вы уже сделали и т.д.

что программный код и архитектура продукта это собственность предыдущих работодателей и коммерческая тайна

Вот тут прячется один из истереэгов. На самом деле я хочу увидеть код, которые разработчик писал сам и применял в коммерческих проектах, может быть хранит его на соурсфорже или гитхабе. Но это идеал.

Ну и всегда должен быть план B:), распечатываем листочки и поехали:
1. Можно ли переопределить значение ссылки?
2. Что может выступать в качестве параметра шаблона?
3. Напишите функцию int itoa( char const* ).

...

Статья класс. Будем считать что это конец флудофых статеек на ДОУ :)

По второму пункту (про архитектуру):
— тут одна сложность есть люди которые очень хорошо рассказывают, но при этом делать ничего не умеют;

— УМЛ — далеко не все, даже в энтерпрайзе, им владеют хорошо, большинство «читать могу, пишу с ошибками»; кроме того сомнительна ценность данной технологии (но это уже другая история);

Более интересен первый пункт (про код):

Не у всех есть возможность показать свой код, тем более промышленный (а не домашние поделки). Судя по пунктам оценки, которые вы написали — оценка кода взяла на себя большую часть (да и на ее основе можно поспрашивать «про архитектуру»)

Почему бы и не показать домашние поделки?

Первое: далеко не у всех он есть :)

Второе:
«домашний» код существенно отличается от «промышленного». Первый должен нравится автору, второй должен легко пониматься (!)всеми членами команды и делаться быстро (вряд ли кто-то будет ждать пока вы создадите идеальный шедевр)
Если человек очень хорошо «вылизывает» код дома — это нормально, на работе — необходим компромисс между качеством и скоростью. И то что человек хорошо делает «домашние» проекты — еще не значит что он сможет «держать темп» на работе.

Да и объем со сложностью решаемых задач не те.

Ну и домашние поделки после 40-ка часов поделок в офисе — это для маньяков. Я вот еще книжку какую-то мудрую могу себя заставить почитать, а кодить — лучше сразу пристрелите. В мире еще столько всего интересного...

Ну и домашние поделки после 40-ка часов поделок в офисе — это для маньяков.

Просто иногда бывает что «прет», вот не так давно всю ночь кодил (за шо и огреб ;) ), а до этого дома пару месяцев даже не прикасался ни к чему «девелоперскому».
Кстати, если говорить про синьоров:
ИМХО, у каждого Синьора должна быть хоть одна «домашняя» поделка (может не отображающая его актуальный уровень). Это больше показатель того что иногда называют «страсть к профессии».

Я не утверждаю что надо кодить 8 часов на работе + 8 дома, а остальные 8 спать.

Таки да. Меня тоже давече одергивали на предмет «что, опять?!». И оставалось только состроить выражение лица типа котэ из Шрека. А иногда дома по месяцу-два шашку в руки не берешь — и вроде как надо, а не идет. Но оно ж на то и «для души», чтобы «писать, когда не можешь не писать» ©. Хотя GTD страдает, тут не поспоришь :)

есть такое избитое выражение:

есть программисты , которые пишут хороший код по настроению, профи пушут всегда хороший код.

И без багов и код после них рефакторить не надо.

не, так пишут полубоги программинга

Вот и я дума... Что все так в тот УМЛ влюблены... Это если проект большой, команда большая, текучка да ещё тех-лид со стороны заказчика — тогда ок — это спасет от кучи граблей. Ну а если проект на 3 человека и заказчик даже не знает как UML расшифровывается? :-)

Это если проект большой, команда большая, текучка да ещё тех-лид со стороны заказчика
Даже на больших проектах редкость (по крайней мере из моего опыта).
Вопрос:
Как часто люди ресуют ЕРД? А САДТ?
Это просто стандарты. Если ими пользоваться на все 100, то все будет супер. Если на 99%, то можно вообще не использовать.
В мире где Водопад еще может выдавать актуальную скорость разработки УМЛ еще актуален.

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

Основная цель — кристализация инженерных знаний по проекту.

Это типа качество документации?

Если да, то далеко не всегда она нужна в полном объеме. На ее поддержку может уходить куда больше времени чем на изменения функционала, и не всегда это удобно для бизнеса.

На ее поддержку может уходить куда больше времени чем на изменения функционала, и не всегда это удобно для бизнеса

Совершенно согласен. Вот тут и нужно уметь балансировать :).

А разве «сеньйор-помидор» не научился балансировать за 23 года?

Почему всем нравиться Ctrl+F или «Goto definition»? UML просто графическсое средство, помогающее смягчить последствия «поломанных телефонов» и семантической перегруженности терминов. Попробуйте как-нибудь обсудить термин «библиотека»?

Не у всех есть возможность показать свой код, тем более промышленный (а не домашние поделки).

Это конечно так, но не совсем так. Формально NDA закрепляет за заказчиком собственность на код и результат работы, равно как и не разглашение названия конторы-заказчика. Но любой формальный документ не описывает всех нюансов. Например, является ли код удаленного бранча по прежнему объектом NDA? А код, существующий только на машине девелопера — например, альтернативное решение, которое не было принято? Если NDA запрещает разглашение конкретной бизнес-реализации и опять-таки формально не включает в себя собственность на весь код, то пара-тройка классов из разных мест проекта не попадает под действие NDA и может быть опубликована. И так далее.
К чему собственно спич — хороший сеньйор всегда знает, что именно попадает под NDA. Я встречал множество вариантов NDA, но ни одного, который бы делал не возможным продемонстрировать хоть что-нибудь. Разумеется для того, чтобы предоставить пример кода и одновременно не нарушить соглашений нужно а) прочитать соглашение и б) понять прочитанное. Но сеньйор который не читает документов, которые подписывает или не понимает их смысла.... По-моему это не совсем сеньйор, или упомянутый в заголовке «сеньйор 80го уровня», как угодно.

Ну мне так кажется.

Формально NDA закрепляет за заказчиком собственность на код и результат работы, равно как и не разглашение названия конторы-заказчика.
Вопрос не только в НДА или еще каком-то документе. Вопрос больше моральный.
Хотя с практической точки зрения, так же возникает вопрос:
Зачем человеку брать на работу того кто зачем-то «вынес» честь кода разработки и показывает его, мало ли чего он еще вынесет?
Можно провести некую аналогию с
«Не рекомендуется на собеседовании поливать грязью свою предыдущую конторы и начальство.»

Второй момент: я не уверен что в моем коде 2-х годичной давности, например, хоть половина строк осталась исходной: что-то фиксят, добавляют функционал, рефакторят наконец.

А код, существующий только на машине девелопера — например, альтернативное решение, которое не было принято?
А оно доделано? Если оно настолько хорошо, почему его не приняли (понятно что ситуации бываю разные)? Можно задать еще кучу всяких вопросов.

На мой взляд, вопрос очень и очень спорный ... или лучше — тонкий. Поэтому я и сказал:

Не у всех есть возможность
Может более корректно сказать: «Не всегда»...

Зачем человеку брать на работу того кто зачем-то «вынес» честь кода разработки и показывает его, мало ли чего он еще вынесет?

И это тоже правильный вопрос, но тут нужно прежде всего важно что именно вынес и почему именно это. Тоже, кстати, хорошие вопросы.

Второй момент: я не уверен что в моем коде 2-х годичной давности, например, хоть половина строк осталась исходной: что-то фиксят, добавляют функционал, рефакторят наконец.

Дык это, сливать код из репозитория как-то не честно, не? Это если в загашниках чего осталось, тогда — да. А специально сливать как-то...

А оно доделано? Если оно настолько хорошо, почему его не приняли (понятно что ситуации бываю разные)? Можно задать еще кучу всяких вопросов.

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

На мой взляд, вопрос очень и очень спорный ... или лучше — тонкий.

А вот с этим я спорить не стану. Очень, очень тонкий вопрос. Но мы ведь и не про джуна говорим, да? :)

И это тоже правильный вопрос, но тут нужно прежде всего важно что именно вынес и почему именно это.

«Ложечки нашлись, а осадочек остался» ©

Нас же интересует почерк, не рукопись или отрывок, если я правильно понял автора.

Если код совсем не связный, то по нему мало чего можно понять, или таки можно? Я не синьор если че :), наверное еще один из показателей Синьора — умение видеть эту грань. Если я все правильно понял, то интересует «хоть немного работающий» (из пункта 3 «Используемые технологии/фреймворки/библиотеки/велосипеды.»)

Но мы ведь и не про джуна говорим, да?

А вот в контексте разговора, я разницу не вижу. Если вам не трудно, поясните.

Если код совсем не связный, то по нему мало чего можно понять, или таки можно?

Как говориться for whom how. Как по мне — можно. Человек (мне кажется, что любой) постарается не ударить в грязь лицом и возьмет что-то, чем гордиться — явно и не явно, не важно. Раз этот код (принципиально несколько классов — 1-2 мало, а 10 уже много. 3-5 достаточно) есть предмет гордости, значит по нему можно смотреть эту самую «каллиграфию» или чистописание, если угодно. И тут можно рассмотреть многое — сколько у класса обязанностей, сколько — у метода, удобно ли спроектированы методы для юнит-тестирования, являются ли методы юнитами по сути, публичные поля, синхронизированные методы/секции, документирование кода и комментарии... Множество параметров. Один-два не скажут ничего, все в комплексе — многое.

Но я могу ошибаться, и это все возможно бред моего воспаленного сознания :)

А вот в контексте разговора, я разницу не вижу. Если вам не трудно, поясните.

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

По первому пункту понял. Только вот относительно меня: Джава-кода которым я бы мог гордится (!)И который был бы не в продакшене — у меня нет (может выросту и он появитсо :) ) Есть джаваскриптовый код, есть ЦПП-код — но это немного другое.

Я назову это «моральная зрелость», пафосно конечно, но другого определения у меня нет. ....

Я имел ввиду что факторов может быть очень много, не только НДА. Как пример: мой случай описанный выше. У некоторых просто может не быть «загашников»: один знакомый регулярно 1 раз в год удаляет все что не используется — фильмы, книги, ... код.

Джава-кода которым я бы мог гордится (!)И который был бы не в продакшене — у меня нет (может выросту и он появитсо :) ) Есть джаваскриптовый код, есть ЦПП-код — но это немного другое.

Ну гордиться — это громкое слово и это в идеале. Тот код, который лично Вы считаете лучшим на данный момент. Опять таки, JavaScript или C++ годится на Java-интервью. Во всяком случае я бы взял посмотреть. Чистый C хуже и сложнее, но я бы тоже взял посмотреть. Brainfuck, Haskell, Perl, Lisp или Prolog — нет, но потому что сам не шарю. Язык особенного значения не имеет. Тем более, если он сродственен языку вакансии — Java, JavaScript, C++, C#, Python во многом похожи и стиль можно понять ИМХО.

Я имел ввиду что факторов может быть очень много, не только НДА.

А, ну так случаи бывают разные, кто бы спорил. Если нет кода — значит нет кода. Просто ответ «у меня NDA и я ничего не могу показать» без продолжений или альтернатив вызывает впечатление простой отмазки. Это легко проверяется вопросом «а что именно покрывает Ваш NDA» :) Но это детали. Мне больше нравится вариант с рефакторингом :)

Просто ответ «у меня NDA и я ничего не могу показать» без продолжений или альтернатив вызывает впечатление простой отмазки.

Эт да. У нас на НДА спихивают любое не желание о чем-то говорить :)

Есть, кстати, альтернатива, которая лично мне нравиться намного больше. Давече мне попалось тестовое задание, которое пока для меня является эталоном лаконичности и проверки технических скилов одновременно.
Простой джава-класс с одим методом, у которого куча обязанностей — тут и установка соединения с REST-сервисом, и получение ответа, и разбор этого самого ответа, и try/catch класса Exception с возвратом пустой строки. И javadoc-комментарием к классу, который гласил «Вот у нас тут код есть, он вроде как работает, но похоже кривовато написан. Отрефакторите его пожалуйста и напишите несколько unit-тестов на свой вкус»

По-моему гениально. Мой вариант рефакторинга принимающую сторону не устроил, но тем слаже победа, чем больших усилий она требует :) Я сделал еще парочку вариантов чисто для себя и обсуждения в узком кругу. Пока еще консенсуса относительно необходимого и достаточного варианта нет :)

«Вот у нас тут код есть, он вроде как работает, но похоже кривовато написан. Отрефакторите его пожалуйста и напишите несколько unit-тестов на свой вкус»

Вот это супер. Такое задание явно не займет много времени и можно посмотреть «в каком стиле» человек пишет. Хотя и имет ряд несоответствий, вроде отрефакторить и написать с нуля — это немного разные стили работы.

Если у вас есть возможность, я думаю многие были бы благодарны (и я в том числе), если бы вы выложи этот пример (я так понимаю что авторство не ваше, поэтому настаивать не буду :) ).

Авторство таки заказчика. Я спрошу актуально ли еще именно это задание. Если нет — с удовольствием поделюсь.

Хотя и имет ряд несоответствий, вроде отрефакторить и написать с нуля — это немного разные стили работы.

И опять таки да, но не совсем :) Тут очень важный и тонкий момент — понимание принципа рефакторинга.
У нас ведь как принято «рефакторить»:
Нельзя возвращать null? Бросаем эксепшин. Плохая практика catch (Exception e)? Поменяем сигнатуру методов. Обязанностей у метода много? Разобьем на три-пять-десять методов и сделаем три-четыре публичных.
А потом ВНЕЗАПНО оказывается, что на возврат null была завязана система валидации, метод без эксепшинов в сигнатуре вызывается в 100500 разлиных мест, а публичный API из одного метода вызывается в 10 внешних системах, которые написаны 4мя командам в 4х таймзонах и на 3х континентах. И шо потом с этим делать?

Так что этот заказчик считает, что если человек может грамотно отрефакторить нечто, то написать «с нуля» точно сможет. И я полностью его поддерживаю. Именно такими методами и можно померять зрелость. Или сеньйорити, если угодно :)

+100500

я практически всегда даю возможность написать код на месте. вот тебе комп, вот автономная задача, вот инет. просто даже наблюдать, как человек среду под свои привычки «запиливает» — много интересного узнаешь :) если приложение кривое, но работает и понимает, в чем именно кривизна — в ведомые годится. если ещё и прямое — говорим дальше.

для тех, кто быстро справился с разработкой с нуля — вот тебе готовый код, как бы ты его отрефакторил? то же, о чем ты говорил, Антон. ну или разработать неавтономный модуль системы (типа задачки на парсинг на 4-м опентоке ;)

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

ну и для экспертов — беседуем о недостатках применяемых фреймворков и практик, а также об обосновании решений «почему все-таки этот молоток выбран».

Простите за глупый вопрос, а что такое «Прокачивание интерфейсов» ?

сорри за сленг — выяснение интерфейсов :)

А я то уже настроился на то что у сеньйора 80го уровня «интерфейсы прокачаны» по самое немогу

Уточніть будь ласка, в який момент і як Ви перевіряєте уміння С працювати в команді.

Дякую, що ділитесь досвідом.

разговор данного формата уже и есть по сути проверкой на умение работать в команде. Это видно по изложению мыслей и по процессу общения.

Первый момент, когда мы обсуждаем пример кода С. Часто я применяю «метод блондинки» и немного провоцирую «тупостью». В команде есть и junior разработчики и разработчики работающие над «удалёнными» подсистемами. С должен иметь запас прочности, чтобы донести до Вас мысль\идею. Это такая симуляция код-ревью.

Второй момент — во время обсуждения структуры проекта. В этот момент С выступает в роли архитектора проекта, а я в роли разработчика. При такой постановке — степень умения\не умения работать видно сразу.

Подписаться на комментарии