Amazon Interview

[dotcom]

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

[tieboss]

Eсли что у меня больше 15 лет опыта .
A первый вопрос был действительно про полиморфизм.
У нас мне такие вопросы не задают.
Больше просят рассказать про то что делал.
С какими проблемами сталкивался и как их решали.
Да и позиция была Senior судя по Job Description.
По этому и сомнения , задают вопросы не соответствующие описанию позиции и опыту.
Да еще и выглядит что вроде как незнакомы с возможностью ClassCastException при upcasting.
Не придирайтесь к словам типа compile time exception плиз , просто писал пост после собеседования , немного нервничал
и заварки кстати не пожалел все же 10 часов разницы и мы только в 10 часов вечера по нашему времени начали ...

[Zorkus]

чем вопрос плохой?

Тем, что спрашивать на интервью мелкие и тупые вопросы по Java как языку - это плохо. Обычно, имхо, вопросы по мелким тонкостям языка задают на собеседовании люди, которые недавно сдали SCJP или как там он называется сейчас, и этим козыряют.

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

[crypto5]

А как поведет себя такая конструкция - тоже вывалится при кастовании?
class Generic<T> {}
public class CuriouslyRecurringGeneric extends Generic<CuriouslyRecurringGeneric> {}

Вы приведите околожизненный пример когда такие знания могут понадобиться.

Про джаву не скажу а в плюсах сплошь и рядом. В ATL к примеру.

Ок, но зачем такое делают?

[tieboss]

Получил письмо от рекрутера.
Они заинтересованы продолжать со мной собеседоваться.
Посмотрим что будет дальше.

Zorkus:задавать такие вопросы на собеседовании - плохой тон имхо. Такие вопросы резко понижают желание там работать

У себя дома я бы так тоже рассуждал но тут для меня другое главное.

[Мальчик-Одуванчик]

А как поведет себя такая конструкция - тоже вывалится при кастовании?
class Generic<T> {}
public class CuriouslyRecurringGeneric extends Generic<CuriouslyRecurringGeneric> {}

Вы приведите околожизненный пример когда такие знания могут понадобиться.

Про джаву не скажу а в плюсах сплошь и рядом. В ATL к примеру.

Ок, но зачем такое делают?

Чтобы обеспечить полиморфизм в статической библиотеке.

[crypto5]

А как поведет себя такая конструкция - тоже вывалится при кастовании?
class Generic<T> {}
public class CuriouslyRecurringGeneric extends Generic<CuriouslyRecurringGeneric> {}

Вы приведите околожизненный пример когда такие знания могут понадобиться.

Про джаву не скажу а в плюсах сплошь и рядом. В ATL к примеру.

Ок, но зачем такое делают?

Чтобы обеспечить полиморфизм в статической библиотеке.

Я к сожалению по прежнему не понимаю. Возможно вы могли бы привести простой пример?

[Мальчик-Одуванчик]

У меня есть приятель, который на элементарные вопросы из разряда "что такое полиморфизм" ставит условие собеседующему, что отвечать на такие вопросы он не будет. Интересно, что без работы он не сидит.

Если копнуть, то наверное и на таком вопросе можно завалить.

[Alexandr]

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

без работы можно не сидеть очень по разному
я в принципе не вижу никакого смысла в подобных понтах на интервью

[Alexandr]

У меня есть приятель, который на элементарные вопросы из разряда "что такое полиморфизм" ставит условие собеседующему, что отвечать на такие вопросы он не будет. Интересно, что без работы он не сидит.

Если копнуть, то наверное и на таком вопросе можно завалить.

Да че там копнуть, у меня знакомые в Дойче есть: приходит к ним народец на жабу, сениор, 5-7 лет опыта, а местами и "масковские орхитекторы" - а им после собеседования - сорри, вы чуть выше джуниура
Представляю, если бы кто-то заявлял еще - тут отвечать не буду, тут тоже

[dotcom]

без работы можно не сидеть очень по разному
я в принципе не вижу никакого смысла в подобных понтах на интервью

Это не понты, это особенность характера такая. Человек то он, вобщем, скромный, но с определенными тараканами.

[Alexandr]

без работы можно не сидеть очень по разному
я в принципе не вижу никакого смысла в подобных понтах на интервью

Это не понты, это особенность характера такая. Человек то он, вобщем, скромный, но с определенными тараканами.

это кстати основание иногда его не брать, так как людей, которые создают гемор другим мало кто любит

[dotcom]

это кстати основание иногда его не брать, так как людей, которые создают гемор другим мало кто любит

Это интересный вопрос. У меня был такой коллега, которого в двух компаниях подряд пытались уволить в течение первой недели из-за ужасного характера. Человек просто не в состоянии искать компромисы и не контролирует эмоции. Ну так в обеих компаниях его просто полюбили страшной любовью, что даже не позволяли уволиться впоследствии. По-моему, он в обеих до сих пор халтурит. Специалист он хороший и если найти к нему подход, то вполне уживчиый и готов работать над любой проблемой. Все же характер - это одно, а умение решать поставленную задачу - это второе. Есть между ними и корреляция. Задача менджера и коллектива найти нужный подход к человеку. Естественно, не у всех получается и не у всех есть терпение. Интересно, как оба товарища уживутся в условиях кризисного рынка, но лучше уж избежать кризиса и подобных экспериментов. Пока оба работают и дай бог им здоровья.

[Medium-rare]

Я к сожалению по прежнему не понимаю. Возможно вы могли бы привести простой пример?

До внедрения C++ 11 стандарта и до внедрения boost во многих местах, и сейчас наблюдаю... Чтобы внедрить подсчёт ссылок для объектов использовалось такое вот интересное "оплодотворение" класса самим собой:

Code: Select all

class StrangeThing : public RefcountedBase< StrangeThing >
{
          // blah();
};

Чем в класс косвенно внедряли родителя, который знал про потомка, чтобы мочь его корректно освобождать, когда счётчик ссылок == 0 без виртуальной базы (зачем её тут не надо, отдельная история).

[Мальчик-Одуванчик]

другая идея возникает когда к некоторому классу требуется сбоку прилепить дополнительный аспект функциональности
как вариант, основной клас обьявляется типом параметризации для класса, обеспечивающего дополнительный функционал.
template<typename Thing>
class SomeBolt-In {
void MyF() { ... дернуть Thing за ... ; }
}
возникает вопрос - а как дернуть? один из вариантов - static_cast<T*>(this)->... Но такое сработает лишь в случае наследования. А вариантов наследования немног: class Thing: public SomeBolt-In<Thing>
Вот и получается реккурентный шаблон. Как частный случай, можно незамысловато смоделировать "декоратор" на этой основе используя лишь статический полиморфизм.

[АццкоМото]

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

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

[Мальчик-Одуванчик]

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

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

стандартный ответ - тем что усиливает монолитность системы.

[АццкоМото]

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

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

стандартный ответ - тем что усиливает монолитность системы.

wtf is "монолитность"? coupling? ну дык использование шаблона в данном случае усиливает его ровно настолько же

[Мальчик-Одуванчик]

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

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

стандартный ответ - тем что усиливает монолитность системы.

wtf is "монолитность"? coupling? ну дык использование шаблона в данном случае усиливает его ровно настолько же

в данном конкретном случае - да, но универсальным способом. Как в примере выше, тот же счетчик можно определить один раз а затем применять к различным типам.
Далее открытое наследование все таки предполагает отношения "is a" а тип "cбоку" таковым по сути не является.
Если прикруток много и они, например, выстраиваются во вложенную цепочку то вместо цепочки наследования обычно применяют декораторы. ( новый уровень косвенности декоратор разрывает монолитную цепочку вложенности наследования).

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

[АццкоМото]

в данном конкретном случае - да, но универсальным способом.

Я правда не понимаю. Т.е. дело не в том, что шаблоны меньше увеличивают coupling; они его увеличивают ровно настолько же, только "более универсальным способом". sounds like a nonsense.

Как в примере выше, тот же счетчик можно определить один раз а затем применять к различным типам.

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

Далее открытое наследование все таки предполагает отношения "is a" а тип c доп функциональностью таковым по сути не является.

Да ладно! Отвертка с будильником очень даже is a screwdriver.

[Мальчик-Одуванчик]

в данном конкретном случае - да, но универсальным способом.

Я правда не понимаю. Т.е. дело не в том, что шаблоны меньше увеличивают coupling; они его увеличивают ровно настолько же, только "более универсальным способом". sounds like a nonsense.

Как в примере выше, тот же счетчик можно определить один раз а затем применять к различным типам.

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

Далее открытое наследование все таки предполагает отношения "is a" а тип c доп функциональностью таковым по сути не является.

Да ладно! Отвертка с будильником очень даже is a screwdriver.

Правильно - но ручка в нашем случае и есть "тип сбоку" и она никак не будильник

[АццкоМото]

Правильно - но ручка в нашем случае и есть "тип сбоку" и она никак не будильник

Стоп... у нас есть класс Отвертка. Нам нужно прикрутить к ней функциональность будильника. И мы делаем класс ОтветкаСБудильником, наследуя от Отвертки. В чем проблема того, что ОтверткаСБудильником - не Будильник? Отношение "is a" должно быть с Отверткой и оно на 100% соблюдается.
В случае агрегации или множественного наследования тоже ничего не ломается

[Мальчик-Одуванчик]

Правильно - но ручка в нашем случае и есть "тип сбоку" и она никак не будильник

Стоп... у нас есть класс Отвертка. Нам нужно прикрутить к ней функциональность будильника. И мы делаем класс ОтветкаСБудильником, наследуя от Отвертки. В чем проблема того, что ОтверткаСБудильником - не Будильник? Отношение "is a" должно быть с Отверткой и оно на 100% соблюдается.
В случае агрегации или множественного наследования тоже ничего не ломается

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

Давайте возьмем два класса Будильник и Чайник. Пусть они поддерживают общую функцию - "отзовись!". При этом будильник может, к примеру, дополнительно показывать время, а чайник греть воду.
Отвертка имеет функцию - покрутить. Поскольку отвертка есть параметризованный класс то в реализации функции "покрутить" мы вызовем функцию "отзовись!" его типа параметризации.
В итоге имеем:
ОтверткаСБудильником - покрутит и позвенит (реализация "отзовись!" в Будильнике) во время кручения.
ОтверткаСЧайником - покрутит и посвистит

Теперь Вы понимаете откуда пошло выражение "Жопа с ручкой"!

[Alexandr]

это кстати основание иногда его не брать, так как людей, которые создают гемор другим мало кто любит

Это интересный вопрос. У меня был такой коллега, которого в двух компаниях подряд пытались уволить в течение первой недели из-за ужасного характера. Человек просто не в состоянии искать компромисы и не контролирует эмоции. Ну так в обеих компаниях его просто полюбили страшной любовью, что даже не позволяли уволиться впоследствии. По-моему, он в обеих до сих пор халтурит. Специалист он хороший и если найти к нему подход, то вполне уживчиый и готов работать над любой проблемой. Все же характер - это одно, а умение решать поставленную задачу - это второе. Есть между ними и корреляция. Задача менджера и коллектива найти нужный подход к человеку. Естественно, не у всех получается и не у всех есть терпение. Интересно, как оба товарища уживутся в условиях кризисного рынка, но лучше уж избежать кризиса и подобных экспериментов. Пока оба работают и дай бог им здоровья.

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

[Alexandr]

вот по поводу статического полиморфизма:
http://en.wikipedia.org/wiki/Curiously_ ... te_Pattern