Здравствуйте, Denis, Вы писали:

D>Здравствуйте, мыщъх, Вы писали:
М>>гм, а если собеседующий спросит: "как?! вы не знаете что такое стек?! нууууу....".
D>1) если собеседующий дебил, это не лечится. радуйтесь, что вам с ним не работать
так он и есть дебил, хотя без оригинальной формулировки задачи трудно заочно судить человека. кстати, есть стек не мутабельный, то ситуация упрощается. еще круче, если сделать стек write-only. зачем нам нужен такой стек с инженерной точки зрения? а зачем нам нужен разделяемый мутабельный стек? в обоих случаях очень трудно представить себе практическую задачу. это что-то очень сильно нетипичное. если это из области фантастики -- держите write-only стек. если это специфичная задача -- не зная задачи трудно предложить решение. как минимум нужно знать -- блокировать ли остальные потоки на время захвата стека одним из них или нет. вполне возможно, что необходимо обеспечить, чтобы поток А ложил один элемент и тормозился пока поток Б его не извлечет, затем поток А ложит еще один элемент и поток Б его снова извлекает. а, возможно, элементы должен извлекать только тот поток, который их туда поклал.

D>2) задавать вопрос надо так, что бы минимизировать неправильное понимание вопроса
я бы на месте собеседуемого попросил бы огласить набор функций предоставляемых так называемым "стеком", а так же предполагаемый сценарий работы с ним. но сильно подозреваю, что вместо ответа мне бы молча указали на дверь.

вообще, о терминах не спорят. о них договариваются. для меня стало открытием, что в питоне стороки не мутабельны. и конструкция s[idx] = '*' не работает. s += '*' работает, но жутко тормозит. и потому приходится извращаться не по детски. объявлять массив размера N. питон под него аллоцирует память. затем этот массив мы быстро-быстро заполняем по индексу и делаем s.append(sub_array). такой кусковой подход раз в десять (!) быстрее. если в питоне строки не мутабельные и никто от этого не умирает, почему мне нужно реализовать мутабельный стек, если меня об этом не просят явно?

Здравствуйте, umnik, Вы писали:

U>Здравствуйте, hokkaido, Вы писали:

U>В целом согласен, но когда я проводил интервью здесь, по крайней мере для простых задач вроде "развернуть список", я ожидал что человек напишет работающее решение от и до. Вы не представляете сколько людей не могут найти простые баги в своем коде на 20 строчек — а ведь им потом code review делать для чужого...

а code review чужого кода делать обязательно?

Здравствуйте, мыщъх, Вы писали:
М>а code review чужого кода делать обязательно?
предлагаешь делать review своего собственного кода, вообще его не делать, зааутсорсить сей процесс, или заставить начальника этим заниматься?

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

Здравствуйте, qqqqq, Вы писали:

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

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

Здравствуйте, мыщъх, Вы писали:

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

С чего при делении на ноль должна быть бесконечность?

Если x/0 = ∞, то ∞*0 = x, где x — произвольное заранее определенное значение. И теперь если задавать значения x, что мы получим при проверке деления умножением?

Здравствуйте, m e, Вы писали:

ME>и что, ты хочешь сказать, что в MS платят столько же, сколько у паблика?
ME>подозреваю, что начальная зарплата там раза в 2 больше

И толку? Все равно благодаря такому подходу набирают кого попало.

ME>>и что, ты хочешь сказать, что в MS платят столько же, сколько у паблика?
ME>>подозреваю, что начальная зарплата там раза в 2 больше

U>И толку? Все равно благодаря такому подходу набирают кого попало.

че правда?

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

Здравствуйте, m e, Вы писали:

ME>что-то мы не видим тут на форуме представителя МС, который плакался бы нам в жилетку насчет того, что кандидаты список не могут обратить и категорически отказываются решать задачи про гномиков

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

Здравствуйте, qqqqq, Вы писали:

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

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

Здравствуйте, abibok, Вы писали:

A>Задача с уловкой: если вы сумели сделать класс контейнера thread-safe, то это минус.
"Слишком умный чтоб у нас работать" (С) ?

Здравствуйте, m e, Вы писали:

М>>работает! можно бесконечно входить в demo, спускаясь все глубже и глубже (в FAR'e). а теперь посмотрите сколько программ развалится, если их попросить обработать директорию с под-директориями.
ME>подозреваю, что там есть апи для отличания такой ссылки от честной директории
Разумеется. Будет стоять как минимум аттрибут Reparse point

ME>под линуксом, афайк, ext2/ext3 не дает создать настоящие хардлинки на директорию; симлинки пожалуста, но их при желании можно отличить
В NTFS на каталог хардлинк создать нельзя. Только Symbolic link или mount point

Здравствуйте, hokkaido, Вы писали:

H>Пожалуй стоит еще раз сказать, что интервью (даже в МС) — это не ЕГЭ.

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

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

H>По алгоритмам и стурктурам данных задачи будут такие, чтобы решение (или аутлайн решения) поместился на доске. Т.е. (условно говоря) реализовывать красно-черные деревья вам не надо будет (но надо знать зачем они нужны!).

H>В общем — расслабьтесь, все будет ОК.

Здравствуйте, мыщъх, Вы писали:

М>а code review чужого кода делать обязательно?

В роботоспособных командах , обязательно.

Здравствуйте, hokkaido, Вы писали:

H>Пожалуй стоит еще раз сказать, что интервью (даже в МС) — это не ЕГЭ.

H>Т.е. важно даже не то, правильно ли вы решили задачу, а то, КАК вы ее решаете. Интервьюера не интересует как разворачивать список, его инетерсует — понимаете ли Вы как подходить к задаче.

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

H>Побольше говорите, объясняйте почему выбрали тот или иной подход.

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

Здравствуйте, SingleUseAccount, Вы писали:

SUA>Насколько мне известно, для MS важнее не подход, а именно факт решения плюс способность доказать его корректность. Так что вполне себе экзамен.

Для принятия решения делать или не делать оффер важны вердикты hire/no hire всех участвующих. А уж они могут быть основаны на чем угодно: подходе, факте решения, или great potential. Хочется верить, что большинство интевьюеров все-таки больше смотрит на подход (ну и отсутствие грубых ошибок в решении), а не на факт "самого правильного решения". Хотя все они — разные люди, и каждый сам выбирает задачу, которую он/она хочет дать. Так что как уже тут было замечено, все зависит от того, кто интервьюирует. И если эти люди не очень адекватны, то наверное, в эту команду и идти не стоит.

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

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, мыщъх, Вы писали:

М>>а code review чужого кода делать обязательно?
M>В роботоспособных командах , обязательно.
у нас в команде это не практикуется. более того, наши скилзы совершенно не перекрываются и ревью кода не проводится. при этом мы очень даже профитабельны (как раз из-за неперекрывающихся скилзов и минимальных штатов) и код работает в режиме 24/7/386.

Здравствуйте, мыщъх, Вы писали:

М>у нас в команде это не практикуется. более того, наши скилзы совершенно не перекрываются и ревью кода не проводится. при этом мы очень даже профитабельны (как раз из-за неперекрывающихся скилзов и минимальных штатов) и код работает в режиме 24/7/386.

Вы не команда вообще?

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, мыщъх, Вы писали:

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

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

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

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

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