Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Ну… создать новый файл, содержимое которого является копией содержимого исходного файла.
К: Нужно ли скопировать также и метаданные о времени создания и модификации оригинального файла?
И: Нет, не нужно.
К: Должен ли файл-копия иметь то же имя, что и исходный файл?
И: Нет.
К: Может ли файл-копия иметь то же имя, что и исходный файл?
И: Хммм… нет.
К: Должен ли я предусмотреть защиту от атаки через подмену букв со сходными начертаниями (например, турецкой I)?
И: Не беспокойтесь об этом.
К: Должен ли файл-копия находиться в том же каталоге, что и исходный файл? Хочу отметить, что если да — то он, вероятно, не может иметь то же самое имя. Если только речь не идёт о копировании файла самого в себя (это тоже интересный вопрос...)
И: Да.
К: Как насчёт атрибутов файла?
И: Скопируйте их тоже.
К: Должен ли я модифицировать атрибуты исходного файла? Если функция копирования, которую Вы просите меня написать, является частью операции резервного копирования или архивирования, то я должен сбросить архивный атрибут у исходного файла.
И: Нет, оставьте их в покое.
К: Вы сказали, что я должен тупо скопировать атрибуты исходного файла на файл-копию. Но если архивный атрибут у исходного файла сброшен, а я его «тупо скопирую» на файл назначения, то это может ввести в заблуждение программы резервного копирования, которые могут использоваться на этом компьютере.
И: Просто скопируйте атрибуты. Меня не волнует, как там у пользователя организовано резервное копирование.
К: Ну, мне кажется, что это не самый разумный подход при разработке программного обеспечения, которым всё-таки будут люди пользоваться, но раз Вы так настаиваете…
И:…
К: Как насчёт атрибута «сжатый»? Ведь может оказаться, что файловая система, на которой находится каталог назначения, не поддерживает сжатие.
И: Делайте копию несжатой.
К: Даже если исходный файл — сжатый, а в каталоге назначения поддерживается сжатие?
И: ДА.
К: А как насчёт атрибута «зашифрованный»? Что, если исходный файл зашифрован, а в каталоге назначения не поддерживается шифрование?
И: В этом случае не шифруйте копию.
К: Не хочу отклоняться от темы, но мне кажется, что такое поведение создаст серьёзную дырку в безопасности. Особенно в случае если файловая система, на которую мы копируем файл, поддерживает произвольные атрибуты (прямо или косвенно).
И: Послушайте, просто скопируйте чёртов файл!
К: Как насчёт информации о создателе файла?
И: Плевать!
К: Как насчёт информации о владельце файла?
И: Плевать!
К: А как насчёт прав доступа? Должен ли я по-разному обрабатывать унаследованные и назначенные права?
И: К чёрту права!
К: На какой ОС должна работать моя функция?
И: Windows XP.
К: Home, Pro, Media Center, или какой-то их комбинации?
И: Pro.
К: На какой пакет обновлений я могу рассчитывать?
И: Service Pack 2.
К: То есть я могу не поддерживать предыдущие уровни обновлений?
И: Верно.
К: Каким образом мне будет передано имя исходного файла?
И: Как параметр.
К: Будет ли оно передано как строка, завершённая нулевым байтом, строка с длиной, или как объект?
И: Строка, завершённая нулевым байтом.
К: Предусматривать ли ситуацию с передачей мне пустого указателя?
И: Нет.
К: Предусматривать ли ситуацию с передачей мне пустой строки?
И: Нет.
К: Предусматривать ли ситуацию с передачей мне неправильно сформированной строки (например, без завершающего нулевого байта)?
И: Нет.
К: В какой кодировке будет переданное мне имя?
И: Unicode.
К: Простите, но Unicode — это вообще-то не кодировка. Unicode-данные должны быть в какой-то конкретной кодировке — например, UTF-8, UCS-2, UTF-16…
И: Ладно, пусть будет UTF-8.
К: Хорошо, но смею заметить, что тогда для передачи в вызов Windows API мне придётся перекодировать в UTF-16, а это несколько геморройно…
И: Тогда UTF-16!
К: С каким порядком байтов?
И: Ррррр… с каким хотите!
К: Предусматривать ли обработку относительных путей, или только абсолютных?
И: Только абсолютных.
К: Есть ли какие-то особенности у передаваемых мне путей, по которыми я должен их фильтровать?
И: Нет. Считайте, что вызывающая программа это уже сделала.
К: Как будет формироваться (или передаваться) имя файла назначения?
[… текли минуты, превращаясь в часы...]
К: Должен ли я поддерживать (или допускать) асинхронное копирование?
И: Нет.
К: Как я должен сообщать об аварийных ситуациях — исключением или кодом возврата?
И: Без разницы.
К: Должен ли я обрабатывать исключения, приходящие из вызываемых мною функций, или просто пропускать их к вызвавшему меня коду?
И: Пропускайте.
К: Что, если файл назначения уже существует?
И: Мамой клянусь, что нет.
К: То есть вызывающая программа это гарантирует?
И: Вот именно.
К: То есть если всё-таки окажется, что он уже существует, то это значит, что гарантии нарушены, и мне следовало бы обрушить программу — что-то явно пошло не так, и мало ли что ещё она там сейчас наделает?
И: Как хотите.
К: А как насчёт вторичных потоков данных у файла?
И: Да делаёте что хотите, чёрт бы Вас побрал!
К: Послушайте, Вам может показаться, что я на Вас давлю, и мне очень жаль — но мне крайне важно уяснить все детали Вашего задания. Очевидно, раз Вы хотите, чтобы я написал Вам новую функцию копирования файла, — вместо того, чтобы воспользоваться одной из множества уже реализованных во всевозможных библиотеках и фреймворках — то у Вас имеются какие-то очень-очень специфические требования, которым библиотечные функции не удовлетворяют, и я намереваюсь эти требования из Вас вытянуть. Конечно, я уже могу быстренько набросать что-нибудь подходящее, но должен отметить, что у нас ещё целая куча не до конца выясненных деталей…
И: ААААААААААААААААААААААААААААААААААААААААААА!!!
Дело сделано.
Комментарии (217)
nikitasius
26.05.2016 22:00+6Супер!
kifirch
27.05.2016 11:01+1Вообще не супер. Если человек не в состоянии сам ответить на эти вопросы, то кому он нужен?
Нужно было решить задачу, а не превратить ее в фарс. Уровень junior у кандидата — а если задача будет сложнее ему потребуется месяц на уточнение всех нюансов?
Wesha
27.05.2016 11:09+16Если не уточнить все нюансы ДО того, как будет написан код, возможны варианты:
- Пронесло, всё работает;
- Всё в основном работает, но в некоторых непредусмотренных ситуациях падает;
- Всё в основном работает, но создана дырка в безопасности системы (см. вопросы про шифрование);
- Всё в основном работает, вот только клиенту было надо совсем не это, так что надо всё написанное выкинуть и переписать с нуля.
"Час работы по дизайну экономит день работы по кодированию".
Areso
27.05.2016 11:26-5Первую проблему решаем оберткой в try-catch. Шифрование — это фишка, которая стоит времени и денег, а на собеседовании есть 15 минут и нужно решить задачу в базовом её варианте (раз про отдельную фишку в виде шифрования заказчик ничего не сказал). Последний случай наиболее печальный, поэтому нужно использовать стандартный прием, которым пользуются менеджеры: «скажите, правильно ли я вас понял, что… ?». Это позволяет, как минимум, разделить ответственность в случае «выкинуть и переписать с нуля», а как максимум — переложить её целиком на заказчика, потому что он должен подтвердить, что вы а) все запомнили из того, что он сказал и, опционально, б) в целом согласен с предложенной концепцией решения задачи.
Sing
27.05.2016 13:08+5> Первую проблему решаем оберткой в try-catch.
И… что? Если ситуация непредусмотренная, что вы достигнете этим? Да, программа не упадёт, будет ещё хуже: она останется работать в непредусмотренном состоянии.Areso
27.05.2016 16:17-1Программа копирования файла в exception напишет, что файл скопировать не удалось и вернет вызывающей программе это сообщение и текст ошибки в лог. Пользователь будет в курсе, что есть проблема и нужно решать её вручную или обращением к производителю ПО. И он не потеряет весь проделанный прогресс (не применимо к данному случаю, но в целом реально) из-за сбойнувшей функции.
Sing
27.05.2016 18:41На деле, никакие пользователи не будут смотреть логи или обращаться к производителю ПО, они просто найдут что-нибудь получше. Вы должны предусмотреть все случаи, когда что-то может пойти не так и логику реакции на такие случаи.
А прогресс нужно сохранять постоянно (после разумного количества действий, разумеется), а не надеяться, что не произойдёт ничего исключительного, типа выключения питания устройства.Areso
27.05.2016 20:14Все случаи? Это в каком-то идеальном мире, наверное. И написано идеальным программистом.
К примеру, уже почти две недели воюю с банком по поводу их сломавшейся выгрузки для юрлиц, и они не могут это починить, даже после того как им указали, что происходит и где происходит. И если юрик не будет обращаться в банк, он будет сидеть без выгрузки. Потому там есть все — и перехват ошибок, и сохранение логов, и описание ошибок с номерами строк, вот это вот всё. И все это документируется (абы-как, честно говоря) и отправляется в банк. И со всеми другими системами, с которыми нужно взаимодействовать происходит все тоже самое. В среднем за год мы отправляем около полудюжины таких запросов, из которых примерно половина — явный косяк производителя ПО. И приходится совместно решать, иначе — никак.
Ну да, если калькулятор будет сыпаться (и он не уникальный), скачают другой. Только с калькулем есть выбор, а вот с банковским ПО/ПО гос.сектора выбора нет.Sing
27.05.2016 20:21> Все случаи? Это в каком-то идеальном мире, наверное. И написано идеальным программистом.
В идеальном мире — да. В реальном мире — все случаи, вероятность появления которых существенна.
Ваш пример как раз подтверждает мои слова — пора менять банк. Точнее, банк будет менять пора в тот момент, когда расходы на переход + потери от перехода превысят расходы от того геморроя, которым вы страдаете.
А то, что «у вас нет другого выбора» — это плохо, конечно, но не является аргументом писать некачественный софт.
Wesha
27.05.2016 17:48+1Первую проблему решаем оберткой в try-catch.
Именно так поступили некоторые чиновники с аварией на ЧАЭС. "У нас тут взорвался реактор, но мы никому не расскажем, выходите спокойно на первомайскую демонстрацию."
Areso
27.05.2016 18:14окей, окей, я же дописал, exception, а там что хотите передавайте, код ошибки, окружение, сообщение пользователю, хоть print('we all will die! run for your life! nuclear plant has been melted down!');
sebres
27.05.2016 12:06+2"Час работы по дизайну экономит день работы по кодированию".
Да-да-да… Тут вот как-то коментировал про стадию "дизайна".
Т.е. я как бы не против оного если с головой, но (понимая что пример утрированный, и что юмор и троллинг) все же как-раз этот пост г. Пикета является квинтэссенцией "передергивания" архитектурной стадии, как оно к сожалению реально часто бывает.
Другой пример: был у меня один коллега, — элементарнейшие вещи (типа той же упомянутой copy) он писал так: сначала писалась дока, потом интерфейс, потом все это правилось до крайней степени, причем его эго еще не удовлетворено, а отведенного времени уже на на 80%-90% съедено. В результате ему просто больше ничего не давали — лучше сам или кому другому отдам… Пока его не ушли.
Имхо, самое первое правило классного разработчика должно быть — держать перфекциониста в себе на очень коротком поводке. Применительно к примеру, как по мне, пусть лучше функция обросла 100-ми todos (которые возможно и даже скорее всего никогда не доделают), но она работает.
velvetcat
27.05.2016 22:53+1> самое первое правило классного разработчика должно быть
Отличать важное от неважного.
VovanZ
27.05.2016 14:15+2«Час работы по дизайну экономит день работы по кодированию» — это про waterfall.
Реальность такова, что на этапе сбора требований и проектирования учесть все нюансы не получается никак. Даже если на «дизайн» было потрачено очень много времени.
Поэтому, современные методологии работают по другому:
1. Делаем как-нибудь, лишь бы проще, быстрее и работало.
2. Показываем промежуточный результат заказчику, выясняем двигаемся ли мы в нужном направлении.
3. Корректируем направления и повторяем итерацию начиная с пункта 1.
Я думаю, правильнее было бы сначала написать самую простую реализацию, а потому уже — задавать уточняющие вопросы и предлагать улучшения.
M-A-XG
27.05.2016 14:54+3Ага, сначала написать одно, а потом все с нуля переписать :)
vayho
27.05.2016 15:03+2Сначала написать одно, потом переписать, потом переписать несколько кусков по разному, а потом вылавливать баги следующие пол года.
vladshulkevich
28.05.2016 12:16это в действительности не так странно выглядит, как Вы, вероятно, имели в виду. в этом есть некий смысл, хотя бы с точки зрения «исследования» реализуемой системы, о которой мы начинаем знать намного больше, чем до того…
sturi
27.05.2016 17:49>>1. Делаем как-нибудь, лишь бы проще, быстрее и работало.
Это даже официально называется макет (или mock-up)
Wingtiger
27.05.2016 17:50+2вот только п.3 отсутствует. Заказчик покупает что есть и мы этим пытаемся пользоваться :(
vladshulkevich
27.05.2016 17:50+3это какая-то современная болезнь, вроде эболы: манагеры как один стремятся пропустить этап проектирования. потом уже бывает поздно.
tangro
26.05.2016 22:12+2мне придётся перекодировать в UTF-16, а это несколько геморройно…
Если это WinXP, то в WinApi есть функция MultiByteToWideChar которая это сделает в две строки кода. Так что даже по задаваемым уточняющим вопросам уже можно сделать вывод о квалификации.
akzhan
27.05.2016 01:59+3Вообще-то абсолютно адекватные вопросы. И да, перекодировка — это выделение буфера, потом освобождение, и это я не рассматриваю нюансы, например, требования к поддержке 32битных символов Unicode (MultiByteToWideChar поддерживают только 31-битные, насколько я помню — вернее, для UTF-8 это означает лимит в 4 байта на символ).
akzhan
27.05.2016 02:16+4Чуточку ошибся, ограничение на символ строже в UTF-16, он может закодировать только 20-битный символ, а UTF-8 — 31-битный. И тут еще не рассмотрены преобразования символов, например, в каноническую форму и так далее.
Эх, и это всего лишь один вопрос из списка :-)
Wesha
27.05.2016 02:18+12Кто в армии служил, тот в цирке не смеётсяКто при жизни писал базовые системные библиотеки, тот в аду отдыхает :)
OlegMax
27.05.2016 19:39Вообще-то абсолютно адекватные вопросы.
Не все. Например, порядок байтов в строке в памяти колебать программиста не должен. Внимательный интервьюер на этом вопросе может сказать «Попался, тролль! Давай, до свидания».
grossws
27.05.2016 19:48Особенно если это имя файла пришло, например, по сети. Ага.
OlegMax
27.05.2016 20:30И прямо из сети попало в функцию, копирующую файл? Тоже до свидания. Это слишком тупой троллинг, как без необходимости спрашивать — а у вас double в стандарте IEEE 754?
grossws
27.05.2016 20:55+3Под double сейчас обычно понимается binary64 из ieee754, но иногда используется, например, decimal64 из того же стандарта.
Но не всегда использовалась смещённая экспонента, не всегда под double понимается 64-битное представление, иногда это проприетарная кодировка (например, на мейнфреймах от ibm), а не ieee754 binary64.
Другой кейс — это обыкновенный binary32/64, но в mixed-endianess как, например, бывает при работе с modbus/rtu.
Так что бывают кейсы, когда это уточнение существенно.
Lertmind
26.05.2016 22:52+20Рассказ так себе. Не было никакого смысла издеваться над интервьюером и терять время, если что-то не сказано — значит на ваше усмотрение. В крайнем случае надо было начать с последнего монолога про объяснение, что хорошую функцию копирования файлов сразу не напишешь.
lostmsu
27.05.2016 00:26+8Это совсем не так. Многие интервьюверы смотрят на валидацию входных данных. Этот рассказ показывает абсурдность этой идеи. Нужно давать задачи, где такие вопросы решаются быстрее, или сразу говорить, что валидация входных данных не нужна вовсе.
Но автор, конечно, краб, т.к. интервьювер корректно ответил на его первый вопрос про то, что он подразумевает под копированием так, что все последующие вопросы до вопроса про вид строк-параметров функции не имеют никакого смысла.
akzhan
27.05.2016 02:21+1Ну, хорошая функция — понятие многозначное :-)
Например, можно реализовать асинхронный ввод/вывод, а можно сползти на блочный уровень (вы же знаете, что NTFS, в принципе, просто устроен).
Kolonist
26.05.2016 22:54+47В реальности этот диалог выглядел бы несколько иначе:
Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Вы нам не подходите.
Ну или, если интервьюер в хорошем настроении, как-то так:Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Мы хотим посмотреть, как Вы понимаете задачу, какие подходы примените в ее решении и какие условия учтете, так что дополнительные вопросы не принимаются.Wesha
27.05.2016 02:12+20
Throwable
27.05.2016 12:09+1Совершенно верно. Человека берут на работу решать проблемы, а не создавать их. Если также он будет донимать вопросами заказчика, то тот просто уйдет.
Задача программиста-аналиатка — уметь трансформировать фукнциональные реквизиты в конкретное решение, а в случае нехватки деталей предлагать собственное решение, а не допытываться по каждому пунтку. Поэтому программа должна работать адевкатно в большинстве случаев и корректно отлавливать нештатные ситуации.Wesha
27.05.2016 17:54Поэтому программа должна работать адевкатно в большинстве случаев и корректно отлавливать нештатные ситуации.
К: Что конкретно Вы имеете в виду, говоря "нештатные ситуации"? (pokerface)
Throwable
30.05.2016 10:57Для этого нужно определить "штатную ситуацию". Если дополнительные реквизиты не определены, нужно взять самое простое решение: создание нового файла с заданным именем и дефолтными атрибутами и копирование в него содержимого заданного файла. Все операции с привилегиями процесса. В случае невозможности копирования вывести (вернуть) ошибку, желательно с пояснением причины.
Все вышеперечисленное аналитик-программист должен автоматически вывести из задания "напиши мне программу для копирования файла". Только при обладании бОльшим количеством данных о целевой задаче и области ее применения, данное решение может быть трансформированно в нечто более сложное. Принцип KISS еще никто не отменял.
Вот кстати притча в тему: https://habrahabr.ru/post/74193/
Wesha
30.05.2016 20:08+1Вот кстати притча в тему: https://habrahabr.ru/post/74193/
Телепаты — да, они такие, им не жалко и 5 рублей платить. Одна проблема: только в притчах и существуют.
Только при обладании бОльшим количеством данных о целевой задаче и области ее применения
А чем, по-Вашему, занимался кандидат, как не сбором "бОльшегом количества данных о целевой задаче и области ее применения"? — "Очевидно, [...] у Вас имеются какие-то очень-очень специфические требования, которым библиотечные функции не удовлетворяют, и я намереваюсь эти требования из Вас вытянуть."
В случае невозможности копирования вывести (вернуть) ошибку, желательно с пояснением причины.
Возможны и ситуации, когда явной ошибки нет, а по факту — есть (например, описываемый кандидатом случай, когда файл скопировался незашифрованным, или не были скопированы права доступа, и
master.passwdоказался world-readable).Throwable
31.05.2016 12:39+2А чем, по-Вашему, занимался кандидат, как не сбором "бОльшегом количества данных о целевой задаче и области ее применения"?
Надменно демонстрировал важность своей работы и ценность своих знаний.
Первым вопросом должен быть не "что вы подразумеваете под вашей просьбой?", а "для чего вам это нужно?", "где вы это будете использовать?", "для какой общей задачи требуется данное решение?" Опишите проблему целиком, а я уже сам решу, нужно ли вам атрибуты менять и вообще нужно ли само копирование файла.
Вот приходите Вы к дентисту: "вылечите мне зуб". А он такой: "что конкретно Вы имеете ввиду под "вылечите"? У вас пульпит, периодонтит, перикоронит или простой кариес? Вам пломбу поставить, удаление нерва, коронку, удаление зуба или что? Что Вы от меня хотите? Сформулируйте точно!"
Wesha
31.05.2016 18:09Вы будете смеяться, но именно так и работает челюстно-лицевой хирург. Только вот проблема: к нему приходят не с кондачка, а с направлением от дантиста, который в бамажке пишет — "а сделай, любезный, вот этому чучелу рут-канал на 18-м зубе".
Я уже который раз долдоню: детальной постановкой задачи занимается специальный человек — software consultant. И именно его задача — выбить из клиента, чего именно он хочет. И зарплата у него несколько другая, чем у кодера-по-спецификации. (В частности, мне на протяжении своей жизни довелось поработать и одним, и другим, и обоими вместе).
gaki
02.06.2016 04:26По-моему, большая часть взаимного непонимания в комментариях к этой статье связана с тем, что зачастую никакого такого отдельного «специального человека» попросту нет. По разным причинам. И каждому приходится работать исключительно «обоими вместе».
Wesha
02.06.2016 06:40И каждому приходится работать исключительно «обоими вместе».
… за одну (меньшую) зарплату ;)
По разным причинам
Например "работодателя жаба душит, а работник не нашёл способа использовать свою редкость как преимущество".
gaki
02.06.2016 07:48Бывает, наверное, что и жаба. А бывает, что клиент сам не понимает, чего хочет. Это непонимание настолько глубоко и всеобъемлюще, что единственный способ что-то из него «выбить» — это показать — нет, даже не показать, а дать попользоваться уже готовым продуктом и спросить: «Ты этого хотел?» В теории, этот самый software consultant и тут был бы очень в тему, а на практике он зачастую превращается в пятое колесо, от которого никакой пользы, кроме вреда в виде увеличившейся силы трения.
Throwable
02.06.2016 11:07По-моему, большая часть взаимного непонимания в комментариях к этой статье связана с тем, что зачастую никакого такого отдельного «специального человека» попросту нет.
Более того, если такой человек есть, то он заведомо лишний в компании. Он не разработчик, поэтому плохо знает детали системы, он также не бизнес аналист, поэтому также не може предложить собственное решение или инициативу клиенту.
Вот типичная работа такого человека:
Поэтому все современные методики разработки пытаются уменьшить число ступеней в иерархии разработки, сделать структуру более плоской и прозрачной. Обязанности "software consultant" ложатся на team lead-а, который суть есть разработчик.
Wesha
02.06.2016 16:56он не разработчик, поэтому плохо знает детали системы, он также не бизнес аналист, поэтому также не може предложить собственное решение или инициативу клиенту.
Это всё равно, что сказать "англо-русский переводчик плохо знает и английский, и русский". Software consultant — это "переводчик с человеческого на программистский", поэтому он как раз должен быть хорошо знаком с обоими "языками". Обычно ими становятся опытные программисты, которые за свою жизнь пообщались со 100500 клиентов, и уже могут понимать, что клиент действительно имеет в виду, говоря "нарисуйте мне красную линию зелёным цветом".
janekprostojanek
27.05.2016 16:09-5Именно! Это первое задание, чтобы отличить кодера от программиста. Кодер будет задавать сотни уточняющих вопросов, на которые программист в состоянии ответить сам.
BigW
27.05.2016 17:54+6это до тех пор, пока вас не попросили «поиграться со шрифтами» или «сделать поярче»… Вы видите функцию так, заказчик по другому и далеко не всегда заказчик может внятно объяснить чего он хочет… Статься, конечно, гипербола, но смысл есть. Думаю все помнят картинку с деревом и качелями…
Wesha
27.05.2016 17:54Вы видите функцию так, заказчик по другому и далеко не всегда заказчик может внятно объяснить чего он хочет…
… А все телепаты, как назло, в отпуске. ;)
gaki
02.06.2016 04:27Самое главное отличие кодера от программиста — это что кодер знает, чем кодер отличается от программиста, а программист знает, что никакой разницы нет.
ToSHiC
26.05.2016 22:54+11Так сурово троллить, конечно, можно, но нужно быть готовым, что в эту компанию вас больше никогда не возьмут работать. Ведь интервьюер предполагает, что кандидат показывает лучшие свои качества, а с большими зеленомордыми троллями работать не особо комфортно.
kamilgarey
27.05.2016 10:30Тролли, по моему опыту, очень хорошо делают Code-Review. Конечно, если под инспекцией кода понимать возможность исправить по максиму, а не пропустить в коде «совсем уж ляпы»
SCareAngel
27.05.2016 17:55+4Мне кажется, что, в случае с code-review, это называется педантичность, а не троллиниг.
impetus
26.05.2016 23:52+23я как-то давно пришёл в одну компанию (не софт) — директор (небольшая компания) водил меня по фирме показывая — чисто провести хотел, но я по дороге столько вопросов ему задал — типа а это что и почему вот так а не эдак, что растянулось на два часа, и на очередной мой вопрос типа «а вот эту проблему вы как решили?» — он ответил — пока никак, вот вы и решайте её, начинать можете хоть сейчас или когда вам удобно в течение месяца…
dobriykot
26.05.2016 23:55+6Вспомнилось «Что бы сделал мистер Фейнман?» (https://blogs.msdn.microsoft.com/ruericlippert/2011/02/28/983/)
CAJAX
26.05.2016 23:58-10Вы посчитали, что вопрос интервьювера глупый и поэтому решили его переплюнуть в глупости?
Когда я провожу собеседования, первый технический тест для кандидата — написать примитивнейший код для вывода таблицы умножения как в образце. При этом мне не нужен код, мне нужно увидеть как он соображает и стоит ли с ним продолжать интервью. Это во первых.
Во вторых безнадежные зануды, даже очень умные, никому в коллективе не нужны.
К слову задача так и не решена.Wesha
27.05.2016 00:18+20Вы посчитали, что вопрос интервьювера глупый и поэтому решили его переплюнуть в глупости?
Не знаю, как насчёт глупости — а вот в невнимательности меня в данном треде переплевали с огромным отрывом уже несколько человек, не заметив в заголовке статьи флажка "перевод".
CAJAX
27.05.2016 00:31+1Нет, я понимаю, как можно взъесться на такое задание, но если бы в подобной ситуации оказался я… уж я бы оторвался по полной:
И далее. Это ваш текст? В оригинале я его искал, но не нашел. Ткните пальцем.Vkil
27.05.2016 00:49Вообще то это есть в оригинале, конец первого абзаца (https://web.archive.org/web/20070704122624/http://exold.com/article/stupid-interview-questions)
Wesha
27.05.2016 00:50Тыкаю:
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
27.05.2016 00:54Ха. точно, я отвлекся на пост по ссылке в оригинале. Прошу прощения.
Хотя сути это не меняет.Wesha
27.05.2016 02:09budgawl
27.05.2016 17:55+2Теперь вот такое предложение. А что, если…
— Не стоит.
— Ясно. Тогда, может быть, нужно…
— Не нужно.
— Понятно… Разрешите хотя бы…
— Вот это попробуйте! Вам поручена эта операция, так что действуйте.Wesha
27.05.2016 17:57Так вот куда уехали телепаты!
degs
27.05.2016 18:24Если телепаты уехали как раз в тот момент когда они нужны, то либо это хреновые телепаты, либо ситуация настолько хреновая, что лучше держаться подальше.
AlexTheLost
27.05.2016 17:57-4ИМХО согласен с CAJAX, очевидно вопросом проверялись знания некоторых основ. Умение написать простой алгоритм и знания базовых API, что в реальности некоторые кандидаты не могут сделать. Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.
Wesha
27.05.2016 18:03-1Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.
Кандидат просто продемонстрировал глубокие знания возможностей и особенностей системы (например, Вы помните про назначенные vs унаследованные права доступа?), а также способность предвидеть и предотвращать потенциальные аварийные ситуациии.
Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.
А ЧСВ в программировании место там, где не светит солнце. "Если Вы никого не раздражаете — значит, Вы не занимаетесь ничем важным". (О, надо будет перевести...)
geekmetwice
27.05.2016 00:30+2Сомнительный юмор. HR — это, конечно, общеизвестный «тапок» в ИТ, но и пижоны в компании тоже не нужны. Хочешь умничать — умничай за свой счёт.
gibson_dev
27.05.2016 08:37+2Вообще обычно HR не просит написать функцию, это делают те кто имеет предстваление о чем прашивает.
VolCh
27.05.2016 08:48+4Хорошая идея для подготовки технического собеседования: попросить HR просить написать функцию без чёткой спецификации и зафиксировать список уточняющих вопросов. По списку (собственно на возможный результат можно даже не смотреть) можно будет судить стоит ли проводить техническое собеседование в принципе.
geekmetwice
27.05.2016 16:16-2Отчасти согласен, но если вы внимательно посмотрите на ответы собеседующего, то будет видно, что он не особо глубоко разбирается в ИТ, хотя и понимает слова «кодировка» и «абсолютный путь». Т.е. это некий «продвинутый HR» (ибо прогер сразу бы зарубил докучающего умника). Сошлёмся на неудачный выбор героев интервью. :)
Maccimo
27.05.2016 09:47-1Вы уверены, что правильно понимаете значение слова «пижон»?
ПИЖОН, -а; м. [от франц. pigeon — голубь] Неодобр. 1. Франтоватый поверхностный молодой человек; щёголь. 2. Тот, кто выставляет себя напоказ, хочет нравиться окружающим.geekmetwice
27.05.2016 13:09+1Вы будете смеяться, но даже ваш собственный коммент — тоже пижонство. Во-первых, поведение собеседуемого и есть чистая «показуха», мол, вот такой я продвинутый, задаю такие умные (как ему самому кажется) вопросы. Вы этого не видите, поэтому пытаетесь ткнуть меня в незнание слов (извините, вы правда думаете, что умнее меня?). Это показывает в вас обоих поверхностное отношение к предмету — бьюсь об заклад, вы даже хотели бы быть на месте этого «перцептраста». Но увы, весь сей опус — не более, чем фарс и попытка возвышения над людьми, которые вобщем-то будут вашим коллективом на годы. Так себя вести можно только при явно хамском желании НЕ устраиваться в компанию, но зато красиво уйти под фанфары малолеток.
Maccimo
27.05.2016 15:39+2Вы уж определитесь: или литературный герой — «пижон», жаждущий понравиться интервьюеру своей дотошностью или же цель героя рассказа — «возвыситься», а вы употребили слово не к месту. На всякий случай напомню, что во время интервью никаких «малолеток» поблизости не наблюдалось.
Ставить диагнозы по фотографии у вас, к слову, тоже получается прескверно.geekmetwice
27.05.2016 16:08Да нет, вы уж сами определитесь — вы решили до***ться до столба или вы действительно не понимаете смысл слова «пижон». Может, вам лучше заняться делом, чем блистать здесь неуместными диагнозами к людям, о которых вы не имеете ни малейшего представления?
janekprostojanek
27.05.2016 16:14-1Да вы, батенька, явно из того же полку прибыли, что и герой этого произведения. И тоже умничаете без толку и без надежды.
saboteur_kiev
27.05.2016 00:57Если это кандидат в программисты — это ниже хуже джуниора, который не способен проставить приоритеты и уяснить задачу. На фрилансе такой даже заказ взять не сможет.
Но если это кандидат в тестировщики или technical writer — то неплохо, весьма неплохо.maxpsyhos
27.05.2016 05:01+13А какие приоритеты и задачу?
Как сказано в последней реплике, в общем случае решение задачи выглядит примерно так:
function copyFile($srcFileName, $dstFileName){
return stdlib.fcopy($srcFileName, $dstFileName);
}
Но задача для интервью не может быть настолько простой, поэтому вполне логично предположить, что где-то в задаче должен быть подвох. Например условия, «очевидные» для интервьюера, которые он не считает нужным оглашать в явном виде.geekmetwice
27.05.2016 13:15+10Профессионал в этом случае не будет сыпать никчемушными вопросами (особенно смехотворно выглядит выяснение версии винды), а сразу напрямую спросит: «Эта задача решается в одну библиотечную функцию. Есть ли в задаче какие-то ещё требования, которые мне стоило бы учесть?».
> Но задача для интервью не может быть настолько простой
«Ты не поверишь!» :) Меня просили НАПИСАТЬ КЛАСС. Ну вот просто, любой класс с любым именем! Потом задача была намного сложнее — ДВА класса и один наследует другой. После задания выяснилось, что я первый из 10 кандидатов это сделал. Мой фэйспалм был достоен Оскара!saboteur_kiev
28.05.2016 00:59Вот активно поддерживаю — можно всегда взять и спросить, есть ли там подвох.
Ну вот реально.
У вас на работе, да даже не много, а вообще были задачи, где вы гадали «а есть ли в таске какой-то подвох», и не имели возможность спросить у техлида или того, кто вам ставил задачу?
EndUser
27.05.2016 01:05+6http://lib.rin.ru/doc/i/39687p5.html
Текст почти утерян, поэтому вот такая сохранившаяся копия. Начинать со слов "-Слышь, Егорыч, у меня для тебя такая
задачка имеется"
gorbln
27.05.2016 08:43-Вот, видишь, ты уже думать начинаешь,- обрадовался Егорыч. —
Хотя, решение твое не представляется мне красивым
Толсто!!!
Mugik
27.05.2016 02:16+1Собеседующий мог бы ответить на последний пункт так: меня в гугле забанили, тогда причина написать свою реализацию была бы очевидна :)
lxsmkv
27.05.2016 03:06+7я бы попросил такого уточняльщика повторить все вводные. И если он бы хоть что-то упустил…
У меня был коллега, который писал для проекта полезную тулзу. Там было дерево файлов и нам нужно было видеть дупликаты, я попросил его выделять дупликаты цветом, и возможность удалить выбраный файл. И тут посыпались неожиданные вопросы:
— цвет фона и текста для дупликата
— для нормального файла
— цвет фона и текста при выделении мышкой дупликата
— цвет фона и текста при выделении нормального файла
так хотелось спросить «ты что издеваешься?». Но я знал что он на полном серьезе, и я его очень уважал (и уважаю до сих пор).
Пришлось принять правила игры и… послать табличку эксель с кейсами и цветовыми комбинациями :)Wesha
27.05.2016 03:07+2я бы попросил такого уточняльщика повторить все вводные. И если он бы хоть что-то упустил…
А что, использование технических средств фиксации информаци (наподобие ручки и бумаги) запрещено корпоративными стандартами?
gearbox
27.05.2016 11:44+2так весь прикол — если челу это действительно надо — он это записывает или помнит, потому что неоходимость и логически вытекает из его плана реализации. Если троллит — то брутфорсит в голове варианты и выдает подходящие. Во втором случае повторить будет сложнее.
M-A-XG
27.05.2016 10:26+1На собеседовании так уточнять, конечно же не стоит :)
Но если есть задача, то она должна быть нормально описана.
В примере выше с большой вероятностью заказчику не понравится текст какого-то фона или текста.
А программиста, наверно, часто задолбывали заказчики, которые сами не знают, чего хотят.
С такими заказчиками я поступаю так:
время работы над их заданиями откладываю, если начинают сыпаться уточнения, которые должны быть сразу.
Многие неясные моменты стараюсь выносить в конфиги.
Но иногда лучше уточнить требования, чтобы не мудохаться зря.
Areso
27.05.2016 10:53+2По моему опыту есть два вида людей: одни, в условиях дефицита информации, реализуют все сами, как им подсказывает опыт и по личному вкусу (а потом начинается — а передвиньте кнопку, а покрасьте её в другой цвет); другие, в условиях дефицита информации, начинают этот дефицит сокращать, вытягивая информацию из заказчика, зато кнопка будет на месте и цвет будет тот, который нравится заказчику. Вторые, кстати, хорошо подходят для всяких внедренческих проектов, инженеров по знаниям и тому подобного.
gaki
27.05.2016 13:02+3А по моему опыту, во втором случае всё равно придётся и передвигать, и перекрашивать кнопку :)
impetus
27.05.2016 15:16как-то был в гостях у товарища… И как-то прозвучал невинный поначалу вопрос — «чаю будешь?»
— не откажусь
— чай или кофе?
— чай
— чёрный или зелёный?
— чёрный
— листовой или в пакетиках
— листовой
— есть хейлис, монарх, шери…
— хейлис
— тебе покрепче или не очень?
— понятно. сделай всё по своему усмотрению, если мне что-то особенно не понравится — я обязательно сообщу.
Почему-то надулся.
SunX
27.05.2016 16:31Зря вы так с ним, выбор чая это сложный творческий процесс :). Человек, видимо просто очень любит различные чаи потому хотел Вас угостить не абы чем а лучшим, что у него есть исходя из Ваших предпочтений.
kemsky
27.05.2016 03:08+14Между прочим, вы недооцениваете сложность копирования файлов. Я несколько лет саппортил приложение для работы с файлами (архивация, извлечение метаданных), поверьте, вы допустите не один десяток ошибок, а если понадобится поддержка samba, afp или кроссплатформа — вы точно налажаете по полной программе. (считайте, что комент, для автора оригинала)
galushko
27.05.2016 06:10+1Такое поведение можно встретить не только у кандидатов, но и у вполне трудоустроенных разработчиков. Я же считаю это сознательной диверсией: для того тебя и нанимают, дуралей, чтобы в ответ на функциональное требование ты выдал грамотное и обоснованное решение, а не соглашался делать на отвали лишь потому, что тебе не дали подробную спецификацию. Попу поди сам вытирает, без спецификации. Вот и здесь то же самое.
VolCh
27.05.2016 08:44+7Чтобы дать обоснованное решение, нужно знать область применения. Причём в данном случае требование не просто функциональное: «напишите функцию копирования файла» — это уже техническое задание по части реализации функционального требования к приложению/системе «копирование бизнес-данных в таких-то ситуациях для таких-то целей». И для грамотного и обоснованного решения нужны либо функциональные требования (ситуации и цели), либо полные спецификации функции.
Навскидку разные варианты по ситуациям и целям копирования файла (не в файловом менеджере или подобном приложении типа IDE, где файл является бизнес-сущностью, а в приложение, где разработчиками выбраны файлы как хранилища каких-то бизнес-данных):
— копирование бизнес-данных как создание новых бизнес-данных идентичным существующим (например, в рамках функционального требования «создание по образцу»)
— локальная резервная копия
— общесистемная резервная копия
— экспорт для внутреннего потребления
— экспорт для внешнего потребления
— импорт как внутреннее потребление
— импорт как внешнее потребление
galushko
27.05.2016 09:12+2Вот таким и должен был быть ответ кандидата, а не диалог в стиле «ты кто такой, давай техзадание». :) Дальше уже можно вести конструктивный разговор. В тексте же я не вижу желания разобраться в проблематике, и это большая беда для проекта, когда разработчик закрывается своей экспертизой, не понимая важность своей роли в команде.
Neikist
27.05.2016 09:19+1Информации явно недостаточно, мы файл копируем просто чтобы скопировать? Или все таки для каких то целей, но эти цели нам не назвали, естественно только и остается что клещами тянуть. Интервьювер что увидеть то хочет? Может знание совсем низкого уровня вроде прямой работы с фс, а может проверить что интервьюируемый вообще хоть что то написать может и с синтаксисом знаком. Нет требований к производительности, для каких это задач? Копирования очень большого объема в сжатые сроки или просто копирования с любой скоростью (в таком случае можно и с меньшими трудозатратами что то непроизводительное сделать)? И т.д.
vayho
27.05.2016 11:44+2Так так так, вы только не забывайте писать название компании в которой работаете чтобы я при поиске работы сразу отфильтровывал вас.
gimntut
27.05.2016 07:19+7Да это же просто идеальный сотрудник для общения с клиентами, которые постоянно меняют требования к задаче!!!
woodhead
27.05.2016 08:08+1Если подумать, то нет. Что мешает этому клиенту поменять требования к задаче, даже если предварительно все будет оговорено очень детально? Вы, наверное, хотели сказать, что это идеальный сотрудник для общения с клиентами, которые сами не знают, что хотят? Тогда да, тут ТЗ на выходе будет, наверное, наиболее полным. Но и здесь я боюсь, что подмножество клиентов, способных пройти подобный кейс до конца, исчезающе мало. Уж очень дотошный малый попался.
Напомнило историю о соискателе на должность тестера, которого не взяли на работу, потому что он везде мог найти баг. С таким тестером ни одно ПО не будет сдано, пока в нём будет хоть одна ошибка.VolCh
27.05.2016 08:55+1Задача тестера — выдать список багов владельцу продукта (хороший тестер выдаст ещё и оценку вероятностей их проявления в реальной эксплуатации и возможных последствий). Принимать решение о сдаче/релизе и их условиях — ответственность владельца, а не команды разработки и(или) тестирования. Тестер (как роль в процессе разработки/приемки) — лишь эксперт для бизнеса, но не ответственный за решение (тоже как роль, физически это может быть один человек).
Bangladesh
27.05.2016 08:02+5первое, что должен был этот разработчик спросить — для чего это нужно сделать и какую задачу юзера это решает?
Wesha
27.05.2016 08:03Вот это абсолютно точно — я всегда разговор начинаю с вопроса "какую задачу Вы пытаетесь решить?"
m8rge
27.05.2016 09:19+4Задачу заказчик себе придумать может совершено любую. Она может не подходить для решения проблемы. Поэтому верный вопрос: «Какую проблему Вы пытаетесь решить?»
Wesha
27.05.2016 09:21Простите, Вы правы, я неправильно перевёл. Дословно я спрашиваю "what problem you are trying to solve?". (В английском языке problem — и проблема, и задача, в данном контексте имеется в виду, конечно, проблема.)
comargo
27.05.2016 18:12+1В свое время прочитал занятную книгу, 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.Wesha
27.05.2016 18:15По поводу смысла Вы правы, но обычно когда человеку, приходящему ко мне, требуется код, у него есть именно problem ;)
А за книжечку спасибо, я на досуге интересуюсь лингвистикой.
fireSparrow
27.05.2016 10:10Это решает задачу получения копии файла ))
Bangladesh
27.05.2016 10:32Для чего эта копия файла нужна пользователю? как пользователь сейчас решает задачу? и вообще кто этот пользователь? системный администратор\бухгалтер\ген дир? это в рамках какого-то процесса делается? и т.д. — эти вопросы можно задавать постепенно, если заказчик не очень хочет разговаривать и не выдает информацию с первого раза :)
В общем если нет аналитика, который всю эту инфомацию для вас добывает, то разработчик должен сам обладать хотя бы первичными навыками анализа ситуации. Мне кажется, хотя я могу ошибаться, что хорош тот разработчик, который понимает для кого он делает продукт и понимает ценность продукта или конкретной фичи\задачи. Если человек не понимает зачем он что-то делает и просто пытается завалить вопросами технического плана, зная заранее, что ответ не будет получен, то ой-ой-ойfireSparrow
27.05.2016 10:35Смайлик в моём предыдущем комментарии как бы намекает, что его не стоит воспринимать всерьёз ;)
kpcb
27.05.2016 08:03+2Интервьюеру надо было отвечать на все вопросы «да», тогда кандидат рано или поздно бы сообразил, что дальше лучше не спрашивать, если он хочет выполнить таки это задание
VolCh
27.05.2016 09:00Во-первых, можно вопросы задавать с «или» («используем UTF-8 или UTF-16?»). Во-вторых, вопросы рано или поздно исчерпаются и выработается полная спецификация функции. В-третьих, поняв простую стратегию интервьюера легко можно манипуляцией формулировок вопросов привести к идеальной (по какой метрике — отдельный вопрос) с твоей точки зрения спецификации :)
gaki
27.05.2016 13:14+3Когда-то довелось поработать с китайскими программистами — они могут отвечать «да» на абсолютно любой вопрос:
— Вот эта функция у тебя делает пузырьковую сортировку по убыванию?
— Да.
— Но почему пузырьковую?
— Да.
— А, нет, погоди, мне показалось — это ж вообще не сортировка.
— Да.
— А что тогда??
— Да.
— ТЫ СЦУКО ИДИОТ ШТОЛЕ???
— ДА!!!
eyeless_watcher
27.05.2016 08:18+2К: Должен ли файл-копия находиться в том же каталоге, что и исходный файл?…
И: Да.
К: Как насчёт атрибута «сжатый»? Ведь может оказаться, что файловая система, на которой находится каталог назначения, не поддерживает сжатие.
К: А как насчёт атрибута «зашифрованный»? Что, если исходный файл зашифрован, а в каталоге назначения не поддерживается шифрование?
Каким образом при копировании файла в тот же каталог тот может не поддерживать что-то, что уже есть у исходного файла?Wesha
27.05.2016 08:28+1Я ждал этого вопроса! Сам заметил неувязку, но именно так у автора, и я решил в переводе не исправлять.
VolCh
27.05.2016 09:04+1Чисто теоретически, могут быть файловые системы по разному хранящие разные файлы. На практике — целевой файл может уже существовать, но в каталоге назначения быть представлен линком на другую файловую систему.
eyeless_watcher
27.05.2016 09:23+1Вы серьёзно думаете, что задающий эти вопросы кандидат имел в виду именно такой вариант
, а не банально вы**ывался? При том, что о возможности существования целевого файла он додумался поинтересоваться только под конец.
Ivan22
27.05.2016 09:15+3Увы в 99% случаев кандидаты ничего, совсем ничего не уточняют. И сразу спешат что-то придумывать.
sergarcada
27.05.2016 09:33+1Сегодня у меня было собеседование на позицию системного администратора. И мне там задали вопрос… нет, не про копирование файлов, а про те самые лампочки из комментария (https://blogs.msdn.microsoft.com/ruericlippert/2011/02/28/983/). Я немного задумался и решил задать уточняющий вопрос: скажите, а вы хабрахабр читаете? Интервьюер (руководитель какой-то там группы) в ответ улыбнулся и мы перешли к более насущным вопросам.
Antelle
27.05.2016 10:09– напишите функцию, которая копирует файл
– извините, у меня сегодня дела, до свидания
Если специалисты компании даже на интервью не способны сформулировать задание более-менее понятно, сразу понятно, чего ожидать от работы там.SamsonovAnton
27.05.2016 10:38+1Вот именно. Собеседователь демонстрирует соискателю, как у них в компании принято ставить и обсуждать задачи. Соискатель в ответ демонстрирует свой подход к делу. Если они друг друга устраивают, то будут работать вместе. Если не устраивают, то не будут. В чем проблема-то?
Antelle
27.05.2016 10:49Тоже не понял, в чём смысл троллинга интервьювера. Сразу понятно, что дело не пойдёт — можно всегда сказать и не тратить время.
sergarcada
27.05.2016 11:35+1Смысл в том, что это вымышленная история. То есть как бы повел себя автор оригинала, если бы ему задали этот же вопрос. Реальный разговор почти наверняка пошел по другому пути.
dilukhin
27.05.2016 10:23+1Интервьюер — классическая еда. Выдуманная. Таких не бывает.
Опытный эйчар отшивает таких вопрошальщиков ответом типа «разработчик должен уметь решать такие вопросы сам, наша задача как раз оценить, как вы это сделаете».Wesha
27.05.2016 10:24разработчик должен уметь решать такие вопросы сам
Лид должен уметь ставить задачу правильно. Чтобы потом не оказалось, что разработчик задачу решил — вот только не ту, которую надо было, потому что все телепаты в отпуске.
dilukhin
27.05.2016 10:51+2Разумеется, если интервью на позицию джуниора, то задание надо расписать подробнее, чем на более высокую позицию. Хороший разработчик должен уметь превращать задачи вида «сделайте мне хорошо» в конкретное ТЗ. И степень умения решать вопросы — как раз то, что требуется выяснить тестовым заданием. Не кандидату решать, что должен для него лид. Вы нам не подходите, выход там.
Wesha
27.05.2016 10:57+2Хороший разработчик должен уметь превращать задачи вида «сделайте мне хорошо» в конкретное ТЗ.
Повторюсь из другой статьи:
Дело в том, что для того, чтобы взять поток мысли, выдаваемый клиентом, и перевести его в однозначную формулировку, понятную программисту (software developer), предназначен специальный человек — software consultant. И платят ему, мягко говоря, несколько больше, чем программисту, потому что работа очень нервная — целый день с идиотами общаться.
(Иногда software developer и software consultant совмещаются в одном человеке — мне, например, но это далеко не всегда так ;)
[...]
Вот и я тредстартеру пытаюсь объяснить это уже пятый раз: задача software developer — взять условие задачи и реализовать код, её рещающий. Причём если в условии полная хня — то и код будет такой же, либо не будет вообще: garbage in — garbage out. А "понять, что же там заказчик мямлит и корректно поставить задачу девелоперу" — это работа software consultant совсем за другие деньги.
"Поэтому я вам советую подождать специалиста, договориться с нянечкой и заплатить. Но можно этого и не делать. Если вас не интересует результат." ©geekmetwice
27.05.2016 13:31+1Не надо защищать инфантильных, нервных, пижонистых программистов, считающих себя богами ИТ. Фантазии заказчика всегда можно свести к нормальным, техническим требованиям, был бы адекватный программист! Как только прогер чувствует себя выше заказчика (а не исполнителем заказа, коим и является) — всё, начинается игра «кто тут умнее» с последущим «они меня не понимают!».
Достаточно посадить перед прогером сисястую красотку и, о чудо, этот компьютерный сухарь вдруг оживает и становится таким понимающим, что аж в морду дать хочется! ГДЕ всё это было ДО девушки?? Вот-вот, «был бы человек хороший».maxpsyhos
27.05.2016 13:36Фантазии заказчика всегда можно свести к нормальным, техническим требованиям,
Высказанные фантазии — можно. «Само-собой разумеющиеся» детали — гиблое дело, у себя в голове заказчик может представлять всё что угодно. Но если он хотя бы коряво об этом требовании не скажет, то вам и сводить в ТЗ будет нечего.
webkumo
27.05.2016 17:05Хм? Нет, спасибо, не надо. Ваш кейс сильно зависит от возраста, опыта и текущего состояния «подопечного», возраста и иных параметров «мотиватора» (и их сочетаемости со вкусами «подопечного»). Но это только начало взаимодействия. На «длинных дистанциях» вменяемость и способность объяснить хотелки «мотиватора» резко выползают на передний план.
Wesha
27.05.2016 18:19+1А может, не надо считать программистов нфантильными, нервными, и пижонистыми?..
geekmetwice
27.05.2016 19:57-2А почему это не надо? Разве профессия не накладывает свой отпечаток? Плюс, в саму профессию идут люди тоже с определёнными склонностями. Например, комплекс бога. :) Или «я им ещё всем покажу!» (когда ты в классе единственный «задрот» (извините за слэнг), но у тебя хватает амбиций вылезти наверх)
Компьютер — он же как раб, ты ему скомандовал — он в точности сделал. Компьютер не истерит, ему не нужны «спасибы» и вежливость, ему нужен сухой набор команд. Увы, привычка «общаться с компьютером» и делает прогеров «неуклюжими социопатами». Не всех, разумеется, но проводя время с компьютером, сложно выстроить гармоничное отношение к другим людям.
Ещё момент: компьютеры заполонили нашу жизнь, но «по-настоящему» понимает их суть только программист. Не удивительно, что остальные «юзеры компьютеров» ему кажутся подножной пылью!Wesha
27.05.2016 21:53
vayho
27.05.2016 11:37> Хороший разработчик должен уметь превращать задачи вида «сделайте мне хорошо» в конкретное ТЗ
Какое опасное заблуждение.
avost
27.05.2016 18:19>Хороший разработчик должен уметь превращать задачи вида «сделайте мне хорошо» в конкретное ТЗ.
Для этого он должен хотя бы находиться в контексте (и, обычно, некоторое время проработавший на данном месте разработчик в нём находится). В данном случае контекст полностью отсутствует.
Возможно, интервьюер хотел функцию копирования файла для ардуины на присоединённой флешке с btrfs? Но не сказал этого (мы же знаем, что нередки случаи, когда интервью используется интервьюером для того, чтобы повысить ЧСВ за счёт кадидата).
gaki
27.05.2016 13:16«Вы же проффесионал»?
Wesha
29.05.2016 01:43gaki
29.05.2016 07:14+1Передо мной когда-то абсолютно серьёзно ставили задачу, суть которой, если очень упрощённо, состояла в том, чтобы нарисовать квадратный круг.
0xd34df00d
29.05.2016 21:57Круг радиуса r — это множество точек, лежащих на расстоянии, меньшим или равным r, от данной точки.
Вводите расстояние \rho(x, y) = \max( |x_i-y_i| ) по всем i от 1 до размерности пространства, опционально доказываете, что это действительно расстояние (ну, симметричность, неотрицательность, неравенство треугольника), потом берете плоский лист бумаги, рисуете квадрат, не забываете его заштриховать, и говорите, что это круг для таким образом введенного расстояния и размерности пространства 2.
Не вижу вообще никаких проблем.gaki
30.05.2016 04:27Всё уже
украденодоказано до нас. В т. н. «манхэттэнской метрике» гипотенуза равна сумме катетов, а круг представляет собой квадрат. Это в теории. А на практике начальник посмотрит на ваше поделие и выдаст что-то вроде: «Хмм… но что-то ваш круг не выглядит круглым. Давайте-ка вы перестанете пудрить мозги и сделаете нормальный квадратный круг, вы же профессионал.»0xd34df00d
30.05.2016 05:22Тоже вариант. От моего варианта круг отличается поворотом на ? / 4 :)
А начальнику я бы сказал «извините, я вам не подхожу, вы мне перезвоните, спасибо».gaki
30.05.2016 05:37Начальнику я тогда сказал, чтобы он, если хочет чудес, нанял на моё место Гарри Поттера. Меня примерно через месяц оттуда уволили (не за сказанное и не за неспособность нарисовать квадратный круг — просто давно всё к тому шло). Не знаю, срослось ли у них с Гарри — думаю, тоже вряд ли.
Shamov
27.05.2016 10:46-2Интервьюер имеет право просто застрелить такого кандидата. Ведь тот всем своим поведением показывает, что очень этого хочет. Кажется, что кандидат говорит какие-то слова, связанные с копированием файлов, но на уровне подтекста он, на самом деле, отчаянно умоляет интервьюера убить его, потому что больше не может жить в мире нормальных людей, будучи настолько неадекватным фриком.
Viacheslav01
27.05.2016 13:20+1А кандидат имеет право застрелить интервьвера?
Shamov
27.05.2016 13:27А интервьюера-то за что?
Viacheslav01
27.05.2016 13:51+1За вопросы :)
Хотя с моей точки зрения, этот вопрос в общем то нормальный, но вот вопросы на тему, а почему вы меняете работу, а если вы от нас уйдете, а раскажите о себе меня напрягают просто не имоверно, с такими вопросами не работников искать, а прямо к работорговцам :)Shamov
27.05.2016 14:04-1А как ещё они могут получить хотя бы приблизительное представление о вас, как о человеке? Им же важно это знать для принятия решения. Им же нужно встроить вас в какую-то команду. Чем больше подобных вопросов они зададут, тем меньше будут риски, которые неизбежно порождает ваше появление в коллективе. Проблема в том, что вы просто не умеете отвечать на такие вопросы. Предложение рассказать о себе вызывает у вас стресс исключительно потому, что вы плохой рассказчик. Учитесь. Больше читайте художественной литературы, чтобы обогатить свою речь красивыми речевыми оборотами. Можете заранее набросать план рассказа о себе.
Wesha
27.05.2016 18:23+1Предложение рассказать о себе вызывает у вас стресс исключительно потому, что вы плохой рассказчик. Учитесь.
Простите, Вы уж определитесь, кто Вам на позицию нужен — профессиональный программист или профессиональный рассказчик?
P.S. Именно поэтому я на все интервью ходил исключительно в джинсах и свитере. Я профессиональный программист, а не профессиональня манекенщица.
Viacheslav01
27.05.2016 20:15Ну я на последнем интервью когда было 3 человека, один из них HR который и начал басню, про «а если вы от нас уйдете, как нам быть», по факту заставляя защищаться, после этого мне не удалось моментально переключится на техническую часть и я честно понимаю, что я бы себя на работу не взял после такого тех собеседования.
Shamov
27.05.2016 20:25Очевидно, нужен профессиональный программист (что проверяется отдельно) со способностями к минимально связному повествованию. Программировать должен как бог, а рассказывать должен уметь хотя бы о себе. Поверьте, никто не ожидает от вас уровня Цицерона. Но можно же хотя бы немного пойти навстречу, проявив понимание, заранее подготовить список наиболее важных фактов о себе и рассказать о них в свободной форме. Должно быть что-то типа резюме, но не профессиональное, а чисто человеческое.
ivanrt
27.05.2016 12:28+3Грамотный интервьюер на уточняющие вопросы отвечать не будет, будет спрашивать а как вы думаете? Расскажите о сложностях или не однозначностях данной операции. И в итоге предложит детали оставить на ваше усмотрение. Знание деталей пойдет вам в плюс, не написанный код в минус. Вопрос упирается в ваши цели в связи с этим интервью.
Elmot
27.05.2016 13:12+2Нервный какой экзаминатор.
«Пишите как вы считаете правильным, а я потом посмотрю и обсудим»
olku
27.05.2016 14:00+2Любая реализация вне спецификации является верной.
lxsmkv
29.05.2016 16:53В школе почему-то решения, не противоречащие заданию, но не соответствующие типовому решению не принимают.
Ну грубо говоря на задачу 2+2= _ в школе нельзя ответить 2+2 = x, x< 5, x > 3, x ? Z
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».
Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.mayorovp
29.05.2016 18:38"2+2 = x, x< 5, x > 3, x ? Z" — это не решение, а новая задача
Недопустимым решением могло бы быть 2+2=113
mOlind
27.05.2016 14:05Стеб стебом, но какая была задача у интервьюера? Проверить адекватность кандидата. Какая была задача у кандидата. Получить работу? Я сомневаюсь. Повеселиться? Возможно. Фарс этот закончился бы много быстрее, т.к. тест на адекватность был бы провален и незачем тратить лишнее время на уточняющие вопросы.
Чтобы задание на собеседовании было корректным надо описать входные параметры (имя файла для чтения, имя файла для записи). Выходные параметры (объем скопированных данных или код ошибки). + Желательно контекст задачи. Зачем происходит это действие. Формализовали по максимуму — программист доволен. Интервьюер доволен.
Cyrus
27.05.2016 15:10+1Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: А вот собственно комплект тестов из 9000 кейсов.
Кандидат понимает, что уже мечтает о работодателе которому достаточно что бы «просто копировало»
Newbilius
27.05.2016 15:27-1Кандидат пляшет от счастья. Это же какой кайф, когда кто-то другой подготовил для тебя реально все кейсы! Намного лучше, чем то, как обычно в жизни происходит — постфактум итеративно дописывать вскрывшиеся моменты.
LifeKILLED
27.05.2016 15:25… А на самом деле кандидат был просто одинок, и ему очень хотелось с кем-то поговорить…
maxipr
27.05.2016 15:36+1По комментам видно, что многие не дочитывают до конца. А вся соль в последней реплике кандидата.
Alfinete
27.05.2016 18:28Круто, конечно, но перебор. Достаточно было бы спросить что-то типа: функция должна быть клоном file.copy(String, String, Boolean)? А вот после ответа «нет» задавать все вышеперечисленные вопросы.
ChymeNik
27.05.2016 18:28В подобных случаях, наверное, лучшим выходом будет просто предупредить, что всё о чем заказчик не говорил будет решено на усмотрение исполнителя.
OnelaW
27.05.2016 18:28Шутка шуткой. Но он прав во многом. Умение четко поставить задачу это умение. И да есть тип людей которые могут действовать только когда поставлена четко задача. И есть тип рукамиводителей, которые тупо переводят стрелки на ближайшего Васю. Вася умный сам разберется. И да если это джун, то он трижды прав со своей дотошностью. Он ведомый он должен четко понимать есть кто ведущий, кто поставит грамотно задачу или всё исполнять мизинцем левой ноги за час до наступления шаббата?
Farxial
27.05.2016 18:28Когда ты просто берёшь и делаешь — работодатель впоследствии может оценить код, насколько ты сделал правильно и, следовательно, подходишь ли ты ему. А тут ты выясняешь, как нужно сделать правильно. Гениально :)
Wesha
27.05.2016 22:57А тут ты выясняешь, как нужно сделать правильно.
Может быть, это станет для Вас откровением, но для разных людей понятия "правильно" могут ооооочень отличаться...
vyatsek
27.05.2016 18:28+4Мне не нравится ни кандидат ни интервьювер. Интервьювер убивает свое время, потому как перед ним человек, который затягивает тривиальную задачу в условиях неопределенных требований. Надо скопировать файл, предусматриваешь более менее очевидные кейсы и делаешь.
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.
Am0ralist
28.05.2016 01:39+1Извините, я уже вторую систему внедряя в производство со стороны потерпевших, то есть пользователей. Прошлая была САПР в промышленности, сейчас ИС в медучереждении.
При мне сегодня у отвечающего за проект инженера был практически истерический смех, от того, как их программисты реализуют бизнес задачи.
Я каждый раз что тогда, что сейчас просто беру описание реализованных задач и начинаю по ним «тыкать». И каждый раз я натыкаюсь на ошибки, особенно, если функционал новый.
Вот прям так: реализовано, что человек, у которого нет прав, не может изменить цену в заявке, срочность и т.д. Я прям себе сразу убираю права, открываю заявку, тыкаю в галочку срочности теста — и правда, галочка срочности не снимается, зато цена при этом сбрасывается на начальную и доступ к изменению коэффициента появляется. Тыкаю в общую срочность заявки и вуаля, оказывается она не заблокирована, т.е. ее можно поставить в любую заявку, а потом см. предыдущее. Всё. задача провалена.
А уж пароль то запросить и сравнить с паролем пользователя из базы любой дурак сможет, не так ли? Не, я серьезно не понимаю, как можно было накосячить в такой тривиальной задаче. Однако первый раз один из модулей запускался с любым паролем, лишь бы логин был верный, а сейчас, если не ошибаюсь, с капсом входит. И да, они хранят пароли в базе в открытом виде.
И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Или это уже нерушимая традиция решать бизнес задачи методом «хренак-хренак и в продакшен»?vyatsek
28.05.2016 12:29-1А вам не кажется что дело не в программистах, а в консерватории? Никто не говорит о реализации хоп хоп и в продакшен.
>И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Серьезно.
Есть тривиальная задача: реализовать копирование файла, никто не знает, в том числе заказчик, как оно точно должно работать. Тривиальна она потому, что у нее нет контекста. В рамках своего мировоззрения разработчик может предусмотреть валидные кейсы, несколько дополнив этот контекст.
Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
michael_vostrikov
28.05.2016 09:06-4На самом деле, такая ситуация могла произойти только в голове автора. Он сыплет умными вопросами, а интервьюер что-то бубнит в ответ, потому что никогда не задумывался о таких подробностях. Действительно, отдает некоторым высокомерием.
В реальности эти вопросы имеют смысл, только если работа связана с разработкой файловых систем и драйверов для них. В этом случае интервьюер после пары таких вопросов говорит «Ок, видно что вы в теме, давайте закончим с этой задачей».
Во всех остальных случаях (например, скопировать загруженный файл из временного каталога в постоянный) нужно вызывать системные функции, которые предоставляет ОС и язык программирования, и которые внутри вызывают функции этих драйверов.
А значит, кандидат не прошел собеседование, потому что, судя по вопросам, собрался писать свой низкоуровневый велосипед. «Вы нам не подходите, до свидания».michael_vostrikov
29.05.2016 18:13Оу, ну после четвертого минуса не могу не спросить) Что именно я сказал неправильно?
mayorovp
29.05.2016 18:42В реальности такие задачи применяют, чтобы понять — умеет ли кандидат вообще писать код или может лишь рассуждать о нем.
michael_vostrikov
29.05.2016 19:04Хм. Под словами «В реальности эти вопросы имеют смысл» я имел в виду не исходную задачу, а вопросы кандидата. Цель самой задачи мне понятна)
Wesha
29.05.2016 20:00В реальности эти вопросы имеют смысл, только если работа связана с разработкой файловых систем и драйверов для них
Ну да, "в реальности" большинство согласно с Вами, а потом удивляется, каким образом хакеры смогли увести из их продукта секретные данные, например. Потому что хакеры думают как раз так, как кандидат:
— А что, если…
— Не стоит.
— Ясно. Тогда, может быть…
— Не нужно.
— Понятно… Разрешите хотя бы…
— Вот это попробуйте!michael_vostrikov
29.05.2016 20:24Ну а как ответы помогут улучшить безопасность самого приложения, если оно пользуется абстракцией над файловой системой? Это больше вопрос окружения. К тому же, мне кажется, не стоит смешивать собеседования на позицию разработчика, тестировщика, и безопасника.
Rumega
30.05.2016 15:45Смешная история, конечно, но получился пост-бальзам на душу двух типов разработчиков:
- Я прикладной программист! Всегда надо вызывать библиотечные/системные функции, а если библиотечная функция чего-то не умеет, то это её проблемы! Пусть заказчик купит нам другую платформу, или заплатит нам миллион за то, чтоб мы таки написали копирование файла.
- Я работаю по спецификации, а заказчик ничего не понимает в сложности задачи. Надо ему показать, какой он глупый, а с меня какой спрос? Спецификация всегда не полна… а я просто работаю по спецификации (goto start)
Добавим в эту аудиторию тех манагеров, кто не в состоянии поставить/описать задачу и сетует на плохих программистов, и получился прекрасный ragebait (ну или cringe bait) для широких слоев населения.
Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)gearbox
30.05.2016 18:58Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)
Товарищ Lol4t0 четко описал ситуацию:
Не забывайте, что интервьюер-то существует только в голове автора, а потому тоже отражает лишь квалификацию последнего
Я могу добавить — мы ничего не имеем, кроме описания сеанса ментального онанизма. Все этим занимаются, но не все потом на основании этого пишут статьи.
Lol4t0
На какую позицию вы претендуете? Тут в лучшем случае junior
Wesha
Мотороллер не мой, я просто разместил
объявуперевод.ponich
По моему это интервьюер на junior
Lol4t0
Не забывайте, что интервьюер-то существует только в голове автора, а потому тоже отражает лишь квалификацию последнего