Domanda di colloquio di Yahoo

Design patterns that would be used in a card game. Not objects and classes but design patterns.

Risposte di colloquio

Anonimo

23 dic 2009

I thought the question was unfair, especially for a person out of graduate school. In graduate school, we do RESEARCH not OOD!

1

Anonimo

24 dic 2009

how long did it take for them to get back after your interview?

Anonimo

24 dic 2009

Exactly 7 business days.

Anonimo

27 dic 2009

Ok. When did you interview? I interviewed around December 2nd week and don't have a reply...

Anonimo

17 gen 2010

Interview questions are designed to figure out how well the candidate knows the subject matter related to the job. Questions about design patterns are absolutely appropriate for a software engineering position, even for someone who is just out of graduate school. Research and OOD are not mutually exclusive; they have no way of knowing how well you know design patterns unless they ask. If you don't know design patterns, simply say so and move on to the next question. That's far better than trying to fake your way through it.

Anonimo

18 gen 2010

Who said anything about faking it :-) Research and OOD are not mutually exclusive but maybe design patterns and research are unless your research is in Software Engineering. My point is that, in most interviews objects, classes, hierarchy are what they are looking for, not actual design patterns. But I agree with you, if you can move on, great but I posted this because I wanted to tell the people interviewing there to brush up on patterns in addition to OOD because my interviewer told me that she/he expected me to say something about design patterns not just the classes/objects that I told her/him.

Anonimo

10 set 2010

Not objects and classes? But OO design patterns are represented by objects and classes. So it looks like they just want to hear some DP names, but actual design with details, and the purpose is just to make sure you know their concept and general idea. How about this: Strategy pattern to separate the card-playing rules from the card itself. Factory pattern to instantiate different types of games. Decorator pattern to apply different combination of rules to the cards. Singleton pattern for the top-level game manager. I wouldn't say these are actually the good choice for the implementation , but since you want to hear some pattern names only, there you go...