Описание проекта на бумажке

А если я на листочке голую женщину смогу нарисовать меня возьмут?

Если рисуют на бумажке проект на который собеседуют — то это как-то странно.
Во-первых кандидата могут рассматривать на несколько проектов и позиций и если каждый проект рисовать то это конференция, а не собеседование выйдет.
Во-вторых на этапе первого собеседования какую информацию раскрывают кандидату про проект? Ну наверняка не схему базы, не архитектурные диаграммы и не иерархию классов. Во многих случаях NDA, а с другой стороны — нахрена эти детали человеку, который еще не часть команды проекта и неизвестно станет ли?
А вот попросить кандидата нарисовать схемы на бумажке — очень полезно!
Для мидла неплохо бы уметь нарисовать диаграмму классов. Например для какого-нибудь патерна. Я обычно прошу нарисовать как в отсутствии множественного наследования добавить функционал в несколько «братских» классов (а-ля «миксины»).
А для синьора и тем более архитекта умение изобразить любую идею «квадратиками» — это обязательно! Если кандидат с лычкой «архитект» не может подняться выше кода на уровень абстракций — это печаль. Пускай даже не по стандарту UML — просто квадратики и стрелочки.
Согласен — бумажка это немного «олд-скул» и удел динозавров вроде меня, которые так и не привыкли к гаджетам.
Любопытно другое: почему так мало кандидатов приносят на собеседование свой ноут или хотя-бы планшет?!
Ведь это было бы очень логично и удобно: хотите посмотреть мои наработки? — вот они, хотите что бы я написал код? — у меня IDE под рукой, диаграммы нарисовать? — редактор есть, сертификаты показать? — вот они, точное название класса забыл? — сейчас гляну доку. Программист сейчас без Интернета как слепой — так почему на собеседовании пытаются писать код по-памяти на бумажке?

У нас когда-то хитрый менеджер так DBA-гуру искал.
Проект старый гнилой, в базе «гордиев узел» и «6 ненормальная форма». Процедуры джоинят по 10 таблиц и работают по нескольку минут. Пока страница загрузится — юзер успевает заснуть на кнопке. Нужны «радикальные реформы», но кастомер «ватный» и хочет «жить по старому» но только с «покращенням». Поэтому решили позвать Путина DBA-гуру чудотворца, который махнет рукой и база заработает в 10 раз быстрее.
Нашли гуру, позвали на собеседование. Сразу распечатали структуру базы на листе А0 и повесили на доску. Распечатали ему самую тормозную процедуру на 3 листа и спросили что делать что бы летала. Думаю план менеджера был что если даже не наймем — так хоть одну проку на шару оптимизирует.
Но гуру был настоящий. Он на все это посмотрел минут 15 с умным лицом (думаю поржал про себя) — и на листочке изобразил десяток баз с несколькими копиями каждой таблицы в каждой базе. Для тупых объяснил что если в одной таблице 100500 миллионов записей — то SQL НИКОГДА не будет с ней работать быстро. Даже SELECT COUNT(*) из такой таблицы работает несколько минут.
Как настоящий профи он не сказал прямо «выкинуть и переписать все», но с такими изменениями проще было сразу начинать писать новый проект с правильной базой.
В итоге из-за такой честности DBA-гуру оказался не нужен — переписывать ведь все равно никто не даст. А ведь мог бы соврать — и потом годами ковырять этот разлагающийся труп за большую зарплату.
P.S. Позже проблема решилась сама: через пару лет 80% юзеров этой гнилой системы разбежалось, база опять стала маленькая — а перфоманс приемлемый. Так что оставшиеся 20% слоупоков счастливо продолжали дергать ифреймы в 6 IE. Может и сейчас где-то в интернетах еще жив тот сайт если клиент уже окончательно на нем не разорился.

Можно еще слепить из пластилина.

Да вы что, совсем уже оборзели, не уважаете стандарты отрасли? Только доска и фломастер!

И правки маркером поверх монитора, на этот раз маркер перманентный.

Есть еще интересней вариант. Можно интервьюируемого человека попросить нарисовать что-то из того что он делал.

Ты бы полегче, что ли. Я тут выяснил, что автор топика HR.

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