Комментарии 224
На какую позицию вы претендуете? Тут в лучшем случае junior
Нужно было решить задачу, а не превратить ее в фарс. Уровень junior у кандидата — а если задача будет сложнее ему потребуется месяц на уточнение всех нюансов?
Если не уточнить все нюансы ДО того, как будет написан код, возможны варианты:
- Пронесло, всё работает;
- Всё в основном работает, но в некоторых непредусмотренных ситуациях падает;
- Всё в основном работает, но создана дырка в безопасности системы (см. вопросы про шифрование);
- Всё в основном работает, вот только клиенту было надо совсем не это, так что надо всё написанное выкинуть и переписать с нуля.
"Час работы по дизайну экономит день работы по кодированию".
И… что? Если ситуация непредусмотренная, что вы достигнете этим? Да, программа не упадёт, будет ещё хуже: она останется работать в непредусмотренном состоянии.
А прогресс нужно сохранять постоянно (после разумного количества действий, разумеется), а не надеяться, что не произойдёт ничего исключительного, типа выключения питания устройства.
К примеру, уже почти две недели воюю с банком по поводу их сломавшейся выгрузки для юрлиц, и они не могут это починить, даже после того как им указали, что происходит и где происходит. И если юрик не будет обращаться в банк, он будет сидеть без выгрузки. Потому там есть все — и перехват ошибок, и сохранение логов, и описание ошибок с номерами строк, вот это вот всё. И все это документируется (абы-как, честно говоря) и отправляется в банк. И со всеми другими системами, с которыми нужно взаимодействовать происходит все тоже самое. В среднем за год мы отправляем около полудюжины таких запросов, из которых примерно половина — явный косяк производителя ПО. И приходится совместно решать, иначе — никак.
Ну да, если калькулятор будет сыпаться (и он не уникальный), скачают другой. Только с калькулем есть выбор, а вот с банковским ПО/ПО гос.сектора выбора нет.
В идеальном мире — да. В реальном мире — все случаи, вероятность появления которых существенна.
Ваш пример как раз подтверждает мои слова — пора менять банк. Точнее, банк будет менять пора в тот момент, когда расходы на переход + потери от перехода превысят расходы от того геморроя, которым вы страдаете.
А то, что «у вас нет другого выбора» — это плохо, конечно, но не является аргументом писать некачественный софт.
Первую проблему решаем оберткой в try-catch.
Именно так поступили некоторые чиновники с аварией на ЧАЭС. "У нас тут взорвался реактор, но мы никому не расскажем, выходите спокойно на первомайскую демонстрацию."
"Час работы по дизайну экономит день работы по кодированию".
Да-да-да… Тут вот как-то коментировал про стадию "дизайна".
Т.е. я как бы не против оного если с головой, но (понимая что пример утрированный, и что юмор и троллинг) все же как-раз этот пост г. Пикета является квинтэссенцией "передергивания" архитектурной стадии, как оно к сожалению реально часто бывает.
Другой пример: был у меня один коллега, — элементарнейшие вещи (типа той же упомянутой copy) он писал так: сначала писалась дока, потом интерфейс, потом все это правилось до крайней степени, причем его эго еще не удовлетворено, а отведенного времени уже на на 80%-90% съедено. В результате ему просто больше ничего не давали — лучше сам или кому другому отдам… Пока его не ушли.
Имхо, самое первое правило классного разработчика должно быть — держать перфекциониста в себе на очень коротком поводке. Применительно к примеру, как по мне, пусть лучше функция обросла 100-ми todos (которые возможно и даже скорее всего никогда не доделают), но она работает.
Реальность такова, что на этапе сбора требований и проектирования учесть все нюансы не получается никак. Даже если на «дизайн» было потрачено очень много времени.
Поэтому, современные методологии работают по другому:
1. Делаем как-нибудь, лишь бы проще, быстрее и работало.
2. Показываем промежуточный результат заказчику, выясняем двигаемся ли мы в нужном направлении.
3. Корректируем направления и повторяем итерацию начиная с пункта 1.
Я думаю, правильнее было бы сначала написать самую простую реализацию, а потому уже — задавать уточняющие вопросы и предлагать улучшения.
Это даже официально называется макет (или mock-up)
мне придётся перекодировать в UTF-16, а это несколько геморройно…
Если это WinXP, то в WinApi есть функция MultiByteToWideChar которая это сделает в две строки кода. Так что даже по задаваемым уточняющим вопросам уже можно сделать вывод о квалификации.
Вообще-то абсолютно адекватные вопросы. И да, перекодировка — это выделение буфера, потом освобождение, и это я не рассматриваю нюансы, например, требования к поддержке 32битных символов Unicode (MultiByteToWideChar поддерживают только 31-битные, насколько я помню — вернее, для UTF-8 это означает лимит в 4 байта на символ).
Чуточку ошибся, ограничение на символ строже в UTF-16, он может закодировать только 20-битный символ, а UTF-8 — 31-битный. И тут еще не рассмотрены преобразования символов, например, в каноническую форму и так далее.
Эх, и это всего лишь один вопрос из списка :-)
Вообще-то абсолютно адекватные вопросы.
Не все. Например, порядок байтов в строке в памяти колебать программиста не должен. Внимательный интервьюер на этом вопросе может сказать «Попался, тролль! Давай, до свидания».
Особенно если это имя файла пришло, например, по сети. Ага.
Под double сейчас обычно понимается binary64 из ieee754, но иногда используется, например, decimal64 из того же стандарта.
Но не всегда использовалась смещённая экспонента, не всегда под double понимается 64-битное представление, иногда это проприетарная кодировка (например, на мейнфреймах от ibm), а не ieee754 binary64.
Другой кейс — это обыкновенный binary32/64, но в mixed-endianess как, например, бывает при работе с modbus/rtu.
Так что бывают кейсы, когда это уточнение существенно.
Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Вы нам не подходите.
Ну или, если интервьюер в хорошем настроении, как-то так:
Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Мы хотим посмотреть, как Вы понимаете задачу, какие подходы примените в ее решении и какие условия учтете, так что дополнительные вопросы не принимаются.
Совершенно верно. Человека берут на работу решать проблемы, а не создавать их. Если также он будет донимать вопросами заказчика, то тот просто уйдет.
Задача программиста-аналиатка — уметь трансформировать фукнциональные реквизиты в конкретное решение, а в случае нехватки деталей предлагать собственное решение, а не допытываться по каждому пунтку. Поэтому программа должна работать адевкатно в большинстве случаев и корректно отлавливать нештатные ситуации.
Поэтому программа должна работать адевкатно в большинстве случаев и корректно отлавливать нештатные ситуации.
К: Что конкретно Вы имеете в виду, говоря "нештатные ситуации"? (pokerface)
Для этого нужно определить "штатную ситуацию". Если дополнительные реквизиты не определены, нужно взять самое простое решение: создание нового файла с заданным именем и дефолтными атрибутами и копирование в него содержимого заданного файла. Все операции с привилегиями процесса. В случае невозможности копирования вывести (вернуть) ошибку, желательно с пояснением причины.
Все вышеперечисленное аналитик-программист должен автоматически вывести из задания "напиши мне программу для копирования файла". Только при обладании бОльшим количеством данных о целевой задаче и области ее применения, данное решение может быть трансформированно в нечто более сложное. Принцип KISS еще никто не отменял.
Вот кстати притча в тему: https://habrahabr.ru/post/74193/
Вот кстати притча в тему: https://habrahabr.ru/post/74193/
Телепаты — да, они такие, им не жалко и 5 рублей платить. Одна проблема: только в притчах и существуют.
Только при обладании бОльшим количеством данных о целевой задаче и области ее применения
А чем, по-Вашему, занимался кандидат, как не сбором "бОльшегом количества данных о целевой задаче и области ее применения"? — "Очевидно, [...] у Вас имеются какие-то очень-очень специфические требования, которым библиотечные функции не удовлетворяют, и я намереваюсь эти требования из Вас вытянуть."
В случае невозможности копирования вывести (вернуть) ошибку, желательно с пояснением причины.
Возможны и ситуации, когда явной ошибки нет, а по факту — есть (например, описываемый кандидатом случай, когда файл скопировался незашифрованным, или не были скопированы права доступа, и master.passwd оказался world-readable).
А чем, по-Вашему, занимался кандидат, как не сбором "бОльшегом количества данных о целевой задаче и области ее применения"?
Надменно демонстрировал важность своей работы и ценность своих знаний.
Первым вопросом должен быть не "что вы подразумеваете под вашей просьбой?", а "для чего вам это нужно?", "где вы это будете использовать?", "для какой общей задачи требуется данное решение?" Опишите проблему целиком, а я уже сам решу, нужно ли вам атрибуты менять и вообще нужно ли само копирование файла.
Вот приходите Вы к дентисту: "вылечите мне зуб". А он такой: "что конкретно Вы имеете ввиду под "вылечите"? У вас пульпит, периодонтит, перикоронит или простой кариес? Вам пломбу поставить, удаление нерва, коронку, удаление зуба или что? Что Вы от меня хотите? Сформулируйте точно!"
Вы будете смеяться, но именно так и работает челюстно-лицевой хирург. Только вот проблема: к нему приходят не с кондачка, а с направлением от дантиста, который в бамажке пишет — "а сделай, любезный, вот этому чучелу рут-канал на 18-м зубе".
Я уже который раз долдоню: детальной постановкой задачи занимается специальный человек — software consultant. И именно его задача — выбить из клиента, чего именно он хочет. И зарплата у него несколько другая, чем у кодера-по-спецификации. (В частности, мне на протяжении своей жизни довелось поработать и одним, и другим, и обоими вместе).
И каждому приходится работать исключительно «обоими вместе».
… за одну (меньшую) зарплату ;)
По разным причинам
Например "работодателя жаба душит, а работник не нашёл способа использовать свою редкость как преимущество".
По-моему, большая часть взаимного непонимания в комментариях к этой статье связана с тем, что зачастую никакого такого отдельного «специального человека» попросту нет.
Более того, если такой человек есть, то он заведомо лишний в компании. Он не разработчик, поэтому плохо знает детали системы, он также не бизнес аналист, поэтому также не може предложить собственное решение или инициативу клиенту.
Вот типичная работа такого человека:
Поэтому все современные методики разработки пытаются уменьшить число ступеней в иерархии разработки, сделать структуру более плоской и прозрачной. Обязанности "software consultant" ложатся на team lead-а, который суть есть разработчик.
он не разработчик, поэтому плохо знает детали системы, он также не бизнес аналист, поэтому также не може предложить собственное решение или инициативу клиенту.
Это всё равно, что сказать "англо-русский переводчик плохо знает и английский, и русский". Software consultant — это "переводчик с человеческого на программистский", поэтому он как раз должен быть хорошо знаком с обоими "языками". Обычно ими становятся опытные программисты, которые за свою жизнь пообщались со 100500 клиентов, и уже могут понимать, что клиент действительно имеет в виду, говоря "нарисуйте мне красную линию зелёным цветом".
Согласен с комментаторами, я был неправ
Когда я провожу собеседования, первый технический тест для кандидата — написать примитивнейший код для вывода таблицы умножения как в образце. При этом мне не нужен код, мне нужно увидеть как он соображает и стоит ли с ним продолжать интервью. Это во первых.
Во вторых безнадежные зануды, даже очень умные, никому в коллективе не нужны.
К слову задача так и не решена.
Вы посчитали, что вопрос интервьювера глупый и поэтому решили его переплюнуть в глупости?
Не знаю, как насчёт глупости — а вот в невнимательности меня в данном треде переплевали с огромным отрывом уже несколько человек, не заметив в заголовке статьи флажка "перевод".
Нет, я понимаю, как можно взъесться на такое задание, но если бы в подобной ситуации оказался я… уж я бы оторвался по полной:
И далее. Это ваш текст? В оригинале я его искал, но не нашел. Ткните пальцем.
Тыкаю:
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
Перевод художественный, а не дословный.
Хотя сути это не меняет.
— Не стоит.
— Ясно. Тогда, может быть, нужно…
— Не нужно.
— Понятно… Разрешите хотя бы…
— Вот это попробуйте! Вам поручена эта операция, так что действуйте.
Так вот куда уехали телепаты!
Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.
Кандидат просто продемонстрировал глубокие знания возможностей и особенностей системы (например, Вы помните про назначенные vs унаследованные права доступа?), а также способность предвидеть и предотвращать потенциальные аварийные ситуациии.
Кандидат просто продемонстрировал свое высокомерие и неуважение к собеседующему.
А ЧСВ в программировании место там, где не светит солнце. "Если Вы никого не раздражаете — значит, Вы не занимаетесь ничем важным". (О, надо будет перевести...)
Affirming the consequent
ПИЖОН, -а; м. [от франц. pigeon — голубь] Неодобр. 1. Франтоватый поверхностный молодой человек; щёголь. 2. Тот, кто выставляет себя напоказ, хочет нравиться окружающим.
Ставить диагнозы по фотографии у вас, к слову, тоже получается прескверно.
Но если это кандидат в тестировщики или technical writer — то неплохо, весьма неплохо.
Как сказано в последней реплике, в общем случае решение задачи выглядит примерно так:
function copyFile($srcFileName, $dstFileName){
return stdlib.fcopy($srcFileName, $dstFileName);
}
Но задача для интервью не может быть настолько простой, поэтому вполне логично предположить, что где-то в задаче должен быть подвох. Например условия, «очевидные» для интервьюера, которые он не считает нужным оглашать в явном виде.
> Но задача для интервью не может быть настолько простой
«Ты не поверишь!» :) Меня просили НАПИСАТЬ КЛАСС. Ну вот просто, любой класс с любым именем! Потом задача была намного сложнее — ДВА класса и один наследует другой. После задания выяснилось, что я первый из 10 кандидатов это сделал. Мой фэйспалм был достоен Оскара!
Ну вот реально.
У вас на работе, да даже не много, а вообще были задачи, где вы гадали «а есть ли в таске какой-то подвох», и не имели возможность спросить у техлида или того, кто вам ставил задачу?
первый из 10 кандидатов
На синьора подавался? :)
Текст почти утерян, поэтому вот такая сохранившаяся копия. Начинать со слов "-Слышь, Егорыч, у меня для тебя такая
задачка имеется"
У меня был коллега, который писал для проекта полезную тулзу. Там было дерево файлов и нам нужно было видеть дупликаты, я попросил его выделять дупликаты цветом, и возможность удалить выбраный файл. И тут посыпались неожиданные вопросы:
— цвет фона и текста для дупликата
— для нормального файла
— цвет фона и текста при выделении мышкой дупликата
— цвет фона и текста при выделении нормального файла
так хотелось спросить «ты что издеваешься?». Но я знал что он на полном серьезе, и я его очень уважал (и уважаю до сих пор).
Пришлось принять правила игры и… послать табличку эксель с кейсами и цветовыми комбинациями :)
я бы попросил такого уточняльщика повторить все вводные. И если он бы хоть что-то упустил…
А что, использование технических средств фиксации информаци (наподобие ручки и бумаги) запрещено корпоративными стандартами?
Но если есть задача, то она должна быть нормально описана.
В примере выше с большой вероятностью заказчику не понравится текст какого-то фона или текста.
А программиста, наверно, часто задолбывали заказчики, которые сами не знают, чего хотят.
С такими заказчиками я поступаю так:
время работы над их заданиями откладываю, если начинают сыпаться уточнения, которые должны быть сразу.
Многие неясные моменты стараюсь выносить в конфиги.
Но иногда лучше уточнить требования, чтобы не мудохаться зря.
— не откажусь
— чай или кофе?
— чай
— чёрный или зелёный?
— чёрный
— листовой или в пакетиках
— листовой
— есть хейлис, монарх, шери…
— хейлис
— тебе покрепче или не очень?
— понятно. сделай всё по своему усмотрению, если мне что-то особенно не понравится — я обязательно сообщу.
Почему-то надулся.
Навскидку разные варианты по ситуациям и целям копирования файла (не в файловом менеджере или подобном приложении типа IDE, где файл является бизнес-сущностью, а в приложение, где разработчиками выбраны файлы как хранилища каких-то бизнес-данных):
— копирование бизнес-данных как создание новых бизнес-данных идентичным существующим (например, в рамках функционального требования «создание по образцу»)
— локальная резервная копия
— общесистемная резервная копия
— экспорт для внутреннего потребления
— экспорт для внешнего потребления
— импорт как внутреннее потребление
— импорт как внешнее потребление
Напомнило историю о соискателе на должность тестера, которого не взяли на работу, потому что он везде мог найти баг. С таким тестером ни одно ПО не будет сдано, пока в нём будет хоть одна ошибка.
Вот это абсолютно точно — я всегда разговор начинаю с вопроса "какую задачу Вы пытаетесь решить?"
Простите, Вы правы, я неправильно перевёл. Дословно я спрашиваю "what problem you are trying to solve?". (В английском языке problem — и проблема, и задача, в данном контексте имеется в виду, конечно, проблема.)
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.
В общем если нет аналитика, который всю эту инфомацию для вас добывает, то разработчик должен сам обладать хотя бы первичными навыками анализа ситуации. Мне кажется, хотя я могу ошибаться, что хорош тот разработчик, который понимает для кого он делает продукт и понимает ценность продукта или конкретной фичи\задачи. Если человек не понимает зачем он что-то делает и просто пытается завалить вопросами технического плана, зная заранее, что ответ не будет получен, то ой-ой-ой
"На каждую хитрую дырку найдётся болт с резьбой" © Cледующие вопросы:
— Вы на все вопросы будете отвечать положительно?
— Да
— Вы берёте меня на работу? (trollface)
— Вот эта функция у тебя делает пузырьковую сортировку по убыванию?
— Да.
— Но почему пузырьковую?
— Да.
— А, нет, погоди, мне показалось — это ж вообще не сортировка.
— Да.
— А что тогда??
— Да.
— ТЫ СЦУКО ИДИОТ ШТОЛЕ???
— ДА!!!
К: Должен ли файл-копия находиться в том же каталоге, что и исходный файл?…
И: Да.
К: Как насчёт атрибута «сжатый»? Ведь может оказаться, что файловая система, на которой находится каталог назначения, не поддерживает сжатие.
К: А как насчёт атрибута «зашифрованный»? Что, если исходный файл зашифрован, а в каталоге назначения не поддерживается шифрование?
Каким образом при копировании файла в тот же каталог тот может не поддерживать что-то, что уже есть у исходного файла?
Я ждал этого вопроса! Сам заметил неувязку, но именно так у автора, и я решил в переводе не исправлять.
Опытный эйчар отшивает таких вопрошальщиков ответом типа «разработчик должен уметь решать такие вопросы сам, наша задача как раз оценить, как вы это сделаете».
разработчик должен уметь решать такие вопросы сам
Лид должен уметь ставить задачу правильно. Чтобы потом не оказалось, что разработчик задачу решил — вот только не ту, которую надо было, потому что все телепаты в отпуске.
Хороший разработчик должен уметь превращать задачи вида «сделайте мне хорошо» в конкретное ТЗ.
Повторюсь из другой статьи:
Дело в том, что для того, чтобы взять поток мысли, выдаваемый клиентом, и перевести его в однозначную формулировку, понятную программисту (software developer), предназначен специальный человек — software consultant. И платят ему, мягко говоря, несколько больше, чем программисту, потому что работа очень нервная — целый день с идиотами общаться.
(Иногда software developer и software consultant совмещаются в одном человеке — мне, например, но это далеко не всегда так ;)
[...]
Вот и я тредстартеру пытаюсь объяснить это уже пятый раз: задача software developer — взять условие задачи и реализовать код, её рещающий. Причём если в условии полная хня — то и код будет такой же, либо не будет вообще: garbage in — garbage out. А "понять, что же там заказчик мямлит и корректно поставить задачу девелоперу" — это работа software consultant совсем за другие деньги.
"Поэтому я вам советую подождать специалиста, договориться с нянечкой и заплатить. Но можно этого и не делать. Если вас не интересует результат." ©
Достаточно посадить перед прогером сисястую красотку и, о чудо, этот компьютерный сухарь вдруг оживает и становится таким понимающим, что аж в морду дать хочется! ГДЕ всё это было ДО девушки?? Вот-вот, «был бы человек хороший».
Фантазии заказчика всегда можно свести к нормальным, техническим требованиям,
Высказанные фантазии — можно. «Само-собой разумеющиеся» детали — гиблое дело, у себя в голове заказчик может представлять всё что угодно. Но если он хотя бы коряво об этом требовании не скажет, то вам и сводить в ТЗ будет нечего.
А может, не надо считать программистов нфантильными, нервными, и пижонистыми?..
Компьютер — он же как раб, ты ему скомандовал — он в точности сделал. Компьютер не истерит, ему не нужны «спасибы» и вежливость, ему нужен сухой набор команд. Увы, привычка «общаться с компьютером» и делает прогеров «неуклюжими социопатами». Не всех, разумеется, но проводя время с компьютером, сложно выстроить гармоничное отношение к другим людям.
Ещё момент: компьютеры заполонили нашу жизнь, но «по-настоящему» понимает их суть только программист. Не удивительно, что остальные «юзеры компьютеров» ему кажутся подножной пылью!
Какое опасное заблуждение.
Для этого он должен хотя бы находиться в контексте (и, обычно, некоторое время проработавший на данном месте разработчик в нём находится). В данном случае контекст полностью отсутствует.
Возможно, интервьюер хотел функцию копирования файла для ардуины на присоединённой флешке с btrfs? Но не сказал этого (мы же знаем, что нередки случаи, когда интервью используется интервьюером для того, чтобы повысить ЧСВ за счёт кадидата).
Кандидат ведет себя как мудак.
Интервьюер имеет право просто застрелить такого кандидата. Ведь тот всем своим поведением показывает, что очень этого хочет. Кажется, что кандидат говорит какие-то слова, связанные с копированием файлов, но на уровне подтекста он, на самом деле, отчаянно умоляет интервьюера убить его, потому что больше не может жить в мире нормальных людей, будучи настолько неадекватным фриком.
Интервьюер имеет право просто застрелить такого кандидата
Уголовный кодекс имеет отличное от Вашего мнение ;)
А интервьюера-то за что?
Хотя с моей точки зрения, этот вопрос в общем то нормальный, но вот вопросы на тему, а почему вы меняете работу, а если вы от нас уйдете, а раскажите о себе меня напрягают просто не имоверно, с такими вопросами не работников искать, а прямо к работорговцам :)
А как ещё они могут получить хотя бы приблизительное представление о вас, как о человеке? Им же важно это знать для принятия решения. Им же нужно встроить вас в какую-то команду. Чем больше подобных вопросов они зададут, тем меньше будут риски, которые неизбежно порождает ваше появление в коллективе. Проблема в том, что вы просто не умеете отвечать на такие вопросы. Предложение рассказать о себе вызывает у вас стресс исключительно потому, что вы плохой рассказчик. Учитесь. Больше читайте художественной литературы, чтобы обогатить свою речь красивыми речевыми оборотами. Можете заранее набросать план рассказа о себе.
Предложение рассказать о себе вызывает у вас стресс исключительно потому, что вы плохой рассказчик. Учитесь.
Простите, Вы уж определитесь, кто Вам на позицию нужен — профессиональный программист или профессиональный рассказчик?
P.S. Именно поэтому я на все интервью ходил исключительно в джинсах и свитере. Я профессиональный программист, а не профессиональня манекенщица.
Очевидно, нужен профессиональный программист (что проверяется отдельно) со способностями к минимально связному повествованию. Программировать должен как бог, а рассказывать должен уметь хотя бы о себе. Поверьте, никто не ожидает от вас уровня Цицерона. Но можно же хотя бы немного пойти навстречу, проявив понимание, заранее подготовить список наиболее важных фактов о себе и рассказать о них в свободной форме. Должно быть что-то типа резюме, но не профессиональное, а чисто человеческое.
"А нас-то за что?"
«Пишите как вы считаете правильным, а я потом посмотрю и обсудим»
ИМХО, кандидат в данной ситуации как "тупая секретарша"
Ну грубо говоря на задачу 2+2= _ в школе нельзя ответить 2+2 = x, x< 5, x > 3, x ∈ Z
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».
Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.
Чтобы задание на собеседовании было корректным надо описать входные параметры (имя файла для чтения, имя файла для записи). Выходные параметры (объем скопированных данных или код ошибки). + Желательно контекст задачи. Зачем происходит это действие. Формализовали по максимуму — программист доволен. Интервьюер доволен.
Интервьюер: А вот собственно комплект тестов из 9000 кейсов.
Кандидат понимает, что уже мечтает о работодателе которому достаточно что бы «просто копировало»
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.
>И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Серьезно.
Есть тривиальная задача: реализовать копирование файла, никто не знает, в том числе заказчик, как оно точно должно работать. Тривиальна она потому, что у нее нет контекста. В рамках своего мировоззрения разработчик может предусмотреть валидные кейсы, несколько дополнив этот контекст.
Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
В реальности эти вопросы имеют смысл, только если работа связана с разработкой файловых систем и драйверов для них. В этом случае интервьюер после пары таких вопросов говорит «Ок, видно что вы в теме, давайте закончим с этой задачей».
Во всех остальных случаях (например, скопировать загруженный файл из временного каталога в постоянный) нужно вызывать системные функции, которые предоставляет ОС и язык программирования, и которые внутри вызывают функции этих драйверов.
А значит, кандидат не прошел собеседование, потому что, судя по вопросам, собрался писать свой низкоуровневый велосипед. «Вы нам не подходите, до свидания».
В реальности такие задачи применяют, чтобы понять — умеет ли кандидат вообще писать код или может лишь рассуждать о нем.
В реальности эти вопросы имеют смысл, только если работа связана с разработкой файловых систем и драйверов для них
Ну да, "в реальности" большинство согласно с Вами, а потом удивляется, каким образом хакеры смогли увести из их продукта секретные данные, например. Потому что хакеры думают как раз так, как кандидат:
— А что, если…
— Не стоит.
— Ясно. Тогда, может быть…
— Не нужно.
— Понятно… Разрешите хотя бы…
— Вот это попробуйте!
- Я прикладной программист! Всегда надо вызывать библиотечные/системные функции, а если библиотечная функция чего-то не умеет, то это её проблемы! Пусть заказчик купит нам другую платформу, или заплатит нам миллион за то, чтоб мы таки написали копирование файла.
- Я работаю по спецификации, а заказчик ничего не понимает в сложности задачи. Надо ему показать, какой он глупый, а с меня какой спрос? Спецификация всегда не полна… а я просто работаю по спецификации (goto start)
Добавим в эту аудиторию тех манагеров, кто не в состоянии поставить/описать задачу и сетует на плохих программистов, и получился прекрасный ragebait (ну или cringe bait) для широких слоев населения.
Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)
Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)
Товарищ Lol4t0 четко описал ситуацию:
Не забывайте, что интервьюер-то существует только в голове автора, а потому тоже отражает лишь квалификацию последнего
Я могу добавить — мы ничего не имеем, кроме описания сеанса ментального онанизма. Все этим занимаются, но не все потом на основании этого пишут статьи.
Я бы первым делом спросил - зачем? А исходя из этого бы уже продумывал реализацию - может, copy через cmd оказалось бы достаточно.
«Кандидат имеет право задавать уточняющие вопросы», или Доводим интервьюера до нервного срыва