Pull to refresh

Comments 233

Многие и более базовых вещей не знают. Чего стоят кандидаты при собеседовании на должность PHP программиста. Даже степени двойки простейшие не могут посчитать.
На память, честно, без подглядывания куда-либо: 2,4,8,16,32,64,128,256,1024,2048,4096,8192,16376(?),32768,65536, дальше не знаю…
да, позор мне. Банально пропустил…
Это не считается ошибкою, примерно как и «ой, ½ и ¼ позабыл…».
Считается. Представьте мне без него число 5 в двоичной системе. Или какую маску имеет нулевой бит?
Тогда и ноль надо.
Это в какой интересно степени?

P.S. КО подсказывает, что 20 = 1
0 это 2 в степени минус бесконечность, но это уже матан
UFO just landed and posted this here
Дык, несколько выше Mithgol c tronix286 считают эту степень лишней :)
Причем тут двоичная система и число пять, если человек попросил только степени двойки? Может ему для других целей а Вы сразу про бинарные исчисления и числа никоим образом не относящиеся к степени двойки.
прикольно, кто-то стал читать и проверять…
так по глазам же режет отсутствие 512, даже при беглом просмотре
Мне больше понравилось то, зачем ставить вопрос возле числа, если можно проверить разделив или умножив на 2 ближайшего известного соседа.

P.S: Ну а если меряться, то я их знаю все до 2^34 :)
Можно брать :)

На память если честно дальше 8192 уже так быстро не вспоминается, но примерное значение скажу сразу :)
Сложно посчитать? Оо Сложно считать становится где-то после 65536
Не все являются системщиками и имеют со степенями двойки постоянный секс, так что наизусть 65536 я обычно не помню, обычно последние 2 цифры как-то забываются.
Просто умножайте последнее число на два и будет вам счастье, не нужно быть системщиком
65535, между прочим

— блин, заминусуют, надо, наверное, написать, что это шутка… да не, ладно, не все, вроде, так плохо…
Хм, парсер съел тег.
2^16 = 65536
блин, смеетесь что ли? возьмите калькулятор и пересчитайте
Без пересчета, степень двойки после нулевой — всегда четное число.
Не обижайтесь на него. Товарищ работал в «большой компании из Редмонда». Видимо там проходят специальную подготовку.
жесть. вот бывают же люди, поражаюсь просто.
попробуйте может для начала сами пересчитать? ;)
а вы попробуйте подумать
хотя, если быть уверенным, что все вокруг тупые, то конечно, какие вопросы.
Простите, а вы действительно не понимаете разницы между максимально возможным представимым беззнаковым числом и соответствующей степенью двойки?
да все уже, уже даже не смешно. сходите по карме потопчитесь.
Блин, смеётесь что ли? Как степень двойки может быть нечётным числом? Выкиньте свой калькулятор в мусорный бак.
Нулевая степень любого числа равна единице, единица без остатка на два не делится.

Ваш К.О.
А если взять отрицательную или дробную степень — то вообще караул будет.
Я просто здесь это оставлю как памятку того что перед тем как что-то сказать, что можно элементарно проверить, проверьте:
Piccy.info - Free Image Hosting
я даже не буду говорить «фотошоп». Слушайте, мне все уже который день понятно.
Теги не нужны, есть юникод.

2¹⁶ = 65536
Отлично выкрутился, респект!
Можно брать человека который по памяти написал в одном ряду 8192 и 16376?) Положился на память и не смутился тем фактом что 2 после умножения на 2 дало 6, а 6 дало 8.
Значения до 1024 помнят практически все, а до 65536 помнят бывшие обладатели компьютеров с соответствующим количеством памяти :)
Это когда еще биос, бывало, пересчитывал её при загрузке по три раза.
Я помню 16777216, это 224, легко запоминается и ровно столько оттенков отображает большинство современных мониторов.
TFT_LCD: Also, most TN panels represent colors using only 6 bits per RGB color, or 18 bit in total, and are unable to display the 16.7 million color shades (24-bit truecolor) that are available from graphics cards.
Что, в переводе на великий и могучий, примерно звучит как «большинство TN матриц представляет цвета, используя только 6 бит на компонент RGB, то есть всего 18 бит, и неспособны отобразить 16,7 миллионов оттенков цвета (24бит), которые доступны с видеоадаптера».
Добрые маркетологи как всегда обманывают неискушённых пользователей.
я вот наизусть помню 4096, 65536 и 262144 и 16777216, потому что раньше увлекался мобильниками, сводки там всякие читал, а там всегда пишут количество цветов дисплея :)
Или с видеокартой на мегабайт памяти, которая умела 800*600*16b. 65536 цветов, ага.

Впрочем, у мобильников тоже одно время это было очень популярное число возможных цветов у экрана.
Ну имелось ввиду что с этим человеком можно разговаривать. Если на такой простой вопрос не могут ответить — собеседование можно сразу закончить.
Между 8192 и 32768 последняя цифра ну никак не 6 =)
Простите, не обновил перед отправкой.
UFO just landed and posted this here
UFO just landed and posted this here
Только если один модуль установлен :) Или одинаковые. У меня были артефакты типа 96(32+64), 192(128+64), 320(256+64), 768(256+512) мегабайт, они запоминанию степеней двойки слабо помогают.
UFO just landed and posted this here
Кстати это как раз одна из проблем — запомнить vs посчитать. Почему 16376 с вопросом? Конечно это неверно — удвойте 8192
Сила не в запоминании цифр, а в понимании того, как их получить.
это пожалуй самое разумное высказывание тут.
Уж если возник вопрос, можно было бы быстренько на два предыдущую находку умножить. Уже ж оно под рукой…
«Дальше не знаю» и «на память» это шутка такая, да? Пожалуйста, скажите, что это шутка.
Если шутка, то я её не понял. В чём она по-вашему?
Э, это че, степени двойки пост что-ли?
Я именно по этому (когда искал людей) никогда не давал сразу сложных задач. Сначала (для РНР-шников) что-то элементарное типа «вывести в браузер файл вверх-ногами» (сначала последняя строка, потом предпоследняя и.т.д.)
И уже только потом (если человек не врал что знаком с РНР) уже идём далее. (В том числе и выпытываем сумеет ли человек столкнувшись с незнакомой ситуацией «вырулить» или «нагуглить» решение.)
Э-э, простите, в смысле «посчитать»?
PHP не знаю, но считал бы оператором shl :)
Посчитать в уме, т.е. подумать и дать ответ.
Часто даже не понимают, что собственно от них хотят.
> Напишите на С функцию, переставляющую в обратном порядке элементы в односвязном списке.
Специальность «Прикладная математика», 2-й курс, лаба по АСД…
Правда писались они на паскале.
Впрочем, это пожалуй единственное, что я и смогу сделать из перечисленных пунктов…
Подумав с минуту пришло в голову — просто переворачивать ссылки, т.е. храним прошлую и будущую, в текущем ссылку на будущую меняем на прошлую, переходим по старой будущей вперед. Вроде линейная сложность получается.
Так это вы описали не для односвязного списка вроде…
Именно для односвязного. Прошлая — откуда пришли, а не та что внутри элемента.
Все, дошло. Долго соображаю, день был длинный.
Выглядеть так будет:
o->o->o->o->o->-o>o->o->-o>o->o->-o>o->o->-o
o<-o->o->o->o->-o>o->o->-o>o->o->-o>o->o->-o
o<-o<-o->o->o->-o>o->o->-o>o->o->-o>o->o->-o
o<-o<-o<-o->o->-o>o->o->-o>o->o->-o>o->o->-o
"<-o->" — не похоже на односвязный список.
o<-o<-o o->o->-o>o->o->-o>o->o->-o>o->o->-o
x->

так точнее.
(1)<-(2)<-(3) (4)->(5)…
x = (3)->

так точнее
Не придирайтесь :)

Вот так:

v
nil    o -> o -> o -> nil
       ^

       v
nil <- o    o -> o -> nil
            ^

            v
nil <- o <- o    o -> nil
                 ^

                 v
nil <- o <- o <- o    nil
                      ^
к пример десять элементов

0 1 2 3 4 5 6 7 8 9

9 8 7 6 5 4 3 2 1 0

Неужто сложно?

Конец в начало. Конец-1 в начало +1.

Ыы примеры кода на русском. Просто я вчера первый раз, по просьбу друга, ковырялся в конфигурации 1с, пытаясь исправить ошибку в функции :)
Это для односвязного. Представьте несколько клеток вряд, от каждой идёт стрелочка к следующей. Нужно развернуть стрелочки. Для этого достаточно хранить два элемента в односвязном списке. Почитайте реализацию nreverse в sbcl, например.
А потом ответившие на этот вопрос в реальных проектах так делают. Для списка из пяти элементов. В сто пятьдесят строк. Вместо того, чтобы вызвать .reversed() :(. Из практики, наболело :)
Там 10-20 строк, откуда 150? :)
А вообще — иногда лениться полезно. Вот мне лень писать лишние 10-20 строк, и я пользую всякие .sort, .reverse, .contain :)
Так они же талантливы. Они еще умудряются показать свои скиллы работы с адресной арифметикой и ручным управлением памятью.
Не далее как в тяпницу мне на собеседовании дали порядка 10 задач, последней из которых была задача FizzBuzz. Я удивился, почему не первой…
Я бы по телефону не ответил — у меня ступор при собеседовании по телефону. «Самые основные вещи, которым его учили в университете» — хорошие у них университеты. На ответы на эти вопросы натыкался в редких ситуациях, залезая в дебри какой-нибудь разработки, не назвал бы их «основными вещами».
С fizzbuzz'ом согласен, со всем остальным с натяжкой — да, эти знания должны быть, но не они являются базой, основой.
С Ит образованием у них ситуация получше чем у нас, но насчет основных вещей автор, имхо, слегка утрирует- заметно ведь, что статья написано с долей юмора.
В универе (в нашем, по крайней мере) все это дают, так что можно считать основами.
В универе дают много всего, и только малую толику можно считать основой. Вот как сейчас помню — мне давали схему ЛЭ 2И-НЕ на КМОП. Полезно, надо знать, но частота использования и базисность таких знаний под большим вопросом.
Это еще что, у нас самые строгие экзамены были по БЖД и экологии :)
Прям на всех факультетах?
В этом топике речь о программистах. Вот и я только их имею в виду.
Присоединяюсь, понимание того, что тебя сейчас проверяют безумно давит и не дает мозгу нормально соображать. Уверен, что если посадить эти 20 человек в спокойной обстановке, то не 1, а больше половины легко справится с заданием.

Я конечно ни разу не был работодателем, возможно и ошибаюсь сейчас, но разве нельзя делать отсев просто требуя исходный код каких-то старых проектов? Несколько раз в жизни проходил собеседования и всегда если меня собирались на что-то там проверять, просто отказывался и проходил исключительно там, где у меня первым делом спрашивали код который я писал. Вот тут я рад, десяток программок, дорогой работодатель, выбирай любую. А вот разработчик без проектов за плечами — вот это действительно странно на мой взгляд. Это как в том же университете, обязательно найдется десяток людей с красными дипломами, превосходно знающих теорию (зачастую без понимания что и к чему), но не написавших ни строчки кода. Шаг влево, шаг вправо — пустота.

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

Даже не учитывая то, что авторство кода — исключительно на «честном слове» собеседуемого, всё равно остаётся тот простой факт, что совершенно неизвестно, сколько раз этот код правился и сколько в нём было багов изначально.
Окончательный код может выглядеть вполне прилично, но изначально в нём могли быть и разыменования нулевых указателей, и выходы за пределы массива, и целый букет прочих багов, которые были отловлены и вычищены после длинной череды сегфолтов и недельной отладки.
А при выполнении задания «здесь и сейчас» всё это моментально всплывёт.
Такой код сразу палится своей нелогичностью.
Он «палится» далеко не всегда.
Не было проверки указателя на null — добавили проверку. Не было проверки на границы массива — добавили проверку. Не было мьютексов — добавили мьютексы. В итоге результирующий код выглядит прилично и логично, а изначальный — полный ппц.
Ну так если он архитектурно при этом правильно, то ничего страшного. Куда страшнее корректный с точки зрения проверок, код, но абсолютно не расширяемый
Всё зависит от ситуации.
Если собеседовение на позицию девелопера (что говорит о тестовом задании «напиши код»), то вряд ли кого-то заинтересует, какую красивую архитектуру сможет забабахать соискатель — он всё равно этим заниматься не будет (по крайней мере в этой компании в ближайшие пару лет).
Поэтому если у парня офигенный потенциал как у архитекта, но код он пишет так себе, то в текущий проект его девелопером возьмут вряд ли, т.к. нужен а) именно девелопер, а не потенциальный архитект, и он нужен б) сейчас, а не через 2-3 года. Он нужен для того, чтобы прийти и писать код, а не набираться опыта и вырастать в офигенного специалиста.

Для набора опыта и вырастания в специалиста есть позиции джуниор-девелоперов, которых может себе позволить далеко не всякая компания, т.к. они на самом деле обходятся дороже, чем просто их [невысокая] зарплата: на присмотр за ними тратят время более опытные специалисты, на отлов их багов тратят время тестеры и так далее.
Кстати, что касается именно той задачки про двоичный поиск — её я написал с первого раза и ни в одном из «хитрых» случаев не запоролся ;)
А вот с разворотом списка накосячил. Правда, косяк обнаружил при контрольной проверке «на бумажке», без компиляции и запуска.
Ну не в этом же дело. Плюс, вы её написали без ошибок дома, с чайком, в уютной обстановке, на личном компьютере, любимой ОСи и любимой IDE

А представьте, во время собеседования, после стресс-тестирования, в шумном офисе, за компьютером секретарши в блокноте и интернет-экслорере.
>… дома, с чайком, в уютной обстановке, на личном компьютере, любимой ОСи и любимой IDE

На работе, без чая/кофе, посреди рабочего дня, на рабочем компьютере, в нелюбимой ОСи, ну разве что в любимом редакторе — и то хорошо :)
Вообще-то говоря, в большинстве случаев (опять-таки, в Штатах), формально говоря программист не имеет права показывать код, написанный им на работе кому бы то ни было постороннему. Это требование входит в документ, который сотрудник подписывает при поступлении на работу. Таким образом, требуя показать старые проекты, новый работодатель может поставить кандидата в странное положение.

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

Да и, к тому же, неизвестно, кто этот код на самом деле писал…
Мне как-то раз задали этот физбаз вопрос… Я ОЧЕНЬ ДОЛГО искал, в чем подвох. Очень долго не мог понять, почему с меня хотят какую-то херню, которую может написать ребенок? При этом проводящий собеседование на меня пристально пялился… вот так:

ʘ_ʘ

На фоне того, как все предыдущие конторы спрашивали, как работает стэк TCP/IP, просили написать парсер или решить задачу с комбинаторикой, такой вопрос реально звучит обескураживающе. Я теребил вопросами: «Может вам очень большие N нужны и оптимизация?», «Вам нужно АОП тут показать?», «Что, просто вот так вот в консоль вывести?», «Может форматирование какое?». На все вопросы был ответ: «Нууу… пишите как думаете… ʘ_ʘ»

Позиция была Flash-developer, кстати… Ну то есть, вы понимаете, всеобщую нахлынувшего неадеквата.
Забавно, именно на подобном вопросе про список я (предположительно) окончательно срезался на собеседовании в гугл (потратил на задачу более получаса).

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

Т.е. в этом есть определенное лукавство — это не поиск сильных программистов, это поиск достаточно программистов достаточно дешево.

Но повторюсь — я тоже бы поступал бы так же.

Но все же есть у меня есть определенный когнитивный диссонанс. Есть вот так называемое «собеседование Баткина» — blog.gamedeff.com/?p=64

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

Вот такая вот дилемма.

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

такие специалисты часто начинают приходить на другие собеседования ;)
Мне интересно действительно ли так важно умение общаться с коллективом? Потому что когда я проходил собеседование, мне отказали именно по причине того, что я «и на русском не очень-то и разговорчивый, а на английском, если придётся, будет ещё сложнее», хотя на все вопросы ответил правильно.
Половина проблем решается в ходе неформальных бесед с коллегами. А общение [и общие ценности] — это ключ к построение эффективной команды.
Проводить собеседование на ИТ-специальность по телефону… По моему, всё таки стоит посадить человека за компьютер и попросить у него реализовать какие-то вещи, а специалист должен посмотреть на его работу, т.к очень многие не могут сказать такое по телефону…
Обычно собеседование по телефону проводится так, что у собеседника и собеседующего открыт расшаренный документ, например, google docs. Так что никаких проблем.
>>основной тест, отсеивающий 19 из 20 кандидатов еще на этапе телефонного собеседования
>>
>>Напишите на С функцию, переставляющую в обратном порядке элементы в односвязном списке.

Да, писать на С в уме, «на лету» диктуя код в телефон — это то еще развлечение…
UFO just landed and posted this here
Ну думаю это в тестовом задании, до соебедования по телефону.
Добавил небольшой апдейт в пост.

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

Впрочем, «пишу на С в уме» — чем не строчка для резюме? :)
Мозжечок совместим с x86, чего уж там.
Надо шипеть со скоростью 300 бит/c. Каждый настоящий программист может прошипеть на 300 бит/c, хороший программист — сможет на 2400.
А настоящий хакер может свистнуть в трубку так, что факс/модемный пул сгорит.
У меня знакомый, когда в очередной раз меняет работу, ходит на 10-20 собеседований подряд. От собеседования к собеседованию вопросы пересекаются и к двадцатому он знает ответы на все из них и с наглой улыбкой требует высокую зарплату. И что вы думаете, дают!
А потом знакомый «в очередной раз меняет работу» =)
Вот вот. Помнится ходила фраза навроде «человек, имеющий мастерски составленное резюме — специалист по устройству на работу».
а потом пинка под зад после испытательного и в ходе оного :)
Уволить человека знающего ТК не так просто, если только он не инсайдер, не явный вредитель, прогульщик и прочее.
Я видел уже эту статью, но почему то не могу поиском найти на хабре.
Незнаю эффективности таких задач на собеседовании… Очень часто сталкивался с тем что очень хороших специалистов пропускают мимо, а ребята банально теряются в задачах этих, так как «университетов» не заканчивали. А ставишь им задачу на решение, даешь необходимое (реальное) время, и они задачу выполняют. Часто глупо держать все решения в голове, если ты с ними не сталкиваешься в реальности в проектах. На юрфаке нам было дано на первом курсе хорошее напутствие:

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

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

отсюда вытекает и другая вещь — часто мне на собеседовании в средние и крупные организации предлагали обучение всей специфике работы на прямо на испытательном сроке.
пришел я на собеседование на телевидение. меня спросили — сервер можешь? могу. берем.
дальше, местные сисадмины уже показали и объяснили тонкости организации всей компьютерной сети телевидения, а инженера научили пользоваться телеоборудованием, потому что всё взаимосвязано. на всё про всё ушло отсилы две недели. никто ничего не потерял.

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

так что, уважаемые hr, опуститесь на землю. талант многих людей раскрывается грамотным подходом и хорошим стимулированием.
Согласитесь, программист должен знать ответ на вопрос 2^7 :)
Нет, он должен знать как получить ответ на этот вопрос.
Я думаю, что вы тока что очень сильно промахнулись.
Сколько 2^7 знает любой, кто имеет базовые знания по компъюторным наукам. Потому что в базовом курсе обязательно идет булева алгебра, конвертирование из одной системы исчисления в другую (а эта операция, между прочим, происходит с применением степеней двойки).
Если вам дали калькуляторы и попросили на них сделать перевод из одной системы в другую — я вам сочуствую, выкиньте документ об образовании в мусорник.
Даже сетевикам нужны эти знания, потому что с помощью степеней двойки производятся преобразования IP'ников в бинарный формат и высчитываются подсети, диапазоны, вхождение IP в подсеть.
Да хотя бы те же условия — булева алгебра, опять же основа основ.

Всё это — базовые вещи, которые необходимы вообще для понимания того, что вы делаете. Если этих базовых знаний нет — значит это просто тренированная обезъянка, которая умеет повторять то что знает в нужных комбинациях.
Да, я знаю что люди работают без профильного образования и частенько даже лучше чем те, кто с профильным. И знаете, все они эти базовые знания получали. Просто не в университете, а из книг, интернета, от коллег и прочих источников. Я с такими работал. Для них и 2^7 не вопрос, а так, разминка.

P.S. Я согласен с мнением, что если клепать чисто сайтики на CMS, можно обойтись и без этого. Но это и не программисты, а кодеры. Там знаний особо не нужно — заучил и вперёд клепать. Работа программиста — это другой круг задачь, требующий гораздо больше знаний, чем есть у кодера.
Я не пойму, какое отношение имеет «знает» к «умеет посчитать» и «может найти решение», всё перечисление это знания которые приводят к результату, а 2^7 всего лишь частный случай, который легко рассчитывается и без калькулятора.
на собеседовании никто никому ничего не должен :)

мне, например несложно в уме это подсчитать. но есть люди, кому это сделать тяжело. однако они с лёгкостью могут написать, к примеру, интерфейс управления космическим кораблём, подглядывая по мере надобности в калькулятор за ответом 2^7.

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

в программировании главное — это свой логический подход для достижения цели! и нет единого шаблона для измерения крутости яиц программиста.
А ^ это операция возведения в степень или бинарный xor? :)
Возведение в степень. Это же не код :)
У меня на мех-мате ситуация была аналогичной:
теория и практика давалась не для того чтобы освоить все классы задач, а чтобы научить людей МЫСЛИТЬ.
Да, есть определенный набор знаний, находящийся в «оперативной памяти» (у каждого своего объема;-)), но не более того. Иначе, простите, за 20 лет в ИТ у меня бы уже было «переполнение», со стольки разными технологиями приходилось сталкиваться и работать с ними.
Что касается собеседований — то не нужно общаться по вашей теме (у многих это повод для поднятия самооценки — это понятно), нужно говорить о задачах и проектах в которых участвовал соискатель, понять его роль, способность к работе, мотивации и т.д.
«Экзамен» по вашей теме тоже возможен, но человек должен в теме какое то время «повариться», т.е. это или через неделю-две испытательного срока, либо же, если уж очень хочется посмотреть на «реальные» знания — давайте задачу на дом — по решению которой человек и сам сможет понять — хочет он к вам или нет (решать такие задачи).
Я думаю, что эта статья увеличила число запросов по ключевым словам в вопросах. Особенно starvation :)
Если кто что найдет интересного, от ссылки кидайте в комментарии.
starvation — недостаток ресурсов, я так понял.
Нет.
«Голодание (starvation) — задержка времени от пробуждения потока до его вызова на процессор, в течение которой он находится в списке потоков, готовых к исполнению. Возникает по причине присутствия потоков с большими или равными приоритетами, которые исполняются все это время.»

с википедии
Телефонное объснение переставление односвязного списка:
1. Вводим три переменные: Предыдущий узел, Текущий узел, Следующий узел. Со старта Предыдущий = null, Текущий = первый элемент списка, Следующий = Текущий->next.
2. Текущий->next = Предыдущий.
3. Предыдущий = Текущий
4. Текущий = Следущий
5. Следующий = Следующий->next.
6. Пока Следующий есть — переход к пункту 2.

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

И та и другая многозадачность до сих пор используется, как-то же их отличать надо. У нас, в России, принято использовать русские слова, при возможности.

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

В процессе перевода я очень порадовался тому, что именно для этих двух терминов есть более-менее устоявшиеся русские аналоги (я, по крайней мере, видел их в учебниках).

А Read-write lock и starvation по-русски вообще никак не называются.
Для меня канцелярит, потому что в выражение въезжал секунд 5. «Сooperative and preemptive multitasking» еще хуже. А вот read-write lock и на английском сразу понятно.
Не вполне вас понял.

Если человек всегда читал только англоязычные книги и статьи, и никогда не встречал русского термина для какого-либо понятия — тогда такие претензии обоснованы.

Но чем вам не угодил оригинальный термин «cooperative/preemptive multitasking»? Он же абсолютно общеупотребительный.
Ок, можно считать, что я просто представляю тех самых 19 из 20 соискателей. Должен же хоть кто-то ими быть
starvation = голодание (потоков) — вроде, в старом Рихтере видел
Могу представить, как рвут на себе волосы переводчики таких книг:)
Это ничто по сравнению с тем, как рвут на себе волосы их читатели, пытающие достучаться до истинного смысла.
С одной стороны, проблема есть, с другой стороны ХРы способны предварительно отсеивать большинство таких кадров до технического собеседования. А так, ну что вы хотите, без такого просева подавляющее большинство неспособно цикл написать по коллекции нормально. У нас просто схожая проблема, даже очень сильный сеньор жаба девелопер, в среднем, как правило, очень сильно плавает в мультитрединге. Тех, кто освоил хотя бы базовые концепции очень небольшой процент, хотя дело то не хитрое. Видимо, на практике не очень просто востребованный навык.
>> Видимо, на практике не очень просто востребованный навык.
Согласен, серьезным сеньором-помидором себя не считаю, но за 5 лет разработки на JavaEE писать какой-то более-менее серьезный мультитрединг (серьезнее отправки письма в отдельном потоке) не приходилось.
На скорую руку написал решение, правда не на чистом Си, а на С++ всё-таки.

  1. struct CNode
  2. {
  3.     CNode(int value = 0): m_value(value), m_pNextNode(0) { }
  4.  
  5.     int m_value;
  6.     CNode *m_pNextNode;
  7. };
  8.  
  9. // Returns new head.
  10. CNode* reverseList(CNode *pHead)
  11. {
  12.     if (!pHead->m_pNextNode)
  13.         return pHead;
  14.  
  15.     CNode *pCurrentNode = pHead;
  16.     CNode *pNextNode = 0;
  17.     CNode *pPrevNode = 0;
  18.     do 
  19.     {
  20.         pNextNode = pCurrentNode->m_pNextNode;
  21.         pCurrentNode->m_pNextNode = pPrevNode;
  22.  
  23.         pPrevNode = pCurrentNode;
  24.         pCurrentNode = pNextNode;
  25.     } while (pNextNode);
  26.  
  27.     return pPrevNode;
  28. }
А если список пустой? То есть nil на входе? ;)
То будет access violation, память не может быть read :).
Лиспы, и всё от них выросшее. Ruby, например.
Смоллтокеры негодуют :)
Objective-C, там обе константы определены, и nil, и NULL.
struct node* invert(struct node *nd)
{
    struct node *next = NULL;
    while (nd) {
        struct node *tmp = nd->next;
        nd->next = next;
        next = nd;
        nd = tmp;
    }

    return next;
}
А ничего, что исходный список будет разрушен?
Вообще, на собеседовании я бы уточнил, можно или нет разрушать. Но думаю, что имеется в виду именно inplace, иначе уж совсем просто.
Из sbcl:

(sb!xc:defmacro list-nreverse-macro (list)
  `(do ((1st (cdr ,list) (if (endp 1st) 1st (cdr 1st)))
        (2nd ,list 1st)
        (3rd '() 2nd))
       ((atom 2nd) 3rd)
     (rplacd 2nd 3rd)))

cdr — пропустить голову
endp — последний ли элемент?
atom — true, если аргумент — не список
rplacd — присвоить элементу новый указатель
www.lispworks.com/documentation/lw50/CLHS/Body/m_do_do.htm
Для интереса посмотрел исходник reverse в Clojure. Да, не эффективно, но чище некуда.

(defn reverse [coll]
(reduce conj () coll)

* в данном случае пустой список как аргумент для reduce — это начальное значение
Хм, я понял задание так:

struct CNode
{
    CNode(int value = 0, CNode* next = NULL): m_value(value), m_pNextNode(next) { }
 
    int m_value;
    CNode *m_pNextNode;
};
 
// Returns new head.
CNode* reverseList(CNode *input)
{ 
    CNode *output = NULL;

    while(input != NULL)
    {
        output = new CNode(input->m_value, output);
        input = input->m_pNextNode;
    }

    return output;
}


Сначала хотел написать рекурсивно, но подумал, что на C это неприлично
Второй вопрос: O(N+M), где M — исходная длина вектора

А вот остальные вопросы — увы, с многопоточностью не очень, разве что общие соображения рассказал бы.
Не-не. Если исходный вектор содержал 100000 элементов (M=100000), и добавляется N=10 элементов, то результирующая сложность будет порядка 100000.

Худший случай — когда элементы вставляются в начало вектора, тогда все 100000 старых элементов придётся сдвинуть.
Это неважно. О-большое сравнительная асимптотическая величина, линейные изменения на неё не влияют.
Так-так… Упорствуем? Что такое O-большое я знаю, но тут нет линейной зависимости.

M никак не связано с N, а значит им нельзя тут пренебречь, сказав, что O(M + N) = O(N)

Поясню на конкретном примере. Если N = 1 (вставляем один элемент), то, руководствуясь вашей логикой, можно было бы сказать, что время добавления одного элемента в вектор O(1), то есть константно.

Между тем (помним, что вопрос был про максимальное время) ответом будет O(M)
О чем вы говорите? Не указано же, N элементов вставляются одним блоком или по отдельности. Не известен язык, так что непонятно, стандартный вектор умеет вставлять только по одному или блоками. Обычно, врде, по одному.

Не указано, какой стратегии реаллокации придерживается реализация вектора — может тупо реаллоцировать k+1, может k*2, может фибоначчи, может степени двойки.
Язык известен («или как там в вашем любимом языке называется динамический массив»), возьмём в качестве «любимого языка» C++, тогда динамическим массивом будет std::vector. Для него гарантируется амортизированное время вставки O(N + M) для вставки множества элементов.

Конечно можно использовать вектор неэффективно и вставлять элементы по одному, но в таком случае можно написать и «for(;;)» в качестве кода для вставки и сказать, что время работы бесконечно.
Суть задания в том, чтобы не создавать новый список, а чтобы переставить элементы уже имеющегося. Пока думал над решениями задачи проскочило еще парочку вариантов, но они более требовательны по памяти и медленней по скорости:
1) Менять местами соседние эл-ты списка, что-то по типу пузырьковой сортировки. Сложность, как ни трудно догадаться O(n^2)
2) Пройтись по списку, сохранив все указатели в вектор/массив и потом снова проходясь по списку уже через вектор/массив просто подставить созраненные значения.
А, ну если не создавать новый, то вот вариант проще и универсальнее вашего. Хотя и там я бы переменные попереименовывал.
Ну я ж говорю, что набросал на скорую руку, универсальности решения я не стемился добиться. Если передо мной стояла такая задача, то был бы совсем другой подход, и, возможно решение. Да и вообще для таких задач в плюсах есть std::list и std::reverse :).
std::list двусвязный, а std::reverse не работает с std::list
Хм, не знал этих тонкостей, спасибо.
gcc умеет хвостовую рекурсию.
Программа, которая при *отключении* оптимизаций перестаёт работать, обычно корректной не считается.
да я бы язык, который не умеет гарантированно хвостовую рекурсию, тоже б за язык не считал.
Согласен, что уровень программистов падает, но не всегда можно оценить человека за короткий промежуток времени. Помню читал на stackoverflow тему, где один из местных гуру говорил, что не получается у него проявить себя на собеседованиях. Вот посадить его за компьютер и попросить найти какую-нибудь проблему в коде и он первый её найдёт и т.д. Рейтинг его тоже весьма внушительный там был, поэтому всё относительно, хотя стрессоустойчивость тоже весьма хорошее качество.
Ну, во-первых: телефонное собеседование (во всяком случае, сейчас в Штатах) НЕ ПОДРАЗУМЕВАЕТ никакого «веб-блокнота». Я и прошёл немало таких собеседований, и проводил их сам неоднократно, и всегда, если и просили написать какой-то код, то он был минимален, и я его диктовал по телефону. Как правило, речь шла о нескольких простых строчках. Впрочем, такого рода вопросы по телефону нечасты, да и я сам стараюсь их не задавать — это всегда можно спросить при личном собеседовании.

Я тоже в какой-то момент начал просить кандидатов на собеседовании написать простенький код, и тоже был поражен чудовищно низким процентом людей, которые способны это сделать. Я просил развернуть строку, добавить элемент в связный список и прочие тривиальные вещи. Многие кандидаты не могли даже написать удаление элемента из списка!

А вот вопросы, приводимые в статье, меня несколько изумили. Да, возможно, это вопросы из курса программирования, и каждый выпускник колледжа или университета должен их знать. Но уже через 5-6 лет работы эти понятия могут подзабыться, если программист занимается другими вещами. Хороший программист вспомнит всё быстро — но, возможно, не на собеседовании.

Ну, и последнее. Довольно забавно читать этот текст, исходящий из уст свежевыпущенных программистов, создавших крошечный стартап. Сколько апломба! Сколько самоуверенности! Сколько убежденности в том, что они точно знают, каковы должны быть НАСТОЯЩИЕ программисты!
>Но уже через 5-6 лет работы эти понятия могут подзабыться
В конкретном случае — нет, всё-таки они искали системных программистов, которые эти проблемы решают более-менее регулярно.
Согласен. Но в этом случае и писать им надо было, как мне кажется, по-другому. А то в их устах это звучит как общее требование к хорошим программистам…
Спасибо за комментарий по поводу применения веб-блокнотов. Возможно, чуть погорячился по поводу «применяется всегда».

Я ориентировался на рассказы знакомых, которые проходили телефонное собеседование в российский Гугл: в двух случаях ребятам предлагалось писать код, если я не ошибаюсь, в Google Docs.
Вообще идея, наверно, неплохая. Трудность в том, что зачастую соискатель будет вести разговор находясь не около компьютера с интернетом. Например, мне несколько раз приходилось вести разговор сидя на лавочке в сквере — была середина рабочего дня, не мог же я проходить интервью сидя на работе :)
И кстати, чего-чего они там пишут? И сколько для этого нужно людей? Два? А кого они набирают?
Неправы. Именно сейчас, и именно в США часто используются веб-блокноты во время телефонных интервью. Тот же Гугл создает документ в Google Docs, и расшаривает его с интервьюируемым незадолго до интервью
Хммм… Ну, давайте скажем так. Я живу в США. В течении последних трех лет я проходил собеседования примерно в 15 компаниях, начиная от того же Гугла, включая очень разные компании, от крупных банков до стартапов. Ни в одном месте мне не предложили использовать ни Гугл Докс, ни что бы то ни было подобное. Вполне возможно, что это новая идея Гугла, однако, как я уже сказал, для многих требование во время телефонного собеседования быть рядом с компьютером с доступом в сеть будет очень неудобно.

Скажите, а вот Вы своё утверждение основываете на личном опыте?
Именно на основании своего личного опыта
Хороший, годный работодатель. Иные сначала час мучают «логическими» задачками, а только потом снисходят до реального мира.
Ага, сушат мозги три часа, что бы доказать что вы идиот и можете претендовать только на пол-зарплаты. Потому что стартап маленький и на целую зарплату денег нет. А потом выясняется что, поскольку головой думать никто не умеет, все равно набрали десять человек, которые умеют списки инвертировать и википедию читать про примитивы синхронизации, вместо одного, который головой думать умеет.
«Как бы вы реализовали read-write lock?»

var Locker: TMultiReadExclusiveWriteSynchronizer;
Locker := TMultiReadExclusiveWriteSynchronizer.Create;

пойдет? ;-)
Хорошая реализация у Рихтера, насколько я помню была. Там использовалась глобальная переменная, работа с которой велась с помощью семейства Interlocked-функий, и два мютекса или критических секции.

Ну а вообще, да, с Висты, например, есть реализованные на уровне ОС read-write локи, да и практически в каждом хорошем фрейворке они уже тоже есть. Но суть изначального вопроса в понимании принципа реализации, никто не будет заставлять писать свои велосипеды, когда уже есть хорошие реализации (в некоторых фирмах за такое и по рукам бьют :)).
rwlock есть не с Висты (2006г.), а с pthread образца 1998 года. А скорее всего и ещё раньше.
Тем более, однако, насколько я помню, RWLock'и в винде являются user-mode объектами синхронизации, а это значит, что не происходит переходов в режим ядра, и соответсвенно, меньше затрат.
У нас как-то на должность старшего веб-разработчика (ASP.NET) взяли чувака: прошел собеседование на отлично (собеседовали полтора часа, задавали сложные и каверзные вопросы). Через два дня дали задачу, в которой надо было получить значения параметра в запросе, так он регулярку написал в экран для этого.
UFO just landed and posted this here
Может они просто интуитивно это понимают, но четко сформулировать не могут? Тоже имхо вполне распространенный фейл на собеседованиях.
Очень трудно интуитивно понимать, что «отношение» — это математический термин для «таблицы» =)
Строго говоря, не только таблицы, а любой структуры табличного вода :) Т.е. еще вьюшек, materialized views, подзапросов, и всего, к чему можно применить select, join.
В понедельник я собеседовал претендента на должность, не связанную с программированием. Тем не менее, в резюме значилось «знание C++», и я задал задачу: «Нужна программа, выводящая строку на экран. Не важно — какую, придумайте удобную Вам. Придумали? Ок, напишите хотя бы одну строку программы.»

Запаслись попкорном? Зря. Продолжения нет, рассказ кончился.
Это вы так описали «Hello, world», а претендент не сумел его изобразить? :) Интересно, в чём же заключалось тогда его «знание С++» %)

«Я знаю карате, айкидо, кун-фу, тэквондо, джиу-джитсу и много других страшных слов».
К сожалению, такие люди встречаются очень часто, и отнимают очень много времени. Не каждый по отдельности, а все вместе — их слишком много.
Я для себя уже выяснил, что половина претендентов под «опытом работы с оборудованием Cisco» подразумевает «втыкал патч-корд в свитч Cisco».
Я себя ловлю временами на том, чтобы написать еще что-нибудь в резюме… недавно в c Python в Ruby пришлось скрипт на пару сотен строк переписывать, зная оба очень поверхностно… скрипт-то работает, а вот в скиллы не запишешь — несерьезно слишком для полноценного знания платформы.
это в смысле пример втыкания патч-корда…
Я в таких случаях пишу: «Знание основ Python, Ruby»
Я бы переформулировал: «мой друг рассказывал, как его начальник втыкал патч-корд… в эту… ну, как её...»
Да их самих надо гнать, пожалуй. Всех. Написать функцию реверсирования не сложно, но гиморойно, потому что C не имеющий… в общем ничего не имеющий. По телефону? Отсеивают тех, кто не найдет за две минуты в гугле?

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

Окасаки-же и про персистентные структуры данных в многопоточных окружениях они, конечно же, не читали никогда.

Сложность вставки в середину массива? Вам надо вставлять в середину (а зачем вообще?), и вы выбрали массив? Вон из профессии. Дешевле завести список, вставить, потом из него сгенерировать массив, если уж прямо так надо. Про эту стоимость можно сказать только то, что она такая высокая, что спасибо, не надо.

RW-Lock и starvation? Ну опять началось, shared state и паттерны, что бы он работал, в многопоточном окружении. Пока вы играетесь со своим shared state, даже последние тормоза поймут, что его использовать по, возможности, нельзя.
Даже Intel пишет свой функцильный язык для параллельных / конкурентных
сред.

За многопоточность, значит, болеете? Давайте поговорим за многопоточность.
Почему, например, MySQL (да и все остальные) не умеет распараллеливать исполнение SQL запросов? Ведь идеальные же для этого, чистые функции.

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

А еще вы за асимптотическую сложность переживаете? А нука — какова
сложность вашего майскульного алгоритма выведения типов Ad-Hoc (вместо алгоритма W, сложность которого известна и корректность которого доказана).

Ну конечно — вы были слишком заняты, учились списки на си инвертировать.
Когда там читать что-то. Пирс? Кто такой Пирс?

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

Судя по вашему комментарию, у вас на собеседовании вопросы будут еще интереснее, и отсев кандидатов будет на порядок выше… или вы собираетесь учить людей, не знащих про существование rwlock, «правильному» многопоточному программированию?..

Вопросы, описанные в статье, очень примитивны, и любой программер их должен знать (server-side, по крайней мере, а GUI формочки можно и без этого лабать)
Смысл в том, что люди, особенно которые себя считают мега-разработчиками, склонны набирать людей, похожих на себя.

При этом даже если кандидат знает что-то, что собеседующий не знает — это, обычно серьезная проблема кандидата.

А набирать людей, похожих на себя — это кадровый инцест с последствиями, похожими на последствия инцеста in RL.
О! Замечательное выражение — «кадровый инцест»! Спасибо, порадовали!
Я поддерживаю джентльмена. Все правильно написал. ЧСВ автора стремится к облакам и успешно достигает.
Посыл статьи правильный. Тон выбран неверный. Не так давно мне довелось интервьюировать кандидата, который все уши прожужжал тем, что после принятия на работу в текущую компанию, не боится ничего — у них самые сложные собеседования. Его занесло настолько, что, в какой-то момент, он ляпнул, что не уверен, пройду ли я тест в их компании. Первым вопросом, который он провалил, было «объясните принцип работу древовидных структур». Далее было не лучше. Последний гвоздь в крышку гроба забил вопрос: расскажите о транзакциях, причинах появления, принципах функционирования, уровнях изоляций.

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

Посыл статьи, повторяю, вполне верный.
У же 7 лет работаю программистом на php и не разу мне не приходилось вычислять степени и тем более переставлять элементы в списке.
Степени вчера вычислял, причём в цикле :)
какова максимальная сложность вставки N элементов в vector

Тут любой даже поверхностно изучавший высшую математику человек должен не задумываясь сказать: «Ну конечно же бесконечность! Потому что сложность реализации любого алгоритма не ограничена сверху.»
Любой даже поверхностно изучавший высшую математику человек должен отличать максимум и супремум :)
С трудом, но нагуглил. Ваша информация устарела уже на 7 лет. Сейчас это 23.3.6.4
А с нами не поделитесь нагугленным?
ISO/IEC IS 14882 — Programming Languages — C++

§ 23.3.6.4 Vector modifiers

2. Complexity: The complexity is linear in the number of elements inserted plus the distance to the end of the vector.
Выделенный текст хорошо было бы сделать ссылками
Sign up to leave a comment.

Articles