Здравствуйте, genre, Вы писали:
G>бесспорно, "видел" лучше чем "не видел". но "видел" хуже чем "делал". G>в этом же форуме многие склонны между последними ставить знак равенства.
Если брать архитектора системы, то желательно чтобы он и делал тоже. Но, хорошие архитектуры живут долго. Можно устроиться в фирму, поработать там 3-6 лет, а дизайн архитектуры существенно не поменяется. Поэтому у человека не будет возможности сделать что-то самому, а вот посмотреть как другие делали — пожалуйста.
А вот во всяких студенческих компаниях, где архитектуры как таковой просто нет, там да, у каждого есть возможность сделать что-то, а потом рассказывать как это было хорошо, а в этом время очередной переписывальщик делает свой хороший дизайн архитектуры.
Здравствуйте, elmal, Вы писали:
G>>видел хороший дизайн — в слове видел слишком много ошибок. должно быть "делал". G>>ну и тд. E>Проблема в том, что весьма мало людей просто видели хороший дизайн и хороший код, не то чтоб это все делать. В результате будут искренне убеждены, что то, что у них сейчас есть — оно великолепно, и они превосходные специалисты.
Хуже всего, если они не имея нормального опыта прочтут про паттерны проектирования, и будут считать, что у них идеальный дизайн ПО.
Здравствуйте, genre, Вы писали:
G>еще раз. есть команда, есть проект, все в курсе всего. в курсе решаемых в данный момент задач, проблем итд. нормальная командная работа. G>то есть на все перечисленные выше вопросы ответ у всех примерно один, отличие в умении формулировать. G>а уровень программистов — радикально разный. но пока на уровень кода не опустишься — не поймешь этого.
Умение сформулировать тоже очень, и очень важно. Если человек не способен устно выражаться и объяснять что к чему, значит он и мысли свои нормально сформулировать не может, и не может работать в команде (где ведется совместная работа и обсуждение). А значит и в коде у него потом ничего не разберешь. Будет шифровка в стиле
if (((i++) % 20) >> 5) return true;
А ораторское искусство тут не так важно, т.к. идет техническая дискуссия и обсуждение технических деталей.
Кроме вопросов по проекту полезно проверить знание ООП и паттернов (без фанатизма, просто для проверки кругозора).
Стиль кода тоже важен, конечно, но как раз его несложно натренировать, если с остальным все хорошо. Ввести соглашение о коде, в крайнем случае настроить IDE чтобы она не компилировалась при несоответствии.
И настаиваю, что пример слишком абстрактный и маловероятный. Все умеет, только ленивый. Как лень проверить на собеседовании? Или так умело показывает что все умеет, но на самом деле не умеет. Ну так задай пару вопросов за пределами комфортной зоны. Если он такой молодец, что наизусть выучил все обсуждения, детально изучил код коллег (и при этом сам ничего не делал, потому что ленивый!!! а все запоминать не лень было???), а думать и кодить не научился, то при первом же вопросе за пределами его зубрежки он посыпется.
Здравствуйте, genre, Вы писали:
G>еще раз. есть команда, есть проект, все в курсе всего. в курсе решаемых в данный момент задач, проблем итд. нормальная командная работа. G>то есть на все перечисленные выше вопросы ответ у всех примерно один, отличие в умении формулировать. G>а уровень программистов — радикально разный. но пока на уровень кода не опустишься — не поймешь этого.
Да, есть команда.
И каждый в ней делает свои задачи.
Несомненно все кое-что(что именно может сильно отличаться в разных командах) знают про задачи всех остальных.
Но именно кое-что. Все они знают именно про свои задачи.
Один делал ресерч и в результате выбрал одно из опробованных им решений.
А другой добавлял поле на форму.
Не будут их ответы одинаковыми никак.
Но это я конечно описал только частный случай из своей практики.
Могу предположить что бывают команды где все добавляют поля на формы. Там скорее всего у всех ответы будут одинаковые
On 15.02.2013 14:36, genre wrote:
> еще раз. есть команда, есть проект, все в курсе всего. в курсе решаемых > в данный момент задач, проблем итд. нормальная командная работа. > то есть на все перечисленные выше вопросы ответ у всех примерно один,
Конечно нет. Буду пытаться тебе объяснить на упрощенных аналогия. есть
бригада каменьшиков — они кирпичи кладут, только оддни углы, а другие
плоскости под веревочку. Так и здесь, все в общем-то в курсе, но каждый
делает конкретные свои задачи и вполне может рассказать, что именно он
сделал, ка ки почему. А если не может, то 90%, что ничего не делал, а
только участвовал и 10%, что говорить не умеет. Что один, что второй
вариант плохих работников.
Здравствуйте, alzt, Вы писали:
G>>понимает по всем проекте может быть от принимал все ключевые решения, до наблюдал как другие принимали эти решения A>Обычно людям неинтересно смотреть как другие принимают решения. Если человек что-то знает, то он точно не в стороне был.
Ну я уже давно избавился от подобного идеализма. Чего и тебе советую.
G>>делает ревью — от находит кучу ошибок до просто долго смотрит в чужой код лишь бы ничего не делать A>Нет таких людей, которые просто смотрят в код. Лучше на рсдн потрындеть.
Ага. Именно. потрындел на рсдн полдня, а отметил, что ревью делал.
A>Если делал ревью, то уже плюс. При постоянных ревью кучи ошибок не будет. A>И здесь ещё плюс, что его код тоже ревьюрится.
Ну ты как собеседующий о результатах этого ревью никогда не узнаешь.
G>>видел хороший дизайн — в слове видел слишком много ошибок. должно быть "делал". A>Сделать что-то хорошее, ни разу не видев как делают хорошо, довольно сложно. A>Если человек не видел хороших дизайнов, но "делал" их, то у меня подозрение, что он переоценивает свою поделку.
Не понимаю этого логического перехода. Речь о том, что из подобной беседы на собеседовании очень сложно узнать делал человек или видел.
Здравствуйте, nile, Вы писали:
G>>еще раз. есть команда, есть проект, все в курсе всего. в курсе решаемых в данный момент задач, проблем итд. нормальная командная работа. G>>то есть на все перечисленные выше вопросы ответ у всех примерно один, отличие в умении формулировать. G>>а уровень программистов — радикально разный. но пока на уровень кода не опустишься — не поймешь этого.
N>Кроме вопросов по проекту полезно проверить знание ООП и паттернов (без фанатизма, просто для проверки кругозора).
то есть твои вопросы по проекту не касаются дизайна (а то есть ооп и паттернов в том числе)? тогда я вообще не понимаю, какие выводы ты можешь сделать из общего разговора о выполненных проектах.
конечно должны быть вопросы и про ооп и про паттерны. но если ты с этим согласен, тогда мне решительно непонятно почему в один ряд с этим не становятся вопросы про алгоритмы. это точно такая же часть работы программиста как и паттерны.
N>Стиль кода тоже важен, конечно, но как раз его несложно натренировать, если с остальным все хорошо. Ввести соглашение о коде, в крайнем случае настроить IDE чтобы она не компилировалась при несоответствии.
стиль кода в смысле расстановки скобочек меня вообще не интересует. а вот стиль кода в смылсе, непример, разбиения на классы проверить невозможно не опускаясь на уровень кода.
N>И настаиваю, что пример слишком абстрактный и маловероятный. Все умеет, только ленивый. Как лень проверить на собеседовании? Или так умело показывает что все умеет, но на самом деле не умеет.
Вот я не понимаю, как из того, что человек рассказывает о сделанном делается вывод, что он это умеет. Вон зайди в автораздел. Там каждый второй рассказывает о конструкции двигателей, досконально в деталях, разбирая что хорошо и что плохо. Можно ли доверить им конструирование нового?
N>Ну так задай пару вопросов за пределами комфортной зоны. Если он такой молодец, что наизусть выучил все обсуждения, детально изучил код коллег (и при этом сам ничего не делал, потому что ленивый!!! а все запоминать не лень было???), а думать и кодить не научился, то при первом же вопросе за пределами его зубрежки он посыпется.
Вот именно поэтому на собеседовании предлагается не только рассказать о старом, но и сделать что-то новое, чтобы выйти за пределы зубрежки.
Здравствуйте, robin_of_the_wood, Вы писали:
___>Да, есть команда. ___>И каждый в ней делает свои задачи.
___>Несомненно все кое-что(что именно может сильно отличаться в разных командах) знают про задачи всех остальных. ___>Но именно кое-что. Все они знают именно про свои задачи.
ну если у тебя команда с крайне жестким распределением обязанностей, то, да, ответы будут разными. но большинство команд все-таки стремится к обратному.
___>Один делал ресерч и в результате выбрал одно из опробованных им решений. ___>А другой добавлял поле на форму. ___>Не будут их ответы одинаковыми никак.
когда первый сделал ресерч, он рассказал о результатах команде, что ресерчилось, как, почему, какие результаты, почему сделан выбор именно в пользу выбранного потому что работать с этой технологией предстоит всем. и если через полгода оба придут к тебе на собеседование то выявить автора будет очень сложно. ну например потому, что когда тебе человек ответит "да я не помню уже таких мелочей, полгода назад было" ты не поймешь не помнит ли он или не знал никогда
Здравствуйте, alzt, Вы писали:
A>Если брать архитектора системы, то желательно чтобы он и делал тоже. Но, хорошие архитектуры живут долго. Можно устроиться в фирму, поработать там 3-6 лет, а дизайн архитектуры существенно не поменяется. Поэтому у человека не будет возможности сделать что-то самому, а вот посмотреть как другие делали — пожалуйста. A>А вот во всяких студенческих компаниях, где архитектуры как таковой просто нет, там да, у каждого есть возможность сделать что-то, а потом рассказывать как это было хорошо, а в этом время очередной переписывальщик делает свой хороший дизайн архитектуры.
ну я все-таки про дизайн, а не про архитектуру. архитектор это штучный товар. а дизайнить приходится каждому.
On 15.02.2013 15:22, genre wrote:
> ну я все-таки про дизайн, а не про архитектуру. архитектор это штучный > товар. а дизайнить приходится каждому.
Не хочу оскорбить, но сразу чувствуется профессионал в ИБД.
Здравствуйте, jazzer, Вы писали:
J>(Надеюсь, ты видишь проблемы в обоих примерах? Если да, то ты, наверное, все-таки имеешь представление о сложности)
Здесь проблема не в сложности. Первый метод — там фикс будет в одной строчке и профайлером эта проблема исправится на ура. А вот во втором примере — там все очень серьезно. Ибо нарвались на неленивого копипастера. Соответственно он там такого понаделает, что потом его творчество хрен когда исправишь. Более того, будет постоянно срывать сроки. И там потом придется вообще все переписывать, затратив огромное количество ресурсов. Так вот — проверки на знание алгоритмов, всяких сложностей и т.д абсолютно не позволят распознать копипастера. А взять копипастера — это просто капец всему, за ним настолько нужно следить, что проще самому всегда все делать.
Здравствуйте, genre, Вы писали:
___>>Да, есть команда. ___>>И каждый в ней делает свои задачи.
___>>Несомненно все кое-что(что именно может сильно отличаться в разных командах) знают про задачи всех остальных. ___>>Но именно кое-что. Все они знают именно про свои задачи.
G>ну если у тебя команда с крайне жестким распределением обязанностей, то, да, ответы будут разными. но большинство команд все-таки стремится к обратному.
Да, у меня в команде ресерч не каждому делать поручали.
Ну а стремиться — дело нужное и правильное.
___>>Один делал ресерч и в результате выбрал одно из опробованных им решений. ___>>А другой добавлял поле на форму. ___>>Не будут их ответы одинаковыми никак.
G>когда первый сделал ресерч, он рассказал о результатах команде, что ресерчилось, как, почему, какие результаты, почему сделан выбор именно в пользу выбранного потому что работать с этой технологией предстоит всем. и если через полгода оба придут к тебе на собеседование то выявить автора будет очень сложно. ну например потому, что когда тебе человек ответит "да я не помню уже таких мелочей, полгода назад было" ты не поймешь не помнит ли он или не знал никогда
В теории все так и есть.
А на практике я помню чего я ресерчил 10 лет назад и НИКОГДА не поверю что это можно забыть за год даже.
А вот забыть про то, что кто-то когда-то расказывал про какие-то там ресерчи когда я тут со своей формой мучался — вот тут без вопросов.
У меня был случай когда с прошлой работы новые люди попавшие на бывший мой проект звонили и расспрашивали про проект.
Я им говорю "Так из моей команды ведь остались в Вашей фирме люди работать. У них спросите"
А они отвечают "Спрашивали. Они уже не помнят ничего"
А я помню до сих пор и тот проект и все его проблемы.
И это совсем не потому что у меня память хорошая
Здравствуйте, robin_of_the_wood, Вы писали:
___>В теории все так и есть. ___>А на практике я помню чего я ресерчил 10 лет назад и НИКОГДА не поверю что это можно забыть за год даже.
а в моей практике человек делавший ресерч может много помнить про принятое решение, потому что его пришлось использовать и очень мало про откинутые варианты. что логично.
On 15.02.2013 15:54, robin_of_the_wood wrote:
> Я им говорю "Так из моей команды ведь остались в Вашей фирме люди > работать. У них спросите" > А они отвечают "Спрашивали. Они уже не помнят ничего" > А я помню до сих пор и тот проект и все его проблемы.
Они скорее всего тоже помнять, но на той конторе отношения такие, что
никто и никому ничего говорить не должен, тем более помогать.
Не ты один, я тоже в такой ситуации оказывался.
Здравствуйте, genre, Вы писали:
___>>А на практике я помню чего я ресерчил 10 лет назад и НИКОГДА не поверю что это можно забыть за год даже.
G>а в моей практике человек делавший ресерч может много помнить про принятое решение, потому что его пришлось использовать и очень мало про откинутые варианты. что логично.
Тут я с Вами согласен.
Но те, кто только что-то слышали про тот ресерч, едва ли вспомнят о нем вообще.
Оно им даром не надо было. Они свои задачи делали и лишними проблемами голову не забивали. Что тоже весьма логично.
Но при этом они будут 10 лет помнить кто перебрал лишнего на корпоративе и безобразничал
Здравствуйте, Vzhyk, Вы писали:
V>Они скорее всего тоже помнять, но на той конторе отношения такие, что V>никто и никому ничего говорить не должен, тем более помогать. V>Не ты один, я тоже в такой ситуации оказывался.
В том конкретном случае — маловероятно.
Но подходец "Я это две недели ковырял — пусть и они помучаются" встречался.
Слава богу не часто
Здравствуйте, robin_of_the_wood, Вы писали:
___>Тут я с Вами согласен. ___>Но те, кто только что-то слышали про тот ресерч, едва ли вспомнят о нем вообще. ___>Оно им даром не надо было. Они свои задачи делали и лишними проблемами голову не забивали. Что тоже весьма логично.
они потом с результатами этого ресерча работали. так что обычно в теме.
Здравствуйте, genre, Вы писали:
G>они потом с результатами этого ресерча работали. так что обычно в теме.
То, что они с результатами работают — факт.
А вот, то что они помнят(знают, интересуются) откуда этот результат взялся — из первого совершенно не следует. Хотя и вполне возможно.
Люди обычно не склонны усложнять свою жизнь.
Да, есть конечно любознательность и все такое.
Но в любом случае спорить особо не буду.
Ваш случай возможен а кому и как часто встречается — это уже как карта ляжет.
Свой случай я тоже не рассматриваю как наиболее вероятный и уж тем-более едитственно верный.
Просто его стоит упомянуть среди массы других вариантов.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>(Надеюсь, ты видишь проблемы в обоих примерах? Если да, то ты, наверное, все-таки имеешь представление о сложности) E>Здесь проблема не в сложности.
Именно в ней. Человек просто не думает, как будет выполняться то, что он пишет.
E>Первый метод — там фикс будет в одной строчке и профайлером эта проблема исправится на ура.
Фикс в ДНК. Вернее, в том, что люди, не имеющие проблем с оценкой сложности кода, такую глупость не будут писать и без профайлера.
Опять же, по опыту других сотрудников, у которых не было проблем на собеседовании — нет проблем и с их кодом.
E>А вот во втором примере — там все очень серьезно. Ибо нарвались на неленивого копипастера. Соответственно он там такого понаделает, что потом его творчество хрен когда исправишь. Более того, будет постоянно срывать сроки. И там потом придется вообще все переписывать, затратив огромное количество ресурсов. Так вот — проверки на знание алгоритмов, всяких сложностей и т.д абсолютно не позволят распознать копипастера. А взять копипастера — это просто капец всему, за ним настолько нужно следить, что проще самому всегда все делать.
Копи-паста тут — полбеды, если человек понимает, какой эффект его копипаста будет иметь.
Разворачивание цикла вручную — это ведь тоже копи-паста, в общем-то.
Даже оставляя за рамками оптимизацию двойного цикла — ведь достаточно было бы даже закешировать в первой строчке тела цикла ссылку на найденный в мапе объект и дальше копи-пастить присваивание внутрь этой найденной ссылки — уже будет работать на 2 порядка быстрее, так вместо 100 сеансов поиска будет всего один.
А здесь пример именно не думания о том, что происходит.
И это выясняется на собеседовании элементарно, когда просишь человека оценить сложность алгоритма, который он написал — у нормального программера ответ будет готов сразу, потому что он об этом думал параллельно с написанием кода (равно как и о том, что будет в случае исключений — это тоже очень хорошо видно на тестовых задачах прямо на собеседовании).
И поэтому я прошу всех, кто ругает задачи на собеседовании, задуматься — а как еще оценить кандидата и отсеять копи-пастеров и прочих бездумно кодящих? У всех ведь резюме примерно одинаково выглядит, у всех опыт за плечами, куча проектов и базвордов.
Поймите простую вещь — по резюме все кандидаты одинаковые.
Резюме злостного копипстера ничем не отличается от резюме нормального вдумчивого программера.
Как распознать, если не давать заданий? (NB я не имею в виду задачи про гномиков и сам их никогда не задаю, я имею в виду задачи, позволяющие оценить стиль программистского мышления)
Здравствуйте, jazzer, Вы писали:
J>И поэтому я прошу всех, кто ругает задачи на собеседовании, задуматься — а как еще оценить кандидата и отсеять копи-пастеров и прочих бездумно кодящих? У всех ведь резюме примерно одинаково выглядит, у всех опыт за плечами, куча проектов и базвордов.
Элементарно. Дать соискателю вот такой код, и пусть рассказывает что в нем плохо и как его улучшить, а то и показывает. Очень быстро и эффективно. Гораздо это лучше, чем тест на умение компилировать в уме с ответами что выведется. J>Резюме злостного копипстера ничем не отличается от резюме нормального вдумчивого программера.
Отличается. У копапастера резюме однозначно будет круче .
