3 ms·

I would much rather hear about their past projects and have them clearly convey design decisions that they made before then have them work on a "on the fly" que

I would much rather hear about their past projects and have them clearly convey design decisions that they made before then have them work on a "on the fly" question. Everybody has off days, not many people have whole off years or careers. Just because I can't design Monopoly in one hour on a certain given day doesn't mean I do not have the relevant experience in my past, whether it be professional or as an undergrad.

yannyu 12y ago
It's not as though this is the only question by which the interviewee will be appraised. This is one more tool in the kit alongside asking about previous projects, interesting classes, career goals, overcoming tough situations, etc. Whether or not questions like these are effective, the point of them is to engage with someone in a way that illustrates how they tackle complex, loosely defined issues: the majority of engineering problems in a nutshell. In most modern tech companies, good communication and not being afraid to ask questions are absolutely essential. Someone who will take an incomplete list of requirements and draw up an entirely incomplete product without questions or discussion is as much a liability as someone who takes the requirements and does nothing, paralyzed by indecision and not knowing what to do. And oftentimes, candidates aren't perfect but you're going to hire them anyway. Going through this process can illustrate how you would expect to interact with the candidate and where the initial rough spots will be as the candidate begins working with the team. From another point of view, candidates are usually more than prepared to talk about anything on their resume. In some cases, this is equivalent to listening to someone give a prepared speech. Asking them free-form questions like the above can be a good way to understand how the candidate reacts in situations where they aren't fully prepared. For some positions this is irrelevant, but for others it's incredibly important to have some measure of poise and thoughtfulness when engaging with someone who doesn't necessarily agree with everything you say and is questioning your thought process. In short, these kinds of questions aren't primarily testing your design and programming abilities, but your ability to communicate and reason with another person in a technical context.
- stevebot 12y ago
  You missed my point. People are prepared to talk about their resume, but when you dig in to their past experience and specifics that is where you get to the interesting discussions. Case and point: Tell me about a design pattern you used on X project? A singleton? Ok, why did you use that? and a long discussion about testability and architecture ensues with questions from both sides. That is WAY more like the communication that happens on the job than a contrived problem which in many cases is disconnected from real life constraints.

yannyu 12y ago

It's not as though this is the only question by which the interviewee will be appraised. This is one more tool in the kit alongside asking about previous projects, interesting classes, career goals, overcoming tough situations, etc. Whether or not questions like these are effective, the point of them is to engage with someone in a way that illustrates how they tackle complex, loosely defined issues: the majority of engineering problems in a nutshell. In most modern tech companies, good communication and not being afraid to ask questions are absolutely essential. Someone who will take an incomplete list of requirements and draw up an entirely incomplete product without questions or discussion is as much a liability as someone who takes the requirements and does nothing, paralyzed by indecision and not knowing what to do. And oftentimes, candidates aren't perfect but you're going to hire them anyway. Going through this process can illustrate how you would expect to interact with the candidate and where the initial rough spots will be as the candidate begins working with the team. From another point of view, candidates are usually more than prepared to talk about anything on their resume. In some cases, this is equivalent to listening to someone give a prepared speech. Asking them free-form questions like the above can be a good way to understand how the candidate reacts in situations where they aren't fully prepared. For some positions this is irrelevant, but for others it's incredibly important to have some measure of poise and thoughtfulness when engaging with someone who doesn't necessarily agree with everything you say and is questioning your thought process. In short, these kinds of questions aren't primarily testing your design and programming abilities, but your ability to communicate and reason with another person in a technical context.

stevebot 12y ago
You missed my point. People are prepared to talk about their resume, but when you dig in to their past experience and specifics that is where you get to the interesting discussions. Case and point: Tell me about a design pattern you used on X project? A singleton? Ok, why did you use that? and a long discussion about testability and architecture ensues with questions from both sides. That is WAY more like the communication that happens on the job than a contrived problem which in many cases is disconnected from real life constraints.