>> Так а зачем это понимать? Насколько я понимаю описанную систему, она позволяет 3 часа бездельничать, 3 часа обдумывать решение и 2 часа его реализовывать. И никаких вопросов это не вызывает.
Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 3 часа, а полчаса, и код потом пишет не два, а час. По идее, баллов ему по этой системе надо начислить за полтора часа работы, а не за 5. Но нет, проверить никак нельзя, поэтому будет 5. Еще один вывод отсюда — то, что такой человек мог бы сделать за день, он будет делать три дня. Потому что система позволяет.
>> А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче?
У нас нет итераций как концепции. Мы не исповедуем Скрам. На больших проектах на моей памяти Скрам ни разу не заработал. Задачи у нас есть — план на квартал. Раз в неделю подбиваем текущий баланс — что успели сделать, что еще осталось. Гранулярность уровня «Написать лоад-балансер для уоркеров, запущенных разными клиентами с учетом приоритетов» — пара-тройка недель. Изредка, бывает, бьем задачи на дни, когда нужно тонко выровнять расписание с какой-то другой командой и надо знать, какие части когда войдут в эксплуатацию.
>> Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист?
Мне сложно усреднять. Очень по-разному. Зависит и от человека, и от дня. Бывает, что вообще ничего в голову не лезет и не получается. День потерян. Бывает, что все в голове сложилось в картинку и забываешь обо всем вокруг и работаешь часов 12. В среднем, наверное, от 3 до 5 часов продуктивного времени в день.
На мой взгляд, вообще не стоит нормировать день, поскольку мерять вы исполнение нормы все равно не сможете — как понять, бездельничает ли программист в какой-то отдельно взятый момент или обдумывает решение какой-нибудь задачи (это ведь включается в категорию «работать»)? Можно нормировать office hours — время, когда программист должен быть доступен (на случай митингов, вопросов, помощи какой-нибудь), но это совсем не то же самое и к производительности мало относится. 5-минутный (да даже часовой) work-item, который надо куда-то логировать для меня тоже выглядит слегка дико. Задачи такого уровня гранулярности стоят больше времени на бюрократию чем на выполнение.
You get what you measure. Если мерять баллами, сотрудники находят способ максимизировать баллы. Помню, во время работы в Microsoft Dynamics CRM одно время эффективность програмиста пытались считать по количеству закрытых багов в неделю. Это привело к том, что на каждый чих программист открывал баг. Надо поменять ресурс в файле — файлим баг, Нужно поменять стиль в CSS слегка — файлим баг. И еще один side effect — реальные сложные баги, требующие серьезного анализа и приличного времени на починку, никто не трогал — не выгодно же.
А почему сразу Яндекс? Ниже я уже упоминал, где такое практикуется. А именно — топовые софтверные гиганты интервьюируют именно так — Гугл, Майкрософт, Фэйсбук, Амазон и прочие. Так же я вроде указал, почему это нужно. Те, кто считают, что это идиотизм, работают в других местах (и может даже об этом не жалеют).
Еще как вариант (если много свободной памяти) можно заранее посчитать мэп обратных зависимостей (в то же время, когда прямые считаются) — от арифметического результата к списку триад. По этим данным легко быстро построить лист билетов, не удовлетворяющим условию задачи. Можно для этого создать массив из миллиона булов, в который писать тру, на каждую такую найденную комбинацию. В конце пройти по массиву, выбрав те индексы, где значение false.
Предложенный алгоритм обхода можно слегка улучшить. Первое, что бросается в глаза — много ненужных операций с листом тикетов — почти каждый кандидат добавляется в лист, и почти каждый потом из листа убирается. Немного переписав цикл, можно оставить только добавление, которое будет происходить после внутреннего for, с заменой break на continue на внешний цикл. Второе — можно сравнивать forward-only (комбинацию с самой собой сравнивать не имеет смысла, комбинацию BA рассматривать после того как раньше рассмотрели AB тоже не имеет смысла), добавляя сразу comb1 + comb2 и comb2 + comb1.
for (int comb1Index = 0; comb1Index < combinations.size(); comb1Index++)
{
nextPair: // labeling for early exit from nested loop
for (int comb2Index = comb1Index + 1; comb2Index < combinations.size(); comb2Index++)
{
Combination comb1 = combinations[comb1Index];
Combination comb2 = combinations[comb2Index];
for (Integer x: comb1.getValues())
{
if (comb2.getValues().contains(x))
{
continue nextPair;
}
}
tickets.add(comb1.toString() + comb2.toString());
tickets.add(comb2.toString() + comb1.toString());
}
}
P.S. Прошу прощение за корявые отступы. Не могу использовать тэги, а пробелы и табы почему-то игнорируются.
Это не принципиально. Хорошо, когда кандидат может решить задачу (любым способом). Еще лучше, если он это делает эффективно (по времени выполнения, например, или по памяти — и может это объяснить). Еще лучше, если он понимает, что решить можно несколькими способами и выбирает какой-то из них, понимая, что он приобретает и что теряет, в зависимости от условий окружения — их можно уточнить у интервьюера, интервьюеры это любят. Ну, допустим, скажут вам, что структура передается извне и изменять ее нельзя. Легче решать задачу, которая в жизни может встретиться, чем задачу, которая вроде как синтетическая, просто на нахождение алгоритма? Мне кажется, что с точки зрения решения разницы никакой — и тут, и там надо найти способ решения, который человеку, не решавшему эту задачу раньше, не очевиден.
Я вот сейчас задумался — в реальном коде поиска цикла в списке я еще не встречал (что в принципе не означает, что его нет). Поиск циклов в графе встречал неоднократно. Вам бы было проще решать задачу на поиск цикла в графе (раз уж применение такому наверняка существует)?
Это типичная задача на знание структур данных с типичным решением (только список конечный, а не бесконечный, иначе в случае отсутствия цикла решение никогда не завершится), ничего общего с головоломками (типа задач про гномиков) не имеющая. Приведенное решение — линейное (от длины списка) по времени и константное по памяти (нужны два указателя, список вам уже дан и в расход памяти на решение не считается). Задачи на списки — одни из самых простых среди задач на структуры данных. И программист вообще в структурах данных должен разбираться.
Возможно не везде так, но крупные богатые компании просто так уволить человека не могут. В том же Майкрософте уволить человека (если не по статье, а за перформанс) занимает 6-12 месяцев. Собирается доказательная база, чтобы в случае чего не платить милионных компенсаций, когда он побежит в суд кричать про дискриминацию. Исключение — layoffs, сокращение штата, по-нашему. Но в таких случаях это массовая операция, не индивидуальный случай, как то, что мы рассматриваем. Релокация же и визы — копеечные расходы по сравнению с полугодовой-годовой зарплатой (сегодняшних цифр я не знаю, а 5 лет назад один работник майкрософту в среднем обходился в $250К в год, это не только зарплата — тут и обеспечение рабочим местом, и дополнительные налоги, и куча всего еще).
Предположим, у вас есть одна открытая позиция, а на интервью пришли два кандидата — вы обоим дали одинаковую задачу, оба решили. Как вы будете выбирать из них? Вы правы, насчет того, что решил бы четвертую — дали бы пятую. Но далеко не всегда это делается для того, чтобы потом давить на человека в целях дать ему более низкую зарплату. Возможно один из кандидатов решил первую задачу и не смог бы решить вторую. Или третью. А другой смог решить четыре и в общих чертах набросать решение пятой. Теперь уже понятнее, кого брать.
Ну в этих компаниях (амазон, майкрософт, гугл, фэйсбук, линкдин, и т.д.) дневное интервью — это норма. Хочешь в них работать — день придется выделить. Кроме того, при смене работы желательно сходить в несколько мест, получить несколько предложений. Это способствует повышению привлекательности пакета компенсации. В таком случае «коту под хвост» — не совсем верное определение. Да и рука набивается проходить интервью, волнение пропадает после какого-то раза — помогает впоследствии. Можно эти походы рассматривать как инвестицию в будущее.
Или эти два ДЦ — два разных работодателя (не Амазон и Амазон)? Если это так, то это не очевидно из ваших коментариев. Очевидно, что фильтр в прошлом ДЦ — это зарплата. В новом же ДЦ (Амазоновском, если я правильно понял), проверить знания на интервью не смогли — взяли слабых людей из прошлого ДЦ вместо сильных, ушедших когда-то оттуда. И это говорит либо о низкой планке, либо о том, что проверяли что-то не то. Скорее всего, и то, и другое — поговорили про предыдущий опыт, а задачки дали примитивные. С таким подходом и неделя интервью не поможет.
Я не уверен, что понимаю ваш последний вопрос. Вы ведь про конкретный ДЦ говорите? Про то, что платили мало, головастые уходили, оставались те, кто не смог бы так же удачно уйти? Теперь результат — куча заурядностей. Последний вопрос про «Are you ok?» что именно означает? И уж совсем непонятно, какое это отношение имеет к интервью.
Ну так тогда проблема совсем в другом — открытые позиции надо занимать людьми, а вменяемые туда не идут — кто-то ведь все же должен работу делать, вот и приходится брать того, кто идет. И никакой альтернативный подход к интервью проблему не решит.
Мне сложно говорить об отечественном рынке, но на западном это необходимое зло, потому как уволить человека очень сложно, а приличную зарплату платить тому, кто ничего не делает, а может быть даже еще и вредит слегка — дело накладное.
упорство и усидчивость — не основные качества, которые я бы хотел видеть в кандидате :) высиживают до конца многие. а так да, представляю — за свою жизнь десятка два таких циклов (из 5-6 интервью) сам прошел. на прошлом месте работы даже при переходе между группами надо было проходить полный цикл интервью.
Прям таки исключительно? Интересно, как в это «исключительно» попали люди, сумевшие этих идиотов как идиотов оценить. По сути — проблема в планке, которую задают интервьюеры. Если интервьюеры сами слабы, то и наберут они таких же как сами.
Я глянул https://habrahabr.ru/company/luxoft/blog/152505/ — весь список вопросов можно вложить в час, если не просить писать код на каждый вопрос. Для средненького кандидата можно растянуть на 2 часа. Код, на мой взгляд, достаточно написать на одну задачу — выделить на это минут 30. Из этого кода уже будет много понятно.
К чему я это — за час с человеком можно разносторонне обсудить вполне себе интересную задачу, где будет и дизайн, и архитектура. И интересующие куски можно попросить закодить. И мнение составится. За последние 10 лет я интервьюировал много кандидатов в Майкрософт и Гугл — именно на часовых интервью (где я был одним из 5-6 человек у кандидадата за день). И как-то оно все же работает. Не всегда нанимаются правильные люди и иногда правильные не нанимаются, но в общем случае вполне себе система работает.
Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 3 часа, а полчаса, и код потом пишет не два, а час. По идее, баллов ему по этой системе надо начислить за полтора часа работы, а не за 5. Но нет, проверить никак нельзя, поэтому будет 5. Еще один вывод отсюда — то, что такой человек мог бы сделать за день, он будет делать три дня. Потому что система позволяет.
>> А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче?
У нас нет итераций как концепции. Мы не исповедуем Скрам. На больших проектах на моей памяти Скрам ни разу не заработал. Задачи у нас есть — план на квартал. Раз в неделю подбиваем текущий баланс — что успели сделать, что еще осталось. Гранулярность уровня «Написать лоад-балансер для уоркеров, запущенных разными клиентами с учетом приоритетов» — пара-тройка недель. Изредка, бывает, бьем задачи на дни, когда нужно тонко выровнять расписание с какой-то другой командой и надо знать, какие части когда войдут в эксплуатацию.
>> Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист?
Мне сложно усреднять. Очень по-разному. Зависит и от человека, и от дня. Бывает, что вообще ничего в голову не лезет и не получается. День потерян. Бывает, что все в голове сложилось в картинку и забываешь обо всем вокруг и работаешь часов 12. В среднем, наверное, от 3 до 5 часов продуктивного времени в день.
for (int comb1Index = 0; comb1Index < combinations.size(); comb1Index++)
{
nextPair: // labeling for early exit from nested loop
for (int comb2Index = comb1Index + 1; comb2Index < combinations.size(); comb2Index++)
{
Combination comb1 = combinations[comb1Index];
Combination comb2 = combinations[comb2Index];
for (Integer x: comb1.getValues())
{
if (comb2.getValues().contains(x))
{
continue nextPair;
}
}
tickets.add(comb1.toString() + comb2.toString());
tickets.add(comb2.toString() + comb1.toString());
}
}
P.S. Прошу прощение за корявые отступы. Не могу использовать тэги, а пробелы и табы почему-то игнорируются.
К чему я это — за час с человеком можно разносторонне обсудить вполне себе интересную задачу, где будет и дизайн, и архитектура. И интересующие куски можно попросить закодить. И мнение составится. За последние 10 лет я интервьюировал много кандидатов в Майкрософт и Гугл — именно на часовых интервью (где я был одним из 5-6 человек у кандидадата за день). И как-то оно все же работает. Не всегда нанимаются правильные люди и иногда правильные не нанимаются, но в общем случае вполне себе система работает.