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

[Flash-04]

вон оно что... похоже это продолжает оставаться кладезем мудрости

[Gennadiy]

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

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

[TuzemecIzMauy]

чувак утверждает что занимался .NET c 98 года

мои наблюдения показывают что чуваки которые занимались .нет с 98 и ранее ОБЯЗАТЕЛЬНО имеют хорошую работу в штатах на хорошой зарплате! вот так!

[Flash-04]

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

абсолютно совпадает с моей точкой зрения

[Sergey_P]

Если лист большой можно и по-замысловатее, чтоб побыстрее работало...
aList.Sort();

Это уже как минимум ln(n)*n, а предлагаемые до этого алгоритмы тупого перебора дают n

На самом деле все равно будет быстрее чем "тупого перебора", за исключкнием Sam Adams который в общем далеко не "тупого перебора".
Вот объясниите мне, почему нужен обязательно замысловатее?
В реальной жизни мв играемся с факторами K1* производительности(память/CPU)+K2*гибкость+K3*читабельность(время на понимание что код делает=> время нужное чтобы надти проблему или его модифицировать). В большей части случаев K3>>K1, но на интервью ожидают увидеть

Code: Select all

  int j = 0;
   for (int i = 0; i < list.Length; i++)
   {
      if ((string)list[i]).StartsWith(prefix))
      {
          list[j++] = list[i];
      }
   }
   if (list.Length != j)
   {
      list.Remove(j, list.Length - j);
   }

Сколько времени нужно чтобы понять, что этот алгоритм делает? Мне, на первый взгляд, кажется что он забивает строками StartsWith(prefix) начало массива, а потом удаляет из середины кусок еще незабитых строк.

Двуручник особенно если снабдит комментами

Code: Select all

aList.Sort();

int start = aList.Count;
for(int i=0; i<aList.Count; i++) {
if(aList[i].ToString().StartWith("A")) { start = i; break; }//первый элемент "A.."
}

int end = -1;
for(int i=aList.Count; i>=0; i--) {
if(aList[i].ToString().StartWith("A")) { end = i; break; }//последний элемент "A.."

}

aList.RemoveRange(start,end-start);

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

Code: Select all

      String bla = "A";
ArrayList noBlaInList = new ArrayList();
      for( int i=0; i< blaInList.size(); i++ ){
// add only noBla elements
if(!((String) listWithBla.get(i)).startsWith(bla))
 noBlaInList.add(listWithBla.get(i));
        } 

Code: Select all

//ecли нужна гибкость – не ограничиваем тип входной коллекции ArrayList
// Iterator нам кое-что будет стоить, но непринципиально 

      String bla = "A";
Iterator it = listWithBla.iterator();
      ArrayList noBlaInList = new ArrayList();
/*creates ArrayList without starts With bla elements */
      while(it.hasNext()){
         String s = (String)it.next();
         if(!s.startsWith(bla))noBlaInList.add(s);
      }

Code: Select all

//ecли нужно очистить исходный list убираем "!" и “no” 
 String bla = "A";
Iterator it = list.iterator();
      ArrayList blaInList = new ArrayList();
      while(it.hasNext()){
         String s = (String)it.next();
         if(s.startsWith(bla))blaInList.add(s);
      }
list.removeAll(blaInList);

или

Code: Select all

list.retainAll(noBlaInList);

IMO за исключкнием
List<string> a = ...
a.RemoveAll(delegate(string s) { return s.StartsWith("A"); });
самое читаемое решение.
Я не работал с FW2 (да и вообще с .NET только раз довелось поработать), но интуитивно код понятен. Вот интересно его по произволитеотности сравнить с моим, особенно по памяти.

Может мне кто объяснить почему на интервью отдают предпочтение не простым и практичным решениям, а позамысловатее.. причем обе стороны.
Помнится кто-то MS задачку подкинул .. что-то типа посчитать количество бензоколонок в US.. как потом выяснилось нужно порассуждать о потреблении бензина, etc. в результате ответ будет +/- порядки.. зачем? Бензоколоноки – бизнес который обязательно регистрировать => можно найдти совершенно точную (ну может не совсем свежую) информацию. Т.е. ожидается не решение проблемы, а упражнения "смотри какой я умный"

[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 в конструктор добавил чтобы предсказуемые результаты по памяти были

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

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