почему нет смысла ехать по H1B?

[Flash-04]

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

[andrey_a1]

для того чтобы у Вас работать, нужно только знать что такое указатели и как с ними работать?

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

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

[andrey_a1]

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

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

[KP580BE51]

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

Как он знает? Такие алгоритмы сейчас на даже не знаю сколько процентов зависят от архитектуры процессора. Правильный ответ будет брать компилятор,направлять вывод в листинг и смотреть что получилось. Потом проверять с секундомером на реальных данных. Вся эта %&#)$(* с указателями, это красиво, но народ забывает что гораздо важнее чтобы основная часть программы с данными в кеше первого уровня уместилась. Плюс сейчас, в эпоху суперскалярных процессоров, тоже поменялись требования к оптимизации: лучше за один цикл сделать не одну проверку а к примеру 64, и счетчик инкрементировать сразу на 64.

[andrey_a1]

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

Как он знает? Такие алгоритмы сейчас на даже не знаю сколько процентов зависят от архитектуры процессора. Правильный ответ будет брать компилятор,направлять вывод в листинг и смотреть что получилось. Потом проверять с секундомером на реальных данных. Вся эта %&#)$(* с указателями, это красиво, но народ забывает что гораздо важнее чтобы основная часть программы с данными в кеше первого уровня уместилась. Плюс сейчас, в эпоху суперскалярных процессоров, тоже поменялись требования к оптимизации: лучше за один цикл сделать не одну проверку а к примеру 64, и счетчик инкрементировать сразу на 64.

Человек знает как решать задачу с бензоколонками - что статистика по ним
легко получаема.

[Sergey_P]

для того чтобы у Вас работать, нужно только знать что такое указатели и как с ними работать?

Вы бы знали какое количество народу идущих на позиции STE/SDET в тот же Mайкрософт этого не знает.

В том же примере если не знать что такое указатели, то можно предположить, что второй ArrayList это потенциально в два раза больше памяти, на самом деле это верно только если количество разновидностей строк << элементов массива
String займет
Total String Object incl. Dependent Array 38±2 + 2*(String length)
ArrayList будет от 55-80 байт до 4* N элементов массива
в обшем заметить его на общем фоне без микроскопа можно только забив несколько миллионов элементов одними и теми-же строками.
Т.е. если этого не знать, можно бросится оптимизаровать то, что в оптимизации совсем не нуждается.. хотя это золотое правило – пока не стало необходимо тюнить между простотой и скоростью/памятью/.. выбор очевиден. Как говорил Альберт Make everything as simple as possible, but not simpler

[Sergey_P]

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

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

SKIP

Плюс сейчас, в эпоху суперскалярных процессоров…

Бороздящих просторы мирового океяна.. Вы про задачку удалением строк?
ArrayList это самая часто используемая коллекция .NET/Java человек претендующий на .NET/Java позицию должен неслабо извернутся чтоб с ней неработать. Насчет зависят от архитектуры процессора /уместится в кеше – пурга
то что в этом примере умещается в кеше оптимизировать бессмысленно

[Flash-04]

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

чтобы избежать такого запущенного случая, задачи нужно периодически менять

[Sam Adams]

Народ, вы что? "Задачка" на уровне 9-го класса школы, понятно ведь, что если спрашивают на интервью, то не нужно использовать дополнительный ненужный ArrayList. Задачи, где априори неизвестны размеры данных (а ведь эта функция вполне может быть библиотечной), нужно решать максимально эффективным способом. А что, если размер данных будет большой? Это ничего, что если ваш ненужный массив будет занимать >~20Мб, то он не будет освобожден GC в .Net 1.1?

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

Между прочим, и Ваш код можно значительно ускорить, всего лишь добавив параметр capacity в конструктор, дабы избежать log(size) перевыделений памяти.

На работе значительную часть времени приходится копаться в профайлере, вы не поверите, насколько использование подхода "процессоры сейчас быстрые, не жалко и ненужный временный массив создать" портит впечатление от приложения. А что, если пользователь создаст в Excel-like приложении таблицу с 10,000 колонок? (как раз вчера случилось у нас, полёт нормальный). А 10 миллионов рядков? Ах да, в М$, видимо, тоже считали, что "нефиг заморачиваться", и решили проблему простым путём - введя ограничение на 256 колонок и 64К рядков

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

[Sergey_P]

Народ, вы что? "Задачка" на уровне 9-го класса школы, понятно ведь, что если спрашивают на интервью, то не нужно использовать дополнительный ненужный ArrayList. Задачи, где априори неизвестны размеры данных (а ведь эта функция вполне может быть библиотечной), нужно решать максимально эффективным способом. А что, если размер данных будет большой? Это ничего, что если ваш ненужный массив будет занимать >~20Мб, то он не будет освобожден GC в .Net 1.1?

Я понимаю, что возвращатся на 5 страниц к союственно задаче облом, но таки неплохо сначала выяснить, что собсбвкнно решаем

Т.е.

Есть ArrayList (для тех кто не работает с .NET - это самый используемый collection class в 1.0 и 1.1 (народа знающего 2.0 мне еще не попадалось)) в который поместили кучу строк (string).

ArrayList Есть. ArrayList внутри тот-же Array по умолчанию удваивающся какждый раз как пончается место => чтоб занять ненужные 20Мб нужно минимум 20Мб/(4байта*2) строк. Строка уже из 1-го символа занимает на порядок больше..
Что эти 20Мб на фоне гигабайтов строк?

Sergey_P, неужели действительно эти несчастные 5 строк кода нечитабельны? Я просто пропустил "!" в условии - забивать начало массива нужно, конечно же, элементами, которые должны остаться после удаления, а не наоборот.

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

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

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

Между прочим, и Ваш код можно значительно ускорить, всего лишь добавив параметр capacity в конструктор, дабы избежать log(size) перевыделений памяти.

Верно log(size) от результирующего массива.. т.е. скажем при 1/3 строк "a..” будет экономия заметная а при 8/9 наоборот. Но разница в секунды будет только если 10-ками миллионов элементов ворочать => гигабайт(ы) даже при строк << элементов
тут я бы capacity в конструктор добавил чтобы предсказуемые результаты по памяти были

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

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

[andrey_a1]

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

чтобы избежать такого запущенного случая, задачи нужно периодически менять

Ну так а если человек чисто случайно знает правильное решение задачи
(ну может встречался с этой проблемой раньше) - он должен это решение
изложить или "демонстрировать гибкость мышления"?

[Flash-04]

изложить, разумеется

[Gennadiy]

изложить или "демонстрировать гибкость мышления"?

Конечно изложить. Если знает - это еще лучше. Опыт никогда лишним не бывает.

[andrey_a1]

изложить или "демонстрировать гибкость мышления"?

Конечно изложить. Если знает - это еще лучше.

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

Опыт никогда лишним не бывает.

Опыт подсчета заправок?

[Gennadiy]

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

1. Откуда вы знаете что хочет услышать интервьюирующий?
2. Всегда можно задать другой вопрос, если уж так необходимо проверить гибкость.
3. Заодно проверится и "гибкость" самого интервьюирующего

Опыт подсчета заправок?

Я лично против отфонарных, не связаных с будущей работой задач типа бензоколонок или канализационных люков. По одной простой причине. Человек идет на интервью настроеный на определенную ноту. А такие задачки вносят серьезный диссонанс и только путают картину. Челоек может просто растерятся услышав такое. Вы же програмиста ищете, а не участника "Что? Где? Когда?".
Неужели нельзя придумать интересную задачу по теме?

[Sergey_P]

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

эх тут мне оказывается попытались ответить, а я пропустил
задачек к которым непонятно как подступится я на интервью невстречал впринцыпе.. т.е. скажем доказывать теорему Ферми непросили, а бензоколонки это самый идиотский вопрос - практичное решение его ничего не говорит о кандидате => требуют бессмысленных рассуждений на тему которые IMHO опять же ничего не говорят о кандидате.
Хотя я даже скорее говорил про пример с удалением строк из листа - в общем-то вменяемый пример, но заметте по какому принципу выбрано "правильное решение"? Я бы назвал изящности.
Т.е. решение не самое простое (легко читаемое), не самое гибкое, мягко говоря не самое быстрое.. НО оно красиво и "ни обдин индус до него не додумался"!
Я, кстати, тоже замечал, что на интервью интуитивно пытаешся решить "поизящней" хотя есть тупой простой и главное практичный ответ.

[Gennadiy]

Хотя я даже скорее говорил про пример с удалением строк из листа - в общем-то вменяемый пример, но заметте по какому принципу выбрано "правильное решение"? Я бы назвал изящности.

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

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

[andrey_a1]

1. Откуда вы знаете что хочет услышать интервьюирующий?

В том то и дело что не знаю.

Я лично против отфонарных, не связаных с будущей работой задач типа бензоколонок или канализационных люков. По одной простой причине. Человек идет на интервью настроеный на определенную ноту. А такие задачки вносят серьезный диссонанс и только путают картину. Челоек может просто растерятся услышав такое. Вы же програмиста ищете, а не участника "Что? Где? Когда?".
Неужели нельзя придумать интересную задачу по теме?

Так и я о том же.

[Scrooge McDuck]

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

Под вторым предложением подпишусь полностью.

[Sergey_P]

Никто кстати про абсолютную "правильность" решения не говорил.

Включая меня. Я говорил о том, что более навороченное решение дает больше очков.. Чем такое решение плохо на практике было наглядно продемонстрированно на форуме – изящное решение с обратным пробеганием на порядки медленнее тупого копирования да и в читабеотности ему уступит, а сравнимое по скорости копирование в начало Sam Adams вообще практически никто прокрутить не смог
даже Двуручник его имплементировал незаметив логической ошибки (my guess – закодировал невдумываясь как же оно работает). Т.е. те кумары которые до обратной итерации додуматся немогли его с гарантией непоймут.

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

Gennadiy Вы отнюдь не худший интервьювер, ктомуже находящийся на безрыбье. Если бы Вам нужны были джависты, а мне было не облом ехать в CT у Вас был бы хороший шанс получть меня в эмплои, причем, надеюсь, и у меня шанс на оффер был бы немаленький. Тем не менее на Привете оффер получил Sam Adams и по той же причине Двуручник стремился решить "позамысловатее".
Кстати мне тут мысль пришла – может ноги ростут из олимпиад? Там какраз оптимальность по памяти/действиям+ изящность давали max очков

[newbee]

Хотя я даже скорее говорил про пример с удалением строк из листа - в общем-то вменяемый пример, но заметте по какому принципу выбрано "правильное решение"? Я бы назвал изящности.

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

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

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

[Gennadiy]

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

Часто сложно дать правильное решение сразу. Причем на интервью. Волнение, прессинг, неожиданность. Кроме того в програмировании понятие правильного решения относительное. Вы могли уже увидить из этого обсуждения. Нормальный интервьюер это должен понимать. И не строить из себя минное поле на котором кандидат-сапер может ошибится только один раз.
Что действительно важно, то что человек пытается искать решение. Если он его знает - хорошо. Это свидетельствует о его опыте. Если не знает, то как он его ищет, тоже о многом говорит. Вообще, то как человек рассуждает многое говорит о нем.
Что ожидается, что человек сразу поймет в чем суть задачи и попытается найти возможные пути решения.
Ну и конечно есть вопросы на которые ответ надо просто знать. Как таблицу умножения в школе. Тут уже попытки угадать не проходят.

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

Есть еще "индийский" подход. Когда интервьюер спрашивает у кандидата вопрос, ответ на который он сам узнал только вчера. Против такого подхода работает контратака. Наберите набор интересный трюков и выдавйте их сторонникам такого подхода. Они такое любят. Конечно вы подложите этим свинью следующим за вами, поскольку ваши трюки будут в меню следующего интервью.

"Русский" подход будет заключатся в глубоком копании в какой-нибудь частной проблеме. Этим он противоположен "американскому" который предполагает свободно говорить обо всем (часто поверхностно).

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

[Двуручник]

даже Двуручник его имплементировал незаметив логической ошибки (my guess – закодировал невдумываясь как же оно работает).

Вдуматься-то как раз вдумался, уловил идею и поспешил с Copy&Paste из форума.

Я прогнал с исправленым логическим условием. Цифры по времени исполнения примерно такие же (все 0.ххх сек).

Алгоритм Sam Adams самый быстрый по прежнему...