Comments 474
Оба голосования неполны (и потому предвзяты). Отсутствует пункт «определяется спецификой выполняемой работы». IMHO, разумеется.
Обида конечно понятна, но возможно действительно искали человека, способного решать такие задачи без любимой IDE.
но возможно действительно искали человека, способного решать такие задачи без любимой IDE

А мне вот интересно, какая работа предполагает такое требование, плюс стрессовые ситуации?
Детали рассказывать не буду, но на одном проекте пришлось на JS писать скрипты для настройки оборудования Cisco.
Из инструментов, по большому счёту, был блокнот.
Кстати, процесс «собеседования» на этот проект был тоже… своеобразный
Вы подписывали NDA до прохождения собеседования? Это невероятно!
Это был вопрос. Мне никто не говорил. Но если NDA не подписан, то вопросами и ответами делиться никто не запрещает.
Даже если я подписал после, не вижу возможности разглашать то, что происходило до подписания. И да, часто NDA подписывается до собеседования.
Почти все крупные фирмы требуют подписать NDA до прохождения собеседования. Конечно обычно они не слишком серьёзно смотрят на то как этот NDA соблюдается: максимум чем вы реально рискуете — это попасть «в чёрный список» и потерять возможность устроится туда на работу в будущем. Тащить вас в суд, скорее всего, не будут, так как вы вряд ли услышите на собеседовании что-то настолько секретное, но всё равно: люди, подписывашие NDA обычно его потом стараются соблюдать…
Мне не попадались такие фирмы. Поэтому я удивился искренне.
Но при этом за Вами же не следили, как вы пишете код? В добавок написание настроек это больше рутинная задача.
Ох, поверьте, рутины там было мало. Вся работа — одно сплошное приключение, растянувшееся на год.
На собеседовании, не то чтобы следили. Общались очень плотно.
Из инструментов, по большому счёту, был блокнот.
Из соображений секретности, безопасности и недоступности по сети?
Из соображений глубокой костыльности. Не было там стандартных решений (именно по этому направлению).
Нельзя было, например, отладить код в какой либо IDE. Задача не позволяла.
Интересно, почему всё же нельзя было поставить IDE, поддерживающую JS, или, в крайнем случае, Notepad++? Запрещалось ставить сторонний софт? Платформа была не Windows/i386 и вообще не i386? Не было физической возможности закачать на диск инсталлятор (или уже развёрнутую программу, если она не требовала инсталляции)? Почему нельзя было перенести скрипт на более удобную машину, там отредактировать, а потом перенести обратно?
Ставить можно было что угодно. В работе это не помогало. Notepad++ отдельные товарищи пользовали, я не любитель.
Просто задачка не очень традиционная. Не Web. Сложно объяснить не вдаваясь в детали. Всё было завязано на сторонний фреймворк.
Наверное можно было написать обвязку для отладки этого всего под IDE, но времени на эксперименты не было.
Давайте я про свой случай расскажу, что ли. Исходники лежат в папке [условно] /src, куда смонтрирована кластерная файловая система, сколько тех исходников знает только Господь Бог и сисадмин (известно только что терабайтов там много, но петабайт, вроде как, пока нету). Как несложно догадаться никакого Windows/i386 нет и не планируется, собирается всё командой, условно, build (тоже где-то в облаке), общаться с программой можно через встроенный в неё web-сервер (сама программа при этом работает, опять-таки, в облаке — там где её поднимет условная команда run). Не так давно думали что делать с тем, что в кое-каких системах упёрлись в старое древнее ограничение в 2GiB кода в одной библиотеке под Linux'ом.

Ваши действия? С какой стороны прикручивать IDE? И как она вам поможет отлаживать код?

P.S. Кстати какое-то количество разработчиков у нас использует IDE. Eclipse, IDEA, CLion. Не могу сказать, что кода от них поступает заметно больше, чем от других.
Если есть web-интерфейс, то всё не так плохо. Можно использовать либо Copy-Paste либо download-upload. Если скрипты на JS, то можно использовать Notepad++, чтобы совсем тупо не накосячить с несбалансированными скобками и незаконченными строками, и, наверное, как-то, ограниченно и с тупыми самописными mock'ами, консоль «хрома» или вообще node.js REPL.
Notepad++ — это всё-таки не совсем IDE. Использовать IDE как «крутой текстовый редактор» — да, можно, но обычно под «использованием IDE» понимается что-то несколько другое.
«Настройки оборудования Cisco» звучит страшно. На самом деле вещь очень простая — текст.
Я думаю что 90 процентов цисковиков настройки циско в блокноте пишут и не жужжат.
Используя perl или python для разворачивания шаблонов.

В итоге — не убедили. Не нужны эти скилзы.
Я как бы и не стремился Вас убеждать. Меня попросили пример — я дал (настолько подробно насколько мог). Верить или нет — ваше дело. Разумеется, сложность была не в Cisco (я вообще не цискарь). Просто конкретно в этой работе IDE не помогало никак. И да, все пользовались блокнотом и не жужжали.
А разве нельзя такой написать в удобной IDE с автодополнениями, подсветкой и отладкой, а потом скопипастить на Cisco, или даже просто переписать с экрана на экран, если нет никаких телнетов?
Мы писали не конфигурацию Cisco, а JavaScript-код конфигурирующий Cisco. И сверху была ещё высокоуровневая обвязка на том же JavaScript, которая дёргалась из Java-фреймворка. Писать JavaScript код в IDE было конечно можно, но копипастить его было некуда.
Стрессовые ли?
Сидя дома за своим компьютером, а не добираясь до офиса компании в людном метро или пробираясь через пробки на машине…
Мне вот не совсем понятно, почему данная ситуация считается стрессовой? То, что для автора она была таковой, вовсе не значит, что собеседник этого и добивался. Мне даже кажется, что он давал подсказки, чтобы разрядить ситуацию и помочь. И возможно ждал бы решения еще полчаса, если бы автор попросту не сдался.
А само решение задач не должно зависеть от IDE или блокнота. Если в голове есть представление алгоритма, то описать его псевдокодом или js не должно составлять труда. Разве-что без IDE и autocomplete программист не помнит языковых конструкций, ну это не делает ему чести.
почему данная ситуация считается стрессовой?

1. Отсутствие привычной среды разработки. Автора вывели из зоны комфорта, заставив писать не в любимой IDE.
2. Работа под присмотром. В комментариях ниже очень красочно описали, каково это
habrahabr.ru/post/276673/#comment_8764473
habrahabr.ru/post/276673/#comment_8764489
3. Академическая задача. Когда на собеседовании предлагают решать задачу не из списка часто практикуемых, то это тоже может выбить из колеи.
1. На большинстве собеседований у кандидата на должность есть только листок и ручка и это стандартная практика, а не вывод из зоны комфорта.
2. Опять-же более чем стандартная практика для любого собеседования.
3. Во время работы задача не из списка часто практикуемых как мне кажется норма, если уж человек не является очень уж узким специалистом.

А вообще как мне кажется если бы человек вместо того чтобы сразу начать писать код в дискомфортной для него ситуации предложил бы начать с наброска блок-схемы решения ему врядли бы отказали и это сильно бы упростило процесс.
Я согласен с Вами, что это обычная практика, я просто отвечал на вопрос: почему данная ситуация считается стрессовой?
Ох уж эти «стандартные практики». Не счесть сколько неимоверных глупостей я слышал перед этой формулой. В итоге, собеседования проходят не те, кто лучше остальных соискателей, а те, кто либо больше других прошел собеседований, либо еще совсем не опытный и не понимает всей серьезности ситуации: первое свое (очень суровое) собеседование я прошел без запинки, а вот на последующих уже заметно волновался, хотя и профессиональные навыки были, разумеется, уже выше.
Я даже на первом собеседовании довольно сильно волновался.
То что проф. навыки были выше помогло бы избежать волнения только в случае если бы вы собеседовались на туже должность что и раньше, а не выше.

Я говорю о том что какую бы глупость вы не увидели на собеседовании это не повод спадать в ступор из-за волнения, тем более если эта глупость считается нормой для 90% собеседований. Вот если бы он рассказывал о чём-то совершенно неожиданном (заставили бы его писать на А4 листе перьевой ручкой) это было бы вполне понятный повод для волнения.
Есть навыки, полезные при программировании и есть навыки, полезные при прохождении собеседований. Если человек часто программирует, то он развивает одни навыки, а если часто проходит собеседования, то совсем другие.
Тут я имел в виду эффект «второго прыжка»: прыгать с парашютом по-настоящему страшно во второй раз, а не в первый.

Про стандартные практики — это не столько по поводу собеседований, сколько вообще в целом, я неоднократно видел ужасные вещи, которые оправдываются тем что «ну а че, все так делают».
Есть весьма веские аргументы в пользу того, что «стандартные практики» при приеме на работу, о которых идет речь, попросту неэффективны.
Обычная практика — ведь не означает — хорошая практика, так ведь?
По умолчанию — означает. То есть обычная практика может быть и плохой (тогда она заменяется на другую «обычную практику»), но «по умолчанию» — она считается хорошей.
Согласен с вам насчет проверки синтаксиса в IDE. Например в моем случае я его использую как, своего рода, REPL, в режиме отладки. Я не считаю что это обязательно, но согласитесь, как же это удобно.
Если в голове есть представление алгоритма, то описать его псевдокодом или js не должно составлять труда.
Но в том-то и проблема, что для нахождения алгоритма (элемнтарного, тривиального алгоритма) потребовалось больше суток! Это, я извиняюсь, вообще как, нормально?

Кроме того в C# (как и в Java, как и в C++) очередь — есть. В JavaScript — нет. Это — тоже грабли, которые соикатель себе подложил сам.

А как ешё должно выглядеть собеседование? Дать элементарную задачу, посмотреть что получится… как иначе-то?
Вообще говоря, и очередь написать не должно составлять проблемы, так что есть она в фреймворке или нет — неважно. Как минимум можно сделать просто массив, пояснив интервьюеру недостатки такого подхода и какие есть более эффективные варианты.
Дык можно и интерпертатор x86 на CSS при желании изобразить! Дело-то не в этом.

Дело просто в том, что «писатели фронтэндов» вообще не думают в терминах очередей, стеков, деревьев. Вот пример. Они даже не осознают, что DOM-дерево — оно таки тоже дерево и при работе с ним могут возникать типичные задачи, связанные с деревьями!

Ну и куда девать такого человека в компании, где на 100 строк кода на «фронтэнде» приходится 10'000 строк на «бэкенде»? Знание JavaScript'а при этом не помешает («бэкенд» тоже может JavaScript использовать… особенно если это, скажем, код для поддержи offine-работы в браузере), но куда ж тут без понимания очередей?
А кто вам сказал, что у вас будет возможность использовать вашу любимую IDE в будущем? Нет, специально никто палки в колёса вставлять не будет, но если, скажем, проект собирается только под MacOS, то вашу «любимую IDE» может оказаться затруднительно использовать. Бонус — за проект, который собирается тремя системами сборки, две из которых работает под MacOS и две — под Linux (это я не из пальца высысываю, это реальный пример, с которым мы работали пару лет назад).

Если вы без «любимой IDE» 20 строк написать не можете, то может вам и не стоит в подобную компанию собеседоваться?
Все кто про стресс говорит, вы статью читали? У меня не нервы сдали и не стресс был, а была ситуация где я выпал из колеи привычного мыслительного процесса из-за того что слишком много внешних факторов изменились. Термины впасть ступор, got stuck, freeze the brain имеют мало общего со стрессом. Почему было такое окружение, по моим догадкам испытание на стрессо-устойчивость, хотя может мне показалось. Статья кстати не обо мне и о том какой я бедный и несчастный. На мой взгляд я поднял несколько важных вопросов такой статьей, хотя я могу ошибаться.
Скажите спасибо что было онлайн собеседование и у вас был хотя бы онлайн блокнот. А то на листочке A4 писали бы карандашом.
Лично мне «на листочке карандашом» было бы намного комфортнее. Хотя бы в силу того, что при планировании решений рукописной формой пользуюсь регулярно, а эти онлайн-блокноты каждый раз новые и у каждого свои нюансы поведения и отображения.
А кто-то ручку не держал в руках… лет 10-12. Ему заказан путь к собеседованиям?
Как вы это себе представляете?

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

Думаю что подобному уникуму будет несложно решить задачу вообще в уме и потом только вписать её в предложенный онлайновый блокнот…
Я такой человек, приятно познакомиться. Использую планшет и десктоп для заметок и рисования схем. С момента расставания с институтом наверное и страницы в сумме не исписал ручкой.
Я тоже много чего могу накодить не привлекая ручку и бумагу, но если задача реально сложная… Планшета и десктопа не хватает: мало влазит, сложно изменения вносить… за пять минут десять набросков не сделать…

Так что сказанное вами, почти наверняка, обозначает, что вы давненько не решали реально сложных задач.
Каковой, в частности, является любая простая задача на собеседовании. Проверить как вы с этим справитесь — будет вдвойне полезно.
Скорость создания схем на бумажке или в специализированном ПО — вопрос привычки и умения. Изменения вносить уж точно проще, чем на бумаге, где можно только дописать что-то сверху.
Есть люди, которым и текст писать на бумаге удобнее и быстрее, чем набирать на клавиатуре компьютера.
Возможно. Повторюсь: пока я таких не встречал. Встречал людей, которые плохо и медленно рисуют схемы на бумаге, таких кто хорошо и быстро делает это на компьютере — не видел.
Ну, есть к примеру Power Designer. Шариковая ручка — довольно таки неудобный инструмент.
У шариковой ручки пока ещё разрешение выше, чем у планшета и десктопа (в смысле количества текста и картинок, которые можно уместить на страницу и окинуть взглядом).
Смотря для чего. Набросать простенькую схему, обсудить и выбросить на листке бумажки — занятие на две минуты. Я ещё никого не видел, кто бы сделал что-то подобное в Power Designer'е за сравнимое время.

А вы, напоминаю, идёте работать в команду. Тут общаться как-то придётся. Это когда вы один — можете обдумывать решения в уме (в ванной, в туалете, где хотите) и сразу «набело» врисовывать решения в Power Designer. А когда вы с кем-то общаетесь ничего лучше листка бумаги или доски не придумано (доска чуть менее удобна, но позволяет общаться больше, чем 2-3 участникам).
Я никуда не иду. Давно уже пришёл. Больше 20 лет уж как в команде. Ручка используется, да, но не чаще чем Power Designer, Visio и пр. В основном для себя, поскольку рисую и пишу от руки я из рук вон. У других участников команды ситуация с письмом от руки примерно аналогичная.
UFO landed and left these words here
Как-то раз тоже в таком же ключе был на собеседовании. Сначала просто общение, потом онлайн общение с будущей командой, а потом онлайн редактор текста, без подсветки. Тоже путался, так как привык уже к vs+r#. В итоге минут через 20, когда я с горем пополам решил проблему, но мне сказали, что решение «в лоб», можно проще и изящнее.
В итоге, потея и путаясь в переменных я завалил тест.
Сочувствую Вам, сам бывал в подобной ситуации, когда решение вот здесь и сейчас не приходит в голову, хотя задача простая, а потом, когда успокоюсь решение приходит само (хотя вопрос — а сколько времени ушло на решение, возможно я обдумывал его все время после не удачи… я как-то не задумывался об этом).

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

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

А еще я сталкивался с ситацие когда требовалось написать рабочий код в онлайн блокноте, я примерно помнил синтаксис и в общих чертах набросал решение, на что мне сказали, что это не годится. :)
Я тоже однажды столкнулся с таким. Попросили написать код на листке бумаги. Набросал примерное решение опустив проверки крайних ситуаций для краткости. На что начались придирки что мол тут вы на null не проверили, тут блок finally не написали, и т.п.
Вот это уже полный идиотизм, я все это опустил думая что проверяют в принципе понимание ситуации.
А у меня было задание отсортировать массив в Java, ну я и написал Arrays.sort(<массив>). Собеседующий посмотрел на меня как на идиота и такой — ну это, как бы сортировку напиши какую-нибудь. Я подумал подумал и написал сортировку выбором. Оказалось собеседующий такой сортировки не знаел и пришлось ему доказывать что этот код отсортирует массив, в итоге он ушел вбил код на компе у него заработало. Дальше он попросил выбрать данные из двух таблиц в SQL связав по id. Я написал не через JOIN а через SELECT..WHERE. Собеседующий снова впал в ступор. Тут я ему снова доказывал что JOIN это просто сахар для такой записи. Корчое доказать удалось, но потом я сам не пошел к ним работать.
Это синтаксический сахар потому что я могу получить нужный результат и без JOIN, но JOIN значительно упрощает и сокращает код.
Практически всегда можно получить нужный результат другим путем, но реализуется ли оно в потрохах точно так же?
А не наоборот ли, случаем?
select-where — это cross join плюс условия.
Если условие содержит соединение ключей, то cross join можно сократить до inner join.
Если мы говорим о cross join или inner join запись select-where будет по понятности и краткости примерно эквивалентна. Если мы говорим о left join или full outer join то запись select where будет гораздо длиннее и сложнее.

Соответственно когда не было джоинов лепили длинные сложные эквиваленты или бд зависимые запросы. Джоины появившиеся в спецификации SQL эту проблему решили. Поправьте если я не прав.

Профайлер в MSSQL, кстати, преобразовал WHERE в JOIN.

Можно попытаться найти, как это решается в MySQL или Postgres — у них же открыты исходники?
У меня однажды была обратная ситуация. Собеседование состояло из двух частей: с программистом и с руководителем.
С программистом вопросы были прикладного характера, на которые я практически на все ответил, потом еще несколько «практических» (код писать) заданий, с которыми я также справился что называется «на ура».
А дальше предстояло собеседование с руководителем. Я думал, что это будут чисто организационные вопросы, мол какую зарплату хочу, какой график и т.д. А руководитель оказался бывшим программистом и начал спрашивать меня как происходят те или иные вещи на нижнем уровне. Например, как организовано хранение данных в MySQL или как на нижнем уровне передается файл на сайт и т.д. И я «поплыл», поскольку мои знания по большей части прикладного характера, т.е. я знаю, что если по полю БД должен осуществляться поиск, его нужно сделать индексированным, а как это там внутри по кластерам или по страницам разбивается — в этом я не силен.
В общем, забраковали меня тогда, Было очень обидно, поскольку я обладал требуемыми им знания, но мои знания просто не были увидены.

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

Обстановка и условия для решения задачи

Меня попросили решить данную задачу с использованием, своего рода, онлайн блокнота, где мой собеседник накидал задание и наблюдал за тем как я набиваю мое решение

Где тут сказано о том, что задача должна быть решена за максимально короткий срок?
под наблюдением

Тобишь, если к вашему рабочему месту подойдет коллега и постоит рядом минут 5 читая ваш код, вы не сможете работать?
в не комфортных для разработчика условиях

Это вы про «блокнот»?
Собеседование подразумевает ограниченность по времени. Быстрота разработки в 99% случаев приводит к говнокоду. Под психологическим давлением — еще и к говнокоду, на который тратится много времени. Ну и каким нормальным компаниям нужны навыки медленного говнокодирования?
Собеседование подразумевает ограниченность по времени

Да не подразумивает. Одно из моих собеседований длилось 3 часа, 2.5 из которых мы с организатором обсуждали и вместе решали данные им задачи. Никакой спешки, дружественная атмосфера, подсказки, шутки, затупы.
Под психологическим давлением — еще и к говнокоду, на который тратится много времени

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

Это вы про «блокнот»?
Это про наблюдение.
Если судить по вашим комментариям, вы вряд ли это поймёте.
Вы путаете «стоять над душой» и «парное программирование». Последнее — практика XP, которую применяют при работе над критически важными участками кода, сложными алгоритмами, когда один мозг хорошо а два лучше проверяют друг друга. И да, в рамках парного программирования принято меняться местами.

Экстримальное программирование никакого отношения к «экстриму» не имеет.
Если моя работа будет заключаться в поедании супов, то вполне комфортно.
Если судить по вашим комментариям, вы вряд ли это поймёте

Повторюсь, я против того, что разработчик боиться показывать процесс своей работы. Значит разработчик не уверен, значит что то не так с разработчиком.
Процесс работы? а что такое «процесс работы»? Не буду говорить за всех, но я могу за 10 минут набросать костяк скрипта, а потом ещё неделю его обрисовывать проверками, рефакторить, тестить и читать логи.
А могу и исписать полтора бумажных блокнота алгоритмами, связями, крайними ситуациями требующими уточнений и за неделю показать пару моделей, контроллеры к ним и десяток представлений, сделанных по быстрому, для тестов.
Не буду говорить за всех, но я могу за 10 минут набросать костяк скрипта, а потом ещё неделю его обрисовывать проверками, рефакторить, тестить и читать логи.
И каждый день будете показывать как идут дела, правильно?

Ну вот и тут та же ситуация — только в миниатюре.

А могу и исписать полтора бумажных блокнота алгоритмами, связями, крайними ситуациями требующими уточнений и за неделю показать пару моделей, контроллеры к ним и десяток представлений, сделанных по быстрому, для тестов.
Та же самая ситация и здесь. Вы можете писать код прямо «в онлайн блокноте» или на бумажке, обсуждать его вслух или добавлять комментарии. Но к комцу собеседования код должен быть. Работающий, желательно.
Процесс работы? а что такое «процесс работы»?

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

Вы молодец, но к чему это было сказано?
Правильно — но потому и собеседования разные. Впрочем оказывается что процессы (и, соответственно, собеседования) скорее зависят от того в каком мире живёт компания и меньше — от специфики самой компании. Facebook, Google и Microsoft гораздо ближе друг к другу, чем, скажем, SAP или .

Было бы странно если бы собеседующие подбирали на собеседованиях людей под чей-то чужой «процесс»?
Умение не путаться в мыслях, когда прямо над душой стоит человек и пристально наблюдает через плечо.
По-моему, это чисто социальный скилл, стрессоустойчивость, если хотите.
С умением решать задачи ничего общего не имеющее.
Я считаю, что хороший (именно хороший) специалист, не боится того, что кто то наблюдает за его работой. Обычно новички и разного рода шарлотаны бояться того, что клиент видит процесс его работы. Это хорошо заметно в сфере ремонта помещений, когда работники резко против присутствия клиента на объекте.
Если на основе только одного этого задания формируется отказ — это неадекватный наниматель. У человека в момент собеседования и так присутствует волнение. А тут неожиданно создается еще более экстремальная ситуация и на ее основе принимается решение. На мой взгляд — крайне неудачный подход.
Согласен. Собеседование не должно состоять из 1 вопроса и 1 ответа.
Я так понимаю это был pre-screen: попытка проверить умение человека вообще программировать, в приниципе. Дальше — вопросов было бы больше.

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

Очень тяжело оценивать всё это не зная какие именно подсказки давались.
попытка проверить умение человека вообще программировать

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

У нас вообще есть чёткое правило: после первого собеседования на позицию «Software Engineer» в отчёте должны быть 10-15 строк кода, написанных кандидатом. Всё остальное обсуждается, этот пункт — вообще без вариантов.
Значит мы по разному понимаем понятие «вообще программировать». Я, обычно, просил у кандидатов их open source наработки. Такие проекты пишутся спокойно, качественно, потому они идеально подходят для оценки кода.
Если кандидат вообще имеет какие-то «open source наработки», то он, во-первых, скорее всего про это скажет, а во-вторых его не испугает задача, которая буквально «убила» автора обсуждаемой статьи. Исключения — случаются (пришлось как-то нам отшить кандидата, который великолепно разбирался в таймингах разных железных протоколов, но не знаю алгоритмов от слова «совсем»...), но они крайне редки.

90% кандидатов за душой не имеют ничего, что можно было бы «пощупать».
которая буквально «убила» автора обсуждаемой статьи

Ну автор утверждает, что дело не в сложности задачи, а в накале страстей.
Заметим, что он это утверждает в статье где первое приличное решение описано как «пример номер 3», придумано «на следующее утро», а хорошее решение не описано вообще.

Если бы то же решение было выдано в первые пять минут прямо на собеседовании, а после наводок собеседующего был бы написан код с O(1) затратами памяти (не такой и сложный, согласитесь), то никакого «накала страстей» и не было бы, а? А был бы ещё один новый сотрудник, скорее всего…
Если бы то же решение было выдано в первые пять минут прямо на собеседовании… то никакого «накала страстей» и не было бы

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

Ну а что часть хороших кандидатов потеряется — работодателю-то какая разница? В случае если соискателей достаточно — это хороший подход. Если вы мелкая контора «Рога и копыта» и к вам никто не идёт — ситуация другая, тут, конечно, придётся действовать мягче.
Думаю, именно мелкие конторы заинтересованы в такого типа тестировании. Крупным более важно качество кода, а не скорость его написания.
Опять двадцать пять! В этой задаче и планировалось обсуждать качество кода, а не время его написания. Ну там за десять-пятнадцать минут кандидат пишет какое-нибудь решение, потому вы его обсуждаем и улучшаем. Кто ж виноват что первый этам затянулся на два дня и окончился только на следующий день?

А такое «качество кода», когда 20 строк пишутся две недели даже крупные компании себе позволить не могут… пусть даже эти 20 строк будут супергениальными.
Разные бывают ситуации. Иногда этих 20 строк приходится ждать два года, а то и больше. Другое дело, что значит, без них можно было обойтись, и были дела поважнее.
Бывает, что и исправление на две строчки делается месяц. Всё бывает. Важно, чтобы это было не правилом, а исключением.

В данном случае речь идёт о 20 строчках, которые пишутся в пять минут и про которые можно доказать, что решение — ассимптотически оптимально. И это — типичный случай. И вот самое важное (как я уже говорил) — чтобы эти типичные случаи разруливались нормально.
Вы правы не на 100%, а на все 200%. С умением решать задачи этот скилл связан слабо. А с умением работать в команде — очень сильно.

Вы сколько времени планируете потратить перед тем, как послать код на ревью? День, два? Нет же, сорее речь будет идти о минутах. Ну о часах, от силы.

Да, тут всё более «сжато» — но и задача ведь игрушечная, согласитесь.
Дело ведь не в том, что код будут смотреть и критиковать, а в том, что само наблюдение выбивает из колеи и не позволяет сосредоточиться.

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

Если задача «в уголке» решается за полчаса давать её нельзя: даже хороший кандидат будет решать её часа два, а то и вообще психанёт и не сможет её решить.

Это-то как раз понятно.
По-моему, это чисто социальный скилл.
Да (точнее, психологический).
С умением решать задачи ничего общего не имеющее.
Ну как… Утверждение слишком сильное, из разряда «никогда», поэтому вынужден сказать «нет». В общем-то IRL нужда в подобных навыках иногда всплывает, и мера их нужности зависит от специфики места работы.
Да, верно, псхологический.

Я согласен со спецификой места работы, возможно, где-то этот скилл полезен или даже необходим.
Но я лично ставил себя на место сферического разработчика в вакууме — когда есть возможность на несколько часов уходить в «поток».
Интересно где это платять за работу, где можно всё делать «уходя в поток». Нет, я бы тоже так хотел. Но, увы, оказывается, что 90% времени занимает рутина, которую нужно делать «под давлением». Увы.
В том-то и дело, что стоит. Или за спиной или сбоку стоит. И просит показать. Вот прямо тут и сейчас? Что будете делать?
Чем-то похоже на первое решение:
static void Connect(Node x){
    Connect(x,new List<Node>(),0);
}
static void Connect(Node x,List<Node> rightLine,int level){
    if(x==null) return;
    if(level==rightLine.Count){
        rightLine.Add(x);
    }else{
        rightLine[level].neighbor=x;
        rightLine[level]=x;
    }
    Connect(x.left,rightLine,level+1);
    Connect(x.right,rightLine,level+1);
}

Сложность O(size), память O(depth).
Когда давно услышал фразу, что умение решать такие задачи говорит о том, что соискатель умеет решать такие задачи и ничего более. Никогда за 10 лет не сталкивался с тем, что вот такого рода задачи надо вот так на коленке решать.
У сотрудника был опыт решение бековой проблемы на чужом ноуте, в другой стране через впн, но при этом всё равно, кофе, IDE, сначала сесть, успокоиться, разрисовать и решать.
Мне так же не приходилось за последние 10 — 12 лет сталкиваться с чем-то подобным. Хотя попадались и задачи по машинному обучению. Не было ничего сложного, была нехватка знаний, иногда. Последняя покрывалась неплохим образованием, опытом и прочтением нужной литературы.
Задача простая, решить ее можно хоть на коленке, хоть стоя на ушах. Не увидел причин для паники автора при решении этой задачи, видимо дело было в банальной спешке.
Помыть посуду — один из моих любимых способов подумать )
А мне в туалет сходить. Закинуть голову к верху и подумать :)
Смотреть за процессом решения задачи — очень плохая практика. Это как удар ниже пояса. Понимание того, что тебя оценивают по заведомо не готовому коду, не дает сосредоточиться на поиске решения. В итоге унижение неизбежно, даже если с задачей справляешься.
Вы как будто в воду смотрите. С каждой написанной строчкой я думал, как бы не сморозить, как бы не написать откровенную чепуху, это просто ужасно блокирует ход мыслей.
Значит собеседование выполнило свою роль фильтра, по параметру «не брать кандидатов, которые боятся сморозить чепуху и стесняются своего кода». а так же по параметрам алгоритмического мышления, ide-независимости, способностям к быстрому анализу и синтезу решения.
Является ли такой фильтр правильным при найме разработчика — вопрос дискуссионный. Мне кажется что все эти навыки необходимы в той или иной степени, возможно их не стоило смешивать в одном тесте. Вопрос такой системы фильтрации вы наверное могли бы обсудить с HR отделом компании если бы прошли собеседование. Но раз компания существует и нанимает разработчиков — значит такая система отбора имеет право на жизнь.
Последнее время задумываюсь о таком новом направлении на моем YouTube канале, как решение задач в реальном времени и демонстрация этого процесса зрителям. Меня не беспокоит лажа или откровенно глупые решения, как это не беспокоит игровых стриммеров. Отнеситесь к написанию кода в том же русле, думаю это не только позволит вам проходить такого рода собеседования, но и не бояться совершать ошибки.
как решение задач в реальном времени и демонстрация этого процесса зрителям. Меня не беспокоит лажа или откровенно глупые решения, как это не беспокоит игровых стриммеров.

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

Сплошь и рядом.
обычно те кого не беспокоит глупые решения и лажа в собственном коде

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

Вы намекаете на то, что я плохой программист?))
Профессионал сначала оттачивает навыки до совершенство

Навык чего, решения задач? Новичкам интересно посмотреть, как опытный программист «в живую» решает незнакомую ему задачу, спотыкается, ищет решения, использует различные подходы для отлавливания ошибок, рассуждает, а не смотреть как лектор записывает на доске изо дня в день одно и то же, без ошибок и запинок.
Меня, кстати, почти всегда на анкетировании оставляли подумать — закончишь, дай знать.
Так, собственно, процесс тут и интересен, само решение-то вполне стандартное. Как ещё можно оценить способность решать задачи, как не наблюдая и участвуя в процессе?
Каждая проверка в той или иной степени унизительна, с этим приходится считаться, это и есть профессионализм — оцениваешь ты, оценивают тебя. Это нормальная ситуация, а не повод для истерики.
Почему нельзя дать более объемную задачу на пару дней, чтобы соискатель мог спокойно ее решить?
У объемной задачи другие цели. По моему скромному опыту это обычно следующий шаг собеседования. Но какой смысл давать объёмную, если соискатель не справился с простой?
Да, кстати, мне в интервью на позиции, где алгоритмизация не была сильной стороной, давали сразу объёмные задачи.
Так может быть он не справился с простой из за стресса, а в спокойной обстановке напишет ее легко. Зачем рисковать потерей кандидата, если можно дать объемную задачу?
С чего вы взяли что это «потеря»? Очевидно, что у работодателя свои критерии полезности и стопы. И работодателю и ХРу и интервьюерам выгодней, если соискатель будет нанят. Если в такой ситуации его отсеивают, то можно почти точно сказать, что в этом конкретном случае он не подходит, несмотря на всю мудрость задним умом.
Если в такой ситуации его отсеивают, то можно почти точно сказать, что в этом конкретном случае он не подходит, несмотря на всю мудрость задним умом.


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

Объемная работа исключает фактор стресса, что позволяет не терять определенный процент кандидатов. Конечно, если работа заранее предполагает постоянный стресс, то тогда нужен устойчивый человек, но я в IT сфере еще не встречал таких требований.
Очень хороший пример, в нём компания наняла подходящего ей соискателя, а он нашёл подходящую ему работу. Не вижу тут проблемы.
Непонятно, как объёмная работа может исключить фактор стресса. Да, тебя не проверяют в реальном времени, но потом твой объёмный код будут оценивать несколько человек, и они уж точно найдут там косяки. В таком свете, мне кажется, простая задачка с подсказками вызовет даже меньше стресса. Фактор стресса при оценке невозможно исключить в принципе.
боритесь со своим стрессом
image
Непонятно, как объёмная работа может исключить фактор стресса.
1. Вы пишете код в комфортной для себя обстановке, у вас есть возможность показать себя и учесть всё необходимое по ТЗ.
2. Пока вы пишете код, вы не переживаете, считает ли интервьювер, что всё затянулось. И вообще, полчаса — это уже много? Ой, он начал зевать, у меня всё плохо?
При объёмной задаче косяки идут в комплекте, да, но ничего страшного. Вроде как наоборот, у компании будет более полное представление о вас. Честно и справедливо.
И вообще, полчаса — это уже много? Ой, он начал зевать, у меня всё плохо?

Ну и фаза луны в день собеседования подкачала.

А если в компанию требуются суровые кодеры, а не «комплексующие непризнанные гении»?
А если в компанию требуются суровые кодеры, а не «комплексующие непризнанные гении»?
Я-то не против, пусть набирают кого считают нужным. Я старался объяснить, как объёмная работа может если не исключить, то минимизировать фактор стресса.
Вы только что лишили всех фрилансеров отговорки, почему проект не сдан во-время. Это раз.
Два — простые задачи в первом круге интервью не исключают сложных во втором.
Другой вопрос — а зачем давать человеку сложную задачу, если он с простой не справился, и вообще дрожит как осиновый лист? Нет, конечно можно, если с кандидатами совсем всё плохо, но когда не справился один из десяти, проще продолжить с остальными и не тратить ресурсы.
И снова — стресс возникает не из за того, что вас о чём то спрашивает ещё 10 минут назад незнакомый человек. Он возникает в конечном счёте от страха, что могут не взять. И это никак не исключить.
Я не совсем понимаю как страх и сильная дрожь связанны со ступором, с путаностью в мыслях? В моем случае я страха не испытывал, лишь ступор. Провалил я собеседование еще и от того что осознал, что не в состоянии решить задачу в данной обстановке хотя мой внутренний голос просто кричал что задача проста. Например я отчасти испытывал чувство злости на глупость ситуации и на себя.
А ступор по вашему просто так, ниоткуда, взялся?
Ступор — это подсознательная реакция организма на опасность. Может вы лично и не испытывали страха, но ваше подсознание явно испытывало. А внутренний голос оказался на самом деле внешним :)
Как ещё можно объяснить ступор во вполне обычной ситуации?
Обычной для вас. Страх это реакция организма на внешний раздражитель. Есть два типа реакции на такой раздражитель. Такого понятия как подсознание испытывающее страх быть не может. А вот раздражитель влияющий на способность логичиски мыслить это вполне реально. Для кого-то это шум, для кого-то это чавкающий коллега. Вы спутали состояние ступора и шока, его легкое проявление. Под ступором я понимаю состояние в котором вы got stuck, со всеми вытекающими и не более.
Приведу пример, который сам встречал не раз. Кандидат проходит интервью в двух разных компаниях из одной отрасли… В компании Б дали задание на пару дней, которое кандидат спокойно сделал дома и полностью удовлетворил требования работодателя.

Другой пример, когда подходящих компаний десятка два и каждая пытается дать задание на пару дней на самом первом интервью… Особенно, когда кандидат ещё не уволился с прошлой работы и у него полно других дел, кроме поиска работы. Нет, я понимаю, если это компания мечты всех кандидатов, аля гугл. Но удивляет уверенность работодателей особо ничем не примечательной компании, что их вакансия единственная на рынке и кандидат потратить неделю на объемные задания чтобы лишь попасть на второе интервью, вместо того чтобы за это время пройти десяток собеседований в других компаниях. Во многих случаях опытные разработчики просто забивают на такие задания.
С учетом нехватки высококвалифицированных кадров (я про IT сферу) чаще всего наоборот и испытательный срок никто не отменял.
Вопрос поставлен правильно, но «правильный» ответ на него не столь однозначен и разнится от фирмы к фирме и от позиции к позиции.
Зачем рисковать потерей кандидата, если можно дать объемную задачу?
Вы так говорите, как будто потеря кандидата — это катастрофа. Ну потеряем мы сколько-то, проблем-то. Если оставшихся хватает — всё в порядке, если нет — подходы нужно менять…
Объемную задачу востребованный соискатель просто не станет решать, разве что это работа его мечты.
Если человек способен решать необходимые задачи, каким образом он приходит к решению интересовать не должно, это уже личное дело разработчика. Понятно, что работодателю интересно поковыряться везде, но должны быть рамки. Разработчик в итоге справился с задачей — он способен решать такие задачи, все просто.
Смотреть за процессом решения задачи — очень плохая практика.

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

Понимание того, что тебя оценивают по заведомо не готовому коду, не дает сосредоточиться на поиске решения.

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

пс. никогда не учавствовал в олимпиадах.
Зависит от человека. Если ему не комфортно — это так же многое говорит о нем.
как человек думает, какие решения он принимает, и почему он их отбрасывает.
А зачем это работодателю? Разве всё в конечном счёте не сводится к тому, чтобы работа была выполнена? Есть другие, более продуктивные (на мой взгляд, конечно) критерии оценки работы, нежели количество рассмотренных решений и причины их отбрасывания.
А зачем это работодателю?

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

Разве всё в конечном счёте не сводится к тому, чтобы работа была выполнена?

Нет, для таких вещей аутсорсеры есть. Выставили условия, получили (или нет) результат.

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

«Почему сделано так» — это не критерий оценки работы, это критерий для включения результата в общий код.
В частности, глядя за процессом, можно пытаться оценить, какие вещи человек будет учитывать в повседневной работе, а какие — нет.
Разве код сам не расскажет, что было учтено, а что нет? А если есть сомнения, почему не спросить: «Что вы думаете по поводу X вот здесь?»

Нет, для таких вещей аутсорсеры есть.
Что дополнительно требуется от собственных разработчиков, сотрудников?
Разве код сам не расскажет, что было учтено, а что нет?

Не всегда. В частности, если человек учел какую-то побочную ситуацию, а потом отбросил ее как невозможную, то в коде об этом не будет ничего (особенно в коде на собеседовании).

А если есть сомнения, почему не спросить: «Что вы думаете по поводу X вот здесь?»

Эти вопросы как раз (а) занимают много времени и (б) их можно задавать только после завершения кода.

Что дополнительно требуется от собственных разработчиков, сотрудников?

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

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

Тогда выполненная работа плюс соответствие требованиям проекта (code style, покрытие тестами и т.п.)?

Этого недостаточно. Ни то, ни другое не помогает для оценки design decisions.
(а) Найм нового сотрудника — это серьёзное вложение, и будет очень странно, если у компании не окажется времени на вопросы.
Закон Паретто никто не отменял. Из нашей статистики: на 100 кандидатов редко когда больше 2-3 будущих сотрудников. Говорить с каждым из них по многу часов — это элементарно дорого. Особенно с учётом того, что большая их часть программировать не умеет от слова «совсем». Потому хочется сделать «первычный отсев» максимально дешевым.

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

Существует такой код на интервью и существуют такие вопросы к нему, при том, что код хорош.
Существует такой код на интервью и существуют такие вопросы к нему, при том, что код плох.
Существуют вопросы, которые стоит задавать только если код плох.
Существуют ли вопросы, которые можно задать только если код хорош — это я не знаю. но подозреваю что тоже да.
Мне как-то предложили решить тестовое задание (не маленькое), с записью процесса работы на видео (скринкаст). Я ответил, что запись меня отвлекает и нервирует, но могу сделать запись только основных моментов. На этом потенциальный работодатель испарился. Хотя даже если бы я хотел сделать запись, мне было бы очень не комфортно работать, т.к. видеозапись вместе с запущенной IDE очень нагружает ноутбук. Предпочитаю с такими работодателями не иметь дела.
Почти 10 тысяч часов с регистрацией рабочего времени скриншотами. Кажется я чудом выжил и сохранил рассудок.
Собственно в этом коренное отличие практики собеседований у нас в ABBYY от описанной (которую используют, afaik, ещё и в Google, и в MS, и в booking). У нас любят дать задачу и выйти из комнаты (причём даже сказать, что на решение есть 100500 времени).
Таким образом мы даём лишний шанс талантливым, но не слишком самоуверенным кандидатам.
Я тоже проваливал подобное собеседование с «блокнотом» и т.п. Плюс, интервью проходило на английском языке. Часть задачек решил, но на одной застопорился.

А потом погуглил чувака, который меня собеседовал и узнал, что он в прошлом ИТ-олимпиадник из СНГ. Отсюда и такой подход к собеседованию, как к олимпиаде :)

Может, и хорошо, что провалил, по крайней мере, сейчас от меня на работе требуется думать, а не решать задачки на скорость.
Эта глупая игра под названием «собеседование». Мне кажется, это вечный бич айтишников.
Работодатель не знает чего хочет, точнее знает, т.к. начитался умных книжек и напридумывал (нарыл в инете) каких-то задач, которые в реальной работе почти никогда не встречаются.
А соискатель попадает в стрессовую ситуацию, пытаясь решить глупые задания из книги «9000 задач, которые вам никогда не пригодятся».
По факту получается, что ищут человека, который будет выполнять работу качественно и вовремя (с некоторыми вариациями), но по собеседованиям складывается впечатление, что им нужен тот, кто умеет решать такие задачки в блокнотике.
Исключения, когда ищут реально крутого программиста, которого разбуди посреди ночи и дай листик, он тебе напишет самую оптимальную реализацию самого сложного алгоритма, который лежит в основе какой-то крутой хардварной штуки, — только подтверждают правило ;D
У меня было похожее собеседование. По скайпу. На .net программиста.
Сказали пиши код прямо в скайп — никаких Visual Studio.
Код написал, кое как, отправляя в скайп куски кода. Визуально все проверил — вроде правильно. Получаю ответ — у тебя прога мало того что не скомпилится, да и еще не вернет правильный ответ. Типо не справился, следующий вопрос.
Меня разозлило это. Скопировал код в студию, запускаю — все ОК, собралось. Выводит правильный ответ.
Кто меня собеседовал даже не стал слушать меня, мол он лучше знает и вообще, тут оценивают мои знания — а не его. Начальник умный, ты дурак.
Потом тоже самое было с SQL кодом, мол напиши запрос. Написал, тоже я дурак. Проверяю на БД, накидал несколько таблиц, данных тестовых. Все верно вывелось! Не хочет даже смотреть.
А потом как начал меня унижать, по каждой фигне. И за все собеседование я его на 3 буквы не послал, думал может проверяет стрессоустойчивость. А нет, оказалось просто он мудак, который самоутверждается за счет таких провенциальных соискателей, сам он типо «москвич» уже.
В таких случаях стоит прерывать собеседования со словами «ваша шарага мне не подходит». Потому что работать в компании с такими вот «умниками» вам нервных клеток не прибавит.
Не, зачем оскорблять, просто не вступать в спор и аккуратно выйти из диалога.
Выйти из диалога жертвой? Человек пришел на собеседование. Не за подачкой, это раз. Если сотрудник работодателя, который проводит собеседование, не в состоянии дать аргументированной оценки знаниям соискателя, а также проявляет какое-либо неуважение, презрение и т.д., то пусть катится куда подальше. К чему лебезить и раболепствовать?
Всё зависит от настроя. Если вы чувствуете себя уязвимо и неуверенно, то агрессивное и непрофессиональное поведение весьма ранит.
Если вы успешны в карьере и в социальной жизни, то вам легко не принимать идиотов на личном уровне и избегать тратить на них время и фокус.
К чему я и призвал. Просто проявление уважения к тем, кто не был замечен в аналогичном деле, это сродни ответу добром на зло. Порождает новое зло. ;)

Тем более, успешным вы быть и можете, но многие люди в IT (говорю за себя и многих моих друзей) после нескольких лет работы на одном месте начинают неуверенно чувствовать себя на собеседованиях, считая, что мало знают, что появился некоторый застой в знаниях.
А если вас собака облает — вы, наверное, встанете на четвереньки и залаете на неё в ответ?
Не угадали. Все же я человек разумный, а не собака. И нахожусь в социуме. Но ваше право, если вам грубят, утереться и пойти дальше ))
Скайп иногда в коде символы на смайлики заменяет и не очень понятно как оно потом у собеседника обратно скопируется.
2 восклицательных знака в начале вставить надо
!!
function (y) {}
Оформляешь в скайпе код в два тега {code} void SomeMethod(){} {code} и текст будет без смайлов и моноширинный.
Рекурсивное решение с использованием стека.
struct leaf {
    public:
        int value;
        leaf* right;
        leaf* left;
        leaf* neighbor;

        leaf(int v, leaf* r, leaf* l) :
            value(v), right(r), left(l), neighbor(nullptr) {};
};

void find_neighbors(leaf* node, std::stack<leaf*> & stack)
{
    if (node == nullptr) {
        return;
    };

    if (!stack.empty()) {
        node->neighbor = stack.top();
        stack.pop();
    };

    find_neighbors(node->right, stack);
    find_neighbors(node->left, stack);
    stack.push(node);

    return;
}


Сложность O(N), память O(logN).
Не будет работать даже для тривиального случая дерева с двумя дочерними узлами.
Даже если пофиксите, то память будет не O(logN)
Вы неправы, вот доказательство ideone.com/OjNWMU.
Расход памяти вычисляется как максимальный размер стека, и равен он, как несложно догадаться, глубине дерева, которая для сбалансированного бинарного дерева равна log2N.
Аналогичная была ситуация, когда пытался на собеседовании с помощью ручки и листа бумаги написать структуру для хранения очереди на абстрактном языке без ссылок, указателей и динамических массивов. Промучился пол часа и сдался. Вышел из офиса и, пока переходил улицу, придумал решение, но возвращаться было уже как-то неловко.

Собеседование было, к слову, на вакансию PHP-программиста. До сих пор не понимаю — нахрена?
Мне кажется, что второй вариант может быть использован для обработки уже готового дерева с каким-то произвольным размещением в памяти.
В массиве достаточно разместить только один слой узлов (листьев), по памяти будет заведомо лучше чем O(N).
Прямо вот бесят такие и подобные задачи, особенно когда надо решить за время без кофе и перекуров на «подумать». Даже если их можно решить за 20 строчек кода. Даже тот же «FizzBuzz» — элементарная задача, но, что она дает на собеседовании?
Показывает, что соискатель хотя бы циклы и ветвления понимает. Я собеседовал много людей и как ни странно, многие не могут fizzbuzz написать, хотя рассказывают байки о большом опыте работы. Нафиг таких нанимать?
Честно, я не могу представить человека, который считает себя программистом и не способен написать задачу на 3 условия.
Это значит, что вы никогда никого не собеседовали. Я таких видел (на собеседованиях) в изрядных количествах.

На что они претендуют, идя на вакансию программиста — науке неведомо.
А мне понравилось:

  • Расскажите про свой опыт разработки Highload приложений?
  • Нет такого опыта
  • Та у вас же ж в резюме написано
  • Ну все пишут, вот и я написал
Ну я например себя считаю посредственным в плане алгоритмов, потому что про обходы графов когда-то слышал, но в чем отличаются — хз (подозреваю, что порядком вызовов на текущем уровне и на рекурсивном дочернем), квиксорт знаю, как работает, корректную имплементацию скорее всего накидать смогу, но какое-нибудь B+ дерево реализовать (помню там повороты какие-то, иногда хитрые) уже не смогу. И я думаю аткой "Блин, а можно вообще с такими навыками устроиться хорошо? Не нормально, а хорошо? А где бы тогда самообучиться, а то времени никогда не хватает". А что FizzBuzz не может кто-то написать мне всегда казалось плохой шуткой.
Если бы. Я помню кандидата, на котором я был "тенью" (shadow: это когда более опытный товарищ обучает тебя интервьюировать, а ты сидишь в углу и молчишь как рыба об лёд — разговаривать запрещено, так как уже само нахождение ещё одного человека кандидата немного напрягает, а если этот второй ещё и говорит, так и ваще).

Так вот: о тонкостях работы с нитями, инициализаторами и прочим — разговор мог длиться часами (я потом основному интервьюеру указал на места, где кандидат говорил правду, а интервьюер "промахнулся). А потом… потом была задача "развернуть слова в строке не используя дополнительную память" (может знаете — это, конечно, не FizzBuzz, но и весьма далеко всё-таки от того, что тут обсуждается).

Если вы думаете, что кандидат в ней "утонул", то вы ошибаетесь. За 15 минут на доске (это давно было, тогда ещё на досках программы писали) кандидат не смог изобразить первую часть — это ту, которая должна была просто всю строку развернуть! Я не издеваюсь! До второй (когда "второй проход" "разворачивает" уже сами слова) дело просто не дошло...

После этого я понял почему есть железное правило: "Кандидат. Должен. Написать. Код. Точка."

Какой код, сколько того кода (поверьте: B+ дерево редко кто на интервью просит реализовывать, так как там много тонких моментов) — это уже на усмотрение интервьюера. Но строк 10-20 кода должно быть. Обязательно. Без вариантов.
Вот прям спорный момент, очень спорный. Оказался как раз в такой ситуации, где просили написать код ручкой на листочке. На интервью было 3 человека, и мне дали подобную задачу на алгоритм. И я тоже не смог его написать, потому что просто было очень сложно сосредоточиться. Разумеется, дома решил эту задачу как нефиг делать.
Собеседование — это само по себе большой стресс для интроверта (которыми, в большинстве своем являются программисты), а еще и непроизвольно пытаешься понравиться, тут не до кода, а в особенности не до кода на физическом носителе (доске).

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

Я понимаю что интровертам может быть сложно общаться с HR, но с другим программистом то какие проблемы?
Нет, лучше им выдавать ручки и бумагу.

Интервьюеры бывают разные, сложно понять что движет человеком. Может он за счет вас пытается самоутвердится. А когда работаешь в команде и когда коммандный дух силен то никакие стрессовые ситуации на вашу продуктивность не влияют. Не сравнивайте две совершенно разные ситуации.
Не сравнивайте две совершенно разные ситуации.
С чего это они вдруг совершенно разные? Если вы идёте устраиваться на работу, то вы вдруг становитесь интровертом и начинаете дрожать как осиновый лист, но когда вам нужно встретится с представителями другой команды и «продать» вашу идею — то вы прям становитесь «мистером уверенность»? Странная логика.

Для места, где вы сможете «запереться у себя в комнате и нафигачить кучу гениального кода» подобный подход, возможно, и не годится, но для работы в реальной компании, где написание кода — самая важная часть, конечно, но которая обязательно должна быть дополнена умением этот код «продать»… не вижу ничего страшного в том, что подобный интроверт будет искать работу в другом месте, где его способности будут полезнее…
Послушайте уважаемый, я не буду себя утруждать и отвечать на ваш вопрос, потому что вы опять ходите кругами и льете из пустого в порожнее. Вашу точку зрения вы уже высказали, все ее приняли к сведению, вы превели ваши аргументы их тоже рассмотрели.

Но вот бесконечно пытаться вдолбить ее собеседникам это уже как-то не совсем прилично, имейте пожалуйста уважение.
нужно встретится с представителями другой команды и «продать» вашу идею — то вы прям становитесь «мистером уверенность»

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

которая обязательно должна быть дополнена умением этот код «продать»

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

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

Вы знаете, что такое интроверсия? Это не когда человек плохо работает в стрессовой ситуации, а когда человеку сложно общаться с незнакомыми людьми. Проработав в компании пару месяцев привыкаешь к коллегам и можешь общаться с ними по работе уже нормально. Именно общение с незнакомыми людьми, тем более если нужно показать им свои навыки и не облажаться и создаёт стрессовую ситуацию для интровертов.
По работе в стрессовой ситуации тоже есть две крайности — одни люди паникуют и впадают в ступор, а у других наоборот активизируется работа мозга и он может сделать больше и быстрее, чем в нормальной. И с интроверсией/экстраверсией это никак не взаимосвязано.
И ещё: не думайте про себя плохо! Да, возможно вам перед тем, как устораиваться на работу в хорошую компанию нужно будет немного подтянуть что-то где-то (почитать немного про те же обходы графов и прочее), но пусть вас статистика (типа "в Гугл проходит два-три кандидата из сотни") не пугает!

Она действительно такова, но это вовсе не значит, что в Гугл берут только уникумов, которых 2-3 человека на 100 программистов.

Нет, тут ситуация совсем иная. Хороший кандидат — он подаст заявление в Гугл и Майкрософт (ну или, в Москве — в Яндекс и Интел), в одной из компаний получит добро — и будет там работать. Плохой же кондидат будет собеседоваться в десять, двадцать, тридцать, сто компаний — пока наконец-то ему удастся "проскочить" и его куда-то возьмут. Потому среди кандидатов количество неадекватов всегда резко повышено по сравнению с ситуацией "в среднем по рынку". Конкретно вашего случая я не знаю, но уверен, что вы находитесь куда выше на шкале от "полный кретин" до "ваще гений", чем вам кажется!
Спасибо на добром слове :) Что касается разворота строки — не во языках это просто. Например на том же шарпе без ансейфа не сделать, ибо строки иммутабельные. Если же речь про разворот любого массива, то действительно удивительно, что человек не справился. Я когда на джуна проходил собеседование, и то отвечал на вопросы типы как работает GC или как разворачивается конструкция using, или как цикл foreach очищает ресурсы (это тоже, что for-с-ресурсами в Java). Очевидно, что человек на более высокую должность должен все это лучше знать. Да, он мог забыть какие-то студенческие вещи, которые ему не пригождались (типа теоремы Бома-Якопини и прочее теоретизирвоание), но практически навыки определенно должны быть выше. Я не бог весть какой пример, но даже мне приходилось писать темплейты для анролла циклов, для повышения производительности, иkb эмит кастомного IL, чтобы обойти ограничения C#. Сейчас есть больше рассказать обо всем этом. Плюс фоновое изучение всяких прологов и лиспов дает новое понимание пользы от делегатов (указателей на функции), монады, обработку ошибок, абстракция на уровне алгоритмов — когда логически похожие алгоритмы объединяют в один, а разницу в подходах суют в делегаты, получается компактно и красиво, хотя для непосвещенного иногда сложно для понимания, когда из 6 параметров 5 — делегаты, причем дженерик на 3 типа определен, и они там хитро взаимодействуют (чтобы все работало как нужно), то нужен действительно небольшой опыт написания на ФП чтобы не запутаться.
Очевидно, что человек на более высокую должность должен все это лучше знать.
К сожалению многим — неочевидно. Не знаю как это работает, но такое ощущение, что во многих компаниях тимлид под которым работают человек 10-15 кода не пишет вообще, только «общее направление» задаёт.

Как это работает — не знаю, я в таких компаниях не работал. Но подобные кандидаты приходят регулярно.
Да все способны.
Просто не все способны взять себя в руки и написав хотя бы протестировать перед тем как нести показывать. А это уже то, на что стоит обратить внимание.
Задача обманчиво слишком простая, и пару мелочей обычно может не заметить даже опытный. Но опытный сперва проверит, увидит и исправит. А неопытный х%як, х%як и в продакшен.
На мой взгляд, вполне адекватная задачка. Думаю, автор ошибся только в том, что не стал сразу писать самый тупой вариант с рекурсией. Кстати, где там О(2^n) в решении «в лоб»? Разве что n — высота дерева…
То, что вы прошли, я бы назвал стресс-тестированием, и к тестированию реальных способностей сотрудника оно не имеет никакого отношения (ну разве что к способностям выживать в похожих условиях, типа «дедлайн + стоящий над душой ПМ/лид»).
Я вас умоляю, какое это стресс-тестирование? Обычное милое собеседование.
И вообще в повседневной работе парное программирование, когда другой разработчик смотрит, как ты пишешь код — обычная практика. Профессионал не имеет права относится к этому как к стрессу.
Ну да. Вы видимо никогда не бывали ни в той ни в другой ситуациях. Я вот например почти каждый день работаю в паре, благо скрум у нас. Поверьте мне на слово, ничего общего с парным программированием данное задание не имеет. Работа в паре подразумевает смену ролей каждые Х минут. Там даже сама суть отличается, дескать когда ты печатаешь, то процесс созидания не так глубок как когда просто сидишь, смотришь и размышляешь. А тут своего рода подавление всякого созидательного процесса из за нависшей над душой личности, которая кстати, не произносит ни слова пока ты сам пытаешься размышлять вслух, а ты в это время стараешься уловить как она реагирует на каждую строчку, ибо как раз привык работать в паре. Не сравнивайте бараньи рога и северное сияние.
Вы видимо никогда не бывали ни в той ни в другой ситуациях

Почему же вдруг? Я сменил пару месяцев назад работу и прошел десятки собеседований, бывало до трех собеседований за день (у меня было время и я хотел выбрать). Были и собеседования онлайн, где я в онлайн-блокнотике пишу код и тет-а-тет и очень странные где прям в комнате, где проходило собеседование собирали шкаф и громко стучали молотком.
А уж парное программирование — обычная практика. Так чего сложного в том, когда ты сидишь дома, в любимом кресле, за любимым компьютером с вкусным чаем и программируешь?

а ты в это время стараешься уловить как она реагирует на каждую строчку

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

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

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

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

Видно, что автор творческий человек. А компания, похоже, искала человека, натасканного на типовые задачи.
Видно, что автор творческий человек.
Откуда видно? Из собеседования — нифига не видно. До тривального, простейшего, практически очевидного решения он дополз на следующий день. Это — творчество? Я вас умоляю.

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

А компания, похоже, искала человека, натасканного на типовые задачи.
Нет. Она искала человека, который не будет делать косяков в простых задачах. Это не одно и то же.

Я прямо и откровенно говорю кандидатам на собеседовании: да, у нас интересная работа. Да, мы занимаемся и наукой тоже. Но статьи и прочее — это достаточно небольшая часть вашей работы. Если вы упрётесь в задачу, с которой вы не совладаете — у нас десятки докторов наук, математиков, статиcтиков и т.д. и т.п. Найдём, поможем, сделаем как надо. Не бойтесь.

Но гораздо важнее — чтобы вы не засунули нам куда-то решение в O(N3), там где элементарно делается O(N log N) или не потратили памяти на два порятка больше, чем нужно, в простых задачах. Просто потому что доктора наук их вам помогать решать не будут. Тут уж, извините, вы всё должны делать сами.

Не бывает такого, чтобы все задачи были творческими. Рутины — всегда больше. И потому «творческий человек» — это хорошо. Это просто замечательно. Но при условии, что он рутинные задачи умеет решать тоже.
UFO landed and left these words here
А зачем вашим кандидатам работать у вас, если они могут спокойно себе писать O(N3) код и получать большИе деньги.
Вот и я думаю: а с чего это кандидаты ломятся в Apple, Google, Microsoft, Yandex и тому подобные компании, где «изуверские собеседования», а не зашибают «больши́е деньги» своим O(N3) кодом в каких-нибудь конторах «Рога и Копыта»?

Я был бы счастлив, если бы подобных кандидатов вообще не приходилось видеть — и им бы было лучше, не пришлось бы писать статей на Хабр… Но как-то так не получается, да…

А таких, которые платят меньше и мучают тупыми вопросами на собеседованиях — пруд пруди.
Ну если они как-то существуют и как-то работников всё-таки находят, значит не так и мало они платят, да?
Ну не так уж и ломятся и не так уж «все». Оттуда тоже много уходит.
Про «всех» я не говорил. Но при отсеве 98-99% и притом, что «много уходит» там ещё работают десятки тысяч сотрудников, а это значит что на собеседования туда приходят, в буквальном смысле, миллионы — если это не называется «ломятся», то как вы это назовёте?
Я называю это просто рекламой. Молодым разработчикам говорят что работать в Яндексе — модно, престижно и каждый день клевое селфи в офигенно модном офисе. Поэтому там большой поток кандидатов и поэтому они могут себе позволить выбирать какими угодно способами. Те, кто прошел их отбор — не обязательно самые лучшие. Просто они смогли пройти отбор.
Ко мне на собеседование приходили люди из Яндекса, которые поработали там и три месяца и два года. Они просто разочаровались. Бывает.

Есть люди, которые серьезно считают что вопрос «сколько теннисных шариков поместится в эту комнату» как-то связан с абстрактным мышлением. Никто не запрещает им проводить собеседования, чтож делать…
Не знаю на кого вы собеседовались, но за 12 лет работы фронтэндером, хоть в транснациональных корпорациях, хоть в маленьких стартапах, ни разу не приходилось применять на практике не только деревья, но даже алгоритмы сортировки. Современное программирование больше про паттерны и борьбу со сложностью и связанностью. Жаль, что многие собеседующие слишком сосредоточеты на том, что их учили в ВУЗе преподаватели, работающие по учебному плану, написанному в 80-х, и получающие в пять раз меньше их. Хотя, возможно, в серверной разработке это более актуально.
А ну и конечно, DOM я забыл, с DOM вам тоже не приходилось работать за 12 лет работы фронтэндером?
… а вложенные массивы/списки — это не деревья, по вашему?
Они самые. Но подход к обработке массивов мне кажется проще, чем к обработке деревьев. Вложенные циклы против рекурсивного прохода. Любой подмассив можно тут же отсортировать/отфильтровать. При определенной сноровке можно тоже самое делать и над деревьями, только сноровка должна откуда-то взяться. А откуда ей взяться, если в подавляющем большинстве можно написать алгоритм и без них?

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

Не просто «массивов», а «вложенных массивов». Поэтому вам кажется.

Мне начинает становиться интересно — а что вообще вы называете деревом?

сейчас в вебе можно замечательно обходиться без работы с деревьями и вообще структурами данных сложнее массива

… и как бишь, вы обрабатываете JSON или XML сложной (а еще веселее — неформализованной) структуры?
Не просто «массивов», а «вложенных массивов». Поэтому вам кажется.

Мне начинает становиться интересно — а что вообще вы называете деревом?


Мил человек, если вам удобнее обрабатывать массивы алгоритмами для деревьев, я ничего против не имею, от меня вам чем чего надо?

… и как бишь, вы обрабатываете JSON или XML сложной (а еще веселее — неформализованной) структуры?


Мне не приходится обрабатывать сложные древовидные структуры, только списки, где for и foreach максимум второго уровня вложенности хватает за глаза.
Мил человек, если вам удобнее обрабатывать массивы алгоритмами для деревьев, я ничего против не имею, от меня вам чем чего надо?

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

Мне не приходится обрабатывать сложные древовидные структуры, только списки, где for и foreach максимум второго уровня вложенности хватает за глаза.

Заводно. Расстрою вас, но это не «сейчас в вебе» (потому что «сейчас в вебе» дофига нетривиальной интеграции), это лично ваш опыт.
Ну ― это смотря чем заниматься. Я за 3 года frontend-разработки уже и конечных автоматов, и разного рода механизмов парсинга, и имутабельных деревьев, и чего только не накушался. Но не жалею, ибо сложные задачи интересны, не наскучивают. Если бы я всё это время, как предыдущие года два, клепал однотипные корпоративные веб-сайты, мне бы пожалуй уже это всё опостылело.

Ну вот например одна из задач: разработать контрол, который предоставит удобный выбор элементов из иерархического словаря произвольной вложенности, с возможностью фильтрации. Этакое древо с галочками и input-text-ом для фильтрации всей этой груды значений. При этом словарь может быть объёмным, и контрол при этом не должен тормозить.

Ну или разработать контрол для вывода чего-либо огромного, и не однотипного. К примеру у вас есть миллион элементов произвольной высоты. Все сразу их в DOM пускать нельзя, вкладка помрёт. Нужно обеспечить показ только видимой части. А теперь представим что элементы могут иметь произвольную вложенность. Становится интереснее, да?

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

Вот вы говорите, что frontend-разработчик. Неужели не приходилось заниматься парсингом какого-нибудь левого HTML-а на nodeJS? А свой собственный шаблонизатор писать пробовали?
Вам просто не повезло с компанией или позицией.

Краткий список интересныx задач заданныйх мне, где CS таки пришлось применить:

имплементировать crc64
сделать 2D-tile engine с компактым хранением
компрессор данных для float с регулируеммыми потерями

А вообше сильно помог сайт http://www.careercup.com.

Перед тем как лечь спать берешь один из самых трудных вопросов, ишешь в wiki как решать, смотришь ответы других, ручками пишешь имплементацию. Перед тем как уснуть прокручиваешь в голове решение. Число алгоритрмов в CS конечно и рано или поздно будешь знать их все и способы их имплементации.

Стремится нужно к тому что за 5 минут будешь готов предложить оптимальное алгоритмическое решение.

Компании из top-100 как правило не дают непосильных задач.

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

Да, большинство в жизни не будет использовано, но сильно меняет мышление.

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

И разве это стрессовая ситуация? Вот когда после 4 часов собеседования из 4х частей с разными собеседующими просят написать на бумажке решение чего — то подобного, и еще 3 человек сидят над душой…
Да, умение написать на бумажке работающий рекурсивный алгоритм — очень важное качество для программиста. Это самый простой способ определить, может ли программист в принципе писать алгоритмы или его будут вгонять в ступор вещи типа «написать toString для нашего рекурсивного доменного объекта».
Тут не нужен рекурсивный алгоритм. Тут очередь нужна. Это если не думать. А если подумать — то вообще ничего не нужно.

«Провяжите» Nю строку — у вот у вас исходные данные для (N+1)й. Два цикла. Два if'а. Никакой рекурсии.
я тоже не поддерживаю такого рода «интервью»…

1) Не понимаю: какая польза от кода написанного человеком за 5 минут?
О какой эффективности может идти речь ?! Если вы хотите проверить именно эффективность — то дайте задачу и скажите, что встретимся завтра. и вот тогда смотрите как задача решена — с использованием стека, или рекурсией или еще как! На собеседовании, человек творческий вряд ли сразу выдаст решение… и я не могу назвать это не профессиональным или следствием отсутствия знаний… Скорее наоборот — человек не зашоренный стандартными решениями совершенно точно не сможет решить задачу сразу… — он над ней должен подумать

2) Абсолютно не понимаю когда обсуждая знания и опыт человека в одном языке программирования просят решить задачу на другом… — это примерно тоже самое как нанимая учителя по русскому языку его на собеседовании попросят правильно расставить языки препинания в предложении написанном на китайском… — вроде как понятно что знания есть, значит должен разобраться… — но что таким образом проверяют ?!

3) Ну и конечно самое главное: мне всегда интересно спросить и задающих такие вопросы — а каким образом эта задача связана с реальной работой? Неужели работники часто пишут код в блокноте, в режиме цайт-нот'а на неизвестном языке ?! гм… боюсь тогда для этой работы не программисты нужны, а затыкатели дыр… (В идеале отключатели части функционала до поры пока в нем не разбирутся и не исправят программисты)

В банковской среде такие стрессовые интервью одно время часто любили проводить (лет 5 назад), например, для менеджера по работе с клиентами типичным было поставить задание «продать» депозит директору какой то торговой точки находящейся рядом с банком прямо сейчас (то есть кандидат должен выйти и осуществить продажу!) — но это хотя бы по существу работы (хотя с точки зрения организации самих продаж очень спорно), и опять таки менеджера никто в кассу не сажал…

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

Вот то, как он будет думать, и представляет интерес для проводящего собеседование.

Абсолютно не понимаю когда обсуждая знания и опыт человека в одном языке программирования просят решить задачу на другом…

Обычно просят решить либо на языке, на котором будут писать на позиции, либо на псевдоязыке.
Вот то, как он будет думать, и представляет интерес для проводящего собеседование.

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

Боюсь нарваться на минусы тем что вторгаюсь в профессиональные споры, сам к сожалению не программист (я любитель), зарабатываю абсолютно другим…

я долгое время ставил продажи в банках, всех своих менеджеров я обязательно обучал продажам, обязательно период обучения, потом тренинги, потом наставничество, потом периодический контроль продаж… в общем все по науке…
опыт постановок продаж у меня был, и я с удовольствием его оттачивал на новых командах, соответственно я знал (считал что знал) как лучше продавать (потому что сам в наставничестве и контроле постоянно участвовал в продажах)…

Ну так вот: в каждом банке где я внедрял систему продаж (а таких в чистом виде таких было 3) — я не спешил сбрасывать со счетов нестандартных менеджеров. Более того могу сказать, что по меньшей мере у меня было 2 менеджера при наставничестве которых хотелось выйти с переговоров и перейти с этим менеджером на уровень обучения — настолько все было «не так» и «через ж.п.»… — но эти менеджеры продавали… и продавали очень даже хорошо...- и они продавали не «не правильно» — они продавали по своему!

Так что не всегда нужно устанавливать стандарты на то как человек думает, в конце концов работодатель должен понять что он платит за результат… — думаю те работодатели которые это поняли — и устраивают рабочее место как тут было описано про гугл (если я правильно помню — вплоть «до перерывов на ничего не делание по своей задаче для того чтобы помочь в чужой»)

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

кстати, еще одна мысль: все эти стандарты на решение задач, тестовые задачи для тестовых результатов нужны для того чтобы выбрать НЕ ХУДШЕГО СОТРУДНИКА требованиям которые поставлены… — еще раз прочитайте что я написал! НЕ ХУДШЕГО!!! то есть готового середнячка, который стандартно решит и сделает…

Всякий раз когда вы будете применять этот метод для поиска людей одаренных — будьте готовы на получение отрицательного результата!!!

просто потому что человек одаренный возможно обратит свое внимание на другой аспект решаемой задачи, или на другой способ (который возможно вы уже посчитали как неэффективный)… и скорее всего то что он будет делать сперва будет жутко не эффективным и не правильным! (потому что человек ищет СВОЙ ПУТЬ)… возможно он придет к избитому решению, но он в отличие от многих других будет искать еще!!!

мне повезло в жизни, и я встречал людей которые делали вещи которые просто не возможно объяснить нормальной логикой… у таких людей просто чутье находить решение там где никто уже и не ищет.., думаю что в программировании этот процесс должен быть более востребован, но как часто бывает в больших организациях зачастую рядовой-HR просто не понимает целей найма, как не понимают сотрудники проводящие тестирование.
Либо, не стоит сбрасывать со счетов, искали все таки НЕ ХУДШЕГО СОТРУДНИКА удовлетворяющего заданным критериям для решения плюс/минус стандартных задач (то есть не для создания чего то действительно нового (продукта), а для сопровождения, контроля, описания, обучения и так далее)
После этого хочется спросить: а вы деньги будете платить за то как он будет думать или за решение которое он в итоге сгенерит?

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

(Если мне нужно только готовое финальное решение — мне не нужен сотрудник, мне нужен аутсорсер, у которого на входе задача, а на выходе — решение.)

Так что не всегда нужно устанавливать стандарты на то как человек думает

А с чего вы взяли, что кто-то устанавливает стандарты?

работодатель должен понять что он платит за результат

Вот только «результат» в программировании — это не просто готовый код.

просто потому что человек одаренный возможно обратит свое внимание на другой аспект решаемой задачи, или на другой способ (который возможно вы уже посчитали как неэффективный)… и скорее всего то что он будет делать сперва будет жутко не эффективным и не правильным! (потому что человек ищет СВОЙ ПУТЬ)… возможно он придет к избитому решению, но он в отличие от многих других будет искать еще!!!

Вот именно поэтому и интересно наблюдать, как человек решает задачу — сразу берет готовое решение с полочки или рассуждает, и если рассуждает, то как именно.
и много пытались проанализировать у автора статьи?
я так понял что его пытались натолкнуть на решение которое было известно (подсказывая), а не выясняя что же он хочет написать…

опять таки- для решения вопроса о профессиональных качествах — есть испытательный срок

все остальное чем обычно занимается HR — это обоснование собственной зарплаты, и к найму сотрудников подходящих для той или иной работы зачастую это отношение имеет весьма отдаленное…

P.s. у меня достаточный опыт и в найме и увольнении сотрудников (с подбором, собеседованиями и прочими «прелестями»)… и могу сказать что очень редко при приеме было ясно на что же способен тот или иной кандидат…
и много пытались проанализировать у автора статьи?

Автор про это ничего не пишет.

я так понял что его пытались натолкнуть на решение которое было известно (подсказывая)

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

опять таки- для решения вопроса о профессиональных качествах — есть испытательный срок

Если каждого потенциального кандидата брать на испытательный срок, слишком много ресурсов будет потрачено.

все остальное чем обычно занимается HR

А при чем тут вообще HR?
Собеседующие зачастую переоценивают свои аналитические способности, особенно в области мышления.
Многие люди ошибаются в оценке своих способностей, но суть не в этом. Все равно оценку на этом собеседовании будет проводить тот же человек, так что нет разницы, ошибется он в оценке во время выполнения задания или во время его обсуждения после. Более того, часто с этим же человеком и предстоит работать впоследствии, поэтому какова бы ни была его ошибка во время собеседования, она же будет сказываться и на работе. Так что все честно.
VitGo
2) Абсолютно не понимаю когда обсуждая знания и опыт человека в одном языке программирования просят решить задачу на другом… — это примерно тоже самое как нанимая учителя по русскому языку его на собеседовании попросят правильно расставить языки препинания в предложении написанном на китайском… — вроде как понятно что знания есть, значит должен разобраться… — но что таким образом проверяют ?!

Вот тут не соглашусь с вами. Есть два вида специалистов, которых нанимают:
1. Программист с глубокими знаниями в узкой области. Тут важны те знания, которые уже есть у него т.к. большую часть своего времени он будет решать типовые задачи.
2. Программист широкого профиля (я говорю не о full stack разработчиках). Здесь важнее не то, что человек знает сейчас, а как быстро он может научиться новому. Чтобы он умел быстро разбираться в новых областях и решить новые для себя задачи.

Я в свое время собеседовал новых программистов в свою команду. Мы искали джунов, для дальнейшего обучения. Понятно, что не ожидалось от них глубоких знаний. Но если он умел учиться, то скорее всего мы его брали. Умение учиться проверялось простеньким тестовым заданием на языке, которого собеседуемый не знал. В конце нашей беседы давалось небольшое задание (требовало потратить примерно полдня), которое нужно было сделать дома на незнакомом языке (о языке договаривались). Задание сводилось не к алгоритмам, а к базовым знаниям этого языка. Без жестких временных ограничений.

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

Конечно, такой подход будет уместен не всегда.
поставил вам +1
Абсолютно согласен.

если человека вывели из зоны знаний (по крайней мере в которых он более уверен) — то это должно быть компенсировано временем и возможности делать задание в комфортной обстановке…

+абсолютно с вами согласен — вы искали людей способных учиться!!! — и выбрали абсолютно правильный способ (как минимум: восприятие новой информации о языке, принятие задачи, ее решение на основе полученных знаний)

но что произошло у автора статьи?
почему чему другой язык в блокноте в цайт-нот'е? проверить что ?! обучаемость к новому языку (наполовину придуманному самому (!!! то есть нужно еще и логически верные инструкции выработать со всеми ньюансами) ?!
не понимаю :-(
В конкретно этой ситуации, думаю, просто не придали этому значения. Это для собеседуемого это важно, а интервьюер мог просто не задуматься об этом.
Либо вам отказали по совокупности различных моментов, обсуждаемых на собеседовании (напр. им нужен C#, а вы специалист по JavaScript) — и это наиболее вероятный вариант.

Либо если действительно отказали по одной задачке, но тогда идти к ним работать не стоит, т.к. у них лид — самодур или подбор персонала идет практически рандомно. В любом случае работать в такой обстановке — карьерное самоубийство для разработчика.
Нет с C# у меня проблем нет, просто небольшое предпочтение отдаю JS, да и онлайн редакторов типа напиши, запусти и поделись для JS гораздо больше чем для C#.
Мне кажется все же последнее, так мне, во всяком случае, сказала охотница за головами.
Знаете, в моем опыте было несколько случаев когда я отказывался от работы пройдя все собеседования… просто на основе анализа того как проводились собеседования, какие задачи мне ставились, какие решения принимались…

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

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

В больших проектах и командах нельзя просто запереться в углу, войти в поток и выдать результат. Потому что проект длится месяцы и в нем участвуют десятки человек. Нужно постоянно разговаривать с заказчиками и разработчиками других модулей, причём разговаривать продуктивно.
Почему это называется problem solving? Возможно чтобы избежать слишком частых проблем вида «а я думал...», «мне никто не сказал», «ты же говорил», «я не знал» и т.п.
Без рекурсии и за О(1) дополнительной памяти:
void Connect(Node x){
    while(x!=null){
        Node newStart=null,y=null;
        while(x!=null){
            if(x.left!=null) y=addNode(x.left,y,ref newStart);
            if(x.right!=null) y=addNode(x.right,y,ref newStart);
            x=x.neighbour;
        }
        x=newStart;
    }
}
Node addNode(Node x,Node y,ref Node start){
    return start==null ? start=x : y.neighbour=x; 
}
Классно, не спорю, но я минут 20 разглядывал эти 14 строчек прежде чем понял, как они работают. Если потребление ресурсов не критично, я бы предпочел увидеть рекурсивное решение. Все же, этот кусок кода сложен для восприятия.
Восприятие субъективно, а асимптотика по памяти объективна.
В общем, подробный комментарий к методу — и решение будет идеально.
Мне тоже стыдно, что не заметил сразу. Хотя на рисунке чётко видно, что из очередной строчки можно получить следующую.
Долго смотрел на это, никак не мог понять. Только потом заметил, что в addNode не просто вычисления делаются, а еще и присваивание… Не понимаю эту любовь все писать в 1 строчку, как будто бумаги жалко или места на экране.
Просто сейчас рука плохо работает, текст набирать трудно.
Мне в топтал попалась задача написать функцию, которая находит минимальное кво шагов необходимое чтобы конь на доске добрался от точки 1 до точки 2. Завалил. Только потом узнал что это олимпиадная задачка. Полегчало
Например, функция принимает начальные и желаемые координаты, а возвращает список необходимых перемещений.
Не все так просто, там циклы есть, так что метки на поле придется все таки ставить.
А что мешает отдельно хранить посещенные клетки, например, двумерный массив булевских значений?
Тогда при чём здесь вообще программирование? Рисуем на бумажке карту и кодируем:
  int dx=abs(targetX-sourceX);  
  int dy=abs(targetY-sourceY);
  int p=max((dx+1)/2,max((dy+1)/2,(dx+dy+2)/3);
  if((p+dx+dy)%2!=0) p++;
  if(dx+dy==1 || (dx==2 && dy==2)) p+=2;
  return p;
У меня то же самое — сложно сделать задачу, которую раньше не решал или с которой не сталкиваешься постоянно, если разговариваешь с кем-то или просто кто-то смотрит и ждет. Я не сталкиваюсь, например, с алгоритмическими задачами, но при этом многие из них могу решить, если подумать над ними некоторое время в спокойной обстановке и представить все в деталях.

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

То есть, это не боязнь завалить собеседование, или боязнь собеседника, а нестандартная для мозга ситуация, которая требует внимания и ресурсов, которые забирает на себя общение с собеседником. Примерно как в квантовой физике — наблюдение влияет на результат наблюдения.

А что-то мешало написать решение в IDE и скопипастить в онлайн? Сам недавно проходил онлайн-собеседование с подобными задачками и делал именно так :)
И да, задачки такого плана на собеседовании — это нормально. Просто надо стараться меньше волноваться. :)
Уважаемый vba, вот вы озвучили аргументы, почему «решение олимпиадных задачек без IDE» — плохой, негодный способ проверять problem solving skills в условиях собеседования.
Какой способ, по-вашему, был бы хорошим и годным?
Разрешите я отвечу своим мнением…

Что проверяется в этом случае? Что есть «problem solving skills»? Способность решать проблемы в случае факапа? Тогда дайте реальную задачу, более приближенную к жизни.
В чем будет срочность в реальной жизни? Service outage, логичнее всего.
Вы хотите чтобы после деплоя новой версии и при лежащем сервере разработчик решал олимпиадные задачи на сортировку и поиск пути в дереве? Точно? В нормальных компаниях это решается откатом назад и спокойным анализом ситуации в курилке, а потом спокойной починкой в течение нескольких дней, тестированием и деплоем.

Вы хотите чтобы человек умел решать олимпиадные задачи и нестандартно решал вопросы? Насчет «нестандартно» можно поговорить отдельно, если вы и правда этого хотите.
А про сложные алгоритмы — будут ли в вашей компании при реальной работе сидеть за спиной и смотреть на экран разработчика? Будут?? Ну нафиг такую компанию.
Не будут — тогда дайте задачу на дом и пусть он спокойно роется на stackoverflow и в гугле. То же самое он будет делать и на работе. Решит — молодец и неважно как. Не решит — ну тем более не подходит.

Если ваша компания предполагает постоянню работу в условиях стресса — тогда имеет смысл проводить такие собеседования. Пусть будет готов что его на работе будут бить внезапно током или спрашивать «сколько будет 18 в степени 42, решить за 5 минут при памяти в 36 килобайт и 17 рублях в кармане??».

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

На собеседованиях я никогда не давал задания написать код на бумажке длиннее трех строк. Это не было нужным. Умного человека видно сразу. Задайте вопросы по архитектуре или по абстрактному решению задач. Ну спросите, если хочется, какие алгоритмы поиска в дереве человек знает. Код написать по алгоритму сможет любой.
Что проверяется в этом случае? Что есть «problem solving skills»? Способность решать проблемы в случае факапа?
Способность решать простые задачи без закладывания «бомб».

А про сложные алгоритмы — будут ли в вашей компании при реальной работе сидеть за спиной и смотреть на экран разработчика?
Где вы тут увидели «сложный алгоритм»? Ту на выбор полдюжины алгоритмов — и все элементарны просто как не знаю что.

Не будут — тогда дайте задачу на дом и пусть он спокойно роется на stackoverflow и в гугле. То же самое он будет делать и на работе.
Вот этого и боятся. Задачи подобного уровня не должны искаться «на stackoverflow и в гугле». Наоборот — человек должен выдавать приличный ответ сходу (хотя бы такой, как в решении номер 3) и дальше его можно уже обсуждать. Например спросить: «да, потребление памяти у вас тут приемлемо, но можно ли сделать лучше?».

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

Умного человека видно сразу.
Фиг. Есть куча кандидатов готовых рассуждать о толкостях блокировки в Java или ещё о чём-нибудь подобном, но неспособных написать цикл так, чтобы чего-нибудь не потерять.

Код написать по алгоритму сможет любой.
Поделитесь травой, а? Которой вы откуриваете 90% кандидатов, которые на это не способны? Всем легче станет, чесслово.
человек должен выдавать приличный ответ сходу (хотя бы такой, как в решении номер 3) и дальше его можно уже обсуждать.


Приличный ответ? Вы серьезно? Для олипиадника может быть. Вы посмотрите на эти задачки, они кишат императивностью и «moving parts». Вы попробуйте подобный алгоритм поставить на поток, да и к чему? Зачем это нужно сегодня, помимо олимпиад? Кто сегодня пишет свои собственные реализации красно-черных деревьев?
Кто сегодня пишет свои собственные реализации красно-черных деревьев?

*опасливо поднимаю руку*
Кто сегодня пишет свои собственные реализации красно-черных деревьев?
Эк вы меня уели. Нет, красно-чёрных деревьев я давненько не реализовывал, признаюсь. А вот изменение алгоритмов от списков к массивам с аренами-аллокаторами — это пожалуйста. И задачки подобные обсуждаемой тут (и их адаптация под не слишком «удобные» структуры данных, которые, зато более «Cache-Friendly» — это наше всё.

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

Чет вы перегнули с цифрой. Не уверен что у гугла если несколько миллиардов пользователей, а вы о какой то астрактной фирме рассуждаете )
Google. Только Android'ов сейчас уже больше миллиарда. А поиском не только с Андроида пользуются.

Microsoft. Пользователей Оффиса — 1.2 миллиарда и это притом, что не всякия винда с Офисом приходит.

Yandex, конечно, до миллирда не дотягивает, но даже его десятки миллионов — это очень неплохо с учётом того, что он фактически «окучивает» одну страну.
Что будет если на собеседовании у вас человек при реализации алгоритма допустит ошибку? Допустим, логическую — типа неправильного условия выхода из цикла.
Вы его сразу прогоните?
С этого момента собеседование только начинается :-) Заметит ли он её сам или придётся подсказывать? Какие мере предложит, чтобы разрулить ситуацию? Что сделает, чтобы такое больше не повторялось? Это как раз самая интрересная часть собеседования — но, как я понял, автор статьи до неё не добрался.

Что касается после приёма на работу… Тут ничего не надо придумывать, всё придумано тысячи лет назад: Errare humanum est, perseverare autem diabolicum, et tertia non datur.

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

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

Моя мысль, которую я хочу пояснить: если человек написал алгоритм сразу и правильно — он, конечно, молодец, но если он не написал или ошибся — это ничего не значит. А значит ценность проверки невелика.

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

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

Я пишу на Django последние пять лет и постоянно допускаю глупейшие ошибки. Не могу запомнить как правильно пишется метод — «create_or_update» или «update_or_create» или еще как-то… Недавно было собеседование, там тоже попросили меня в Google Docs решить простейшую задачу в реальном времени. Даже не сортировку и ни разу не олимпиадную. За мной поправляли синтаксические ошибки, добавляли переносы и пробелы для читаемости, чтобы я не отвлекался от логики. Но я тоже запутался и что-то корявое написал. Хотя дома вечером спокойно потом для себя решил.

Если же вам нравится видеть как человек в вашем присутствии чувствует себя неловко — тогда да, есть смысл в таких задачах. Иначе — нет.
ИМХО.
Если он не написал или ошибся — это ничего не значит.
Если ошибся — не проблема. Не ошибается тот, кто ничего не делает. Но если он за час не решил задачу, которую, в общем-то, нужно решать за пару минут… то это о чём-то да, говорит, да? Иногда это говорит о том, что связь была отвратительная и кандидат просто не слышал ваших подсказок. Но не всегда же!

А значит ценность проверки невелика.
Совершенно верно. Мы же решаем не вопрос где ставить запятую в известном выражении «казнить нельзя помиловать», а и всего лишь вопрос: «стоит ли вот этого кандидата вот прямо сейчас брать на работу». Если это была случайная оплошность — ну придёт кандидат через год-два. Или не придёт. В любом случае это — не конец света!

Проще распечатать несколько вариантов готового кода и дать ему с просьбой прокомментировать подход или найти ошибки.
Большинство кандидатов будут потеть столь же усердно, но о кандидате вы узнаете меньше.
Но если он за час не решил задачу, которую, в общем-то, нужно решать за пару минут
Откуда в вас столько снобизма? Аж противно читать. При том, что, кажется, уже каждый 4-ый комментарий в этом топике ваш. Вы так самоутверждаетесь что-ли? Да, это не самая сложная задача, но и не самая простая. Да, человек, который с подобным почти не сталкивается в реальной работе, вполне может затупить. А вы уже счёт на минуты повели.
Это не снобизм. Это — взгляд с другой стороны баррикад. Задача, которая не решается в спокойной, расслабленной обстановке «без нажима» за две-три минуты вообще не имеет права появляться на собеседовании. Ну пять минут — от силы (и то, если есть уверенность в том, что кандидат достаточно сильный).

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

Что касается комментариев: тут вообще не так много людей с приличным опытом собеседований (проинтервьюировавших в своей жизни хотя бы сотню кандидатов из которых хотя бы десяток были приняты на работу), так чтобы была возможность сравнить ощущения от кандидатов во время интервью и а в работе. Приходится объяснять подробно, раз уж я в эту дискуссию встрял: я такую возможность имею и потому вижу мир в совсем ином свете. Вы видите «непризнанного гения», которого «отсеяли злые рекрутеры», я, как уже объяснял, вижу процесс где интервьюер увидел потенциальные болевые места после прочтения 5 строчек резюме, аккуратно и честно проверил их и кандидата «отсеял».

Ну вот где вы видите в описанном процессе проблему? Подсказки, как утверждается, были, попытки помочь — были, то, что кандидат их «не взял» скорее говорит о кандидате, чем об интервьюере, то, что дойдя до написания статьи он так и не дошёл до ассимптотически оптимальноего решения, а смог предложить только лишь хорошее — ну вы тут действительно видите повод для обсуждения?
В описанном процессе собеседования я не вижу проблемы. Если работа как-то связана с навыками в алгоритмах, и от соискателя требуется понимание алгоритмов, структур данных и соображайка в этом деле, то почему нет.

Главное чтобы соискателей хватало. Кадровый кризис, он ведь суров. Когда я столкнулся с задачей набора стажёров, я эту задачу с треском провалил. Соискателей было много, но людей, которые, хотя бы, имели опыт с СУВ, не писали транслитом, и имели зачаточные навыки в ООП, ― практически не было. Про «О большое» я вообще молчу. Про такие вещи я даже не заикался.

Меня смутил только лишь снобизм. Следуя вашим словам, получается, что автор вообще никуда не годен, раз не может решить за 2 дня задачу, на которую вам потребовалось бы всего 2 минуты. Гнать её в шею, да? Да и меня, наверное, мне тоже 2 минут не хватит. Быть может 10 или 20… Зачем меня только на работе держат.
Меня смутил только лишь снобизм. Следуя вашим словам, получается, что автор вообще никуда не годен, раз не может решить за 2 дня задачу, на которую вам потребовалось бы всего 2 минуты.

Не никуда не годен, а в их команду не годен.

Цель собеседования — выявить не самого талантливого программиста, а самого полезного на данном конкретном месте.
Следуя вашим словам, получается, что автор вообще никуда не годен, раз не может решить за 2 дня задачу

Вы знаете, у меня такое же впечатление сложилось. Вот и пиши после этого очерки о собственном опыте, тебя самого же еще и в грязь мокнут…
Если работа как-то связана с навыками в алгоритмах, и от соискателя требуется понимание алгоритмов, структур данных и соображайка в этом деле, то почему нет.
Любая работа в большой компании всегда связана с алгоритмами и структурами данных. Про одну сторону я уже говорил. Но есть и другая. Если вы засунули O(N2) «не по делу» в сайтик с маленьким интеренет-магазином, то вы можете превратить тысячу в миллион, а десять тысяч — в сто миллионов. При быстродействии современных компьютеров в миллиарды операций в секунду «это» будет тормозить, но работать.

А вот если вы сделаете это с миллиардом пользователей — то вы миллиард превратите в квинтиллион и всё. Конец. Это — уже не полетит. Одна подобного рода ошибка, случайно допущенная и незамеченная, стоит столько, что правило: «людей, которые могут подобное сотворить и не заметить на работу мы не берём» абсолютно железное.

Байку про русский код читали? Вот именно для того, чтобы чтобы такого никогда не видеть подобные собеседования и проводятся.
А вот если вы сделаете это с миллиардом пользователей
Дык, ну а кто левого человека, просто так, пустит в проект с миллиардной посещаемостью? К чему этот оторванный от реальности пример? Понятное дело, что и вакансии на web-программистов друг от друга отличаются. Зачем вы всех под одну гребёнку? Ясное дело, что в Twitter и в «Веб-студия: Рога и Копыта» возьмут разных людей. Первым нужны спецы, вторым они противопоказаны.
Если вы засунули O(N2) «не по делу» … «это» будет тормозить, но работать.
Очень часто именно это и требуется. Точнее не так: только на это и хватает бюджета.
Любая работа в большой компании всегда связана с алгоритмами и структурами данных
Мне всегда казалось, что чем крупнее штат, тем меньше требований к отдельному винтику. Но в больших компаниях я никогда не работал (и работать не хочу, если честно). Могу ошибаться.
Очень часто именно это и требуется. Точнее не так: только на это и хватает бюджета.
Возможно. Но:
Примерно месяц назад со мной связался охотница за головами из одной крупной софтверной компании.
Большая компания редко когда предполагает копеечный бюджет.
Мне всегда казалось, что чем крупнее штат, тем меньше требований к отдельному винтику.
Не «меньше требований». Меньше «возможностей для контроля».

А вот дальше разные компании «устроены по разному». Если это компания типа SAP, то да, там будет туча консалтеров, которые будут заниматься «за чашку риса» внедрением в туевой хуче мест SAP ERP. Но и там будет «ядро», которое это самое SAP ERP пишет — и вот к нему будут применяться примерно такие требования, какие увидел топикстартер.

Дык, ну а кто левого человека, просто так, пустит в проект с миллиардной посещаемостью?
А откуда, как вы думаете, берутся люди, которые пишут код в таких проектах? Их что — на гидропонике выращивают?

Зачем вы всех под одну гребёнку?
Не «зачем», а «почему». Потому что так проще и дешевле.

Это мелкая компания может себе позволить нанять узкого специалиста заточенного строго под «натягивание шаблонов на вордпресс». Крупной компании таких может вдруг потребоваться десяток (если не сотня) — и откуда их взять?

Если вы можете, условно говоря, перебросить людей с Google Maps на ChromeOS или там с MS Office на MS SQL, то вам не нужно думать о том куда девать людей с узкой специализацией в случае закрытия проекта. Да, в целом вы можете затратить несколько больше денег, но у вас появляется возможность манёвра, что для большой компании зачастую важнее.
Мне кажется, что более адекватный вариант — это брать чувака сначала по контракту на какую-нить среднюю задачу или на пару недель и смотреть как он работает и как с ним ладит команда и тд. Тк кроме чисто технических скилов, есть еще социальные, которые тоже могут быть важны и которые сложно уловить на собеседование. А потом уже, если все хорошо переводить в штат.
Но, естественно, нужно брать не всех подряд, а по-любому как то пофильтровать, по резюме, возможно подобными простейшими задачами, какими-нить разговорами, мне кажется давать реализовать какую-нить дейкстру или еще какой-нить алгоритм, до которого люди доходили десятилетиями сходу на 40 минут это перебор для кандидатов.