Ask HN: What are interviewers looking for when they give you puzzles?
I've been doing some programming interviews lately, and they've all included "typical" programming challenges. A lot of them can be done through brute force, but it's evident they are looking for the optimal solution ie. O(n).
I'm curious, do these companies want to see if you've already done a similar questions and are able to re-apply the solution? Or are they looking for you to produce a novel approach to the problem? If the latter, is it a typical expectation for a Software Engineer to be able to produce optimal solutions in short periods of time like that?
I've been spending a lot of time studying these types of interview questions, but I continue to run into puzzles I've never seen. I'm concerned that they are looking for a degree of problem solving skills that I might not have.
22 comments
[ 0.28 ms ] story [ 57.2 ms ] threadIf someone interviewing you has a CS degree from MIT they may want to show off to you and everyone else how much they know and how clever they are. It's possible the job requires deep computer science expertise, but most programming jobs simply don't.
A few years ago Google -- famous for their tech interviews -- revealed that they had found no correlation between the interview tests and puzzles and job performance.
My own experience (36 years) working with many, many programmers in all kinds of environments is that some are good at puzzles and enjoy them, and others aren't. It doesn't appear to have much to do with their ability to write the bread-and-butter type of code that most of us spend our careers writing. Sure, it's good (maybe essential in some contexts) to know if an algorithm is O(n) or O(n^2). I've worked on projects where recognizing a better algorithm made the code faster or cleaner. But these are edge cases for most programmers, who are mostly shuffling data from one format to another and trying to get their build system to run on their laptop.
Of course you can ask the interviewers what they expect to learn from sweating you over puzzles, or how many times they have had to move Mt. Fuji in their day-to-day work, but challenging the interview process is probably not going to help your prospects.
Any articles/links on this one?
"On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."
From an interview with Laszlo Bock, senior vice president of people operations at Google.
http://typicalprogrammer.com/thirteen-patterns-of-programmer...
Maybe.
Personally, I do use questions like this, and I'm looking for a combination of things.
Firstly, how much reading have you done, and how many of these things have you come across before? If you know them all, that tells me you have to hand an arsenal of techniques to bring to bear on a problem, and you care enough to have done considerable outside reading and preparation. That's a good sign.
Secondly, if there's a problem you've not met before, what do you do? Do you freeze? Do you go thoughtful? Do you ask questions to clarify? Do you look to step around the problem? Are you sufficiently confident in yourself to simply get to work, or are you worried that your inability will be seen as an excuse not to hire you?
Thirdly, as you start to work on it, what's your intuition like? What techniques do you bring to bear? Do you assume there's one, right, trick answer, or do you treat this as a challenge to be played with?
Finally, how do you react to contributions from others? Do you welcome working together and relish discovering stuff, or do you want to work alone, seeing how you get on?
All of these have positive and negative aspects when weighed against a given possible job. What I'm looking for is that balance between someone who brings new skills and knowledge to the team, and the ability to work with the team, and to have enough in common to be able to communicate effectively. Some people love puzzles, some hate them. Some are great at theoretical analyses, some aren't. Some people can devise or adapt algorithms, and some can't. A good team needs a balance, and asking these sorts of questions of people is part of finding out their strengths and weaknesses, to see how they'll fit in a team.
Do you want my advice?
Work on your abilities. Be professional in your personal development in whatever area you are interested in, as well as other related areas. Read widely, work on projects, work with people, and expose yourself to technologies outside your comfort zone. When faced with puzzles and problems like these, be yourself. Ask what's expected, and work with your interviewer in a professional manner - an interview should be a dialogue. At the end of the interview ask yourself - do I want to work with these people?
If they don't hire you for who you are and what you bring to the table then you would likely not be a good fit, and would likely not enjoy your work and/or the environment. If they offer you the position, you've learned a bit about what they are like to work with, so you are in a position to decide if you want the job.
But this is not an ideal world, so you will need to decide what compromises you're willing to make.
I'm heavily in the synthesis camp, and that kind of inquiry is something that favors my style of thinking over more analysis-oriented folks. I'm not even sure how you'd go about pulling analytic strength out of people.
So at least in my opinion it is about seeing how you think not whether you can solve some complex problem in 5 minutes. This is also why I have changed how I ask and what I ask. I've moved to telling people up front that I don't care if they get the right answer, I just want them to show me their thought process and how they would go about solving it. And I will also participate and provide feedback and talk through it with you like we would as team members. This way we can see how good or bad we might work together.
So at least for me, and my team, its never about can you state that a hash table is O(1) for access but O(n) for search vs a b-tree is O(log n) for both etc. It is more about can you think through a problem well enough to give us the best solution and will you work with us to find it. e.g. puzzle questions IMO used to be a lot about self gratification to the interviewer's own ego, now we use them to see thought processes and to be interactive to see how we all work together.
True puzzles do not provide very much useful information, as they are often based on a trick, and don't actually overlap a lot with what we do. Even algorithmic puzzles are pretty dumb.
But problem solving, O(n), and composing algorithms is very important to what we do. So what I'm looking for when I ask you to write a function so solve X is:
- Can you understand a problem and critically think about it?
- Can you handle super-basic logic to work out a solution?
- Do you at least vaguely understand performance concerns, i.e. can you identify whether a given input is problematic, or talk about possible ways to improve it?
I've definitely encountered questions where I wasn't familiar with a certain topic, and usually they'll realize it and just give me hints. I did also have interviewers who just watched me struggle though.
If I had asked a question like that, and if you can do some bitwise voodoo to solve it in O(n), great. But what I'd be looking for is, can you solve it all? Do you understand the problem statement enough to write a general sort of algorithm? If your first pass is O(n^4) and I point it out, can you understand this, and think of ways to improve? If I point out a problematic or erroneous input, can you reason about what will happen? Etc.
I think this is what we need to look for in interviews. Certainly not, can you solve this brain teaser I read in a magazine.
When a candidate is struggling or even just asks me, "is there a trick to this that I'm not seeing?," I will give them pretty big hints. They get bonus points for knowing when to ask for help and/or for being able to incorporate new information into their code quickly. I've always been offered the same courtesy when on the other side of the table.
That said, I personally don't give much weight to challenges or tests and would be surprised to hear if anyone considered them more important than relevant experience.
This is true, and certainly my approach to doing interviews.
I tend to ask two kinds of questions. There are easy ones, with lots of different solutions. On those I do want to see a working answer (because they are supposed to be easy), but I explicitly track how the candidate arrived at their particular answer. I get an idea how they think, and what kinds of solutions they consider, not to mention how they deal with bad approaches.
And then there are the hard ones. They usually have exactly one correct solution, but finding that is not required. Instead I focus on how the candidate approaches the problem, and how they deal with different tradeoffs. The interesting bits are generally false path eliminations, the kinds of hints they need, and quite often how they formulate the problem to themselves.
Once a candidate has shown that they pass a definite baseline requirement for proficiency, the rest is mostly about trying to see how they approach problem solving in general.
In interviews, I wouldn't expect a candidate to come up with optimal solutions to every problem as sometimes you just need a fortunate eureka moment for that. If they couldn't verbalise their thoughts on the tradeoffs between the alternative implementations they were thinking about I'd be less sure of them though.
The best part is that each and every one of these interviewers thinks they're special. Like they are somehow clever and intelligent by asking this type of questions. They don't even realize that they are using the same lazy approach everybody else is taking.
The truth is, tech interviews revolve around your interviewer. How you make HIM feel. I've seen idiots get hired because they were enthusiastic. And extremely intelligent people rejected because "they couldn't communicate the way I like it".
So in an interview forget about your skills, experience and anything else related to the job. It doesn't matter. Just woo the person across the table and you will get an offer. This works most of the time for shitty companies with lazy interviewers. And that's most of them.
Personally, I found that that companies that allow this type of interviewing behavior will overwork and underpay you. Because they don't care. They just want to push things out to make a quick buck. If you want to be treated like an expert that has a brain in his skull, avoid them completely.
Instead, find the companies that trust your experience. That act like you're as good as you say. And just make a quick check to see if you know what you're talking about. They are rare and most of them are startups. But the higher pay and better work environment is completely worth it.
Startups in the valley are notorious for following these. It's based off the misguided assumption that it equates to a candidate's future quality, throughput and they can mold you into any stack.
The real value comes from learning algorithms when you can actually apply them. You'll real learn things when the time comes - and self-interest in your own software / task will keep you engaged enough continue optimizing speed.
If you truly were a master at o(n) this, quadratic that and shipped voluminous amounts of code - take that and apply for a quant job.
- That you're able to take ownership of a task and see it to completion
- That you can work with the tech stack that the company uses
- That you can actually do what you say you can do
You can tell a great deal about the interviewers sophistication, business acumen, and level of seniority by the types of questions they ask.
The puzzler question may come off amateurish. Sometimes the interviewer is simply probing for emotional intelligence and good humour. They want to know if you'll be a cultural fit and accretive to the team. Play along, it's part of the process.
Sadly, the first level of interviews are often done by low-level types, even worse...HR flunkies.