Как стать автором
Обновить

Комментарии 224

На какую позицию вы претендуете? Тут в лучшем случае junior

Мотороллер не мой, я просто разместил объяву перевод.

По моему это интервьюер на junior

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

Вообще не супер. Если человек не в состоянии сам ответить на эти вопросы, то кому он нужен?
Нужно было решить задачу, а не превратить ее в фарс. Уровень junior у кандидата — а если задача будет сложнее ему потребуется месяц на уточнение всех нюансов?

Если не уточнить все нюансы ДО того, как будет написан код, возможны варианты:


  • Пронесло, всё работает;
  • Всё в основном работает, но в некоторых непредусмотренных ситуациях падает;
  • Всё в основном работает, но создана дырка в безопасности системы (см. вопросы про шифрование);
  • Всё в основном работает, вот только клиенту было надо совсем не это, так что надо всё написанное выкинуть и переписать с нуля.

"Час работы по дизайну экономит день работы по кодированию".

Первую проблему решаем оберткой в try-catch. Шифрование — это фишка, которая стоит времени и денег, а на собеседовании есть 15 минут и нужно решить задачу в базовом её варианте (раз про отдельную фишку в виде шифрования заказчик ничего не сказал). Последний случай наиболее печальный, поэтому нужно использовать стандартный прием, которым пользуются менеджеры: «скажите, правильно ли я вас понял, что… ?». Это позволяет, как минимум, разделить ответственность в случае «выкинуть и переписать с нуля», а как максимум — переложить её целиком на заказчика, потому что он должен подтвердить, что вы а) все запомнили из того, что он сказал и, опционально, б) в целом согласен с предложенной концепцией решения задачи.
> Первую проблему решаем оберткой в try-catch.

И… что? Если ситуация непредусмотренная, что вы достигнете этим? Да, программа не упадёт, будет ещё хуже: она останется работать в непредусмотренном состоянии.
Программа копирования файла в exception напишет, что файл скопировать не удалось и вернет вызывающей программе это сообщение и текст ошибки в лог. Пользователь будет в курсе, что есть проблема и нужно решать её вручную или обращением к производителю ПО. И он не потеряет весь проделанный прогресс (не применимо к данному случаю, но в целом реально) из-за сбойнувшей функции.

При чём тут копировение? kifirch спросил:


а если задача будет сложнее ему потребуется месяц на уточнение всех нюансов?

И я объяснил, что будет, "если задача будет сложнее",

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

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

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

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

А то, что «у вас нет другого выбора» — это плохо, конечно, но не является аргументом писать некачественный софт.
Первую проблему решаем оберткой в try-catch.

Именно так поступили некоторые чиновники с аварией на ЧАЭС. "У нас тут взорвался реактор, но мы никому не расскажем, выходите спокойно на первомайскую демонстрацию."

окей, окей, я же дописал, exception, а там что хотите передавайте, код ошибки, окружение, сообщение пользователю, хоть print('we all will die! run for your life! nuclear plant has been melted down!');
"Час работы по дизайну экономит день работы по кодированию".

Да-да-да… Тут вот как-то коментировал про стадию "дизайна".


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


Другой пример: был у меня один коллега, — элементарнейшие вещи (типа той же упомянутой copy) он писал так: сначала писалась дока, потом интерфейс, потом все это правилось до крайней степени, причем его эго еще не удовлетворено, а отведенного времени уже на на 80%-90% съедено. В результате ему просто больше ничего не давали — лучше сам или кому другому отдам… Пока его не ушли.


Имхо, самое первое правило классного разработчика должно быть — держать перфекциониста в себе на очень коротком поводке. Применительно к примеру, как по мне, пусть лучше функция обросла 100-ми todos (которые возможно и даже скорее всего никогда не доделают), но она работает.

> самое первое правило классного разработчика должно быть

Отличать важное от неважного.
НЛО прилетело и опубликовало эту надпись здесь
«Час работы по дизайну экономит день работы по кодированию» — это про waterfall.

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

Поэтому, современные методологии работают по другому:
1. Делаем как-нибудь, лишь бы проще, быстрее и работало.
2. Показываем промежуточный результат заказчику, выясняем двигаемся ли мы в нужном направлении.
3. Корректируем направления и повторяем итерацию начиная с пункта 1.

Я думаю, правильнее было бы сначала написать самую простую реализацию, а потому уже — задавать уточняющие вопросы и предлагать улучшения.
Ага, сначала написать одно, а потом все с нуля переписать :)
Сначала написать одно, потом переписать, потом переписать несколько кусков по разному, а потом вылавливать баги следующие пол года.
это в действительности не так странно выглядит, как Вы, вероятно, имели в виду. в этом есть некий смысл, хотя бы с точки зрения «исследования» реализуемой системы, о которой мы начинаем знать намного больше, чем до того…
>>1. Делаем как-нибудь, лишь бы проще, быстрее и работало.

Это даже официально называется макет (или mock-up)
вот только п.3 отсутствует. Заказчик покупает что есть и мы этим пытаемся пользоваться :(
это какая-то современная болезнь, вроде эболы: манагеры как один стремятся пропустить этап проектирования. потом уже бывает поздно.
мне придётся перекодировать в UTF-16, а это несколько геморройно…

Если это WinXP, то в WinApi есть функция MultiByteToWideChar которая это сделает в две строки кода. Так что даже по задаваемым уточняющим вопросам уже можно сделать вывод о квалификации.

Вообще-то абсолютно адекватные вопросы. И да, перекодировка — это выделение буфера, потом освобождение, и это я не рассматриваю нюансы, например, требования к поддержке 32битных символов Unicode (MultiByteToWideChar поддерживают только 31-битные, насколько я помню — вернее, для UTF-8 это означает лимит в 4 байта на символ).

Чуточку ошибся, ограничение на символ строже в UTF-16, он может закодировать только 20-битный символ, а UTF-8 — 31-битный. И тут еще не рассмотрены преобразования символов, например, в каноническую форму и так далее.


Эх, и это всего лишь один вопрос из списка :-)

Кто в армии служил, тот в цирке не смеётся Кто при жизни писал базовые системные библиотеки, тот в аду отдыхает :)

Тот под других дрова подкладывает и в котле мешает…

Главное, чтобы дрова были подписанные

Вообще-то абсолютно адекватные вопросы.

Не все. Например, порядок байтов в строке в памяти колебать программиста не должен. Внимательный интервьюер на этом вопросе может сказать «Попался, тролль! Давай, до свидания».

Особенно если это имя файла пришло, например, по сети. Ага.

И прямо из сети попало в функцию, копирующую файл? Тоже до свидания. Это слишком тупой троллинг, как без необходимости спрашивать — а у вас double в стандарте IEEE 754?

Под double сейчас обычно понимается binary64 из ieee754, но иногда используется, например, decimal64 из того же стандарта.


Но не всегда использовалась смещённая экспонента, не всегда под double понимается 64-битное представление, иногда это проприетарная кодировка (например, на мейнфреймах от ibm), а не ieee754 binary64.


Другой кейс — это обыкновенный binary32/64, но в mixed-endianess как, например, бывает при работе с modbus/rtu.


Так что бывают кейсы, когда это уточнение существенно.

Мда, всё очень запущено. Мы вам перезвоним.

Лучше не стоит, не вижу смысла связываться с подобными вам.

Рассказ так себе. Не было никакого смысла издеваться над интервьюером и терять время, если что-то не сказано — значит на ваше усмотрение. В крайнем случае надо было начать с последнего монолога про объяснение, что хорошую функцию копирования файлов сразу не напишешь.
НЛО прилетело и опубликовало эту надпись здесь

Ну, хорошая функция — понятие многозначное :-)


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

В реальности этот диалог выглядел бы несколько иначе:
Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Вы нам не подходите.

Ну или, если интервьюер в хорошем настроении, как-то так:
Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Мы хотим посмотреть, как Вы понимаете задачу, какие подходы примените в ее решении и какие условия учтете, так что дополнительные вопросы не принимаются.

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

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

К: Что конкретно Вы имеете в виду, говоря "нештатные ситуации"? (pokerface)

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


Все вышеперечисленное аналитик-программист должен автоматически вывести из задания "напиши мне программу для копирования файла". Только при обладании бОльшим количеством данных о целевой задаче и области ее применения, данное решение может быть трансформированно в нечто более сложное. Принцип KISS еще никто не отменял.


Вот кстати притча в тему: https://habrahabr.ru/post/74193/

Вот кстати притча в тему: https://habrahabr.ru/post/74193/

Телепаты — да, они такие, им не жалко и 5 рублей платить. Одна проблема: только в притчах и существуют.


Только при обладании бОльшим количеством данных о целевой задаче и области ее применения

А чем, по-Вашему, занимался кандидат, как не сбором "бОльшегом количества данных о целевой задаче и области ее применения"? — "Очевидно, [...] у Вас имеются какие-то очень-очень специфические требования, которым библиотечные функции не удовлетворяют, и я намереваюсь эти требования из Вас вытянуть."


В случае невозможности копирования вывести (вернуть) ошибку, желательно с пояснением причины.

Возможны и ситуации, когда явной ошибки нет, а по факту — есть (например, описываемый кандидатом случай, когда файл скопировался незашифрованным, или не были скопированы права доступа, и master.passwd оказался world-readable).

А чем, по-Вашему, занимался кандидат, как не сбором "бОльшегом количества данных о целевой задаче и области ее применения"?

Надменно демонстрировал важность своей работы и ценность своих знаний.


Первым вопросом должен быть не "что вы подразумеваете под вашей просьбой?", а "для чего вам это нужно?", "где вы это будете использовать?", "для какой общей задачи требуется данное решение?" Опишите проблему целиком, а я уже сам решу, нужно ли вам атрибуты менять и вообще нужно ли само копирование файла.


Вот приходите Вы к дентисту: "вылечите мне зуб". А он такой: "что конкретно Вы имеете ввиду под "вылечите"? У вас пульпит, периодонтит, перикоронит или простой кариес? Вам пломбу поставить, удаление нерва, коронку, удаление зуба или что? Что Вы от меня хотите? Сформулируйте точно!"

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


Я уже который раз долдоню: детальной постановкой задачи занимается специальный человек — software consultant. И именно его задача — выбить из клиента, чего именно он хочет. И зарплата у него несколько другая, чем у кодера-по-спецификации. (В частности, мне на протяжении своей жизни довелось поработать и одним, и другим, и обоими вместе).

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

… за одну (меньшую) зарплату ;)


По разным причинам

Например "работодателя жаба душит, а работник не нашёл способа использовать свою редкость как преимущество".

Бывает, наверное, что и жаба. А бывает, что клиент сам не понимает, чего хочет. Это непонимание настолько глубоко и всеобъемлюще, что единственный способ что-то из него «выбить» — это показать — нет, даже не показать, а дать попользоваться уже готовым продуктом и спросить: «Ты этого хотел?» В теории, этот самый software consultant и тут был бы очень в тему, а на практике он зачастую превращается в пятое колесо, от которого никакой пользы, кроме вреда в виде увеличившейся силы трения.
По-моему, большая часть взаимного непонимания в комментариях к этой статье связана с тем, что зачастую никакого такого отдельного «специального человека» попросту нет.

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



Поэтому все современные методики разработки пытаются уменьшить число ступеней в иерархии разработки, сделать структуру более плоской и прозрачной. Обязанности "software consultant" ложатся на team lead-а, который суть есть разработчик.

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

Это всё равно, что сказать "англо-русский переводчик плохо знает и английский, и русский". Software consultant — это "переводчик с человеческого на программистский", поэтому он как раз должен быть хорошо знаком с обоими "языками". Обычно ими становятся опытные программисты, которые за свою жизнь пообщались со 100500 клиентов, и уже могут понимать, что клиент действительно имеет в виду, говоря "нарисуйте мне красную линию зелёным цветом".

Именно! Это первое задание, чтобы отличить кодера от программиста. Кодер будет задавать сотни уточняющих вопросов, на которые программист в состоянии ответить сам.
это до тех пор, пока вас не попросили «поиграться со шрифтами» или «сделать поярче»… Вы видите функцию так, заказчик по другому и далеко не всегда заказчик может внятно объяснить чего он хочет… Статься, конечно, гипербола, но смысл есть. Думаю все помнят картинку с деревом и качелями…
Вы видите функцию так, заказчик по другому и далеко не всегда заказчик может внятно объяснить чего он хочет…

… А все телепаты, как назло, в отпуске. ;)

Да, герменевтика - она такая... ) Заказчик, может, и сам не представляет до конца (да даже не "до конца", а и до середины не представляет), что именно ему нужно и удивляется, получив результат.

Самое главное отличие кодера от программиста — это что кодер знает, чем кодер отличается от программиста, а программист знает, что никакой разницы нет.

Согласен с комментаторами, я был неправ

Так сурово троллить, конечно, можно, но нужно быть готовым, что в эту компанию вас больше никогда не возьмут работать. Ведь интервьюер предполагает, что кандидат показывает лучшие свои качества, а с большими зеленомордыми троллями работать не особо комфортно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Тролли, по моему опыту, очень хорошо делают Code-Review. Конечно, если под инспекцией кода понимать возможность исправить по максиму, а не пропустить в коде «совсем уж ляпы»
Мне кажется, что, в случае с code-review, это называется педантичность, а не троллиниг.
Троллинг 80lvl — это одно из качеств профессионального тестировщика)))
я как-то давно пришёл в одну компанию (не софт) — директор (небольшая компания) водил меня по фирме показывая — чисто провести хотел, но я по дороге столько вопросов ему задал — типа а это что и почему вот так а не эдак, что растянулось на два часа, и на очередной мой вопрос типа «а вот эту проблему вы как решили?» — он ответил — пока никак, вот вы и решайте её, начинать можете хоть сейчас или когда вам удобно в течение месяца…
Вспомнилось «Что бы сделал мистер Фейнман?» (https://blogs.msdn.microsoft.com/ruericlippert/2011/02/28/983/)
Вы посчитали, что вопрос интервьювера глупый и поэтому решили его переплюнуть в глупости?

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

К слову задача так и не решена.
Вы посчитали, что вопрос интервьювера глупый и поэтому решили его переплюнуть в глупости?

Не знаю, как насчёт глупости — а вот в невнимательности меня в данном треде переплевали с огромным отрывом уже несколько человек, не заметив в заголовке статьи флажка "перевод".

Нет, я понимаю, как можно взъесться на такое задание, но если бы в подобной ситуации оказался я… уж я бы оторвался по полной:

И далее. Это ваш текст? В оригинале я его искал, но не нашел. Ткните пальцем.
Вообще то это есть в оригинале, конец первого абзаца (https://web.archive.org/web/20070704122624/http://exold.com/article/stupid-interview-questions)

Тыкаю:


Now, while it’s quite possible to take umbrage at this, if I were in that situation, I’d see it as a chance for some free entertainment

Перевод художественный, а не дословный.

Ха. точно, я отвлекся на пост по ссылке в оригинале. Прошу прощения.
Хотя сути это не меняет.
Теперь вот такое предложение. А что, если…
— Не стоит.
— Ясно. Тогда, может быть, нужно…
— Не нужно.
— Понятно… Разрешите хотя бы…
— Вот это попробуйте! Вам поручена эта операция, так что действуйте.

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

ИМХО согласен с CAJAX, очевидно вопросом проверялись знания некоторых основ. Умение написать простой алгоритм и знания базовых API, что в реальности некоторые кандидаты не могут сделать. Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.
Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.

Кандидат просто продемонстрировал глубокие знания возможностей и особенностей системы (например, Вы помните про назначенные vs унаследованные права доступа?), а также способность предвидеть и предотвращать потенциальные аварийные ситуациии.


Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.

А ЧСВ в программировании место там, где не светит солнце. "Если Вы никого не раздражаете — значит, Вы не занимаетесь ничем важным". (О, надо будет перевести...)

Оно.

Affirming the consequent

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

ПИЖОН, -а; м. [от франц. pigeon — голубь] Неодобр. 1. Франтоватый поверхностный молодой человек; щёголь. 2. Тот, кто выставляет себя напоказ, хочет нравиться окружающим.
Вы будете смеяться, но даже ваш собственный коммент — тоже пижонство. Во-первых, поведение собеседуемого и есть чистая «показуха», мол, вот такой я продвинутый, задаю такие умные (как ему самому кажется) вопросы. Вы этого не видите, поэтому пытаетесь ткнуть меня в незнание слов (извините, вы правда думаете, что умнее меня?). Это показывает в вас обоих поверхностное отношение к предмету — бьюсь об заклад, вы даже хотели бы быть на месте этого «перцептраста». Но увы, весь сей опус — не более, чем фарс и попытка возвышения над людьми, которые вобщем-то будут вашим коллективом на годы. Так себя вести можно только при явно хамском желании НЕ устраиваться в компанию, но зато красиво уйти под фанфары малолеток.
Вы уж определитесь: или литературный герой — «пижон», жаждущий понравиться интервьюеру своей дотошностью или же цель героя рассказа — «возвыситься», а вы употребили слово не к месту. На всякий случай напомню, что во время интервью никаких «малолеток» поблизости не наблюдалось.

Ставить диагнозы по фотографии у вас, к слову, тоже получается прескверно.
Да нет, вы уж сами определитесь — вы решили до***ться до столба или вы действительно не понимаете смысл слова «пижон». Может, вам лучше заняться делом, чем блистать здесь неуместными диагнозами к людям, о которых вы не имеете ни малейшего представления?
Да вы, батенька, явно из того же полку прибыли, что и герой этого произведения. И тоже умничаете без толку и без надежды.
Если это кандидат в программисты — это ниже хуже джуниора, который не способен проставить приоритеты и уяснить задачу. На фрилансе такой даже заказ взять не сможет.

Но если это кандидат в тестировщики или technical writer — то неплохо, весьма неплохо.
А какие приоритеты и задачу?
Как сказано в последней реплике, в общем случае решение задачи выглядит примерно так:

function copyFile($srcFileName, $dstFileName){
return stdlib.fcopy($srcFileName, $dstFileName);
}

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

> Но задача для интервью не может быть настолько простой

«Ты не поверишь!» :) Меня просили НАПИСАТЬ КЛАСС. Ну вот просто, любой класс с любым именем! Потом задача была намного сложнее — ДВА класса и один наследует другой. После задания выяснилось, что я первый из 10 кандидатов это сделал. Мой фэйспалм был достоен Оскара!
Вот активно поддерживаю — можно всегда взять и спросить, есть ли там подвох.

Ну вот реально.
У вас на работе, да даже не много, а вообще были задачи, где вы гадали «а есть ли в таске какой-то подвох», и не имели возможность спросить у техлида или того, кто вам ставил задачу?

первый из 10 кандидатов

На синьора подавался? :)

http://lib.rin.ru/doc/i/39687p5.html
Текст почти утерян, поэтому вот такая сохранившаяся копия. Начинать со слов "-Слышь, Егорыч, у меня для тебя такая
задачка имеется"
-Вот, видишь, ты уже думать начинаешь,- обрадовался Егорыч. —
Хотя, решение твое не представляется мне красивым

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

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

А что, использование технических средств фиксации информаци (наподобие ручки и бумаги) запрещено корпоративными стандартами?

А он разве записывал?

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

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

А программиста, наверно, часто задолбывали заказчики, которые сами не знают, чего хотят.
С такими заказчиками я поступаю так:
время работы над их заданиями откладываю, если начинают сыпаться уточнения, которые должны быть сразу.

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

Я подозреваю, почему.

Между прочим, вы недооцениваете сложность копирования файлов. Я несколько лет саппортил приложение для работы с файлами (архивация, извлечение метаданных), поверьте, вы допустите не один десяток ошибок, а если понадобится поддержка samba, afp или кроссплатформа — вы точно налажаете по полной программе. (считайте, что комент, для автора оригинала)
Такое поведение можно встретить не только у кандидатов, но и у вполне трудоустроенных разработчиков. Я же считаю это сознательной диверсией: для того тебя и нанимают, дуралей, чтобы в ответ на функциональное требование ты выдал грамотное и обоснованное решение, а не соглашался делать на отвали лишь потому, что тебе не дали подробную спецификацию. Попу поди сам вытирает, без спецификации. Вот и здесь то же самое.
Чтобы дать обоснованное решение, нужно знать область применения. Причём в данном случае требование не просто функциональное: «напишите функцию копирования файла» — это уже техническое задание по части реализации функционального требования к приложению/системе «копирование бизнес-данных в таких-то ситуациях для таких-то целей». И для грамотного и обоснованного решения нужны либо функциональные требования (ситуации и цели), либо полные спецификации функции.

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

Вот таким и должен был быть ответ кандидата, а не диалог в стиле «ты кто такой, давай техзадание». :) Дальше уже можно вести конструктивный разговор. В тексте же я не вижу желания разобраться в проблематике, и это большая беда для проекта, когда разработчик закрывается своей экспертизой, не понимая важность своей роли в команде.
Информации явно недостаточно, мы файл копируем просто чтобы скопировать? Или все таки для каких то целей, но эти цели нам не назвали, естественно только и остается что клещами тянуть. Интервьювер что увидеть то хочет? Может знание совсем низкого уровня вроде прямой работы с фс, а может проверить что интервьюируемый вообще хоть что то написать может и с синтаксисом знаком. Нет требований к производительности, для каких это задач? Копирования очень большого объема в сжатые сроки или просто копирования с любой скоростью (в таком случае можно и с меньшими трудозатратами что то непроизводительное сделать)? И т.д.
Так так так, вы только не забывайте писать название компании в которой работаете чтобы я при поиске работы сразу отфильтровывал вас.
Да это же просто идеальный сотрудник для общения с клиентами, которые постоянно меняют требования к задаче!!!
Если подумать, то нет. Что мешает этому клиенту поменять требования к задаче, даже если предварительно все будет оговорено очень детально? Вы, наверное, хотели сказать, что это идеальный сотрудник для общения с клиентами, которые сами не знают, что хотят? Тогда да, тут ТЗ на выходе будет, наверное, наиболее полным. Но и здесь я боюсь, что подмножество клиентов, способных пройти подобный кейс до конца, исчезающе мало. Уж очень дотошный малый попался.

Напомнило историю о соискателе на должность тестера, которого не взяли на работу, потому что он везде мог найти баг. С таким тестером ни одно ПО не будет сдано, пока в нём будет хоть одна ошибка.
он везде мог найти баг

Эта история?

О, да.
Хотя, прочитал повторно, оказывается, его взяли. Почему-то был уверен, что нет. Простите, что ввёл в заблуждение.
Задача тестера — выдать список багов владельцу продукта (хороший тестер выдаст ещё и оценку вероятностей их проявления в реальной эксплуатации и возможных последствий). Принимать решение о сдаче/релизе и их условиях — ответственность владельца, а не команды разработки и(или) тестирования. Тестер (как роль в процессе разработки/приемки) — лишь эксперт для бизнеса, но не ответственный за решение (тоже как роль, физически это может быть один человек).
первое, что должен был этот разработчик спросить — для чего это нужно сделать и какую задачу юзера это решает?

Вот это абсолютно точно — я всегда разговор начинаю с вопроса "какую задачу Вы пытаетесь решить?"

Задачу заказчик себе придумать может совершено любую. Она может не подходить для решения проблемы. Поэтому верный вопрос: «Какую проблему Вы пытаетесь решить?»

Простите, Вы правы, я неправильно перевёл. Дословно я спрашиваю "what problem you are trying to solve?". (В английском языке problem — и проблема, и задача, в данном контексте имеется в виду, конечно, проблема.)

В свое время прочитал занятную книгу, Lynn Visson, Русские проблемы в английской речи
Lynn Visson — американка русского происхождения; с 1970-х годов профессор русского языка и литературы в американских университетах, а в последние двадцать с лишним лет — синхронный переводчик с русского и с французского языков на английский в ООН.

Вот тут ее мнение о слове «проблема»:
www.e-reading.club/chapter.php/99688/10/Visson_-_Russkie_problemy_v_angliiiskoii_rechi.html

Кроме того, они часто бывают озадачены тем, почему у «негативно настроенных» русских столько «проблем». Дело в том, что слова «проблема» и problem не точно соответствуют друг другу по всем оттенкам смысла. На обоих языках это слово может означать вопрос, или дилемму, требующую решения. Но в определенном контексте эта русская «проблема» приобретает иное значение, и тогда ей гораздо более соответствуют issues или questions.
Во время командировок в Россию американцы часто слышат от того или иного русского коллеги, что им предстоит вместе c ним обсудить или решать «целый ряд проблем», а потом удивляются, почему, с их точки зрения, никаких problems не было. Оказывается, предлагавший собраться хотел обговорить то, что по сути означает ряд вопросов, тем, пунктов повестки дня, а по-английски называется: issues, questions, subjects, topics, agenda items, points, elements (for discussion). Что же касается слова problem, то оно для англоговорящего означает вопрос, по которому есть серьезные расхождения в позициях сторон или который будет сложно решить. Если таких спорных или сложных вопросов нет, то лучше не пугать собеседника и предупреждать не о «проблемах» (problems), а говорить: the list of items on our agenda / the subjects / topics for our discussion / talks / negotiations.

По поводу смысла Вы правы, но обычно когда человеку, приходящему ко мне, требуется код, у него есть именно problem ;)


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

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

"На каждую хитрую дырку найдётся болт с резьбой" © Cледующие вопросы:
— Вы на все вопросы будете отвечать положительно?
— Да
— Вы берёте меня на работу? (trollface)

Да?
Во-первых, можно вопросы задавать с «или» («используем UTF-8 или UTF-16?»). Во-вторых, вопросы рано или поздно исчерпаются и выработается полная спецификация функции. В-третьих, поняв простую стратегию интервьюера легко можно манипуляцией формулировок вопросов привести к идеальной (по какой метрике — отдельный вопрос) с твоей точки зрения спецификации :)
Когда-то довелось поработать с китайскими программистами — они могут отвечать «да» на абсолютно любой вопрос:

— Вот эта функция у тебя делает пузырьковую сортировку по убыванию?
— Да.
— Но почему пузырьковую?
— Да.
— А, нет, погоди, мне показалось — это ж вообще не сортировка.
— Да.
— А что тогда??
— Да.
— ТЫ СЦУКО ИДИОТ ШТОЛЕ???
— ДА!!!
К: Должен ли файл-копия находиться в том же каталоге, что и исходный файл?…
И: Да.

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

К: А как насчёт атрибута «зашифрованный»? Что, если исходный файл зашифрован, а в каталоге назначения не поддерживается шифрование?

Каким образом при копировании файла в тот же каталог тот может не поддерживать что-то, что уже есть у исходного файла?

Я ждал этого вопроса! Сам заметил неувязку, но именно так у автора, и я решил в переводе не исправлять.

Чисто теоретически, могут быть файловые системы по разному хранящие разные файлы. На практике — целевой файл может уже существовать, но в каталоге назначения быть представлен линком на другую файловую систему.
Вы серьёзно думаете, что задающий эти вопросы кандидат имел в виду именно такой вариант, а не банально вы**ывался? При том, что о возможности существования целевого файла он додумался поинтересоваться только под конец.
Увы в 99% случаев кандидаты ничего, совсем ничего не уточняют. И сразу спешат что-то придумывать.
Мне кажется, что в данном случае эта задача была чем-то вроде FizzBuzz — просто способ убедиться, что кандидат вообще способен писать работающий код.
А получилось как в статье про FizzBuzz на TensorFlow с машинным обучением https://habrahabr.ru/post/301536/
Сегодня у меня было собеседование на позицию системного администратора. И мне там задали вопрос… нет, не про копирование файлов, а про те самые лампочки из комментария (https://blogs.msdn.microsoft.com/ruericlippert/2011/02/28/983/). Я немного задумался и решил задать уточняющий вопрос: скажите, а вы хабрахабр читаете? Интервьюер (руководитель какой-то там группы) в ответ улыбнулся и мы перешли к более насущным вопросам.

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

Тогда уж "– Функций нет, но вы держитесь, до свидания" :)
Вот именно. Собеседователь демонстрирует соискателю, как у них в компании принято ставить и обсуждать задачи. Соискатель в ответ демонстрирует свой подход к делу. Если они друг друга устраивают, то будут работать вместе. Если не устраивают, то не будут. В чем проблема-то?

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

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

Лид должен уметь ставить задачу правильно. Чтобы потом не оказалось, что разработчик задачу решил — вот только не ту, которую надо было, потому что все телепаты в отпуске.

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

Повторюсь из другой статьи:


Дело в том, что для того, чтобы взять поток мысли, выдаваемый клиентом, и перевести его в однозначную формулировку, понятную программисту (software developer), предназначен специальный человек — software consultant. И платят ему, мягко говоря, несколько больше, чем программисту, потому что работа очень нервная — целый день с идиотами общаться.
(Иногда software developer и software consultant совмещаются в одном человеке — мне, например, но это далеко не всегда так ;)
[...]
Вот и я тредстартеру пытаюсь объяснить это уже пятый раз: задача software developer — взять условие задачи и реализовать код, её рещающий. Причём если в условии полная хня — то и код будет такой же, либо не будет вообще: garbage in — garbage out. А "понять, что же там заказчик мямлит и корректно поставить задачу девелоперу" — это работа software consultant совсем за другие деньги.
"Поэтому я вам советую подождать специалиста, договориться с нянечкой и заплатить. Но можно этого и не делать. Если вас не интересует результат." ©
Не надо защищать инфантильных, нервных, пижонистых программистов, считающих себя богами ИТ. Фантазии заказчика всегда можно свести к нормальным, техническим требованиям, был бы адекватный программист! Как только прогер чувствует себя выше заказчика (а не исполнителем заказа, коим и является) — всё, начинается игра «кто тут умнее» с последущим «они меня не понимают!».
Достаточно посадить перед прогером сисястую красотку и, о чудо, этот компьютерный сухарь вдруг оживает и становится таким понимающим, что аж в морду дать хочется! ГДЕ всё это было ДО девушки?? Вот-вот, «был бы человек хороший».
Фантазии заказчика всегда можно свести к нормальным, техническим требованиям,


Высказанные фантазии — можно. «Само-собой разумеющиеся» детали — гиблое дело, у себя в голове заказчик может представлять всё что угодно. Но если он хотя бы коряво об этом требовании не скажет, то вам и сводить в ТЗ будет нечего.
Хм? Нет, спасибо, не надо. Ваш кейс сильно зависит от возраста, опыта и текущего состояния «подопечного», возраста и иных параметров «мотиватора» (и их сочетаемости со вкусами «подопечного»). Но это только начало взаимодействия. На «длинных дистанциях» вменяемость и способность объяснить хотелки «мотиватора» резко выползают на передний план.

А может, не надо считать программистов нфантильными, нервными, и пижонистыми?..

А почему это не надо? Разве профессия не накладывает свой отпечаток? Плюс, в саму профессию идут люди тоже с определёнными склонностями. Например, комплекс бога. :) Или «я им ещё всем покажу!» (когда ты в классе единственный «задрот» (извините за слэнг), но у тебя хватает амбиций вылезти наверх)

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

Ещё момент: компьютеры заполонили нашу жизнь, но «по-настоящему» понимает их суть только программист. Не удивительно, что остальные «юзеры компьютеров» ему кажутся подножной пылью!
> Хороший разработчик должен уметь превращать задачи вида «сделайте мне хорошо» в конкретное ТЗ

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

Кандидат ведет себя как мудак.

А потом напишет историю про тупых эйчаров

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

Интервьюер имеет право просто застрелить такого кандидата

Уголовный кодекс имеет отличное от Вашего мнение ;)

Это понятно. Правовая система несовершенна. Я подхожу к вопросу с точки зрения морали.

А кандидат имеет право застрелить интервьвера?

А интервьюера-то за что?

За вопросы :)
Хотя с моей точки зрения, этот вопрос в общем то нормальный, но вот вопросы на тему, а почему вы меняете работу, а если вы от нас уйдете, а раскажите о себе меня напрягают просто не имоверно, с такими вопросами не работников искать, а прямо к работорговцам :)

А как ещё они могут получить хотя бы приблизительное представление о вас, как о человеке? Им же важно это знать для принятия решения. Им же нужно встроить вас в какую-то команду. Чем больше подобных вопросов они зададут, тем меньше будут риски, которые неизбежно порождает ваше появление в коллективе. Проблема в том, что вы просто не умеете отвечать на такие вопросы. Предложение рассказать о себе вызывает у вас стресс исключительно потому, что вы плохой рассказчик. Учитесь. Больше читайте художественной литературы, чтобы обогатить свою речь красивыми речевыми оборотами. Можете заранее набросать план рассказа о себе.

Предложение рассказать о себе вызывает у вас стресс исключительно потому, что вы плохой рассказчик. Учитесь.

Простите, Вы уж определитесь, кто Вам на позицию нужен — профессиональный программист или профессиональный рассказчик?


P.S. Именно поэтому я на все интервью ходил исключительно в джинсах и свитере. Я профессиональный программист, а не профессиональня манекенщица.

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

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

"А нас-то за что?"

С вьетнамскими «коллегами» почти каждый раз такие дискуссии :)

Коллеги с какой стороны выступают? :)

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

ИМХО, кандидат в данной ситуации как "тупая секретарша"


Чего тут смеяться, видно же — у секретарши база голосовой идентификации слетела!


А директор у неё — настоящий программист, даёт задание точно и детально.

Любая реализация вне спецификации является верной.
В школе почему-то решения, не противоречащие заданию, но не соответствующие типовому решению не принимают.
Ну грубо говоря на задачу 2+2= _ в школе нельзя ответить 2+2 = x, x< 5, x > 3, x ∈ Z
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».

Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.

"2+2 = x, x< 5, x > 3, x ∈ Z" — это не решение, а новая задача


Недопустимым решением могло бы быть 2+2=113

Стеб стебом, но какая была задача у интервьюера? Проверить адекватность кандидата. Какая была задача у кандидата. Получить работу? Я сомневаюсь. Повеселиться? Возможно. Фарс этот закончился бы много быстрее, т.к. тест на адекватность был бы провален и незачем тратить лишнее время на уточняющие вопросы.
Чтобы задание на собеседовании было корректным надо описать входные параметры (имя файла для чтения, имя файла для записи). Выходные параметры (объем скопированных данных или код ошибки). + Желательно контекст задачи. Зачем происходит это действие. Формализовали по максимуму — программист доволен. Интервьюер доволен.
Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: А вот собственно комплект тестов из 9000 кейсов.
Кандидат понимает, что уже мечтает о работодателе которому достаточно что бы «просто копировало»
Кандидат пляшет от счастья. Это же какой кайф, когда кто-то другой подготовил для тебя реально все кейсы! Намного лучше, чем то, как обычно в жизни происходит — постфактум итеративно дописывать вскрывшиеся моменты.
… А на самом деле кандидат был просто одинок, и ему очень хотелось с кем-то поговорить…
По комментам видно, что многие не дочитывают до конца. А вся соль в последней реплике кандидата.
Проблема-то как раз в том, что эта реплика последняя, а не первая.
Круто, конечно, но перебор. Достаточно было бы спросить что-то типа: функция должна быть клоном file.copy(String, String, Boolean)? А вот после ответа «нет» задавать все вышеперечисленные вопросы.
Усложнять легко, упрощать сложно. (с)
В подобных случаях, наверное, лучшим выходом будет просто предупредить, что всё о чем заказчик не говорил будет решено на усмотрение исполнителя.
Шутка шуткой. Но он прав во многом. Умение четко поставить задачу это умение. И да есть тип людей которые могут действовать только когда поставлена четко задача. И есть тип рукамиводителей, которые тупо переводят стрелки на ближайшего Васю. Вася умный сам разберется. И да если это джун, то он трижды прав со своей дотошностью. Он ведомый он должен четко понимать есть кто ведущий, кто поставит грамотно задачу или всё исполнять мизинцем левой ноги за час до наступления шаббата?
НЛО прилетело и опубликовало эту надпись здесь
А тут ты выясняешь, как нужно сделать правильно.

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

Мне не нравится ни кандидат ни интервьювер. Интервьювер убивает свое время, потому как перед ним человек, который затягивает тривиальную задачу в условиях неопределенных требований. Надо скопировать файл, предусматриваешь более менее очевидные кейсы и делаешь.
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.
НЛО прилетело и опубликовало эту надпись здесь
А вам не кажется что дело не в программистах, а в консерватории? Никто не говорит о реализации хоп хоп и в продакшен.

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

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

Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
А вот тут похожая история про то, как Fizz Bizz Test (1, 2, Fizz, 4, Bizz, Fizz, 7, 8, Fizz, Bizz...) решают на нейронных сетях и тензорфлоу.
На самом деле, такая ситуация могла произойти только в голове автора. Он сыплет умными вопросами, а интервьюер что-то бубнит в ответ, потому что никогда не задумывался о таких подробностях. Действительно, отдает некоторым высокомерием.

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

Во всех остальных случаях (например, скопировать загруженный файл из временного каталога в постоянный) нужно вызывать системные функции, которые предоставляет ОС и язык программирования, и которые внутри вызывают функции этих драйверов.
А значит, кандидат не прошел собеседование, потому что, судя по вопросам, собрался писать свой низкоуровневый велосипед. «Вы нам не подходите, до свидания».
Оу, ну после четвертого минуса не могу не спросить) Что именно я сказал неправильно?

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

Хм. Под словами «В реальности эти вопросы имеют смысл» я имел в виду не исходную задачу, а вопросы кандидата. Цель самой задачи мне понятна)
В реальности эти вопросы имеют смысл, только если работа связана с разработкой файловых систем и драйверов для них

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


— А что, если…
— Не стоит.
— Ясно. Тогда, может быть…
— Не нужно.
— Понятно… Разрешите хотя бы…
— Вот это попробуйте!

Ну а как ответы помогут улучшить безопасность самого приложения, если оно пользуется абстракцией над файловой системой? Это больше вопрос окружения. К тому же, мне кажется, не стоит смешивать собеседования на позицию разработчика, тестировщика, и безопасника.
Смешная история, конечно, но получился пост-бальзам на душу двух типов разработчиков:

  1. Я прикладной программист! Всегда надо вызывать библиотечные/системные функции, а если библиотечная функция чего-то не умеет, то это её проблемы! Пусть заказчик купит нам другую платформу, или заплатит нам миллион за то, чтоб мы таки написали копирование файла.
  2. Я работаю по спецификации, а заказчик ничего не понимает в сложности задачи. Надо ему показать, какой он глупый, а с меня какой спрос? Спецификация всегда не полна… а я просто работаю по спецификации (goto start)

Добавим в эту аудиторию тех манагеров, кто не в состоянии поставить/описать задачу и сетует на плохих программистов, и получился прекрасный ragebait (ну или cringe bait) для широких слоев населения.

Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)
Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)

Товарищ Lol4t0 четко описал ситуацию:


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

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

Я бы первым делом спросил - зачем? А исходя из этого бы уже продумывал реализацию - может, copy через cmd оказалось бы достаточно.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории