Здравствуйте, avpavlov, Вы писали:
U>>Потому что сложную задачу решить в формате собеседования невозможно. Можно лишь вспомнить решение сложной задачи, которую человек решал ранее. A>Естественно, поэтому можно дать среднюю и посмотреть на рассуждения кандидата
И даже среднюю нельзя. Задача даже средней сложности требует знания контекста, в котором она решается, и терминологии. Когда человек решает задачу по работе, то у него уже общее понимание контекста и принятой терминологии обычно есть, и тем не менее для новой задачи на выяснение контекста уходит от нескольких часов до нескольких дней. А на собеседовании у человека понимания контекста и вашей терминологии вообще нет, поэтому времени нужно еще больше. Соответственно на собеседовании можно решить только примитивную задачу, на чуть более сложную времени уже не хватит.
Здравствуйте, avpavlov, Вы писали:
U>>2) Способность понять какие ситуации надо обрабатывать специальным образом
A>Вот этого без реального опыта никак не достичь. А реальный опыт откладывается в голове реальными знаниями
Опыт не "откладывается", а набирается. Вы путаете опыт с набором разнородной информации, хранимой в памяти. Та информация постоянно обновляется. Старая стирается, новая добавляется, и так каждый день.
Опыт к хранимой фактической информации отношения не имеет.
U>И даже среднюю нельзя. Задача даже средней сложности требует знания контекста, в котором она решается, и терминологии. Когда человек решает задачу по работе, то у него уже общее понимание контекста и принятой терминологии обычно есть, и тем не менее для новой задачи на выяснение контекста уходит от нескольких часов до нескольких дней. А на собеседовании у человека понимания контекста и вашей терминологии вообще нет, поэтому времени нужно еще больше. Соответственно на собеседовании можно решить только примитивную задачу, на чуть более сложную времени уже не хватит.
Вот по его вопросам и можно будет понять, чего он стоит — человек с опытом задаст правильные вопросы, а балобол с перком гугления будет гнуть пальцы и утверждать, что задача поставлена некорректно или что такие задачи должны решать "специально назначенные люди" или ещё сто тысяч миллионов отговорок найдётся.
мощно задвинул
DD>Вы путаете опыт с набором разнородной информации, хранимой в памяти. Та информация постоянно обновляется. Старая стирается, новая добавляется, и так каждый день. DD>Опыт к хранимой фактической информации отношения не имеет.
надеюсь программируешь ты лучше, чем формулируешь свои мысли.
Здравствуйте, avpavlov, Вы писали:
DD>>Опыт не "откладывается", а набирается.
A>мощно задвинул
С чем не согласен?
DD>>Вы путаете опыт с набором разнородной информации, хранимой в памяти. Та информация постоянно обновляется. Старая стирается, новая добавляется, и так каждый день. DD>>Опыт к хранимой фактической информации отношения не имеет.
A>надеюсь программируешь ты лучше, чем формулируешь свои мысли.
Здравствуйте, DorfDepp, Вы писали:
DD>Здравствуйте, avpavlov, Вы писали:
DD>>>Опыт не "откладывается", а набирается.
A>>мощно задвинул
DD>С чем не согласен?
И ты и я использовали "простонародные" определения опыта, при этом ты не только разглядел между ними разницу, но и с умным видом заявил, что одно простонародное определение лучше другого.
Здравствуйте, avpavlov, Вы писали:
A>Здравствуйте, DorfDepp, Вы писали:
DD>>Здравствуйте, avpavlov, Вы писали:
DD>>>>Опыт не "откладывается", а набирается.
A>>>мощно задвинул
DD>>С чем не согласен?
A>И ты и я использовали "простонародные" определения опыта, при этом ты не только разглядел между ними разницу, но и с умным видом заявил, что одно простонародное определение лучше другого.
Здравствуйте, avpavlov, Вы писали:
A>Детский сад какой-то. Мы про математика говорим или программиста? Это для математиков всё заканчивается, когда они доказали принципиальную возможность чего-либо, а вот программисту нужно положить это на конкретную технологию, и это ни хрена не является второстепенным.
Перечисленное мной это базисные инженерные навыки, которые развиваются очень медленно, особенно в зрелом возрасте. Напротив, освоить технологию с нуля до высокого уровня при хороших инженерных навыках можно максимум за несколько месяцев. Поэтому инженерные навыки нужно проверять в первую очередь, т.к. обучить им практически невозможно, а технологическим навыкам человек обучается влет.
Если у человека хорошие базисные инженерные навыки, то, как правило, проблем положить принципиальное решение на конкретную технологию у него не возникает. Исключением может быть лишь ситуация когда вы используете шаманские технологии с очень высоким порогом вхождения. Тогда, да, опыт использования таких технологий желателен. Но если вы используете такие технологии, да еще и на тривиальных задачах, то я вам сочувствую.
Здравствуйте, avpavlov, Вы писали:
A>Вот по его вопросам и можно будет понять, чего он стоит — человек с опытом задаст правильные вопросы, а балобол с перком гугления будет гнуть пальцы и утверждать, что задача поставлена некорректно или что такие задачи должны решать "специально назначенные люди" или ещё сто тысяч миллионов отговорок найдётся.
Можно парочку примеров вопросов, которые вы задаете на собеседовании?
Тут ведь какая штука получается. Хочешь получить больше денег — приложи усилия чтоб себя продать. Хочешь в команду умных и мотивированных ребят — убавь пофигизм, и изо всех сил покажи себя специалистом и хорошим парнем.
Это не даёт никакой гарантии, что работодатель предложит то, что тебе надо. Но без этого точно без шансов.
"вялый, малознающий, без видимой перспективы — проект не потянет, команду не поведёт. Поставлю ка я его младшим помощником на багфиксинг, маразмы разгребать".
U>Можно парочку примеров вопросов, которые вы задаете на собеседовании?
Мы про СКЛ говорим? Всё нижеперечисленное применяется к кандидатам, которые заявляют в своём резюме хорошее знание СКЛ.
I) По телефону:
1) Перечислите виды джойнов?
Засчитывается просто перечисление через запятую, отличия одного от другого не требуются, но если правильно назвали, то это плюс.
Если лефт джойн был назван, то дополнительный вопрос
2) В таблице "Города" 10 записей, в таблице "Люди" 100 записей.
Таблица "Люди" ссылается на "Города" и город известен для каждого человека.
Сколько записей будет в "города лефт джойн люди по правильному условию"
С ответом не тороплю, повторяю сколько попросят. Если многократно настаивают на расшифровке "правильного условия" и требуют имён колонок — плохой знак.
"100" принимается за правильный ответ. "от 100 до 109" — это уже просто волшебный кандидат.
При телефонном собеседовании неправильные ответы не являются причиной отказа, кандидат оценивается как раз по сумме всего — как рассказывает о проектах и своей роли, как рассказывает об организации работы команды и т.д., вопросы на знание простых вещей в самом конце.
II) Личное собеседование
Если кандидата пригласили на личное собеседование, и у меня помечено что, например, про левый джойн он не ответил "ой я забыл/волновался/устал" и на личном собеседовании выясняется, что он даже не попытался освежить свои знания — очень плохой знак.
На личном собеседовании даётся листок с 8мью вопросами, ответы кандидата разбираю вместе с ним по мере написания, если ошибся, то пытаюсь намёками подтолкнуть к правильному решению (привожу контрпримеры, или прошу расписать резалтсет и т.п.) — если исправил, то хорошо. Из 8ми вопросов всего два являются обязательными, незнание которых является поводом прекратить собеседование. Остальные скорее простой способ проверить глубину текущих знаний.
Обязательные вопросы
1) Таблицы t1 и t2 заполнены следующими данными (тут нарисованы таблицы данных 1..5, 1..10):
a) Сколько строк будет выбрано в результате следующих запросов:
select * from t1, t2
select distinct * from t1, t2
2) Есть таблица городов и таблица клиентов. В таблице клиентов есть поле, ссылающееся на таблицу городов. Эта ссылка необязательная, т.е. не для каждого клиента известен его город. Также, не каждый город имеет ссылки из таблицы клиентов, т.е. не в каждом городе есть клиенты. Известно, что в базе на данный момент 100 городов, из них 20 городов не имеют клиентов. Также, в базе 1000 клиентов, и для 500 из них город неизвестен. Сколько строк вернут следущие запросы:
select * from City inner join Client on City.id = Client.city_id
select * from City left outer join Client on City.id = Client.city_id
select * from City right outer join Client on City.id = Client.city_id
select * from City full outer join Client on City.id = Client.city_id
select * from City, Client where City.id = Client.city_id
Если кандидат даже с подталкиванием не может ответить на эти вопросы, то смысла продолжать нет. На мой взгляд джойны это из разряда указателей в языке С, некоторые никогда не смогут понять как это работает (не знаю почему). Это азы СКЛ и если человек пишет в резюме 5 лет SQL и не может на эти вопросы ответить, то просто рискованно его брать.
Когда закончили с листком (у действительно опытных это занимает менее 10 минут), далее просто проверяю способность кандидата рассуждать, спрашивать, обосновывать и т.д. — прошу спроектировать несколько таблиц, связи между ними, почему так, а не этак, какие операции будет удобно делать, а какие неудобно, что нужно сделать, чтобы и эти было удобно ну и т.д.
--------------------------------
На самом деле мы никогда не ищем чистых СКЛников, а всегда Ява+СКЛ, так что есть ещё секция про Яву, но она построена на схожем принципе — 1-2 вопроса по телефону, небольшой вопросник на собеседовании и свободная беседа.
Телефонное собеседование занимает от 20 до 40 минут (в зависимости от словоохотливости кандидата), личное собеседование — 2-2.5 часа, то же в зависимости от кандидата. И телефонное и личное собеседования, и их длина заранее оговаривается с кандидатом, так что если кому-то не нравится длина собеседования — они могут отказаться и не мучать себя.
Здравствуйте, Undying, Вы писали:
A>>Опытные спецы неспособные ответить на простейшие вопросы? А в чём тогда заключается их опыт? U>В умении решать реальные задачи.
Не, я вот правда не понимаю. Есть у нас программист, который на работе, в течении нескольких лет достаточно регулярно пишет sql скрипты разной сложности. А потом приходит на собеседование и выясняется, что он не способен за разумное время решить несложную задачку на написание sql скрипта.
Какие выводы можно из этого сделать? У меня всего два получаются:
1. Он никаких скриптов на работе не писал, те врет.
2. каждый новый несложный скрипт потребует у него "пару дней чтобы вспомнить" (см сообщение рядом).
U>Знания о том как принципиальный алгоритм положить на конкретную технологию являются второстепенными, т.к. даже если разработчик чего-то не знает, то это элементарно гуглится.
Если бы это было правдой, то не существовало бы вакансии С++ программист, Java программист итд. Искали бы просто абстрактных программистов. Одна вхождение в новую технологию занимает ненулевое время.
А когда "ничего не знаю, но ща нагуглю" и возникают тонны говнокода.
A>Когда закончили с листком (у действительно опытных это занимает менее 10 минут), далее просто проверяю способность кандидата рассуждать, спрашивать, обосновывать и т.д. — прошу спроектировать несколько таблиц, связи между ними, почему так, а не этак, какие операции будет удобно делать, а какие неудобно, что нужно сделать, чтобы и эти было удобно ну и т.д.
Интересно, и как это структура таблиц может зависеть от "удобства выполнения операций" ?
Здравствуйте, Flying Dutchman, Вы писали:
FD>Здравствуйте, avpavlov, Вы писали:
A>>Когда закончили с листком (у действительно опытных это занимает менее 10 минут), далее просто проверяю способность кандидата рассуждать, спрашивать, обосновывать и т.д. — прошу спроектировать несколько таблиц, связи между ними, почему так, а не этак, какие операции будет удобно делать, а какие неудобно, что нужно сделать, чтобы и эти было удобно ну и т.д.
FD>Интересно, и как это структура таблиц может зависеть от "удобства выполнения операций" ?
Простейший пример: хранение нескольких телефонов можно сделать несколькими способами
— в одном поле через запятую
— несколько колонок
— подчинённая таблица со связью 1-ко-многим
У каждого способа есть плюсы и минусы (== удобство/неудобство выполнения тех или иных операций)
Правда этот простейший не так интересен, но поговорить можно и не о простейшем.
Здравствуйте, avpavlov, Вы писали:
A>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Интересно, и как это структура таблиц может зависеть от "удобства выполнения операций" ?
A>Простейший пример: хранение нескольких телефонов можно сделать несколькими способами
A>- в одном поле через запятую A>- несколько колонок A>- подчинённая таблица со связью 1-ко-многим
из которых правильный только последний (нормализованный).
A>У каждого способа есть плюсы и минусы (== удобство/неудобство выполнения тех или иных операций)
Трудно себе представить, какие плюсы могут быть у первых двух. Скорее наоборот — на практике много раз приходилось переделывать структуру таблиц из первых двух способов в третий.
Хотя, действительно, можно найти примеры дизайна таблиц для одной и той же функциональности, зависящие от удобства операций. Например, дерево можно хранить в таблице либо "тривиальным" образом (с внешнм ключом, ссылающимся на эту же таблицу), либо сдклать дизайн на основе вложенных множеств. О обоих случаях таблицы бкдкт нормализованными.
FD>из которых правильный только последний (нормализованный).
Это уже обсуждалось в "базах данных" поэтому не хочу спорить ещё раз, но замечу, что слепая вера в живительную силу тотальной нормализации в моих глазах является минусом. Нормализация просто один из инструментов в арсенале программиста и, как каждый инструмент, он может быть подходящим или нет.
FD>Трудно себе представить, какие плюсы могут быть у первых двух. Скорее наоборот — на практике много раз приходилось переделывать структуру таблиц из первых двух способов в третий.
Первый ("через запятую") достаточен, если никаких действий с телефонами не производится.
Второй ("много колонок") — в общем-то, тоже, — если данные в таблице не требуются для анализа. С телефонами вообще пример очень плохой, ибо для них действительно осмысленнен только третий подход.
Но жизнь штука разнообразная. Во многих системах менеджмента серверов (в т.ч. виртуальных) в таблицах хранятся performance counters — выборки/семплы. Разумеется, в tiered виде (т.е. каждые отсчеты каждые 5 секунд, затем поминутно — только 1 сутки, далее — усредненные почасовые за месяц, далее — дневные за год и т.п.). Выборка требуется по CPU (желательно поядерно!), RAM, disk space, network traffic/bandwidth consumption (по разным классам трафика, и по направлению — входящий/исходящий). Это для физических машин. У виртуальных есть эти и несколько других. У машин на Linux — есть добавочные свои счетчики, на Windows — свои. С точки зрения теоретической правильности, следует завести большущую таблицу с семплами, ключом в ней будет ID сервера + ID счетчика + дата/время семпла. Итого — от 5 до 40 счетчиков.
Но!
Имея всего-то 930 серверов (положим, 30 реальных и по 30 виртуальных на каждом — это вполне нормальная density для многих виртуализационных решений), надо каждые 5 секунд писать по 4.650-37.200 семплов, или от 930 до 7.440 в секунду.
Или нарушить чудесную теорию нормальных форм, и завести плохо расширяемую таблицу, столбцы которой будет теми самыми семплами. Негибко, зато работает.
Так вот, о чем это я. О гибкости мышления: какими бы сильными не были догмы, забитые вам в разум или даже подкорку, нельзя им тупо следовать.
A>Опытные спецы неспособные ответить на простейшие вопросы? А в чём тогда заключается их опыт?
Я бы не назвал себя мега гуру, но для примера:
на днях из любопытства сходил на собеседование — входе общения интерес к позиции пропал начисто,
и на просьбу написать запрос(на бумажке) выдал WHERE field1 = NULL, ясное дело, должно быть IS NULL
На работе IS NULL писал автоматом не задумываясь, а здесь черт дернул
Примечательно, на мой вопрос по их проекту "чем выбираете данные? например датаадаптерами...", собеседующие стушевались и промямлили "да просто, запросами"
Предполагалась работа под .Net 1.1
