7

I write business applications for a living. Often, for whatever reason, an interviewer asks me to write up a program to solve some kind of game like problem. I find this to be an inappropriate question for two main reasons:

  1. Games often deal with constructs that are rarely used in business dev. E.G. Multi-dimensional arrays. Store player locations on a checkerboard for instance. (Maybe it's just me, but I never use these things in biz)

  2. My usual tools like BL/DL, ORMs and even designing the entities themselves don't translate well. So I often end up with some goofy lookin code to start. This is especially awkward if the interviewer is looking over your should to determine how "well you code". Horribly uncomfortable, because...well I don't code like that...I don't write games for a living either.

Do you folks use them in your interviews and have they been effective for learning about a business apps dev?

|improve this question

closed as primarily opinion-based by Thomas Owens♦ Jun 7 '15 at 12:47

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    I actually had the same sentiment... its even worse if its a game you can't remember the rules to... – bunglestink Dec 22 '11 at 19:24
  • 3
    I maintain that a good programming interview problem will relate to the subject at hand. If it's a financial company, I'd expect some sort of calculator, or accounting problem. If it's web development company, I'd expect a web app or backend data-access problem. If you spend a little time on interview questions, it's not too hard to come up with a short question that relates to what you do in some way. – Kris Harper Dec 22 '11 at 19:31
  • 4
    Multidimensional arrays are rarely used in business dev? Ever pulled data from a database? – Ben Brocka Dec 22 '11 at 19:42
  • @bunglestink They pick a game like Checkers because 95% of people know the rules to Checkers. If they don't then a 2 minute explanation is all they need for "gathering requirements". – maple_shaft♦ Dec 22 '11 at 19:43
  • 3
    As someone with fourteen years experience as a professional game programmer, I'd just like to point out that folks with experience in that industry wouldn't actually use multidimensional arrays to store the contents of a checkerboard (even though that's the intuitive approach). Mapping the squares of a checkerboard to the indices of a single-dimensional array is just as easy, and is far better for performance. :) – Trevor Powell Dec 22 '11 at 23:31
7

It's one of those "We want to inteview like Google/Facebook/Amazon/etc" questions. Unless you're actually interviewing for a position at a game company, it wouldn't be useful to ask such questions. It would be more valuable to discuss/test something related to the problem domain of the company. For example, if I wanted you to write a web service to handle different formats of daily pricing feeds from 50+ different vendors I'd ask how you would approach it and have you sketch out, with some pseudo-code, how you would do it.

I did get asked gaming questions like this in an interview once, at a company developing a MMORPG. Sadly, I didn't get that job.

|improve this answer
  • 9
    "We want to inteview like Google/Facebook/Amazon/etc but we don't know how to do it" – karlphillip Dec 22 '11 at 19:46
6

I have used them in my interviews and I have been asked similar question in interviews. Most of these questions are designed to gauge how well can you break a task into smaller components and how "neatly" for the lack of the better word can you make interactions between the components.

Normally I don't hover over the interviewee while he or she is doing the task but periodically I'd like to look at their work to gauge their train of thought. This type of technique is also used to gauge how well a person can tune out the yell for "Get it done! Get it done! Get it done!" and actually focus to do the right thing.

Typical questions I saw was to design objects for the game of chess, checkers, tic-tac-toe or something similarly simple. Writing implementation of methods is usually not required for things like this.

|improve this answer
  • 3
    A "Swordfish" style interview? – jfrankcarr Dec 22 '11 at 19:40
  • No guns or girls involved but yes... :) – Karlson Dec 22 '11 at 19:51
  • 3
    re-"This type of technique is also used to gauge how well a person can tune out the yell for "Get it done! Get it done! Get it done!" and actually focus to do the right thing." - I hope this doesn't simulate your work environment. Have you considered throwing stuff at the interviewee, taking away their equipment as they work, blindfolding them? You don't want weaklings! – psr Dec 22 '11 at 19:55
  • That would be illegal in most place to do but on occasion it does emulate the work environment pretty well... – Karlson Dec 22 '11 at 20:00
  • @psr - Hey, you never know when you might need an employee to baby sit and meet that hard deadline at the same time! – Buttons840 Dec 22 '11 at 20:46
3

I agree that trying to code while someone is staring over your shoulder is distracting.

My take on the game idea is that it allows you to get a feel for if the candidate can take a bizarre, off-the-cuff problem and come up with a workable solution to it. It is not like they are asking you to have multiple moving sprites and arc vectors or anything that requires memorization of trigonometry.

They are asking you to do Checkers, because it is a simple game, simple set of rules, clear outcomes, and requires the use of a data structure more complicated than just an array. The question is legitimate.

|improve this answer
1

Thats odd, I have never had that experience. I get the exact opposite end of that spectrum. I usually get something like this "..we are experiencing this particular business/tech problem for these reasons, how would you go about solving it". My interviews have always had much more practical questions.

When I interview people I tend to to go with asking about current work they are doing and then digging in deeper on areas that are relevant. I usually get a very good sense of the persons ability and passion about what they do by digging in. Are they getting excited about the problems they solved, are they offering up details about the challenges or am I having to dig them out etc.

|improve this answer
1

Most programming quizzes should focus on whether the applicant can program AND test logic/problem solving. Programming and logic/problem solving are both very important. It's not that easy to come up with a generic and challenging quiz, to get good programmers/problem solvers to work for you.

I think the game aspect of the interview is trying to test the logic/problem solving ability of the programmer, and in that regard, as long as the question is not too clever or obtuse, I think it is a reasonable method to test a programmer's problem solving ability.

That being said, quizzes are a rabbit hole few companies get right.

In general, a reasonable programmming quiz should be three parts:

  1. Fizz buzz type of question to weed out applicants who can't program
  2. A general question to test coding and logic/problem solving skills (this can be difficult to craft)
  3. A speciic question to test industry skill and experience (for example, if database, then maybe some SQL type of questions, join tables, etc.)
|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.