Как нанять грамотного индуса?

[jms]

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

Проснитесь, братья! "Вихри враждебные веют над нами..."(с)

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

[deve]

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

Проснитесь, братья! "Вихри враждебные веют над нами..."(с)

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

Глупо мерятся оценкой своего алгортма с помощью биг О нотации. Мало это коррелирует с нашей реальностью.
W2 лучше меряйтесь

[Komissar]

Отвечая автору топика: единственно работающее решение -- это отбояриться (под предлогом "временно" и "для пользы проекта") от индусов, постараться сохранить хоть несколько ключевых людей из мск. команды. Если не получается сохранить хороших аутсорсеров - отказаться от индусов совсем. Not a good match of skills, they couldn't resolve this and that type of problems.

Далее, сидеть в первом ряду с попкорном и наблюдать, как дешевые индусы валят проекты в соседних отделах. Одновременно, искать другую работу.

Поймите, как только вы их взяли - дальше будет хуже. Хорошие индусы (даже если были) исчезнут с проекта, а плохие станут Вашей проблемой. Мол, Леша/Петя/Ваня не может справиться с менеджингом таких хороших, послушных индусов. Это его - леши-вани-петина проблема.

Если отказаться от индусов очень страшно, что начальство уволит - тогда надо согласиться на кандидата после 3 интевью, но написать начальству в емейле "особое мнение" - мол, нанимаю, но вот такие и такие concerns. И тут же активно начинать искать другую работу.

Хорошие, умные индусы существуют в природе. Но они дороже хороших местных американцев. Так што думайте сами, решайте сами.

[jms]

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

Проснитесь, братья! "Вихри враждебные веют над нами..."(с)

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

Глупо мерятся оценкой своего алгортма с помощью биг О нотации. Мало это коррелирует с нашей реальностью.
W2 лучше меряйтесь

Ну про биг О вы зря так. Я вот из этой дискусии стал чуточку умнее(благодаря ссылке от John Smith) и может когда нибудь сверкну на каком нибудь собеседовании. Ну а про W2 то я знаю что я еще скромный падаван в этой области, и не вмешиваюсь в речи гуру с шестизначными зарплатами а внимательно впитываю знания!

[SBolgov]

Кстати о гугле, вот ответ на задачу o циклическом сдвиге (Внимание! кто хочет сам решить - туда не смотреть): http://stackoverflow.com/questions/8762 ... m-position

Кстати мой алгоритм быстрее, у них 2n итерации, а у меня n
Хотя записывается их намного элегантнее.

У них тоже за n итераций ( хинт: реверс массива длины n делается за n/2 итераций)

От ить чёрт...

По ссылке не полез - хотел сам подумать. А как хинт увидел - сразу всё ясно стало.

Три реверса - и готово. Сложность - в худшем случае N (ровно N, а не O()), в лучшем N - 1. И ничего лучше не придумаешь в принципе.

Блин, вот как научиться самому додумываться до таких элегантных решений?

[jms]

Кстати о гугле, вот ответ на задачу o циклическом сдвиге (Внимание! кто хочет сам решить - туда не смотреть): http://stackoverflow.com/questions/8762 ... m-position

Кстати мой алгоритм быстрее, у них 2n итерации, а у меня n
Хотя записывается их намного элегантнее.

У них тоже за n итераций ( хинт: реверс массива длины n делается за n/2 итераций)

От ить чёрт...

По ссылке не полез - хотел сам подумать. А как хинт увидел - сразу всё ясно стало.

Три реверса - и готово. Сложность - в худшем случае N (ровно N, а не O()), в лучшем N - 2. И ничего лучше не придумаешь в принципе.

Блин, вот как научиться самому додумываться до таких элегантных решений?

Не может быть сложность N-2 (ну если не считать вырожденных случаев вроде m = 0), так как все элементы должны быть передвинуты.. Ну и сложность это количество элементарных операций, а не итераций цикла, так что все таки O(n).

[SBolgov]

Не может быть сложность N-2 (ну если не считать вырожденных случаев вроде m = 0), так как все элементы должны быть передвинуты..

А, да. N-1 всё-таки. Сейчас поправлю.

Мне померещилось, что если N - чётное, а m - нечётное, то экономим 2 перестановки, а не одну.

Ну и сложность это количество элементарных операций, а не итераций цикла, так что все таки O(n).

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

P.S. А если m = 0, то и сложность 0.

[John Smith]

Предлагаю задачку поместить в головоломки, а по теме - я с Комиссаром согласен - от индусов отпихиваться до последнего патрона

Грамотность - неграмотность индусов - здесь уже никакой роли не играет. У них же подход прост - нужно загрести весь девелопмент (пусть даже начиная с каких нибудь на первый взгляд второстепенных задач) + манаджмент под себя, в Индию, или правильным вендорам. А когда клиент готов - то все, поезд уже ушел грамотность проверять, причем ушел етот поезд вместе с вами.

[jms]

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

Именно что бы абстрагироватья от конкретной архитектуры/языка и т.д. и придумали big O. Остальное все допущения.

[Kalifornian]

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

Самый цЫрк это когда русский программист интервьирует своего собрата.

[Mic]

Глупо мерятся оценкой своего алгортма с помощью биг О нотации. Мало это коррелирует с нашей реальностью.
W2 лучше меряйтесь

[Mic]

Вот, кстати, версия, аццки быстрая, полезная, если у вас множественое обращение к одному и тому же массиву:

Code: Select all

private List<string[]> cache = null;

public void FastLoopShifting()
{
	string[] arr = { "0", "1", "2", "3", "4" };
	string[] result = FastShift(arr, 3);
	PrintResult(result, 0);
}

private string[] FastShift(string[] arr, int shift)
{
	if (arr == null)
		throw new ApplicationException("The parameter 'string[] arr' is null");

	GetCacheReady(arr);
	return cache[shift];
}

private void GetCacheReady(string[] arr)
{
	if (cache != null)
		return;

	if (arr == null)
		throw new ApplicationException("The parameter 'string[] arr' is null");

	cache = new List<string[]>();
	cache.Add((string[])arr.Clone());

	for (int i = 0; i < arr.Length - 1; i++)
	{
		ShiftRight(arr);
		cache.Add((string[])arr.Clone());
	}
}

[SBolgov]

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

Именно что бы абстрагироватья от конкретной архитектуры/языка и т.д. и придумали big O. Остальное все допущения.

Полностью избавиться от допущений big O всё равно не позволяет. Ибо "N итераций цикла = O(N) элементарных операций" только в том случае, если каждая итерация требует O(1) операций. А это уже и есть допущение об архитектуре.

Так что лучше всё-таки сложность мерять итерациями. "Элементарные операции" слишком уж разными бывают.

P.S. big O, кстати, придумали для нужд матанализа. В те времена, когда о языках программирования и архитектурах ещё и речи не было.

[dB13]

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

Согласен с Komissar'ом. Всё же, что мешает московской команде последовать стратегии индуской? Оутсорс -- опасная штука.

[eagersh]

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

Самый цЫрк это когда русский программист интервьирует своего собрата.

Прямо в точку. Особенно в Америке. Не знаю про другие страны.
Я пару раз попадал в похожие ситуации. Если интервируемый, который явно по акценту русскоговорящий, разговаривает с тобой на английском то это еще ничего. Интервью проходит как обычно. Но если с порога начинает говорить на русском то можно вставать и уходить. Причины отказа могут быть разные. От типа "у вас нету никакой квалификации и проэкт над котором вы работаете вообще то работать не должен так как у него архитектура не правильная", делая анализ всего за несколько минут не вникая в детали, до вообще смешных причин типа "А вы знаете сколько стоит жилье в Силиконовой Долине? У вас сколько дом стоит в городе? Такой дом вы здесь позволить не можете." Последнее пожелание было высказанно в компании которой нужен был определенного плана специалист которого они не могли долго найти. Пригласил меня на интерью индус, у которого начальник русский, наивно пологая что это поможет меня нанять в компанию. Он ведь не знал что у русских все наоборот. Может мне так везло, но я и у других знакомых такое тоже случалось. У индусов надо брать пример. Да и у китайцев тоже. И тогда не будет проблем с передачей проэктов из России в Индию.