Remember when you were in school? They’d assign homework like, “Read chapter foo and answer the questions at the end of the chapter”… projects consisted of, “Do this, you have 2 weeks.”
Let’s face it. Anyone in the real world for any amount of time knows that’s not the way things really are. Dates move, requirements change, and oh yeah… the answer isn’t really something you can ask about because you’re typically doing something new… that no one else has done. No checking the end of the book. No blowing it off and taking a bad grade. The rules are different.
So, on top of this is the interview process. This is where they ask you a series of academic minutia to see how you work under pressure. By the way, if you admit to the fact that you don’t like academic minutia or that work would not typically be like this, “BZZZT” sorry game over.
In software engineering… academic minutia comes in the form of algorithms. An algorithm for those of you outside the industry is a small piece of code to take care of some ridiculously small simple function in the most mathematically quick manner.
Example. I have two long lists of numbers. Find me the numbers that match between the two lists. In mathematics we call this “the intersection of two sets.”
Sadly, when asked a question of this ilk; the answer, “Um, use the “FindIntersectionOfTwoSets function” isn’t good enough. No, that’s apparently be a smart ass, even though… the advanced programmer knows that someone has already solved the problem and it’s best not to reinvent the wheel.
So, you start asking questions… see this isn’t a test of whether you can belch out an answer, they want to see how you think. Under pressure. Because sure enough, if you write software to categorize web images, at some point, you will need to solve this problem under pressure and explain how you did it. (Savants be warned, your talents are not requested)
In all honesty, I think our industry and in general the professional world is broken. Younger and younger managers and dev supervisors who don’t understand the technology and the people they are managing. As a result, you hire in kids who can belch an answer because they can’t think for themselves or worse… can’t solve a simple problem.
So… one final question I’ve recently heard asked of an interviewee:
You are in a boat in a pond. You throw a large object out of the boat which promptly sinks. Does the water level of the pond go up or down?
If I were to give my gut shot response: That depends entirely how much splashing around she does when she realizes you’ve thrown her out of the boat.
Anyone want to start a real software company with me?
grymble.
« MEMETIME or DAILY RANT… not sure which Weirdness in reflection »
I hate when people ask ridiculous interview questions. In no way are they testing how you think, or how well you interact with others; they’re testing how well you’ve memorized something. What on earth is the point of that? Particularly in the age of google. Sheesh.
As for their little “puzzle”… sounds like a trick quesiton. The brick displacing the same amount of water in the boat or not in the boat, isn’t it?
The question is poorly phrased: “you throw a large object out of the boat which promptly sinks.” What sinks — the object, or the boat? The answer’s different depending on which it is.
There is going to be certain basic information you’ll expect people to just know if they claim to know certain subjects well, but trivia or unrealistic interview questions bother me as well.
What I really liked about the interview for where I work now is that the technical questions they asked me were the sorts of things that you would need to solve in the real world. And the ‘requirements’ did keep evolving as I answered the question too!
Some interviewers – the realistic ones – do know that doing a job is an open-book test, not a closed one. Developers usually have books in their cubes and know how to Google well. If they use multiple languages they’ll sometimes get slightly rusty on the syntax details of less used ones, but will know how to recognize and fix it when they do. Writing code on a white board is not like doing it in a computer.
Interviewers that won’t admit these things are either stuck up little brats or managers who don’t actually understand what you’ll be doing… in either case, not the ideal co-workers or bosses.
What confuses me is it sounds almost like you are also complaining about ‘see how you think’ questions. Those are important. I just don’t think ones with nothing to do with the job are sensible. I keep hearing about this ‘how many barbers are there?’ one. That would really annoy me. This number-matching one sounds like something that would have been covered in some CS class. So anyone who has had that and remembers it could answer a lot faster. Others could maybe work out how to do it themselves. If they get it right, I think the people who can work it out are better, but in some interviews they prefer the one who can just spit it out.
Anyone want to start a real software company with me?
I don’t know any languages but I could run the network. Yay!
I remember someone once telling me about an interview some number of years ago. The interviewer asked if he’d had 5 years of experience with Windows NT, to which the interviewee had to reply no. When the interviewer said that was too bad because that was one of the requirements the interviewee explained to him that they would not be able to fill the position at all then – unless they waited another 3 yrs. *g*
Interview
I have recently been doing the initial phone screens for my company hiring college grads . . . then being in on the interview for those candidates. I asked to do this because I had never been on the other side of the table before, and I discovered something . . . it is hard.
When you are covering basic skills it is easy . . . when you have a job which actually requires someone to think like software development and hardware design and fabrication, it gets a little more dicey. I spent a couple of hours talking to different people asking what kinds of questions they asked in interviews, and they were totally useless to me.
The most pertinent information I get in an interview comes at two points, when I ask a question, what are the persons reactions(do they instantly start working on a board, belting out code, draw a diagram, ask me to clarify the problem since I usually give one without enough information), and in the end when they are given a chance to ask questions whether they are good questions.
Interviewing sucks, and why the questions are asked may make no sense to anyone but the person asking them.
My two cents
Maybe what they’re really testing is how docile and obedient you are (i.e. how willing to do something stupid just because you’re told to). That’s what they’re looking for in workers and citizens these days. Obedience. Not thinking. Not questioning.
We ask technical questions and give small real-time programming problems, though we try to avoid the canned ones. I mean, we pretty much assume that the person has, if necessary, memorized the really basic ones by rote, so what do we learn there?
There are a number of reasons for asking these questions. One is that we do in fact want to see how people go about solving the problem. When I’m asking the questions I deliberately under-specify the problem; I want to know if the candidate is going to ask clarifying questions or proceed with his assumptions (which is ok if he states the assumptions but not if he doesn’t). A bigger reason is that we can’t give him a real problem of the sort we are currently working on and expect him to tackle it in the span of an interview; there’s too much background knowledge that we’d have to spend time explaining first, and that’s not the point of the interview. Today’s problems are different from the ones we’ll have by the time his start date rolls around anyway, so any problem that can be stated fairly quickly will do.
All that said, we spend much more time discussing technical issues than giving little quizzes. We ask about things like the relative merits of C++ and Java, or about when to use composition versus delegation, or where some of the issues in writing multi-threaded code are, or things of that sort (all depending on the candidate’s background and the position we’re interviewing for, of course). We also expect the candidates to ask us questions; I think a non-trivial contributor to my getting this job was that I tried to drill into the technical details of the stuff they were explaining to me. Hey, if I’m going to be working on it, I want to know it’s not stupid. 🙂
interviewing is hard
I agree with: interviewing is hard. I’ve been struggling with what questions to ask, as what I’m looking for in a new hire has changed over the years. Phone interviews are particularly difficult.
I believe problems that allow the interviewer to see how you think when you solve a problem under pressure can be good, depending on the problem.
First there’s the obvious: how do you approach the problem? Do you make unstated assumptions? Do you try for a simple solution first, and then see if it’s worth optimizing? If you write code, do you use common idioms? Test to make sure it works with some examples, looking for off-by-one errors?
If I clarify things that change your assumptions and break your solution, do you get stuck? Frustrated? Increase your interest?
I do hate questions that have a trick that you either see or you don’t. Like swapping the values of two integer variables without using a temp (how is that useful anyway?).
What sort of questions do you like to ask when you perform an interview? What questions have you been asked that you thought were good questions, or provided the interviewer with some unique insight?