09.08.2011 18:51, Ulitka пишет:
> > А почему? Вдруг он хороший программист, просто любопытный и идейный, да > и разговор поддержать?
Потому что он из пушки по воробьям стреляет. Ну или гвозди микроскопом
забивает.
> Вот допустим у нас строка — 5K символов. Это > влезет в 80 cache lines на каком-то Xeon-е. Что быстрее — идти с обеих > сторон строки и делать swap или CUDA? Тут интересно как сработает > prefetcher в случае reverse iteration, не будет ли давать cold miss на > каждом 65-м байтике? Возможно, прийдется дать hint (ну, GCC например > сама умеет такое делать, если использовать subscript). Ну или залить всю > память в GPU, обсчитать и слить результат обратно? Или лучше host mapped > mamory заиспользовать? Стойте, погодите, может MPI лучше прикрутить? Или > самому распараллелить? Кстати, кто-то из кандидатов делал/упоминал loop > unrolling?
Бррр. Что курил?
Здравствуйте, Alex Dav, Вы писали:
AD>Здравствуйте, shrecher, Вы писали:
S>>А зачем? Задача на переворот строки — банально. Ее спрашивают на каждом втором собеседовании. AD>А как часто вы это используете в жизни?
Это простое и понятное алгоритмическое задание, которе должен уметь решать любой программист.
AD>Лучше уж дать задачу — разбить строку на токены — это хоть живая вещь.
Здравствуйте, monax, Вы писали:
M>После такой беседы даю человеку карандаш с листиком или предлагаю доску с маркером (кому как нравится) и прошу написать мне функцию для переворота строки на php.
я надеюсь вы сами на себе этот тест проверили? — взяли лист бумаги и написали переворот строки
(эксперимент не чистый, т.к. когда сам себя проверяешь — обстановка более спокойная)
если не проверили — попробуйте решить аналогичную простую задачу, типа перевод 32-разрядного целого числа в строку с десятичным числом.
возможно вы узнаете много нового.
Здравствуйте, monax, Вы писали:
M>Теперь о собеседовании.
M>После такой беседы даю человеку карандаш с листиком или предлагаю доску с маркером (кому как нравится) и прошу написать мне функцию для переворота строки на php...
M>Потом рисую две таблицы на доске...
Имхо, годится.
M>После этих простых вопросов человек уже в теме и тогда меня начинает интересовать, способен ли человек разбивать задачу на мелкие подзадачи до того момента, как сядет писать код. Прошу его нарисовать мне структуру файлов/функий/классов, с помощью которых он бы реализовал систему управления контентом для этих двух таблиц. Т.е. хочу видеть, как он будет делать декомпозицию. Нескольких квадратиков с перечнем задач у каждого квадратика вполне достаточно, чтобы начать разговор и успешно его закончить через минут 10-20.
А вот тут не уверен. Все-таки навык более практический, приходящий с опытом. Хотя пример элементарный, может и сгодится, если строго не судить.
M>З.Ы. я был удивлён, как много людей не способны написать код для переворачивания строки.
Хехе, мне эту задачу задали на последнем этапе собеседования на вакансию сеньера с з/п далеко за сотню вечнозеленых Я для себя похожие выводы сделал, хотя сам этот алгоритм сочинял (если там есть, что сочинять) по ходу.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, monax, Вы писали:
M>>После такой беседы даю человеку карандаш с листиком или предлагаю доску с маркером (кому как нравится) и прошу написать мне функцию для переворота строки на php.
A>я надеюсь вы сами на себе этот тест проверили? — взяли лист бумаги и написали переворот строки A>(эксперимент не чистый, т.к. когда сам себя проверяешь — обстановка более спокойная)
Что там сложного, хоть на бумаге, хоть на доске? 5 строк кода, на php может еще меньше.
M>вариантов может быть много и не факт, что мой — лучший. когда искал прошлой зимой человека в группу, то увидел несколько новых для себя решений. а давать человеку сразу задание написать код, не поговорив — вот это уже невежливо и неадекватно. ну вот если непредвзято посмотреть, то собеседование — это не только выбор сотрудника с моей стороны, но и выбор работодателя с его стороны. если я начну сразу человека гонять вопросами, не объяснив, что он будет делать, зачем и для кого, а также сколько он будет получать за это, то я его вполне пойму, если он встанет и уйдёт сразу же. к тому же общий разговор в начале знакомства как раз помогает кандидату освоиться и не сильно теряться из-за стресса.
Какой лучший — это вопрос, на который можно ответить только зная Вашу ситуацию, поэтому отвечать на него придется Вам Все зависит от того кто Вам нужен, какова ситуация на рынке труда, как компания на нем позиционирована. Я не считаю что начало с тестов как-то оскорбительно, есть известные компании, чтобы только попасть на собеседования в которые нужно уже что-то написать/решить, а есть такие где интервью закончится сразу же если кандидат не знает чем занимается компания, в которую он пришел. Но, я думаю, с учетом российской специфики вводная болтовня должна быть, особенно если есть hr — логично начать именно с этого. Хотя, почитав сдешний форум, создается впечатление что разговор с симпатичной девушкой вводит многих как-минимум в ступор
Здравствуйте, Abalak, Вы писали:
M>>После этих простых вопросов человек уже в теме и тогда меня начинает интересовать, способен ли человек разбивать задачу на мелкие подзадачи до того момента, как сядет писать код. Прошу его нарисовать мне структуру файлов/функий/классов, с помощью которых он бы реализовал систему управления контентом для этих двух таблиц. Т.е. хочу видеть, как он будет делать декомпозицию. Нескольких квадратиков с перечнем задач у каждого квадратика вполне достаточно, чтобы начать разговор и успешно его закончить через минут 10-20.
A>А вот тут не уверен. Все-таки навык более практический, приходящий с опытом. Хотя пример элементарный, может и сгодится, если строго не судить.
А что тут судить? Это ж не вопрос из разряда "сколько будет 2+2", где ответ один. Тут может идти обмен мнениями, можно подискутировать по поводу разбиения на части, можно что-то ещё придумать. В общем, это просто тема для разговора, а не вопрос с однозначным ответом.
M>>З.Ы. я был удивлён, как много людей не способны написать код для переворачивания строки.
A>Хехе, мне эту задачу задали на последнем этапе собеседования на вакансию сеньера с з/п далеко за сотню вечнозеленых Я для себя похожие выводы сделал, хотя сам этот алгоритм сочинял (если там есть, что сочинять) по ходу.
Дык мне и не нужно, чтобы человек на зубок помнил самый лучший алгоритм (если такой вообще есть), мне нужно чтобы он написал маленький кусок кода, который перевернёт строку задом наперёд. Я тут уже три варианта переворота написал, которые бы зачёл.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, monax, Вы писали:
M>>После такой беседы даю человеку карандаш с листиком или предлагаю доску с маркером (кому как нравится) и прошу написать мне функцию для переворота строки на php.
A>я надеюсь вы сами на себе этот тест проверили? — взяли лист бумаги и написали переворот строки A>(эксперимент не чистый, т.к. когда сам себя проверяешь — обстановка более спокойная)
Именно, и не только в спокойной обстановке (я сам писал такой код на одном из собеседований). Ещё я попросил двух своих друзей программистов провести мне собеседование. Одно прошёл без проблем, во втором не ответил на один вопрос, где нужно было применять код Хемминга (но на работу меня бы всё равно взяли, потому что ход решения был правильный, не хватило одного шага для верного решения).
A>если не проверили — попробуйте решить аналогичную простую задачу, типа перевод 32-разрядного целого числа в строку с десятичным числом. A>возможно вы узнаете много нового.
Не узнал В бытность студентом писал много курсовых на ассемблере на заказ. Там почти в каждом была подзадача, где нужно было что-то куда-то переводить. Ну и перевод десятичного в двоичный сложнее, чем двоичного в десятичный, потому что тут достаточно посчитать степени двойки и сложить.
Здравствуйте, shrecher, Вы писали:
AD>>А как часто вы это используете в жизни? S>Это простое и понятное алгоритмическое задание, которе должен уметь решать любой программист.
std::string::rbegin() работает гораздо быстрее.
S>Это сложнее, на доске не написать.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, monax, Вы писали:
M>>З.Ы. я был удивлён, как много людей не способны написать код для переворачивания строки.
KP>Ты ща еще больше удивишься, когда набежит куча народу и расскажет тебе что давать задание на переворачивание строки на собеседовании это просто жуткое ущемление прав кандидата, а ты в собеседованиях вообще нихрена не понимаешь.
IMHO лучше попросить написать код, меняющий порядок слов в строке, а то переворот строки, это как-то уж совсем..
Причем я бы даже код не спрашивал, а просто сказать какой будет алгоритм.
Подход хороший. Но я всё таки против бумажки и карандаша. Ноутбук или десктоп предпочтительнее. Надо еще учесть что новое поколение специалистов от карандашей уже отвыкает. Объективно на столах специалистов начинающих сейчас карьеру очень мало блокнотиков-бумажек. У людей с большим опытом весь стол завален листочками с неведомыми набросками, кусками диаграмм и прочим.
Здравствуйте, shrecher, Вы писали:
S>Это простое и понятное алгоритмическое задание, которе должен уметь решать любой программист.
вот с должен только не надо — я знаю кучу проектов где ни со строками (менять), ни с масивами (в чистом виде) работать не надо.
я понимаю что это чисто алгоритмическое задание, но т.к. автор пишет что далеко не все справляются — я предпологаю что люди просто нервничают и делают ошибки,
вот почему и предлагаю использовать более практичную задачу по разбиву на токены. Кстати, именно это меня спрашивали западные компании, которые, по утверждениям многих здесь находящихся, вообще не интересуются кодом, алгоритмами...
S>Это сложнее, на доске не написать.
не спорю. Хуже того, когда спрашивали меня — мне еще привели код, где она вызывается, т.е. ф-ция должна была работать уже в написаном коде.
Здравствуйте, gangof4, Вы писали:
G>Здравствуйте, kaa.python, Вы писали:
KP>>Здравствуйте, monax, Вы писали:
M>>>З.Ы. я был удивлён, как много людей не способны написать код для переворачивания строки.
KP>>Ты ща еще больше удивишься, когда набежит куча народу и расскажет тебе что давать задание на переворачивание строки на собеседовании это просто жуткое ущемление прав кандидата, а ты в собеседованиях вообще нихрена не понимаешь.
G>IMHO лучше попросить написать код, меняющий порядок слов в строке, а то переворот строки, это как-то уж совсем.. G>Причем я бы даже код не спрашивал, а просто сказать какой будет алгоритм.
Нужно было бы еще уточнить, как именно должен меняться порядок. А то можно и поменять два любых слова местами и все — готово.
Здравствуйте, elmal, Вы писали:
E>На практике человек ОЧЕНЬ редко пишет код на бумажке, это уже не актуально лет 20 минимум. Вот не привык он! Обленился, сейчас навык работы с перфокартами несколько потерял актуальность, очень жаль, что вы до сих пор с перфокартами работаете, пора б технику то обновить! Тем более, что обычно итерирование по строке через цикл на практике очень редко требуется, как результат, что там ставить — length() — 1 или length() хрен еще вспомнишь, так как 100 лет на практике не надо.
Если нужно продумать непростой код (алгоритмически, а не по синтаксису — пофиг на синтаксис и точные имена методов), то лучше бумажки ничего нет. Комп, ide, синтаксические проверки и прочая хрень очень сильно грузят мозг и отвлекают.
Относительно простой псевдокод можно набрать в комментариях и потом реализовывать, но комп все равно давит на мозг. Для чего-то реально мозгоемкого бумага (где написанное нельзя стереть и все исправления видны, так что писать приходится вдумчиво) и тихая обстановка рулят.
Комп и IDE — для спинномозговой рутины, особого участия мозга не требующей, когда уже все ясно и надо просто добить код до окончательного варианта и дописать всякую рутинную обвязку.
E>Он привык по быстрому написать на компе, написать тестик, прогнать тестик.
Что это за программисты с марса, которые с ходу берут и пишут тестик ? На более-менее сложный алгоритмический код толковый тестик пишется сильно труднее, чем сам код. Алгоритм бы с кодом сначала выписать.
Про рутинный код не говорю. Там и тесты проще писать, и думать особо не надо.
E>Много с SQL работать приходится? Даешь доступ к реальной базе, и просишь написать запрос, удовлетворяющий условию. Просишь модифицировать реальный запрос. Нужно html верстать? Даешь реальную html, и просишь его немного модифицировать, а также попросить сказать, как бы это сделать пооптимальнее, чтоб часть кода кешировалась, стили ьыли настраиваемые и тому подобное. Надо немного программировать? Напиши сам формочку на jscript, с удобными интерфейсами, и попроси кандидата устранить дубликаты, например. E>Ведь сделаешь если — времени меньше потратишь как своего, так и кандидата, да и больше информации о нем получишь.
Тупление в написании простых sql на бумаге коррелирует с туплением на любой сложной задачке. Мелкие синтаксические ошибки имеют меньшее значение, но способность их заметить тоже коррелирует. А вот точное название, например, функций sql коррелирует только с опытом работы на конкретной базе с данными функциями, принципиальной роли не играет.
Приходилось иметь дело с "реальными запросами" строчек в 30, которые оригинальные авторы уже не рисковали сильно переписывать. Детальный анализ, что там в конечном счете делается, проще всего провести в кресле за чашкой кофе с распечаткой, ручкой для пометок в руках, и еще листком бумаги для произвольных набросков. Ну, понятно (кто этим занимался), что срубить прирост производильности на пару десятичных порядков в таких случаях — обычное дело. IDE помогает мало, т.к. профайлер например намекнет на необходимость тех или иных индексов, а индексами такая шняга не решается. Нужен мозг. В ide он работает не лучше, чем на бумаге.
PS. Я отвечал с позиции senior-а. Для junior-а, действительно, на бумажке уметь писать необязательно — он еще не дорос. И алгоритмы оптимизировать не надо. Хорошо, если хоть реализует то, что уже разжевано.
Здравствуйте, kittown, Вы писали:
K>Если нужно продумать непростой код (алгоритмически, а не по синтаксису — пофиг на синтаксис и точные имена методов), то лучше бумажки ничего нет. Комп, ide, синтаксические проверки и прочая хрень очень сильно грузят мозг и отвлекают. K>PS. Я отвечал с позиции senior-а. Для junior-а, действительно, на бумажке уметь писать необязательно — он еще не дорос. И алгоритмы оптимизировать не надо. Хорошо, если хоть реализует то, что уже разжевано.
Я даже соглашусь, но:
1) Здесь на бумажке требовалось написать тривиальный, но рабочий код. Тривиальная ошибка вида выход за пределы массива, считалась критичной. Соответственно никакой потребности в бамажке нет. И далее, на практике на бумажке требуют не набросать алгоритм, а чаще всего требуется полная реализация. Некоторые орлы хотят еще ввод вывод элементов чтоб был, если ввод вывод не написал то это недочет;
2) Когда мне дают задачу, где на бумажке требуется набросать высокоуровневый алгоритм — у меня никакого неприятия нет, я только приветствую такие задания, особенно если они приближены к реальности. Я готов выполнять, и действительно, я скорее всего на практике возьму именно бумажку. Но когда требуют чтоб я на бумажке этот алгоритм реализовал в деталях, с вводом-выводом, и без ошибок — такие задания меня просто бесят.
Здравствуйте, monax, Вы писали:
M>После этих простых вопросов человек уже в теме и тогда меня начинает интересовать, способен ли человек разбивать задачу на мелкие подзадачи до того момента, как сядет писать код. Прошу его нарисовать мне структуру файлов/функий/классов, с помощью которых он бы реализовал систему управления контентом для этих двух таблиц. Т.е. хочу видеть, как он будет делать декомпозицию. Нескольких квадратиков с перечнем задач у каждого квадратика вполне достаточно, чтобы начать разговор и успешно его закончить через минут 10-20.
Человек без опыта реального программирования вполне может не уметь этого делать. С опытом тоже не факт, смотря где работал.
В принципе поддержу предыдущих ораторов в плане того, что бумажка очень неудобна. Возьмите ноутбук, настройте на нём окружение (апач, notepad++ с открытым php файлом, браузер с им же, чтобы смотреть результаты) и просите на нём делать задания. Не то, чтобы переворот строки было сложно написать на бумажке, но всё же полный цикл edit [compile] run проще. Да и интереснее наверное смотреть на кандидата в "боевых" условиях.
K>Если нужно продумать непростой код (алгоритмически, а не по синтаксису — пофиг на синтаксис и точные имена методов), то лучше бумажки ничего нет. Комп, ide, синтаксические проверки и прочая хрень очень сильно грузят мозг и отвлекают.
Только такой "непростой код" вообще не на языке программирования обычно выражен. А какими-нибудь схемами, диаграммами — в общем, псевдокодом.
Писать код на реальном языке программирования на бумажке неудобно и непривычно. Простой пример: я вот _вообще_ не помню, какие классы в Java работают с файлами (нутром чую, что должен быть класс File, у него какие-нибудь Input/Output Streams, и какие-нибудь форматтеры али ридеры). Я не помню точных названий классов и их методов (в основном потому, что никогда не надо было). Написать код на бумажке не смогу. А вот с IDE + google — легко, названия находятся за 5 минут. Методы — еще за 5 минут.
U>А интересно, как круче всего перевернуть строку? Ну просто ходить с конца и от начала и делать swap — то конечно просто. А вот SSE2 какой-то прикрутить, чтобы пожесточее перевернуть? Ну или можно на CUDA, распердолить потоков N / 2 где N — кол-во символов, каждый поток переворачивает свою пару, ггг
Я для себя похожие выводы сделал, хотя сам этот алгоритм сочинял (если там есть, что сочинять) по ходу.
Все зависит от того кто Вам нужен, какова ситуация на рынке труда, как компания на нем позиционирована. Я не считаю что начало с тестов как-то оскорбительно, есть известные компании, чтобы только попасть на собеседования в которые нужно уже что-то написать/решить, а есть такие где интервью закончится сразу же если кандидат не знает чем занимается компания, в которую он пришел. Но, я думаю, с учетом российской специфики вводная болтовня должна быть, особенно если есть hr — логично начать именно с этого. Хотя, почитав сдешний форум, создается впечатление что разговор с симпатичной девушкой вводит многих как-минимум в ступор 
И алгоритмы оптимизировать не надо. Хорошо, если хоть реализует то, что уже разжевано.
