E>>При реальной работе я обставлю всех кандидатов, конкурентов не боюсь, а о них мечтаю. При собеседованиях — приоритет будет у того, кто меньше ошибется в вопросах многопоточности. Отношусь философски — не требуются мои сильные стороны, вам же хуже. А может и лучше, а то если возьмете меня, то по прошествии времени, авторитет будет у меня, а не у вас. ОК>За это я спокоен. Наоборот, считаю, что лучше работать с толковыми ребятами.
Проблема еще в том, что все считают себя умными на деле такими не являясь. И еще я заметил что меньше знает человек или способен на что-то, то тем больше он мнит о себе. Ну да это оффтопик уже.
H>>int avg(int x, int y) { return (int)(((long long)x + y)/2); }
LMA>Уже лучше. Если бы в начале был еще assert (лучше статический), проверяющий, что размер long long больше, чем размер int, так вообще было бы хорошо. Соответственно — хороший повод на собеседовании обсудить цену преобразования int в long long и операций над ним на разных платформах, особенно если речь именно об C, а не C++, потому что C99 требует для long long не менее 64 бит. Ну и т.д.
Еще советую изменить название функции на какой-нибудь набор букв и цифр и тогда никто уж точно не поймет что она делает!
H>>При этом создатели STL не страдали идиотизмом проверки на переполнения, справедливо считая что это вопрос к программисту который использует инструмент и выбирает адекватные типы данных.
LMA>Именно. Это как раз одна из причин, почему в задании приводится объявление функции avg — чтобы было видно, что адекватный результат функции — int.
Я фигею как можно извратиться над какой-то avg()! Если тебе так хочется обсудить переполнение, то этот пример очень неудачный. В реальном коде, как тебе сказали, программисты берут тип с большим числом битов и не страдают фигней. Мне double-ов до сих пор хватало.
H>>Вы просили кандидатов продекламировать эти параграфы наизусть или пересказать своими словами? LMA>Нет, помнить стандарты вообще не требуется. Требуется уметь писать код, который им не противоречит.
Ты троллишь? Умение писать код не значит фигачить везде проверки на переполнение. Это значит брать типы данных при которых переполнение не произойдет.
Здравствуйте, Олег К., Вы писали:
ОК>Было бы странно если бы в течении 30 — 50 минут которое длится интервью тебя бы попросили написать реальный код. Развернуть строку — несложное и довольно-таки примитивное задание которое не требует каких-либо специальный знаний или поисков алгоритма в Интернете.
Задание слишком простое. Мне всегда казалось, что именно на плюсах крайне важно не забывать const в нужных местах ставить, умение уходить от прямой работы с указателями, надежно работать с памятью (автоматически, а не через кучу явных delete в любом месте на каждый чих, размазывая это по всему коду) четко понимать, как твоими классами будут пользоваться другие и потому часть операций запрещать, а часть реализовывать так, чтобы клиенты не могли сделать ошибку. А что этим заданием проверите? Я бы его в школе сделал, и сейчас сделаю, несмотря на то, что плюсы забыл практически, и не владею тем, что я перечислил, я собеседование сам у себя по плюсам не пройду. На бумажке могу и ошибиться, -1 например не поставить или еще что такое. Итого — мне значит можно па плюсовика претендавать? Задание я тестовое скорее всего сделаю, если синтаксис повторю, благо у меня справочник лежит на полке, а вот работать достаточно эффективно увы, первое время не смогу — будут проблемы со сборкой проекта, с отладкой, всякими специализациями шаблонов я не пользовался на практике, так что могу что-нидь натворить не то, буду долго втыкать почему не компиляется. Про проекты — могу очень много интересного наговорить, сказав что все делал на плюсах, как проверять будете.
Кстати, как я уже говорил, я бы вместо этого задания предпочел бы дать человеку кусок реального проекта, намеренно сделать в нем ошибку, и попросить сделать code review. Пусть напишет что надо исправить, общие замечания по коду, а то и дать комп, и пусть порефакторит. Потом если хорошо сделает, можно будет даже закоммитить его исправления, и время на собеседование отыграете, и человека проверите — двух зайцев одним ударом.
ОК>Это тоже не сложно но большинство даже простого синтаксиса не знают. ОК>Да никакой это не алгоритм. В смысле сложности, то есть. Нужно всего лишь помнить немного синтаксиса да иметь голову на плечах.
Что значит простого синтаксиса? Простой синтаксис компилятор проверяет. Даже до компиляции куча ошибок IDE подсветит. Проблем не будет, проблемы могут начаться после непростого синтаксиса.
ОК>До свидания сразу никто не скажет но я вообще не понимаю как можно извратить код такой функции чтобы струдом понимать что она делает. Такие тоже бывали. Пример с memcpy() я уже приводил. По-твоему такого человека надо было нанять?
С memcpy() конечно перебор (для копирования одного байта, как я понял ). Но стоило хоть поинтересоваться для чего он так сделал. Вдруг в этом смысл какой, и от этого все станет в 100 раз быстрее и надежнее работать, а забраковали слишком умного . Я вот лично привык подвергать свои знания сомнению. Всегда думаю — а вдруг я не прав, и в говнокоде есть какой-то сакральный смысл ? Сможет меня убедить, что именно так и надо писать — такого человека надо нанимать. Не сможет — увы, я слишком глуп чтоб понять великие идеи, мы не сработаемся, лучше собеседуйтесь на мое место.
ОК>Так почему не подтянешь слабую сторону? Особенно перед интервью.
Эта сторона слабая для прохождения интервью, но никак не для эффективного выполнения работы. Эта сторона, кстати, в свое время у меня была сильной. Причем самой сильной. Синтаксис знал так, что мог написать такое, что без поллитра не разберешься . Особенно с битовыми операциями был силен . А потом понял, что в программировании надо не навороты синтаксиса демонстрировать, а писать так, чтобы код был понятным и недежным. И если ты ошибся, ошибка должна быть заключена в одной функции, а не быть размазанной по всему коду. Некоторый синтаксис использовать перестал вообще (например массивы), и многое забыл, так как мало использую. Может еще решение диффур, аналитическую геометрию, сортировки, обходы дерева на память, алгоритмы поиска кратчайшего пути в графах и все такое подтягивать, перед каждым собеседованием? Вдруг спросят?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, errest, Вы писали:
E>>Какие тестовые задания могут дать на C/C++? E>>Нужны простенькие — типа сортировки массива и найти ошибки
LMA>Напишите функцию, вычисляющую среднее значение двух любых значений типа int: LMA>int avg(int x, int y);
Я прошу прощения за воскресный тупняк (после субботнего пива в больших количествах), но почему нельзя написать что-то типа:
int avg(int x, int y)
{
int minVal = min(x,y);
int maxVal = max(x,y);
return minVal + (maxVal - minVal) / 2;
}
тут и с переполнением вроде нормально всё и с отрицательными работает.
I> return minVal + (maxVal — minVal) / 2; I>тут и с переполнением вроде нормально всё и с отрицательными работает.
это работает для unsigned (собственно, такой пример в применении к указателям есть в K&R).
Для signed int это не работает потому что INT_MAX — INT_MIN слишком большое и не влезет в signed int.
Здравствуйте, Олег К., Вы писали:
H>>>int avg(int x, int y) { return (int)(((long long)x + y)/2); }
LMA>>Уже лучше. Если бы в начале был еще assert (лучше статический), проверяющий, что размер long long больше, чем размер int, так вообще было бы хорошо. Соответственно — хороший повод на собеседовании обсудить цену преобразования int в long long и операций над ним на разных платформах, особенно если речь именно об C, а не C++, потому что C99 требует для long long не менее 64 бит. Ну и т.д. ОК>Еще советую изменить название функции на какой-нибудь набор букв и цифр и тогда никто уж точно не поймет что она делает!
Если Вам непонятно, что делает приведенная выше функция, видимо у Вас проблемы.
H>>>При этом создатели STL не страдали идиотизмом проверки на переполнения, справедливо считая что это вопрос к программисту который использует инструмент и выбирает адекватные типы данных.
LMA>>Именно. Это как раз одна из причин, почему в задании приводится объявление функции avg — чтобы было видно, что адекватный результат функции — int. ОК>Я фигею как можно извратиться над какой-то avg()! Если тебе так хочется обсудить переполнение, то этот пример очень неудачный.
Никому нет желания обсуждать что-то конкретное с кандидатами, есть желание, не тратя понапрасну своего и их времени, отсечь тех людей, которые на ровном месте в состоянии внести в код баг. Для багов хватает более нетривиальных ситуаций.
ОК>В реальном коде, как тебе сказали, программисты берут тип с большим числом битов и не страдают фигней.
Когда дорастешь, узнаешь, что это не всега лучший способ. Реальный код — это какой?
Если человек не в состоянии решать даже такую проблему без увеличения разрядности, что он будет делать когда завтра ему придется реализовывать
long long avg(long long, long long) для 5 различных платформ? Реализовывать собственный тип данных, который бедет выполнять сложение в 3 раза медленнее, чем long long?
ОК>Мне double-ов до сих пор хватало.
Ну так зачем это всем рассказывать — позорить себя так?
Здравствуйте, hrensgory, Вы писали:
H>LordMAD пишет: >> >> H>2. Архитектура и проектирование >> H>4. Объектно-ориентированное программирование >> H>7. Базы данных >> H>10. Автоматизированное тестирование >> H>12. Составление спецификаций и анализ требований >> >> Я думаю будет понятно, если я просто приведу пример вопроса, например, >> по теме Объектно-ориентированное программирование: >> >> К каким требованиям на предусловия (preconditions) и постусловия >> (postconditions) приводит Принцип замещения Лисков (Liskov Substitution >> Principle — LSP)?
H>К сожалению, стало яснее только на 20%. Более всего интересуют примеры H>вопросов к рядовому разработчику №№ 12 и 2 (если на все лениво примеры H>приводить).
Архитектура и проектирование. Дается конкретная достаточно мелкая подзадачка, кандидат должен описать словами как он планирует её решать. Например, ему поручили решить вопрос аутентификации пользователей в конкретной системе. Он должен описать как он будет хранить информацию связанную с паролями пользователей, как будет решаться вопрос смены пароля, как это будет работать если будет доступен Kerberos и т.д.
Базы данных. Если в данной конкретной вакансии речь идет об реляционных БД, вопросами проверяется умение проектировать БД и писать запросы (не на конкретном диалекте SQL и т.д., а с помощью реляционной алгебры и/или реляционного исчисления).
Автоматизированное тестирование. Например, кандидату предлагается для некоторого небольшого фрагмента кода сказать — что именно нужно подвергнуть тестам (и каким тестам) и как лучше переписать этот код, чтобы он лучше поддавался тестированию.
Составление спецификаций и анализ требований. Например, кандидату дается достаточно мелкая подзадачка, а он должен выделить соответствующие сценарии использования и, например, описать — что не будет реализовано в первой версии.
Здравствуйте, Ilias, Вы писали:
I>Я прошу прощения за воскресный тупняк (после субботнего пива в больших количествах), но почему нельзя написать что-то типа: I>
I>int avg(int x, int y)
I>{
I> int minVal = min(x,y);
I> int maxVal = max(x,y);
I> return minVal + (maxVal - minVal) / 2;
I>}
I>
I>тут и с переполнением вроде нормально всё и с отрицательными работает.
Собственно уже ответили: например, если одно из значений INT_MAX, а другое — отрицательное, maxVal — minVal создаст проблему с переполнением.
ОК>>Еще советую изменить название функции на какой-нибудь набор букв и цифр и тогда никто уж точно не поймет что она делает! LMA>Если Вам непонятно, что делает приведенная выше функция, видимо у Вас проблемы.
Проблем у меня нету. Проблемы есть у тех кто так пишет!
ОК>>Я фигею как можно извратиться над какой-то avg()! Если тебе так хочется обсудить переполнение, то этот пример очень неудачный. LMA>Никому нет желания обсуждать что-то конкретное с кандидатами, есть желание, не тратя понапрасну своего и их времени, отсечь тех людей, которые на ровном месте в состоянии внести в код баг. Для багов хватает более нетривиальных ситуаций.
Бла-бла-бла. Надуманное решение к надуманной проблеме. Тебе должно быть лестно что смог так закрутить функцию.
Вот что мне интересно — вы там также весь код пишите или это только для интервью? Кандидат написал-таки эту функцию а дальше это нафиг уже никому не надо?
ОК>>В реальном коде, как тебе сказали, программисты берут тип с большим числом битов и не страдают фигней. LMA>Когда дорастешь, узнаешь, что это не всега лучший способ.
Еще вопрос кому до кого дорастать!
LMA>Реальный код — это какой?
Демагог.
LMA>Если человек не в состоянии решать даже такую проблему без увеличения разрядности, что он будет делать когда завтра ему придется реализовывать LMA>long long avg(long long, long long) для 5 различных платформ? Реализовывать собственный тип данных, который бедет выполнять сложение в 3 раза медленнее, чем long long?
Вы там реально пишите для "пяти различных платформ" или ты это тут абстрактно так рассуждаешь?
Я порядком багов правил и правлю, но что-то не припомню чтобы один из них был связан с переполнением.
ОК>>Мне double-ов до сих пор хватало. LMA>Ну так зачем это всем рассказывать — позорить себя так?
Да ладно тебе. Это ты тут конкретно жжешь. В этой подветке, с Liskov Substitution Principle и далее.
E>Задание слишком простое.
Нормальное. Большинство и такое не сделают а я не хочу (точнее не хотел уже) особо напрягать людей.
Вот ты тут рассуждаешь что надо понимать в плюсах, как программировать, что использовать и т.д., а на деле все происходит по-другому. Прийдут на интервью, тянут время, закатывают глаза делая вид что не помнят. Ну скажи ты уже что не знаешь, так нет же.
ОК>>Это тоже не сложно но большинство даже простого синтаксиса не знают. ОК>>Да никакой это не алгоритм. В смысле сложности, то есть. Нужно всего лишь помнить немного синтаксиса да иметь голову на плечах. E>Что значит простого синтаксиса? Простой синтаксис компилятор проверяет. Даже до компиляции куча ошибок IDE подсветит. Проблем не будет, проблемы могут начаться после непростого синтаксиса.
Синтаксис надо знать. Например помнить что после объявления класса нужна точка с запятой или как написать производный класс. Я не говорю о каких-то там дебрях языка.
ОК>>До свидания сразу никто не скажет но я вообще не понимаю как можно извратить код такой функции чтобы струдом понимать что она делает. Такие тоже бывали. Пример с memcpy() я уже приводил. По-твоему такого человека надо было нанять? E>С memcpy() конечно перебор (для копирования одного байта, как я понял ).
Правильно понял.
E>Но стоило хоть поинтересоваться для чего он так сделал. Вдруг в этом смысл какой, и от этого все станет в 100 раз быстрее и надежнее работать, а забраковали слишком умного .
Этот пример уже был последней каплей терпения. Ты просто не представляешь кто бывает на интервью.
Здравствуйте, Олег К., Вы писали:
ОК>Проблем у меня нету. Проблемы есть у тех кто так пишет!
Ну так расскажи мне — какие у меня и моих коллег проблемы!
ОК>Вот что мне интересно — вы там также весь код пишите или это только для интервью?
Представляешь, весь код такой!
ОК>Вы там реально пишите для "пяти различных платформ" или ты это тут абстрактно так рассуждаешь?
Представляешь, реально!
ОК>Я порядком багов правил и правлю, но что-то не припомню чтобы один из них был связан с переполнением.
А работники McDonald's ни разу не сталкивались с проблемами при приготовлении стейка с кровью. Потому что у них не готовят стейк с кровью.
ОК>>>Мне double-ов до сих пор хватало. LMA>>Ну так зачем это всем рассказывать — позорить себя так? ОК>Да ладно тебе. Это ты тут конкретно жжешь. В этой подветке, с Liskov Substitution Principle и далее.
ОК>Два вопроса. Сколько надо времени на все эти вопросы и задачи? Какую зарплату предлагаете кандидатам?
Зависит от конкретного вопроса. На большинство вопросов — 1-2 минуты, не более. Общее время на вопросы по всем темам — не более 45-60 минут. Это соответственно, если раньше не становится ясно, что далее проводить собеседование нет смысла. Ну и как следствие, более затратные по времени темы идут в конце.
Здравствуйте, Олег К., Вы писали:
ОК>Нормальное. Большинство и такое не сделают а я не хочу (точнее не хотел уже) особо напрягать людей.
Итак, человек в простейшем задание не ошибся. Говорит ли это о его уровне, говорит ли это о том, что реальный код он будет писать нормально? Я считаю, что нет, и надо давать задание посложнее. Иначе возьмем тех, кого обычно берут (я про индуссокодеров в спагетти стиле, которых так любят нанимать), и потом их творчество расхлебывать.
ОК>Вот ты тут рассуждаешь что надо понимать в плюсах, как программировать, что использовать и т.д., а на деле все происходит по-другому. Прийдут на интервью, тянут время, закатывают глаза делая вид что не помнят. Ну скажи ты уже что не знаешь, так нет же.
Ну вполне логично что не помнят. В реальной работе некоторые вещи помнить не требуется, вот и не помнят. Помнят принципы, а не детали. То, что не помнят, говорит о том, что редко ходят по собеседованиям, а не то, что они плохо будут справляться с работой, так как умудрилтсь за 10 лет ни одной строчки не написать, не знают даже как класс отнаследовать, вместо вместо private priv написали, не скомпилится — явно человек первый раз в жизни программу пишет . На бумажке плохой почерк и куча помарок — значит и в коде будет черти что, да ?
ОК>Синтаксис надо знать. Например помнить что после объявления класса нужна точка с запятой или как написать производный класс. Я не говорю о каких-то там дебрях языка.
Можно спросить, чем мне поможет память о том, когда нужно ставить точки с запятой а когда нет? У меня например в IDE, если я точку с запятой не поставлю, или поставлю лишние — сразу будет выдано предупреждение об этом, до компиляции. Как то давно уже на это внимание не обращаю. И синтаксис main я, каюсь, не помню, у меня в IDE есть шаблон, который генерит. На самом деле немного то я конечно помню, нак как писал более чем 100 раз, но далеко не факт, что я не ошибусь на собеседовании.
ОК>>Проблем у меня нету. Проблемы есть у тех кто так пишет! LMA>Ну так расскажи мне — какие у меня и моих коллег проблемы!
Большие проблемы! И вы даже не представляете какие у вас проблемы!
ОК>>Вот что мне интересно — вы там также весь код пишите или это только для интервью? LMA>Представляешь, весь код такой!
Могу представить. Более того, считаю что таких вот "гениев" нужно заставлять поддерживать код написанный другими такими "гениями" чтоб неповадно было.
ОК>>Вы там реально пишите для "пяти различных платформ" или ты это тут абстрактно так рассуждаешь? LMA>Представляешь, реально!
Что за платформы? Что за аппликейшн?
ОК>>>>Мне double-ов до сих пор хватало. LMA>>>Ну так зачем это всем рассказывать — позорить себя так? ОК>>Да ладно тебе. Это ты тут конкретно жжешь. В этой подветке, с Liskov Substitution Principle и далее. LMA>Тебе и с LSP не приходилось сталкиваться, что ли? Что-то помню такое. Скорее всего приходилось, но просто не помню это под этими fancy words. Ты тоже это забудешь как повзрослеешь.
Здравствуйте, Олег К., Вы писали:
LMA>>Нет, помнить стандарты вообще не требуется. Требуется уметь писать код, который им не противоречит. ОК>Ты троллишь? Умение писать код не значит фигачить везде проверки на переполнение. Это значит брать типы данных при которых переполнение не произойдет.
Не всегда и float можно взять, не говоря уж про double. Long long и прочее тоже может не поощряться. Например, вычисления для мобильных платформ в fixed point. Там даже при несложной физике много тонких моментов вылезает. Правда, те же физические движки для моб. игр пишут одна-две конторы, остальным это не особо нужно. Готовым пользуются уже.
Если у чела компания чем-то подобным занимается, то задача вполне оправдана. Такое и нужно спрашивать.
Если же чел спрашивает такое, только ради того, чтобы проверить, как кандидат знает параграфы стандарта, то плохая задача. Такой выпендреж не есть хорошо.
Здравствуйте, Олег К., Вы писали:
ОК>>>Проблем у меня нету. Проблемы есть у тех кто так пишет! LMA>>Ну так расскажи мне — какие у меня и моих коллег проблемы! ОК>Большие проблемы! И вы даже не представляете какие у вас проблемы!
А по сути есть что сказать?
ОК>>>Вот что мне интересно — вы там также весь код пишите или это только для интервью? LMA>>Представляешь, весь код такой! ОК>Могу представить. Более того, считаю что таких вот "гениев" нужно заставлять поддерживать код написанный другими такими "гениями" чтоб неповадно было.
Давай угадаю – ты, конечно, считаешь, что главное — сделать так, чтобы любой вменяемый и аккуратный студент смог в любой момент включится в работу?
LMA>>Тебе и с LSP не приходилось сталкиваться, что ли? ОК> Что-то помню такое. Скорее всего приходилось, но просто не помню это под этими fancy words. Ты тоже это забудешь как повзрослеешь.
Ну, да. Зачем использовать короткие слова и абревиатуры на брифингах и code review, когда можно долго и нудно объяснять что имеешь в виду.
.
И еще я заметил что меньше знает человек или способен на что-то, то тем больше он мнит о себе. Ну да это оффтопик уже.
Что-то помню такое. Скорее всего приходилось, но просто не помню это под этими fancy words. Ты тоже это забудешь как повзрослеешь.
