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

N>По сути не сушествует идеального подхода.
N>Знание базовых алгоритмов не гарантирует, что собеседуемый является хорошим работником. Это всего лишь гарантирует, что он знает базовые алгоритмы. Сможет ли он применить их в реальной жизни — вопрос открытый. Ориентируется ли он в реальных задачах, зачастую нечетко сформулированных — далеко не факт.

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


N>Большой опыт участия в сложных проектах не гарантирует, что собеседуемый является хорошим кодером. Это всего лишь гарантирует, что у него хороший кругозор и он владеет предметной областью на экспертном уровне (ну т.е. может посоветовать, выбрать правильное направление, но при этом может выдать некачественный код).

N>Какой выход? Надо комбинировать оба подхода.
N>1. Обсудить предыдущий опыт в деталях
N>2. Предложить тестовое задание, и обсудить его решение, с написанием кода. Но задание необязательно должно быть академическим и алгоритмическим. Это вполне может быть и реальная задача из предстоящего проекта.
N>3. Собеседование проводят несколько человек. На что не обратит внимание один, заметит другой. В комплексе получим более-менее объективную картину.

а вот с этим я в целом согласен.

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

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

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

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

>> Ну вот занимался он автоматизацией бухгалтерии. я предментной области не
>> знаю, архитектуру он не разрабатывал (следовательно за нее не отвечает),
>> да и разглашать ничего не может. ну и о чем мы поговорим?
V>Что за бред про разглашать не может. Даже если для ФСБ что делал, есть
V>то, что можешь рассказывать, а есть то, что не можешь. ДЛя рограммиста
V>же не требуется рассказывать, какие методы слежки он применял, для него
V>требуется рассказать, что именно он в програмерской части делал и как и
V>почему.
ну NDA разные бывают. а по поводу первых пунктов возражения есть?
V>Если же чел сразу же прикрывается НДА, то идет лесом, потому как точно
V>ничего не делал.
ну я пошол

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

V>Да нет, отсевая опытных, ты именно что мешаешь. Просто у вас достаточно
V>крепкое ядро, которое раньше набрали, на нем и держитесь.
Спасибо, что глаза открыл. Я-то мучался, отчего ж мы еще держимся...

On 14.02.2013 19:32, cvetkov wrote:

> не проблема, точных формулировок я может и не вспомню, но поддержать
> разговор смогу.
Ну-ну. Главное верить. Ну например, расскажи мне о EM алгоритме, а
иначе, если не знаешь, как ты им пользоваться будешь. Ладно упрощу,
расскажи мне алгоритм Витерби. И т.д. Просто в отличие от многих
недоманагеров тут я подобной глупостью никогда не страдал.

> но это к делу не относится, мы спрашиваем вопросы относящиеся к
> специализации и имеющие, хоть и косвенное, но отношение к исполняемым
> обязанастям.
А это вопросы непосредственно по работе, а не косвенно.

On 14.02.2013 19:32, cvetkov wrote:

> ну я пошол
Кто ты?

On 14.02.2013 20:22, qxWork wrote:

> Спасибо, что глаза открыл. Я-то мучался, отчего ж мы еще держимся...
Я рад, что помог.

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

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

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

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

V>Жесть. Ну не может такого быть. Ты просто не в курсе деталей проекта,
V>поэтому он тебе и кажется одним сполошным пятном. Вот ты точно не
V>расскажешь, если попросить.
Напомнило эпизод с английским. В школе ещё сдавал экзамен по английскому языку, там зачем-то должна была приехать какая-то проверка, которая проверяет не столько меня, но и главным образом учителя. Если всё будет совсем плохо, то и ученикам поставят оценки ниже.
И учитель говорит нам — вы главное поувереннее отвечайте, если не знаете ничего по билету, рассказываете просто что знаете, всё равно в коммиссии все немецкий учили.

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

A>Так брать надо. Если человек понимает не только в своей области ответственности, но и во всём проекте, регулярно делает ревью сам и подвергается, видел хороший дизайн, работал в организации с хорошо поставленными процессами, да ещё и коммуникабельный.
A>Непонятно, кто вам нужен.

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

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

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

G>видел хороший дизайн — в слове видел слишком много ошибок. должно быть "делал".
G>ну и тд.
Проблема в том, что весьма мало людей просто видели хороший дизайн и хороший код, не то чтоб это все делать. В результате будут искренне убеждены, что то, что у них сейчас есть — оно великолепно, и они превосходные специалисты. Они может даже и видели, но не смогли отличить хороший дизайн от плохого. Ибо если видел хороший дизайн — будешь потом стремиться сам его повторить, а то и сделать лучше того, что видел. Если же не видел такого, то пока сможешь поставить перед собой подобную планку — пройдет лет 20-30, и ты хоть обчитайся вводных книжек по базовым алгоритмам и деталям каких то технологий, хоть наизусть это все выучи — все равно так и не научишься нормально дизайнить и писать нормальный код.

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

G>меня даже радует, что так много людей придерживаются мнения, что этого достаточно. Это дает мне шанс на то, что все программисты обладающие перечисленными выше качествами, но при этом категорически не умеющие думать, решать задачи и писать хороший код рано или поздно скопятся где-то вокруг тебя в вжика, а мне повезет работать с нормальными людьми.
Мы обсуждаем сферических коней в вакууме. Где бы найти этих гениальных лентяев, которые так хорошо разбираются в предмете, при этом ничего не делая.
Если человек сам ничего не делал, то это все равно вскроется, если копнуть глубже (и при условии, что интервьюер ориентируется в теме).
Если интервьюер не может определить уровень компетентности соискателя, может проблема в интервьюере и он сам не может понять, кто ему нужен?

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

V>On 14.02.2013 19:32, cvetkov wrote:

>> не проблема, точных формулировок я может и не вспомню, но поддержать
>> разговор смогу.
V>Ну-ну. Главное верить. Ну например, расскажи мне о EM алгоритме

Хороший вопрос, поддерживаю

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

E>Проблема в том, что весьма мало людей просто видели хороший дизайн и хороший код, не то чтоб это все делать. В результате будут искренне убеждены, что то, что у них сейчас есть — оно великолепно, и они превосходные специалисты. Они может даже и видели, но не смогли отличить хороший дизайн от плохого. Ибо если видел хороший дизайн — будешь потом стремиться сам его повторить, а то и сделать лучше того, что видел. Если же не видел такого, то пока сможешь поставить перед собой подобную планку — пройдет лет 20-30, и ты хоть обчитайся вводных книжек по базовым алгоритмам и деталям каких то технологий, хоть наизусть это все выучи — все равно так и не научишься нормально дизайнить и писать нормальный код.

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

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


N>Если человек сам ничего не делал, то это все равно вскроется, если копнуть глубже (и при условии, что интервьюер ориентируется в теме).

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

On 15.02.2013 14:17, genre wrote:

> насколько глубже?
> что конкретно надо спрашивать у человека, который рассказывает, что
> работал в таком-то большом проекте, за последние полгода сделал такие-то
> фичи.
Вот и спрашивать про эти фичи. Пойми меня интересует не его
деятельность, а только то что он сделал, как и почему.
А глубже? До тех пор пока не объяснит в деталях. Знаю тему, хорошо, не
знаю, еще лучше, будет объяснять до тех пор, пока не пойму. Если не
сможет объяснить что он сделал, как и почему пойдет лесом — зачем такие
работники, которые не понимают, что делают. Мы же не кубометры грунта
выдаем на гора.

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

N>>Если человек сам ничего не делал, то это все равно вскроется, если копнуть глубже (и при условии, что интервьюер ориентируется в теме).

G>насколько глубже?
G>что конкретно надо спрашивать у человека, который рассказывает, что работал в таком-то большом проекте, за последние полгода сделал такие-то фичи.

Спросите про проблемы, которые были на проекте.
Про нерешенные спросите. Почему не решили. Что перепробовали. Почему именно это.
Про те что решали-решили. Опять же что пробовали, почему выбрали именно конкретный вариант.
И активность человека и его вклад и его роль очень сильно прояснятся.

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

___>Спросите про проблемы, которые были на проекте.
___>Про нерешенные спросите. Почему не решили. Что перепробовали. Почему именно это.
___>Про те что решали-решили. Опять же что пробовали, почему выбрали именно конкретный вариант.
___>И активность человека и его вклад и его роль очень сильно прояснятся.

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

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

L> Здравствуйте господа интервьюеры. Скажите какой принципиальный смысл спрашивать университетскую ерунду на собеседованиях.
L> Навеяно тем что на последнем интервью начали спрашивать реализации стандартных коллекций ну и временные сложности алгоритмов. на моё удивление я всё же помню принцип работы сортировок ,поиска . Даже помню реализацию TreeMap. Однако не помню реализацию hashmap)
L> Вобщем вопрос такой. спрсите у меня всё это сразу посе вуза) я бы ответил без вопросов. Даже с временными сложностями. Но вот как то быть полезным фирме врят ли бы смог) Сейчас когда за плечами куча сданных проектов чувствуються силы и понимание. Есть пару сертификатов международно признанных. Но вот непомню я к примеру сколько будет временная сложность сортировки по Хоару. Непомню точную реализацию Hashmap . Скажите мне теперь в нормальной конторе делать нечего?

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

У меня бывали в подчинении такие вот сотрудники (и при первой же возможности мы от них избавились, ессно), тоже с сертификатами и "кучей сданных проектов за плечами", которые писали код типа

for (int i=0; i<strlen(s); ++i)
  s[i] = to_upper(s[i]);

или

std::map< std::string, std::vector<int> > bigmap;
for( std::string name: names)
{
  bigmap[name][0] = 0;
  bigmap[name][1] = 1;
  bigmap[name][2] = 2;
  ...
  bigmap[name][100] = 100;
}

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

Профессиональный программер должен думать о многих вещах одновременно.
В частности, при написании кода нужно постоянно думать о
1) сложности по времени и памяти того, что ты пишешь;
2) устойчивости кода к исключениям (особенно важно в С++);
3) (если многопоточное исполнение) о гонках и блокировках.
Это все должно крутиться у тебя в бэкграунде, прямо пока ты пишешь код, а не так что ты вначале наколбасил гору кода, а потом стал думать (если вспомнил), а какая же получилась сложность. Это должна быть профессиональная привычка.

You will always get what you always got
  If you always do  what you always did

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

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

G>делает ревью — от находит кучу ошибок до просто долго смотрит в чужой код лишь бы ничего не делать
Нет таких людей, которые просто смотрят в код. Лучше на рсдн потрындеть.
Если делал ревью, то уже плюс. При постоянных ревью кучи ошибок не будет.
И здесь ещё плюс, что его код тоже ревьюрится.

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