Advertisement

Interview questions.

Started by August 25, 2005 05:48 PM
18 comments, last by Obscure 19 years, 2 months ago
Hi, this post is inspired by a question in the 'math and physics' forum. The poster had been asked the following question at an interview: How would you quickly test whether a number was a power of 2? I've been reading about questions that get asked at interviews, but mostly I find lists of questions without an accompanying explanation of *why* these questions are asked, what kind of information are the interviewers trying to get out of the interviewee? In the above case there is a simple little technical trick that answers the problem. I confess I didn't know it. But is that what the interviewers were trying to eak out? Knowledge of coding tricks? Anyway, I was wondering if any of you out there have experience in the inteviewers seat where these kinds of "trick" questions are asked and whehter you would mind explaing the rationale behind asking the question. -Josh

--www.physicaluncertainty.com
--linkedin
--irc.freenode.net#gdnet

I think the motivation for an interviewer to ask the power of 2 question is less about "the answer" and more about if the interviewee understands how numbers are stored.

Most "trick" style questions test something similar, and most of the time the interviewer is more interested in the thought process of the candidate ("Hm... well I know that power of 2 unsigned integers only have one bit set") than in the actual solution (return (!(n & (n-1)))).

--Steven
Advertisement
Quote: Original post by jjd
Hi,

this post is inspired by a question in the 'math and physics' forum. The poster had been asked the following question at an interview: How would you quickly test whether a number was a power of 2?

I've been reading about questions that get asked at interviews, but mostly I find lists of questions without an accompanying explanation of *why* these questions are asked, what kind of information are the interviewers trying to get out of the interviewee?

In the above case there is a simple little technical trick that answers the problem. I confess I didn't know it. But is that what the interviewers were trying to eak out? Knowledge of coding tricks?

Anyway, I was wondering if any of you out there have experience in the inteviewers seat where these kinds of "trick" questions are asked and whehter you would mind explaing the rationale behind asking the question.


-Josh


Trick questions are out there, though I'm not sure this is one of them - as it comes up in code a bit. Interviewers like questions which are easy to judge correctness and don't require alot of knowledge.

What was the answer? For a floating point i'd just AND the mantisa (no bits should be set), for a integer you can count bits (or many other bit tricks).
EvilDecl81
I think interviewers just ask these questions because they are expected to. Seriously, I've been asked to guess how many gas stations are in California, whether the water level rises if you throw a rock off a boat, how to tell if a light bulb in another room turns on when you hit a switch, how to find the smallest number of balances needed to find the heaviest pool ball, and all sorts of really weird stuff that involved linking chains and literally making up answers with no possible facts. If there is anything they can gain from an interviewee by listening to them figure out brain teasers over a phone, I've yet to see any indication of what or why.

The real kicker is that there is a book out there. It's called something like "Programming Interviews Exposed" or something and it has nearly every trick question I've ever been asked, how to answer it, why it is asked, and what they want to hear, as well as many of the programming questions (ie write a double-linked list, or count the 1s in a number's bit representation). Really pissed me off that I found this book after I already got in. If I had this book ahead of time, when they asked me about the pool balls, I would've had the answer right there. Also, interestingly enough, my wife and I applied to the same company, a few weeks apart. We both got the same questions, but since she already told me about them, I had the answers immediately - I even told the guy on the phone that I knew the answers, but he asked them to me anyway.

As to why they ask these questions... I think it's padding. A lot of times, you will be interviewing for technical jobs with non-techies, like the company den mother. Most companies will send out these kind of tests after you simply send in a single resume - it's a buffer. Resumes are plentiful and worthless to them, so they look at your resume AFTER you send in the obligatory questionaire.

I used to have a folder on my computer that was filled with a dozen or so programming tests from a bunch of different companies. Unfortunately, that was two computers ago, but I think it'd be quite enlightening to see a few of those tests lined up together to see how absolutely worthless they really are.
--Sqorgarhttp://gamebastard.blogspot.com
Quote: Original post by Sqorgar
If there is anything they can gain from an interviewee by listening to them figure out brain teasers over a phone, I've yet to see any indication of what or why.
It is a Kobayashi Maru test (sort of). They want to see how someone reacts to the unexpected or when placed in a situation where there is no clearly correct answer. Very often the more important question is the one that folllows on, which is "why?" - they want to know what you would do and why you would do it, while at the same time watching how you react when taken out of the zone you were expecting to be in.
Dan Marchant - Business Development Consultant
www.obscure.co.uk
It's not the Kobayashi Maru - the people on the other side of the phone aren't psychologists. They are den mothers and lead programmers, neither qualified to judge temperment or problem solving capability at such an abstract level. If they asked you a non-trick question, like "write a linked list" or "what did you do in your last job", yeah, they can do something with that because that's concrete examples of knowledge. How an replicant approaches an absurd problem with only one, very oddly shaped answer, asked under the duress of an interview they already feel nervous in - that's just no good. There's no control. Not a large enough sample size. Such questions would be worthless to even a psychologist without more information. Problem solving doesn't have just one answer and doesn't typically exist in a controlled space where you can't bring other knowledge in.

I mean, how do you figure out if a lightbulb in the next room went on? I can think of two dozen ways to do this - mirrors (you don't have a mirror), cameras (you don't have a camera), open the door (the door won't open, and light doesn't filter under the crack, and even if it did, the light bulbs are for some reason so close to each other that it would be impossible to tell which ones were lit), destroy the door (it's a metal door), keep the lights on long enough that the ones turned on break (you only have a few minutes to figure it out) - but the only solution they accept is that you turn on the light for a few minutes and go in and check how warm they are. That's the ONLY solution? We've got an absurd set up where, for some reason, you are locked in a room with a lightswitch that some idiot hooked up to a different room, the light can't be on while the door is open, the door is magically light proof, and somehow, of all the information and solutions you CAN'T bring into the problem, you CAN bring in the fact that lightbulbs get warm? What does that tell you about a person? That they can eventually stumble into your way of thinking on absurdist problems?

I've always wanted to say "Okay, I solved your brain teaser, now you solve mine". I hate that they seem to completely ignore the fact that you are interviewing them as well, and seem to use brain teasers as a way to cement their authority over the interviewee.
--Sqorgarhttp://gamebastard.blogspot.com
Advertisement
Quote: Original post by Sqorgar
I've always wanted to say "Okay, I solved your brain teaser, now you solve mine". I hate that they seem to completely ignore the fact that you are interviewing them as well, and seem to use brain teasers as a way to cement their authority over the interviewee.
Oh man, is this ever so true... excellent point, Sqorgar. In just about every professional interview, I've always taken advantage of the opportunity given when the interviewer says, "well, that about wraps things up. Do you have any questions?" :)

I confess: it is slightly out of spite that I volley my own reasonably challenging questions back on them, but also because I'm the inquisitive type. And hopefully, by displaying that I'm inquisitive, it also displays an eagerness to learn.

-Razorguts
AB HarrisEngineer, RG Studios
You can learn alot about a person from their response to the absurd...hell, Zen koans are EXACTLY that. Remember that they have your resume and if you had a past job, they can contact your former boss to know what you did there. The interview is more about getting to know you as a person, not as a programmer.

If an interview was like a test with a right or wrong answer, what's the point of paying someone good money to administer it? Why not simply have a program do it for you or take the test at a testing center? The reason is that in a face to face interview, they are interested in knowing you beyond the paper...you can do a linked list? Great, so can every other candidate, big deal. You did this kind of work in your last job? Big whoop, I can read that on your resume or call your former boss.

But what's going to happen when the shit hits the fan? How do you ask that question? If you ask "How well do you handle pressure?" what idiot would say "Oh, not well at all"....therefore you need these questions to simulate the pressure, the shit, in a way a display of skills simply can't.

For example, look at the reactions of the last two posters...somewhat confrontational in regards to the interviewer, as if they are doing them a favor by showing up. You don't get that in a resume and you won't elicit that reaction by asking them to regurgitate code. And it's that reaction that will make the interviewer think "This person can be part of our team" or "This person will just add friction to the team".
See? Now I'm offended. You're post is just as confrontational as us other two posters - just from the interviewer's side. You make it sound like we need to live up to YOUR expectations and who gives a rat's ass if you live up to ours? If the shit does indeed hit the fan, how does the team that's already in place react? You make it sound like any error in teamwork has no choice but to be due to the new guy, when it has been my experience that many game dev teams don't know their asshole from their elbows and get themselves in shit just fine without regards to whom they hire next.

Game interviews are not interrogations and they should definitely not be one sided. You shouldn't sit there answering question after question and then they don't answer anything in return. I can't tell you the number of interviews I've had where they wouldn't even tell me the genre of the game they were working on - that would require some sort of NDA, because as well all know, the game industry is so absolutely devoid of new ideas that they must protect even PC ports from already released console games against potential applicants. You can call my old boss, but see what happens if I call YOUR boss and ask about you.

No, interviews shouldn't be like you suggest. You aren't just trying to find someone that would work well with the team - he's trying to find a team that he'd work well with himself. It needs to be a two way flow of information and discourse, between equals, and the asking of trick questions automatically put the interviewee in a subordinate position. Can you really imagine what would happen if I asked a brain teaser to a lead programmer? Wouldn't I be able to find out just as much about him through one as he would about me?

No, the game industry doesn't give an ass about the people who work in. They just want a warm body to fill a seat that can solve whatever problems they need to solve now. Don't know STL? Too bad. Forget about learning it. You have to already have mastered it by the age of 12. They want skillsets, not people. They want people to fill already existing holes, not find their own position in the team. These brain teasers are just another skillset they are looking for. If you are a cooperative problem solver that works best by bouncing ideas off people, to sit there and bounce ideas off complete silence on the other end of the phone is unnerving and grotesque.

And for the record, I'm confrontational now - not then. Hell, I so wish I had been. I had such a horrible time in the industry mainly because I didn't rock the boat and followed instructions without complaint - followed them right off a damn cliff.
--Sqorgarhttp://gamebastard.blogspot.com
Quote: Original post by Sqorgar
I mean, how do you figure out if a lightbulb in the next room went on?


I remember being asked that lightbulb question somewhere; can't remember if it was for an interview question or in training for interview questions. If I remember the question, it was that you had three switches on your side, and you had to match each switch to the three light bulbs in the other room. As you said, the expected answer was to leave one on, leave another off, and to turn the third one on for a short while then leave it off, giving you a third state.

I think my answer was to leave one on, leave one off, then to toggle the third one on and off really quickly for several seconds until you hear the bulb blowing. Can't remember how well that one went down with the interviewer [smile].

This topic is closed to new replies.

Advertisement