Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 233
Многие и более базовых вещей не знают. Чего стоят кандидаты при собеседовании на должность PHP программиста. Даже степени двойки простейшие не могут посчитать.
На память, честно, без подглядывания куда-либо: 2,4,8,16,32,64,128,256,1024,2048,4096,8192,16376(?),32768,65536, дальше не знаю…
А 512?
да, позор мне. Банально пропустил…
ага, и 1 еще =)
Это не считается ошибкою, примерно как и «ой, ½ и ¼ позабыл…».
Считается. Представьте мне без него число 5 в двоичной системе. Или какую маску имеет нулевой бит?
прикольно, кто-то стал читать и проверять…
Можно брать :)
На память если честно дальше 8192 уже так быстро не вспоминается, но примерное значение скажу сразу :)
На память если честно дальше 8192 уже так быстро не вспоминается, но примерное значение скажу сразу :)
Сложно посчитать? Оо Сложно считать становится где-то после 65536
Не все являются системщиками и имеют со степенями двойки постоянный секс, так что наизусть 65536 я обычно не помню, обычно последние 2 цифры как-то забываются.
65535, между прочим
— блин, заминусуют, надо, наверное, написать, что это шутка… да не, ладно, не все, вроде, так плохо…
— блин, заминусуют, надо, наверное, написать, что это шутка… да не, ладно, не все, вроде, так плохо…
216 = 65536
Хм, парсер съел тег.
2^16 = 65536
2^16 = 65536
блин, смеетесь что ли? возьмите калькулятор и пересчитайте
Без пересчета, степень двойки после нулевой — всегда четное число.
Не обижайтесь на него. Товарищ работал в «большой компании из Редмонда». Видимо там проходят специальную подготовку.
Блин, смеётесь что ли? Как степень двойки может быть нечётным числом? Выкиньте свой калькулятор в мусорный бак.
Я просто здесь это оставлю как памятку того что перед тем как что-то сказать, что можно элементарно проверить, проверьте:
Теги не нужны, есть юникод.
2¹⁶ = 65536
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бит), которые доступны с видеоадаптера».
Добрые маркетологи как всегда обманывают неискушённых пользователей.
Что, в переводе на великий и могучий, примерно звучит как «большинство TN матриц представляет цвета, используя только 6 бит на компонент RGB, то есть всего 18 бит, и неспособны отобразить 16,7 миллионов оттенков цвета (24бит), которые доступны с видеоадаптера».
Добрые маркетологи как всегда обманывают неискушённых пользователей.
я вот наизусть помню 4096, 65536 и 262144 и 16777216, потому что раньше увлекался мобильниками, сводки там всякие читал, а там всегда пишут количество цветов дисплея :)
Или с видеокартой на мегабайт памяти, которая умела 800*600*16b. 65536 цветов, ага.
Впрочем, у мобильников тоже одно время это было очень популярное число возможных цветов у экрана.
Впрочем, у мобильников тоже одно время это было очень популярное число возможных цветов у экрана.
Ну имелось ввиду что с этим человеком можно разговаривать. Если на такой простой вопрос не могут ответить — собеседование можно сразу закончить.
16384 :)
Между 8192 и 32768 последняя цифра ну никак не 6 =)
Кстати это как раз одна из проблем — запомнить vs посчитать. Почему 16376 с вопросом? Конечно это неверно — удвойте 8192
Сила не в запоминании цифр, а в понимании того, как их получить.
Уж если возник вопрос, можно было бы быстренько на два предыдущую находку умножить. Уже ж оно под рукой…
512, 16384
«Дальше не знаю» и «на память» это шутка такая, да? Пожалуйста, скажите, что это шутка.
Э, это че, степени двойки пост что-ли?
Я именно по этому (когда искал людей) никогда не давал сразу сложных задач. Сначала (для РНР-шников) что-то элементарное типа «вывести в браузер файл вверх-ногами» (сначала последняя строка, потом предпоследняя и.т.д.)
И уже только потом (если человек не врал что знаком с РНР) уже идём далее. (В том числе и выпытываем сумеет ли человек столкнувшись с незнакомой ситуацией «вырулить» или «нагуглить» решение.)
И уже только потом (если человек не врал что знаком с РНР) уже идём далее. (В том числе и выпытываем сумеет ли человек столкнувшись с незнакомой ситуацией «вырулить» или «нагуглить» решение.)
Э-э, простите, в смысле «посчитать»?
PHP не знаю, но считал бы оператором shl :)
PHP не знаю, но считал бы оператором shl :)
> Напишите на С функцию, переставляющую в обратном порядке элементы в односвязном списке.
Специальность «Прикладная математика», 2-й курс, лаба по АСД…
Правда писались они на паскале.
Специальность «Прикладная математика», 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<-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->
так точнее.
x->
так точнее.
Не придирайтесь :)
Вот так:
Вот так:
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с, пытаясь исправить ошибку в функции :)
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 задач, последней из которых была задача FizzBuzz. Я удивился, почему не первой…
Я бы по телефону не ответил — у меня ступор при собеседовании по телефону. «Самые основные вещи, которым его учили в университете» — хорошие у них университеты. На ответы на эти вопросы натыкался в редких ситуациях, залезая в дебри какой-нибудь разработки, не назвал бы их «основными вещами».
С fizzbuzz'ом согласен, со всем остальным с натяжкой — да, эти знания должны быть, но не они являются базой, основой.
С fizzbuzz'ом согласен, со всем остальным с натяжкой — да, эти знания должны быть, но не они являются базой, основой.
С Ит образованием у них ситуация получше чем у нас, но насчет основных вещей автор, имхо, слегка утрирует- заметно ведь, что статья написано с долей юмора.
В универе (в нашем, по крайней мере) все это дают, так что можно считать основами.
Присоединяюсь, понимание того, что тебя сейчас проверяют безумно давит и не дает мозгу нормально соображать. Уверен, что если посадить эти 20 человек в спокойной обстановке, то не 1, а больше половины легко справится с заданием.
Я конечно ни разу не был работодателем, возможно и ошибаюсь сейчас, но разве нельзя делать отсев просто требуя исходный код каких-то старых проектов? Несколько раз в жизни проходил собеседования и всегда если меня собирались на что-то там проверять, просто отказывался и проходил исключительно там, где у меня первым делом спрашивали код который я писал. Вот тут я рад, десяток программок, дорогой работодатель, выбирай любую. А вот разработчик без проектов за плечами — вот это действительно странно на мой взгляд. Это как в том же университете, обязательно найдется десяток людей с красными дипломами, превосходно знающих теорию (зачастую без понимания что и к чему), но не написавших ни строчки кода. Шаг влево, шаг вправо — пустота.
Вообще подобные собеседования, это же как гвозди забивать, пока один — нормально все идет, а как подойдет кто смотреть, так как на зло, что ни удар, так по пальцу.
Я конечно ни разу не был работодателем, возможно и ошибаюсь сейчас, но разве нельзя делать отсев просто требуя исходный код каких-то старых проектов? Несколько раз в жизни проходил собеседования и всегда если меня собирались на что-то там проверять, просто отказывался и проходил исключительно там, где у меня первым делом спрашивали код который я писал. Вот тут я рад, десяток программок, дорогой работодатель, выбирай любую. А вот разработчик без проектов за плечами — вот это действительно странно на мой взгляд. Это как в том же университете, обязательно найдется десяток людей с красными дипломами, превосходно знающих теорию (зачастую без понимания что и к чему), но не написавших ни строчки кода. Шаг влево, шаг вправо — пустота.
Вообще подобные собеседования, это же как гвозди забивать, пока один — нормально все идет, а как подойдет кто смотреть, так как на зло, что ни удар, так по пальцу.
>… разве нельзя делать отсев просто требуя исходный код каких-то старых проектов?
Даже не учитывая то, что авторство кода — исключительно на «честном слове» собеседуемого, всё равно остаётся тот простой факт, что совершенно неизвестно, сколько раз этот код правился и сколько в нём было багов изначально.
Окончательный код может выглядеть вполне прилично, но изначально в нём могли быть и разыменования нулевых указателей, и выходы за пределы массива, и целый букет прочих багов, которые были отловлены и вычищены после длинной череды сегфолтов и недельной отладки.
А при выполнении задания «здесь и сейчас» всё это моментально всплывёт.
Даже не учитывая то, что авторство кода — исключительно на «честном слове» собеседуемого, всё равно остаётся тот простой факт, что совершенно неизвестно, сколько раз этот код правился и сколько в нём было багов изначально.
Окончательный код может выглядеть вполне прилично, но изначально в нём могли быть и разыменования нулевых указателей, и выходы за пределы массива, и целый букет прочих багов, которые были отловлены и вычищены после длинной череды сегфолтов и недельной отладки.
А при выполнении задания «здесь и сейчас» всё это моментально всплывёт.
Такой код сразу палится своей нелогичностью.
Он «палится» далеко не всегда.
Не было проверки указателя на null — добавили проверку. Не было проверки на границы массива — добавили проверку. Не было мьютексов — добавили мьютексы. В итоге результирующий код выглядит прилично и логично, а изначальный — полный ппц.
Не было проверки указателя на null — добавили проверку. Не было проверки на границы массива — добавили проверку. Не было мьютексов — добавили мьютексы. В итоге результирующий код выглядит прилично и логично, а изначальный — полный ппц.
Ну так если он архитектурно при этом правильно, то ничего страшного. Куда страшнее корректный с точки зрения проверок, код, но абсолютно не расширяемый
Всё зависит от ситуации.
Если собеседовение на позицию девелопера (что говорит о тестовом задании «напиши код»), то вряд ли кого-то заинтересует, какую красивую архитектуру сможет забабахать соискатель — он всё равно этим заниматься не будет (по крайней мере в этой компании в ближайшие пару лет).
Поэтому если у парня офигенный потенциал как у архитекта, но код он пишет так себе, то в текущий проект его девелопером возьмут вряд ли, т.к. нужен а) именно девелопер, а не потенциальный архитект, и он нужен б) сейчас, а не через 2-3 года. Он нужен для того, чтобы прийти и писать код, а не набираться опыта и вырастать в офигенного специалиста.
Для набора опыта и вырастания в специалиста есть позиции джуниор-девелоперов, которых может себе позволить далеко не всякая компания, т.к. они на самом деле обходятся дороже, чем просто их [невысокая] зарплата: на присмотр за ними тратят время более опытные специалисты, на отлов их багов тратят время тестеры и так далее.
Если собеседовение на позицию девелопера (что говорит о тестовом задании «напиши код»), то вряд ли кого-то заинтересует, какую красивую архитектуру сможет забабахать соискатель — он всё равно этим заниматься не будет (по крайней мере в этой компании в ближайшие пару лет).
Поэтому если у парня офигенный потенциал как у архитекта, но код он пишет так себе, то в текущий проект его девелопером возьмут вряд ли, т.к. нужен а) именно девелопер, а не потенциальный архитект, и он нужен б) сейчас, а не через 2-3 года. Он нужен для того, чтобы прийти и писать код, а не набираться опыта и вырастать в офигенного специалиста.
Для набора опыта и вырастания в специалиста есть позиции джуниор-девелоперов, которых может себе позволить далеко не всякая компания, т.к. они на самом деле обходятся дороже, чем просто их [невысокая] зарплата: на присмотр за ними тратят время более опытные специалисты, на отлов их багов тратят время тестеры и так далее.
Весь код так и пишется =) И если на собеседовании зададут двоичный поиск написать — тоже сразу фейл будет. ;)
Кстати, что касается именно той задачки про двоичный поиск — её я написал с первого раза и ни в одном из «хитрых» случаев не запоролся ;)
А вот с разворотом списка накосячил. Правда, косяк обнаружил при контрольной проверке «на бумажке», без компиляции и запуска.
А вот с разворотом списка накосячил. Правда, косяк обнаружил при контрольной проверке «на бумажке», без компиляции и запуска.
Вообще-то говоря, в большинстве случаев (опять-таки, в Штатах), формально говоря программист не имеет права показывать код, написанный им на работе кому бы то ни было постороннему. Это требование входит в документ, который сотрудник подписывает при поступлении на работу. Таким образом, требуя показать старые проекты, новый работодатель может поставить кандидата в странное положение.
Конечно, всегда остаются личные проекты. Но у меня в них зачастую код в таком виде, что показывать его нет желания.
Да и, к тому же, неизвестно, кто этот код на самом деле писал…
Конечно, всегда остаются личные проекты. Но у меня в них зачастую код в таком виде, что показывать его нет желания.
Да и, к тому же, неизвестно, кто этот код на самом деле писал…
Мне как-то раз задали этот физбаз вопрос… Я ОЧЕНЬ ДОЛГО искал, в чем подвох. Очень долго не мог понять, почему с меня хотят какую-то херню, которую может написать ребенок? При этом проводящий собеседование на меня пристально пялился… вот так:
ʘ_ʘ
На фоне того, как все предыдущие конторы спрашивали, как работает стэк TCP/IP, просили написать парсер или решить задачу с комбинаторикой, такой вопрос реально звучит обескураживающе. Я теребил вопросами: «Может вам очень большие N нужны и оптимизация?», «Вам нужно АОП тут показать?», «Что, просто вот так вот в консоль вывести?», «Может форматирование какое?». На все вопросы был ответ: «Нууу… пишите как думаете… ʘ_ʘ»
Позиция была Flash-developer, кстати… Ну то есть, вы понимаете, всеобщую нахлынувшего неадеквата.
ʘ_ʘ
На фоне того, как все предыдущие конторы спрашивали, как работает стэк TCP/IP, просили написать парсер или решить задачу с комбинаторикой, такой вопрос реально звучит обескураживающе. Я теребил вопросами: «Может вам очень большие N нужны и оптимизация?», «Вам нужно АОП тут показать?», «Что, просто вот так вот в консоль вывести?», «Может форматирование какое?». На все вопросы был ответ: «Нууу… пишите как думаете… ʘ_ʘ»
Позиция была Flash-developer, кстати… Ну то есть, вы понимаете, всеобщую нахлынувшего неадеквата.
Забавно, именно на подобном вопросе про список я (предположительно) окончательно срезался на собеседовании в гугл (потратил на задачу более получаса).
Но нужно понимать что реально, это как бы попытка просто сэкономить. Т.е. я бы и сам с удовольствием бы так отсеивал бы специалистов — это очень удобно. И это работает.
Но это не означает что вы найдете лучших. Это означает что вы найдете достаточно хорогих потратив достаточно мало денег/времени.
Т.е. в этом есть определенное лукавство — это не поиск сильных программистов, это поиск достаточно программистов достаточно дешево.
Но повторюсь — я тоже бы поступал бы так же.
Но все же есть у меня есть определенный когнитивный диссонанс. Есть вот так называемое «собеседование Баткина» — blog.gamedeff.com/?p=64
Это набор базовых знаний для геймдева этакий. Тоже очень хорошо отсеивает плохих программистов.
Я прекрасно понимаю что с каждым годом из этого набора я помню все меньше и меньше.
Т.е. моя ценность с точки зрения сколько я могу дать ответов падает, но при этом моя ценность как специалиста выражаемая в проектах и деньгах только растет.
Вот такая вот дилемма.
Но нужно понимать что реально, это как бы попытка просто сэкономить. Т.е. я бы и сам с удовольствием бы так отсеивал бы специалистов — это очень удобно. И это работает.
Но это не означает что вы найдете лучших. Это означает что вы найдете достаточно хорогих потратив достаточно мало денег/времени.
Т.е. в этом есть определенное лукавство — это не поиск сильных программистов, это поиск достаточно программистов достаточно дешево.
Но повторюсь — я тоже бы поступал бы так же.
Но все же есть у меня есть определенный когнитивный диссонанс. Есть вот так называемое «собеседование Баткина» — blog.gamedeff.com/?p=64
Это набор базовых знаний для геймдева этакий. Тоже очень хорошо отсеивает плохих программистов.
Я прекрасно понимаю что с каждым годом из этого набора я помню все меньше и меньше.
Т.е. моя ценность с точки зрения сколько я могу дать ответов падает, но при этом моя ценность как специалиста выражаемая в проектах и деньгах только растет.
Вот такая вот дилемма.
Мне интересно действительно ли так важно умение общаться с коллективом? Потому что когда я проходил собеседование, мне отказали именно по причине того, что я «и на русском не очень-то и разговорчивый, а на английском, если придётся, будет ещё сложнее», хотя на все вопросы ответил правильно.
Проводить собеседование на ИТ-специальность по телефону… По моему, всё таки стоит посадить человека за компьютер и попросить у него реализовать какие-то вещи, а специалист должен посмотреть на его работу, т.к очень многие не могут сказать такое по телефону…
>>основной тест, отсеивающий 19 из 20 кандидатов еще на этапе телефонного собеседования
>>
>>Напишите на С функцию, переставляющую в обратном порядке элементы в односвязном списке.
Да, писать на С в уме, «на лету» диктуя код в телефон — это то еще развлечение…
>>
>>Напишите на С функцию, переставляющую в обратном порядке элементы в односвязном списке.
Да, писать на С в уме, «на лету» диктуя код в телефон — это то еще развлечение…
Ну думаю это в тестовом задании, до соебедования по телефону.
Добавил небольшой апдейт в пост.
При телефонных собеседованиях обычно используют какой-нибудь расшаренный блокнот, в котором канидат может писать код и давать его на ревью собеседующим.
Впрочем, «пишу на С в уме» — чем не строчка для резюме? :)
При телефонных собеседованиях обычно используют какой-нибудь расшаренный блокнот, в котором канидат может писать код и давать его на ревью собеседующим.
Впрочем, «пишу на С в уме» — чем не строчка для резюме? :)
Надо шипеть со скоростью 300 бит/c. Каждый настоящий программист может прошипеть на 300 бит/c, хороший программист — сможет на 2400.
У меня знакомый, когда в очередной раз меняет работу, ходит на 10-20 собеседований подряд. От собеседования к собеседованию вопросы пересекаются и к двадцатому он знает ответы на все из них и с наглой улыбкой требует высокую зарплату. И что вы думаете, дают!
Я видел уже эту статью, но почему то не могу поиском найти на хабре.
Незнаю эффективности таких задач на собеседовании… Очень часто сталкивался с тем что очень хороших специалистов пропускают мимо, а ребята банально теряются в задачах этих, так как «университетов» не заканчивали. А ставишь им задачу на решение, даешь необходимое (реальное) время, и они задачу выполняют. Часто глупо держать все решения в голове, если ты с ними не сталкиваешься в реальности в проектах. На юрфаке нам было дано на первом курсе хорошее напутствие:
Не пытайтесь запомнить все статьи, не стоит зубрить номерки статей и поправок, необходимо всего-лишь знать где и что искать. Развивайте логику и ищите данные по задаче.
Т.е. есть задача, необходимо найти решение, даже если помнить все статьи, вы все равно не будете знать текущего положения вещей, найденные новые решения, внутренние ведомственные документы, в зависимости от ситуации меняется и решение.
Не пытайтесь запомнить все статьи, не стоит зубрить номерки статей и поправок, необходимо всего-лишь знать где и что искать. Развивайте логику и ищите данные по задаче.
Т.е. есть задача, необходимо найти решение, даже если помнить все статьи, вы все равно не будете знать текущего положения вещей, найденные новые решения, внутренние ведомственные документы, в зависимости от ситуации меняется и решение.
вот это очень верно написано, а с названием топика я категорически не согласен.
каждый программист — уникальный. кому то нравится одно направление — игры. второй прётся от написания драйверов. третий умеет хорошо еще что-то одно делать… не бывает таких, чтобы слёту за полчаса на собеседовании показали себя и жнецом, и швецом, и на дуде игрецом. однако, если им дать время вникнуть в суть вопроса, почитать маны, уверен что они влёгкую справятся с любой адекватной задачей.
невозможно сразу всё знать и уметь. это должен понимать работодатель.
отсюда вытекает и другая вещь — часто мне на собеседовании в средние и крупные организации предлагали обучение всей специфике работы на прямо на испытательном сроке.
пришел я на собеседование на телевидение. меня спросили — сервер можешь? могу. берем.
дальше, местные сисадмины уже показали и объяснили тонкости организации всей компьютерной сети телевидения, а инженера научили пользоваться телеоборудованием, потому что всё взаимосвязано. на всё про всё ушло отсилы две недели. никто ничего не потерял.
а так конечно, если бы меня спросили написать какую-нибудь функцию для преобразования одного типа сигнала в другой, да еще и за полчаса времени, да еще и не зная всех тонкостей, я б ниразу не смог. и мало кто смог бы.
так что, уважаемые hr, опуститесь на землю. талант многих людей раскрывается грамотным подходом и хорошим стимулированием.
каждый программист — уникальный. кому то нравится одно направление — игры. второй прётся от написания драйверов. третий умеет хорошо еще что-то одно делать… не бывает таких, чтобы слёту за полчаса на собеседовании показали себя и жнецом, и швецом, и на дуде игрецом. однако, если им дать время вникнуть в суть вопроса, почитать маны, уверен что они влёгкую справятся с любой адекватной задачей.
невозможно сразу всё знать и уметь. это должен понимать работодатель.
отсюда вытекает и другая вещь — часто мне на собеседовании в средние и крупные организации предлагали обучение всей специфике работы на прямо на испытательном сроке.
пришел я на собеседование на телевидение. меня спросили — сервер можешь? могу. берем.
дальше, местные сисадмины уже показали и объяснили тонкости организации всей компьютерной сети телевидения, а инженера научили пользоваться телеоборудованием, потому что всё взаимосвязано. на всё про всё ушло отсилы две недели. никто ничего не потерял.
а так конечно, если бы меня спросили написать какую-нибудь функцию для преобразования одного типа сигнала в другой, да еще и за полчаса времени, да еще и не зная всех тонкостей, я б ниразу не смог. и мало кто смог бы.
так что, уважаемые hr, опуститесь на землю. талант многих людей раскрывается грамотным подходом и хорошим стимулированием.
Согласитесь, программист должен знать ответ на вопрос 2^7 :)
Нет, он должен знать как получить ответ на этот вопрос.
Я думаю, что вы тока что очень сильно промахнулись.
Сколько 2^7 знает любой, кто имеет базовые знания по компъюторным наукам. Потому что в базовом курсе обязательно идет булева алгебра, конвертирование из одной системы исчисления в другую (а эта операция, между прочим, происходит с применением степеней двойки).
Если вам дали калькуляторы и попросили на них сделать перевод из одной системы в другую — я вам сочуствую, выкиньте документ об образовании в мусорник.
Даже сетевикам нужны эти знания, потому что с помощью степеней двойки производятся преобразования IP'ников в бинарный формат и высчитываются подсети, диапазоны, вхождение IP в подсеть.
Да хотя бы те же условия — булева алгебра, опять же основа основ.
Всё это — базовые вещи, которые необходимы вообще для понимания того, что вы делаете. Если этих базовых знаний нет — значит это просто тренированная обезъянка, которая умеет повторять то что знает в нужных комбинациях.
Да, я знаю что люди работают без профильного образования и частенько даже лучше чем те, кто с профильным. И знаете, все они эти базовые знания получали. Просто не в университете, а из книг, интернета, от коллег и прочих источников. Я с такими работал. Для них и 2^7 не вопрос, а так, разминка.
P.S. Я согласен с мнением, что если клепать чисто сайтики на CMS, можно обойтись и без этого. Но это и не программисты, а кодеры. Там знаний особо не нужно — заучил и вперёд клепать. Работа программиста — это другой круг задачь, требующий гораздо больше знаний, чем есть у кодера.
Сколько 2^7 знает любой, кто имеет базовые знания по компъюторным наукам. Потому что в базовом курсе обязательно идет булева алгебра, конвертирование из одной системы исчисления в другую (а эта операция, между прочим, происходит с применением степеней двойки).
Если вам дали калькуляторы и попросили на них сделать перевод из одной системы в другую — я вам сочуствую, выкиньте документ об образовании в мусорник.
Даже сетевикам нужны эти знания, потому что с помощью степеней двойки производятся преобразования IP'ников в бинарный формат и высчитываются подсети, диапазоны, вхождение IP в подсеть.
Да хотя бы те же условия — булева алгебра, опять же основа основ.
Всё это — базовые вещи, которые необходимы вообще для понимания того, что вы делаете. Если этих базовых знаний нет — значит это просто тренированная обезъянка, которая умеет повторять то что знает в нужных комбинациях.
Да, я знаю что люди работают без профильного образования и частенько даже лучше чем те, кто с профильным. И знаете, все они эти базовые знания получали. Просто не в университете, а из книг, интернета, от коллег и прочих источников. Я с такими работал. Для них и 2^7 не вопрос, а так, разминка.
P.S. Я согласен с мнением, что если клепать чисто сайтики на CMS, можно обойтись и без этого. Но это и не программисты, а кодеры. Там знаний особо не нужно — заучил и вперёд клепать. Работа программиста — это другой круг задачь, требующий гораздо больше знаний, чем есть у кодера.
на собеседовании никто никому ничего не должен :)
мне, например несложно в уме это подсчитать. но есть люди, кому это сделать тяжело. однако они с лёгкостью могут написать, к примеру, интерфейс управления космическим кораблём, подглядывая по мере надобности в калькулятор за ответом 2^7.
на мой взгляд ничего плохого нет в том, что человек не знает ответа на чисто математические вопросы. человеку-калькулятору место в университете или в бухгалтерии (о даа! наконецто начальство сэкономит на калькуляторе!)
в программировании главное — это свой логический подход для достижения цели! и нет единого шаблона для измерения крутости яиц программиста.
мне, например несложно в уме это подсчитать. но есть люди, кому это сделать тяжело. однако они с лёгкостью могут написать, к примеру, интерфейс управления космическим кораблём, подглядывая по мере надобности в калькулятор за ответом 2^7.
на мой взгляд ничего плохого нет в том, что человек не знает ответа на чисто математические вопросы. человеку-калькулятору место в университете или в бухгалтерии (о даа! наконецто начальство сэкономит на калькуляторе!)
в программировании главное — это свой логический подход для достижения цели! и нет единого шаблона для измерения крутости яиц программиста.
А ^ это операция возведения в степень или бинарный xor? :)
У меня на мех-мате ситуация была аналогичной:
теория и практика давалась не для того чтобы освоить все классы задач, а чтобы научить людей МЫСЛИТЬ.
Да, есть определенный набор знаний, находящийся в «оперативной памяти» (у каждого своего объема;-)), но не более того. Иначе, простите, за 20 лет в ИТ у меня бы уже было «переполнение», со стольки разными технологиями приходилось сталкиваться и работать с ними.
Что касается собеседований — то не нужно общаться по вашей теме (у многих это повод для поднятия самооценки — это понятно), нужно говорить о задачах и проектах в которых участвовал соискатель, понять его роль, способность к работе, мотивации и т.д.
«Экзамен» по вашей теме тоже возможен, но человек должен в теме какое то время «повариться», т.е. это или через неделю-две испытательного срока, либо же, если уж очень хочется посмотреть на «реальные» знания — давайте задачу на дом — по решению которой человек и сам сможет понять — хочет он к вам или нет (решать такие задачи).
теория и практика давалась не для того чтобы освоить все классы задач, а чтобы научить людей МЫСЛИТЬ.
Да, есть определенный набор знаний, находящийся в «оперативной памяти» (у каждого своего объема;-)), но не более того. Иначе, простите, за 20 лет в ИТ у меня бы уже было «переполнение», со стольки разными технологиями приходилось сталкиваться и работать с ними.
Что касается собеседований — то не нужно общаться по вашей теме (у многих это повод для поднятия самооценки — это понятно), нужно говорить о задачах и проектах в которых участвовал соискатель, понять его роль, способность к работе, мотивации и т.д.
«Экзамен» по вашей теме тоже возможен, но человек должен в теме какое то время «повариться», т.е. это или через неделю-две испытательного срока, либо же, если уж очень хочется посмотреть на «реальные» знания — давайте задачу на дом — по решению которой человек и сам сможет понять — хочет он к вам или нет (решать такие задачи).
Я думаю, что эта статья увеличила число запросов по ключевым словам в вопросах. Особенно starvation :)
Если кто что найдет интересного, от ссылки кидайте в комментарии.
Если кто что найдет интересного, от ссылки кидайте в комментарии.
starvation — недостаток ресурсов, я так понял.
Нет.
«Голодание (starvation) — задержка времени от пробуждения потока до его вызова на процессор, в течение которой он находится в списке потоков, готовых к исполнению. Возникает по причине присутствия потоков с большими или равными приоритетами, которые исполняются все это время.»
с википедии
«Голодание (starvation) — задержка времени от пробуждения потока до его вызова на процессор, в течение которой он находится в списке потоков, готовых к исполнению. Возникает по причине присутствия потоков с большими или равными приоритетами, которые исполняются все это время.»
с википедии
Телефонное объснение переставление односвязного списка:
1. Вводим три переменные: Предыдущий узел, Текущий узел, Следующий узел. Со старта Предыдущий = null, Текущий = первый элемент списка, Следующий = Текущий->next.
2. Текущий->next = Предыдущий.
3. Предыдущий = Текущий
4. Текущий = Следущий
5. Следующий = Следующий->next.
6. Пока Следующий есть — переход к пункту 2.
Это вполне можно продиктовать по телефону. Разве нет?
1. Вводим три переменные: Предыдущий узел, Текущий узел, Следующий узел. Со старта Предыдущий = null, Текущий = первый элемент списка, Следующий = Текущий->next.
2. Текущий->next = Предыдущий.
3. Предыдущий = Текущий
4. Текущий = Следущий
5. Следующий = Следующий->next.
6. Пока Следующий есть — переход к пункту 2.
Это вполне можно продиктовать по телефону. Разве нет?
Обрадуются, что вы хоть что-то соображаете, и спросят «о различиях между кооперативной и вытесняющей многозадачностью». Пока вы будете переваривать этот гнусный канцелярит, а потом пытаться понять, как сформулировать отличие черного от белого, так и запишут: «в трубке только тишина».
хм, канцелярит? Можете привести более благозвучный вариант?
Есть подозрение, что нормально сказать нельзя потому и только потому, что нигде кроме собеседований и тестов это не произносится на самом деле. Поправьте, если это не так
Ну и не забывайте о том, что изначально это всё-таки американская статья, и автор проводит собеседования исключительно на английском:)
Это не так.
И та и другая многозадачность до сих пор используется, как-то же их отличать надо. У нас, в России, принято использовать русские слова, при возможности.
Как раз на собеседованиях и тестах я это ни разу не слышал, т.к. в энтерпрайзе кооперативная многозадачность никого не интересует.
И та и другая многозадачность до сих пор используется, как-то же их отличать надо. У нас, в России, принято использовать русские слова, при возможности.
Как раз на собеседованиях и тестах я это ни разу не слышал, т.к. в энтерпрайзе кооперативная многозадачность никого не интересует.
Правда, почему канцелярит?
В процессе перевода я очень порадовался тому, что именно для этих двух терминов есть более-менее устоявшиеся русские аналоги (я, по крайней мере, видел их в учебниках).
А Read-write lock и starvation по-русски вообще никак не называются.
В процессе перевода я очень порадовался тому, что именно для этих двух терминов есть более-менее устоявшиеся русские аналоги (я, по крайней мере, видел их в учебниках).
А Read-write lock и starvation по-русски вообще никак не называются.
Для меня канцелярит, потому что в выражение въезжал секунд 5. «Сooperative and preemptive multitasking» еще хуже. А вот read-write lock и на английском сразу понятно.
starvation = голодание (потоков) — вроде, в старом Рихтере видел
С одной стороны, проблема есть, с другой стороны ХРы способны предварительно отсеивать большинство таких кадров до технического собеседования. А так, ну что вы хотите, без такого просева подавляющее большинство неспособно цикл написать по коллекции нормально. У нас просто схожая проблема, даже очень сильный сеньор жаба девелопер, в среднем, как правило, очень сильно плавает в мультитрединге. Тех, кто освоил хотя бы базовые концепции очень небольшой процент, хотя дело то не хитрое. Видимо, на практике не очень просто востребованный навык.
На скорую руку написал решение, правда не на чистом Си, а на С++ всё-таки.
- struct CNode
- {
- CNode(int value = 0): m_value(value), m_pNextNode(0) { }
- int m_value;
- CNode *m_pNextNode;
- };
- // Returns new head.
- CNode* reverseList(CNode *pHead)
- {
- if (!pHead->m_pNextNode)
- return pHead;
- CNode *pCurrentNode = pHead;
- CNode *pNextNode = 0;
- CNode *pPrevNode = 0;
- do
- {
- pNextNode = pCurrentNode->m_pNextNode;
- pCurrentNode->m_pNextNode = pPrevNode;
- pPrevNode = pCurrentNode;
- pCurrentNode = pNextNode;
- } while (pNextNode);
- return pPrevNode;
- }
А если список пустой? То есть nil на входе? ;)
Из 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
(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
Хм, я понял задание так:
Сначала хотел написать рекурсивно, но подумал, что на C это неприлично
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 — исходная длина вектора
А вот остальные вопросы — увы, с многопоточностью не очень, разве что общие соображения рассказал бы.
А вот остальные вопросы — увы, с многопоточностью не очень, разве что общие соображения рассказал бы.
O(N+M)=O(N)
Не-не. Если исходный вектор содержал 100000 элементов (M=100000), и добавляется N=10 элементов, то результирующая сложность будет порядка 100000.
Худший случай — когда элементы вставляются в начало вектора, тогда все 100000 старых элементов придётся сдвинуть.
Худший случай — когда элементы вставляются в начало вектора, тогда все 100000 старых элементов придётся сдвинуть.
Это неважно. О-большое сравнительная асимптотическая величина, линейные изменения на неё не влияют.
Так-так… Упорствуем? Что такое O-большое я знаю, но тут нет линейной зависимости.
M никак не связано с N, а значит им нельзя тут пренебречь, сказав, что O(M + N) = O(N)
Поясню на конкретном примере. Если N = 1 (вставляем один элемент), то, руководствуясь вашей логикой, можно было бы сказать, что время добавления одного элемента в вектор O(1), то есть константно.
Между тем (помним, что вопрос был про максимальное время) ответом будет O(M)
M никак не связано с N, а значит им нельзя тут пренебречь, сказав, что O(M + N) = O(N)
Поясню на конкретном примере. Если N = 1 (вставляем один элемент), то, руководствуясь вашей логикой, можно было бы сказать, что время добавления одного элемента в вектор O(1), то есть константно.
Между тем (помним, что вопрос был про максимальное время) ответом будет O(M)
О чем вы говорите? Не указано же, N элементов вставляются одним блоком или по отдельности. Не известен язык, так что непонятно, стандартный вектор умеет вставлять только по одному или блоками. Обычно, врде, по одному.
Не указано, какой стратегии реаллокации придерживается реализация вектора — может тупо реаллоцировать k+1, может k*2, может фибоначчи, может степени двойки.
Не указано, какой стратегии реаллокации придерживается реализация вектора — может тупо реаллоцировать k+1, может k*2, может фибоначчи, может степени двойки.
Язык известен («или как там в вашем любимом языке называется динамический массив»), возьмём в качестве «любимого языка» C++, тогда динамическим массивом будет std::vector. Для него гарантируется амортизированное время вставки O(N + M) для вставки множества элементов.
Конечно можно использовать вектор неэффективно и вставлять элементы по одному, но в таком случае можно написать и «for(;;)» в качестве кода для вставки и сказать, что время работы бесконечно.
Конечно можно использовать вектор неэффективно и вставлять элементы по одному, но в таком случае можно написать и «for(;;)» в качестве кода для вставки и сказать, что время работы бесконечно.
Суть задания в том, чтобы не создавать новый список, а чтобы переставить элементы уже имеющегося. Пока думал над решениями задачи проскочило еще парочку вариантов, но они более требовательны по памяти и медленней по скорости:
1) Менять местами соседние эл-ты списка, что-то по типу пузырьковой сортировки. Сложность, как ни трудно догадаться O(n^2)
2) Пройтись по списку, сохранив все указатели в вектор/массив и потом снова проходясь по списку уже через вектор/массив просто подставить созраненные значения.
1) Менять местами соседние эл-ты списка, что-то по типу пузырьковой сортировки. Сложность, как ни трудно догадаться O(n^2)
2) Пройтись по списку, сохранив все указатели в вектор/массив и потом снова проходясь по списку уже через вектор/массив просто подставить созраненные значения.
А, ну если не создавать новый, то вот вариант проще и универсальнее вашего. Хотя и там я бы переменные попереименовывал.
gcc умеет хвостовую рекурсию.
Согласен, что уровень программистов падает, но не всегда можно оценить человека за короткий промежуток времени. Помню читал на stackoverflow тему, где один из местных гуру говорил, что не получается у него проявить себя на собеседованиях. Вот посадить его за компьютер и попросить найти какую-нибудь проблему в коде и он первый её найдёт и т.д. Рейтинг его тоже весьма внушительный там был, поэтому всё относительно, хотя стрессоустойчивость тоже весьма хорошее качество.
Ну, во-первых: телефонное собеседование (во всяком случае, сейчас в Штатах) НЕ ПОДРАЗУМЕВАЕТ никакого «веб-блокнота». Я и прошёл немало таких собеседований, и проводил их сам неоднократно, и всегда, если и просили написать какой-то код, то он был минимален, и я его диктовал по телефону. Как правило, речь шла о нескольких простых строчках. Впрочем, такого рода вопросы по телефону нечасты, да и я сам стараюсь их не задавать — это всегда можно спросить при личном собеседовании.
Я тоже в какой-то момент начал просить кандидатов на собеседовании написать простенький код, и тоже был поражен чудовищно низким процентом людей, которые способны это сделать. Я просил развернуть строку, добавить элемент в связный список и прочие тривиальные вещи. Многие кандидаты не могли даже написать удаление элемента из списка!
А вот вопросы, приводимые в статье, меня несколько изумили. Да, возможно, это вопросы из курса программирования, и каждый выпускник колледжа или университета должен их знать. Но уже через 5-6 лет работы эти понятия могут подзабыться, если программист занимается другими вещами. Хороший программист вспомнит всё быстро — но, возможно, не на собеседовании.
Ну, и последнее. Довольно забавно читать этот текст, исходящий из уст свежевыпущенных программистов, создавших крошечный стартап. Сколько апломба! Сколько самоуверенности! Сколько убежденности в том, что они точно знают, каковы должны быть НАСТОЯЩИЕ программисты!
Я тоже в какой-то момент начал просить кандидатов на собеседовании написать простенький код, и тоже был поражен чудовищно низким процентом людей, которые способны это сделать. Я просил развернуть строку, добавить элемент в связный список и прочие тривиальные вещи. Многие кандидаты не могли даже написать удаление элемента из списка!
А вот вопросы, приводимые в статье, меня несколько изумили. Да, возможно, это вопросы из курса программирования, и каждый выпускник колледжа или университета должен их знать. Но уже через 5-6 лет работы эти понятия могут подзабыться, если программист занимается другими вещами. Хороший программист вспомнит всё быстро — но, возможно, не на собеседовании.
Ну, и последнее. Довольно забавно читать этот текст, исходящий из уст свежевыпущенных программистов, создавших крошечный стартап. Сколько апломба! Сколько самоуверенности! Сколько убежденности в том, что они точно знают, каковы должны быть НАСТОЯЩИЕ программисты!
>Но уже через 5-6 лет работы эти понятия могут подзабыться
В конкретном случае — нет, всё-таки они искали системных программистов, которые эти проблемы решают более-менее регулярно.
В конкретном случае — нет, всё-таки они искали системных программистов, которые эти проблемы решают более-менее регулярно.
Спасибо за комментарий по поводу применения веб-блокнотов. Возможно, чуть погорячился по поводу «применяется всегда».
Я ориентировался на рассказы знакомых, которые проходили телефонное собеседование в российский Гугл: в двух случаях ребятам предлагалось писать код, если я не ошибаюсь, в Google Docs.
Я ориентировался на рассказы знакомых, которые проходили телефонное собеседование в российский Гугл: в двух случаях ребятам предлагалось писать код, если я не ошибаюсь, в Google Docs.
И кстати, чего-чего они там пишут? И сколько для этого нужно людей? Два? А кого они набирают?
Неправы. Именно сейчас, и именно в США часто используются веб-блокноты во время телефонных интервью. Тот же Гугл создает документ в Google Docs, и расшаривает его с интервьюируемым незадолго до интервью
Хммм… Ну, давайте скажем так. Я живу в США. В течении последних трех лет я проходил собеседования примерно в 15 компаниях, начиная от того же Гугла, включая очень разные компании, от крупных банков до стартапов. Ни в одном месте мне не предложили использовать ни Гугл Докс, ни что бы то ни было подобное. Вполне возможно, что это новая идея Гугла, однако, как я уже сказал, для многих требование во время телефонного собеседования быть рядом с компьютером с доступом в сеть будет очень неудобно.
Скажите, а вот Вы своё утверждение основываете на личном опыте?
Скажите, а вот Вы своё утверждение основываете на личном опыте?
Хороший, годный работодатель. Иные сначала час мучают «логическими» задачками, а только потом снисходят до реального мира.
Ага, сушат мозги три часа, что бы доказать что вы идиот и можете претендовать только на пол-зарплаты. Потому что стартап маленький и на целую зарплату денег нет. А потом выясняется что, поскольку головой думать никто не умеет, все равно набрали десять человек, которые умеют списки инвертировать и википедию читать про примитивы синхронизации, вместо одного, который головой думать умеет.
How HR department reads your resume / How programmers read your resume:
www.hanovsolutions.com/resume_comic.png
К сожалению времени переводить сейчас нет, но пройти мимо просто не мог )
www.hanovsolutions.com/resume_comic.png
К сожалению времени переводить сейчас нет, но пройти мимо просто не мог )
«Как бы вы реализовали read-write lock?»
var Locker: TMultiReadExclusiveWriteSynchronizer;
Locker := TMultiReadExclusiveWriteSynchronizer.Create;
пойдет? ;-)
var Locker: TMultiReadExclusiveWriteSynchronizer;
Locker := TMultiReadExclusiveWriteSynchronizer.Create;
пойдет? ;-)
Хорошая реализация у Рихтера, насколько я помню была. Там использовалась глобальная переменная, работа с которой велась с помощью семейства Interlocked-функий, и два мютекса или критических секции.
Ну а вообще, да, с Висты, например, есть реализованные на уровне ОС read-write локи, да и практически в каждом хорошем фрейворке они уже тоже есть. Но суть изначального вопроса в понимании принципа реализации, никто не будет заставлять писать свои велосипеды, когда уже есть хорошие реализации (в некоторых фирмах за такое и по рукам бьют :)).
Ну а вообще, да, с Висты, например, есть реализованные на уровне ОС read-write локи, да и практически в каждом хорошем фрейворке они уже тоже есть. Но суть изначального вопроса в понимании принципа реализации, никто не будет заставлять писать свои велосипеды, когда уже есть хорошие реализации (в некоторых фирмах за такое и по рукам бьют :)).
У нас как-то на должность старшего веб-разработчика (ASP.NET) взяли чувака: прошел собеседование на отлично (собеседовали полтора часа, задавали сложные и каверзные вопросы). Через два дня дали задачу, в которой надо было получить значения параметра в запросе, так он регулярку написал в экран для этого.
В понедельник я собеседовал претендента на должность, не связанную с программированием. Тем не менее, в резюме значилось «знание C++», и я задал задачу: «Нужна программа, выводящая строку на экран. Не важно — какую, придумайте удобную Вам. Придумали? Ок, напишите хотя бы одну строку программы.»
Запаслись попкорном? Зря. Продолжения нет, рассказ кончился.
Запаслись попкорном? Зря. Продолжения нет, рассказ кончился.
Я для себя уже выяснил, что половина претендентов под «опытом работы с оборудованием Cisco» подразумевает «втыкал патч-корд в свитч Cisco».
Я себя ловлю временами на том, чтобы написать еще что-нибудь в резюме… недавно в c Python в Ruby пришлось скрипт на пару сотен строк переписывать, зная оба очень поверхностно… скрипт-то работает, а вот в скиллы не запишешь — несерьезно слишком для полноценного знания платформы.
Я бы переформулировал: «мой друг рассказывал, как его начальник втыкал патч-корд… в эту… ну, как её...»
Да их самих надо гнать, пожалуй. Всех. Написать функцию реверсирования не сложно, но гиморойно, потому что C не имеющий… в общем ничего не имеющий. По телефону? Отсеивают тех, кто не найдет за две минуты в гугле?
Причем, алгоритм, который они хотят видеть — он, конечно же, мутабельный, с константной памятью, в многопоточном окружении его надо будет снабдить примитивами синхронизации и поиметь блокировку.
Окасаки-же и про персистентные структуры данных в многопоточных окружениях они, конечно же, не читали никогда.
Сложность вставки в середину массива? Вам надо вставлять в середину (а зачем вообще?), и вы выбрали массив? Вон из профессии. Дешевле завести список, вставить, потом из него сгенерировать массив, если уж прямо так надо. Про эту стоимость можно сказать только то, что она такая высокая, что спасибо, не надо.
RW-Lock и starvation? Ну опять началось, shared state и паттерны, что бы он работал, в многопоточном окружении. Пока вы играетесь со своим shared state, даже последние тормоза поймут, что его использовать по, возможности, нельзя.
Даже Intel пишет свой функцильный язык для параллельных / конкурентных
сред.
За многопоточность, значит, болеете? Давайте поговорим за многопоточность.
Почему, например, MySQL (да и все остальные) не умеет распараллеливать исполнение SQL запросов? Ведь идеальные же для этого, чистые функции.
А потому что такие как вы, инверсоры сишных списков и любители эфемерных структур данных, не прочитавших ни одной книжки, превратили код в кучу нечитабельного говна, плотно спаянного побочными эффектами, и что-то существенное в нем изменить невозможно, можно только латать из года в год. И распараллеливания запросов, скорее всего, в нем не будет НИКОГДА.
А еще вы за асимптотическую сложность переживаете? А нука — какова
сложность вашего майскульного алгоритма выведения типов Ad-Hoc (вместо алгоритма W, сложность которого известна и корректность которого доказана).
Ну конечно — вы были слишком заняты, учились списки на си инвертировать.
Когда там читать что-то. Пирс? Кто такой Пирс?
Все такие вот собеседования, они, в основном чешут ЧСВ собеседующих. На вопросах,
которые те придумали и они им кажутся очень важными, ведь они их сами придумали и знают на них ответы!
Причем, алгоритм, который они хотят видеть — он, конечно же, мутабельный, с константной памятью, в многопоточном окружении его надо будет снабдить примитивами синхронизации и поиметь блокировку.
Окасаки-же и про персистентные структуры данных в многопоточных окружениях они, конечно же, не читали никогда.
Сложность вставки в середину массива? Вам надо вставлять в середину (а зачем вообще?), и вы выбрали массив? Вон из профессии. Дешевле завести список, вставить, потом из него сгенерировать массив, если уж прямо так надо. Про эту стоимость можно сказать только то, что она такая высокая, что спасибо, не надо.
RW-Lock и starvation? Ну опять началось, shared state и паттерны, что бы он работал, в многопоточном окружении. Пока вы играетесь со своим shared state, даже последние тормоза поймут, что его использовать по, возможности, нельзя.
Даже Intel пишет свой функцильный язык для параллельных / конкурентных
сред.
За многопоточность, значит, болеете? Давайте поговорим за многопоточность.
Почему, например, MySQL (да и все остальные) не умеет распараллеливать исполнение SQL запросов? Ведь идеальные же для этого, чистые функции.
А потому что такие как вы, инверсоры сишных списков и любители эфемерных структур данных, не прочитавших ни одной книжки, превратили код в кучу нечитабельного говна, плотно спаянного побочными эффектами, и что-то существенное в нем изменить невозможно, можно только латать из года в год. И распараллеливания запросов, скорее всего, в нем не будет НИКОГДА.
А еще вы за асимптотическую сложность переживаете? А нука — какова
сложность вашего майскульного алгоритма выведения типов Ad-Hoc (вместо алгоритма W, сложность которого известна и корректность которого доказана).
Ну конечно — вы были слишком заняты, учились списки на си инвертировать.
Когда там читать что-то. Пирс? Кто такой Пирс?
Все такие вот собеседования, они, в основном чешут ЧСВ собеседующих. На вопросах,
которые те придумали и они им кажутся очень важными, ведь они их сами придумали и знают на них ответы!
Судя по вашему комментарию, у вас на собеседовании вопросы будут еще интереснее, и отсев кандидатов будет на порядок выше… или вы собираетесь учить людей, не знащих про существование rwlock, «правильному» многопоточному программированию?..
Вопросы, описанные в статье, очень примитивны, и любой программер их должен знать (server-side, по крайней мере, а GUI формочки можно и без этого лабать)
Вопросы, описанные в статье, очень примитивны, и любой программер их должен знать (server-side, по крайней мере, а GUI формочки можно и без этого лабать)
Смысл в том, что люди, особенно которые себя считают мега-разработчиками, склонны набирать людей, похожих на себя.
При этом даже если кандидат знает что-то, что собеседующий не знает — это, обычно серьезная проблема кандидата.
А набирать людей, похожих на себя — это кадровый инцест с последствиями, похожими на последствия инцеста in RL.
При этом даже если кандидат знает что-то, что собеседующий не знает — это, обычно серьезная проблема кандидата.
А набирать людей, похожих на себя — это кадровый инцест с последствиями, похожими на последствия инцеста in RL.
Я поддерживаю джентльмена. Все правильно написал. ЧСВ автора стремится к облакам и успешно достигает.
Посыл статьи правильный. Тон выбран неверный. Не так давно мне довелось интервьюировать кандидата, который все уши прожужжал тем, что после принятия на работу в текущую компанию, не боится ничего — у них самые сложные собеседования. Его занесло настолько, что, в какой-то момент, он ляпнул, что не уверен, пройду ли я тест в их компании. Первым вопросом, который он провалил, было «объясните принцип работу древовидных структур». Далее было не лучше. Последний гвоздь в крышку гроба забил вопрос: расскажите о транзакциях, причинах появления, принципах функционирования, уровнях изоляций.
Видите ли, люди, однажды попавшие в компанию, далеко не всегда сохраняют высокий уровень в дальнейшем. Прочтя ваши самовосхваления у меня, в первую очередь, возник вопрос, насколько правомерно именно ваша гордость.
Посыл статьи, повторяю, вполне верный.
Видите ли, люди, однажды попавшие в компанию, далеко не всегда сохраняют высокий уровень в дальнейшем. Прочтя ваши самовосхваления у меня, в первую очередь, возник вопрос, насколько правомерно именно ваша гордость.
Посыл статьи, повторяю, вполне верный.
У же 7 лет работаю программистом на php и не разу мне не приходилось вычислять степени и тем более переставлять элементы в списке.
какова максимальная сложность вставки N элементов в vector
Тут любой даже поверхностно изучавший высшую математику человек должен не задумываясь сказать: «Ну конечно же бесконечность! Потому что сложность реализации любого алгоритма не ограничена сверху.»
Выделенный текст хорошо было бы сделать ссылками
Предлагаю решение для всех. Буду рад комментариям.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настоящие программисты, где же вы?