Dealing with hard questions during a software developer interview

Question

I've recently attended an interview for a software developer position. At one point I was given three questions - two code writing and another more theoretical. One of the code writing questions included writing a parser for arithmetic expressions string. I've came up with a working algorithm, but I didn't have time to write the code (also, there was another more efficient algorithm which the interviewer told me about later).

At home I've checked the algorithm - Shunting Yard), which is quite complicated (my algorithm was even more complicated and was similar to Operator-precedence algorithm). Is it realistic to expect an applicant to implement this argument in 20 minutes on paper without Internet access and answer two more moderately hard questions? What were the expectations?

Answer 1

I find these sorts of tests are most suited to recent graduates who remember their theory from university. When a company asks me to do a test, I usually decline and tell them to hire a graduate instead as I would most likely fail the test since what they are testing for are things I haven't used in over 15 years. It causes some friction with recruiters but that is not my problem.

I'm happy to have a whiteboard discuss-as-you-go type technical interview for a company which extends me the courtesy of giving me their time to interview me. Any company asking for a coding test before even wanting to meet me gets a hard pass.

My advice is don't get too hung up on it, written tests before meeting a candidate is just lazy interviewing.

To further elaborate: When I try to explain this to recruiters as to why I decline such tests I use the analogy of the English language. We all use the language daily, we're good at it (some better than others). But I bet I could stump you (the recruiter) with a grammar test for something you haven't revisited since school and to top it off I bet I could find obscure words in a dictionary that you don't know. Then I can cheerfully declare that you the recruiter, a native English speaker, doesn't know how to speak English and hire a school leaver who does remember the obscure and mostly unused/irrelevant details.

Answer 2

We don't know what the expectations were. Maybe they wanted to filter the 0.1% of people, according to their definition of 0.1%.

Maybe they wanted to see how you approach hard problems under stress, and actually solving this wasn't the purpose. Maybe they just wanted to see how far you got.

Different companies have different hiring criteria. If you fit them, you get the offer. If not, search for another company.

If the company regularly filters out so many people that they find nobody, they will have to rethink their hiring approach.

Answer 3

This isn't reasonable from the company, nor is it helpful.

I'm a technical lead for a big software company and do plenty of recruitment. I've worked across a number of companies, and none of them do the whole "invert a binary tree on paper" thing that some big American companies seem to do.

We don't do it for a few reasons:

1. It tells us precisely nothing about a candidate's ability to do the job. You're, quite literally, never going to have to write code on paper and there are very, very few situations you wouldn't have access to Google (we freely tell candidates to use Google during their tech tests if needs be).
2. Unless you're writing framework, or very specialist code, a good 90% of a software engineer's job is stitching together various disparate systems to get them to work coherently. Writing readable, testable, and maintainable code that does this reliably is often far more important than pulling the most optimal algorithm out of your ass.
3. Finally, it adds totally undue stress and pressure on the candidate. You're making them do something that they'd never normally do, in a way that they wouldn't normally do it, with potentially hundreds of thousands of whatever your local currency is on the line. That's horrible. Why would you do that to someone and what impression does that give them of your company? It would almost be acceptable if you got some useful information out of it, but you don't. Your employees shouldn't be working in an atmosphere of undue pressure and fear, so why does it matter if your candidates can perform under those conditions? It doesn't.

So, my advice, although I understand it might be somewhat difficult to follow at your stage in your career:

1. Refuse to engage with this crap. If someone tells you to write code on paper, say no. If, as an industry, we stop engaging with this, it will stop happening.
2. Go and find better companies that actually understand what makes a software engineer good at their job and go work for them instead. You'll be far happier for it.
3. Any company that engages in gimmicky "lateral thinking" or Myers Briggs style interview stages, isn't worth working for. If they don't care about the efficacy of their recruitment pipeline, then they don't care about their employees.

And remember, you work in software engineering. We're basically the most in demand profession in the world right now, and that's becoming increasingly true as time goes on. There are far more jobs than there are competent software engineers, we have all the power. Interviews are two way streets, if companies don't treat you well during them, go and find another company. Also, make sure you feed back to them exactly why.

Then hopefully we can stop this stuff from becoming even more prevalent.

Answer 4

Recruiters sometimes like to ask candidates to write code on paper to assess their problem solving skills and ability to think for themselves.

It's also worth noting that recruiters may deliberately choose questions that are more challenging than what you're likely to encounter at work. They want to see how you deal with difficult problems and whether you have the skills and knowledge needed to work on complex projects.

In your case, it looks like you did your best and managed to come up with a working algorithm, which is a good sign. Even if your algorithm wasn't that efficient, the fact that you find a solution shows your problem-solving skills and willingness to tackle difficult problems.

Or.. sometimes the project burns and they are looking for someone who will solve current problems in the best possible way.

Answer 5

Most interviewing questions has both an overt and a subvert component.

By asking you to produce some code, they're determining whether you can write code. That's the surface part.

Underneath, they're perhaps gauging how you interpreted the instructions, whether you missed anything that was given in the instructions, how you interacted when perhaps clarifying a deliberately vague point (immediately, after starting, ignoring the vague thing, or being oblivious to the vagueness)

They might also be checking if your indentation style matches what they were taught in school, or if you use CamelCase variable names, or other stylistic niceties that don't affect the function.

Simply do the best you can, and it can help to talk out loud more if you're coding on a whiteboard. This gives a view into your thought-processes which is really what the questions are trying to show.

---

Side story - I remember doing this verbalisation years ago while taking a drivers license practical test. Instructor said at the end it was very helpful for him, he knew I'd observed things, even if I hadn't needed to react. I also made a point of turning the head and looking at things rather than just one's eyes.

The point here is to show you know what you're doing, and doing it the "right" way. At the end, the code you wrote is a means to an end, which is demonstrating You.

Answer 6

Another option is that your interviewers didn’t think through their question or thought the answer would be easy and obvious. Don’t assume that they’ve had dozens of interviews and streamlined the whole process.

I’ve had colleagues come to me with “We have an interview this afternoon for a position which is somewhat related to yours, do you have a coding example or some questions we could give the candidate from your field?” And I’d suggest some things but without any idea about the experience of the candidate or how much time they’d be given. We don’t have a lot of interviews, especially not for some particular positions.

Answer 7

One option that I haven't seen mentioned is that it's possible you misunderstood the question, and thus overcomplicated it for yourself. Either through your own fault of reading in things that the question never explicitly asked, or through the question writer's fault for accidentally asking for something they never actually intended candidates to answer. For instance, perhaps they only intended for candidates to solve the problem for a certain subset of arithmetic expressions, or ignoring rules of operator precedence.

Quite often interview questions are written with deliberately vague requirements — candidates are then rewarded for asking clarifying questions. While personally I prefer to ask questions that are clear in their core requirements and maybe have some interesting edge cases which I hope candidates will notice and ask about, it's probably a good lesson to learn to always ask clarifying questions, especially if at first glance a problem seems impossibly hard. This reflects well against the real world, where sometimes client requirements are much more limited and narrow than software engineers are prone to naturally assuming.

So my advice is, next time you're in an interview, ask plenty of questions. If you're worried about coming across as clueless, you could phrase your questions in more leading ways (eg "should I assume that I need to follow operator precedence rules?") to make it clear you've already considered a possible answer and just want confirmation. If the company you're interviewing with reacts badly to this, or doesn't have an interview framework where you're able to ask these questions in the first place, then I'd suggest it's not a place any software engineer should want to work as you'll probably be spending most of your time implementing things your clients don't even want...

Answer 8

It's possible that the interviewer was checking to see how you'd respond to being given a task with an impossible time frame. In my opinion, the best answer would have been to say "I don't believe I can complete this task in the 20 minutes allowed". That tells the interviewer that you're not shy to raise alarm bells when you've been set an unreasonable deadline, and that's actually a huge positive in an employee.

In response, the interviewer might then have said something like "just complete as much of it as you can", or maybe "well then, estimate how long it would take", or even "that's the answer I wanted, let's move on to the next question".

In one interview a few years ago, I was given a small Java programming task and told to complete it in 10 minutes, on paper. Instead of completing the task, I wrote a JUnit test for the task. This impressed the interviewer, and I got the job. It was kind of a calculated risk though, and you may not feel brave enough to try this.

Answer 9

Job interview always work in 2 directions.

You don't know for sure what are theirs expectations but you should know yours. If you feel under pressure, or otherwise uncomfortable on the interview, there is a great chance you'd feel the same when working for them, because the interview is a part of the working culture in a more way a company would want to.

I suppose the hiring manager found it cool to test how the candidates perform under pressure and unrealistic deadlines, which means, that both of them are likely to be part of their everyday business. Now, would you like to work for a company like that? If the answer is 'yes', because you need any job hardly, then hope for luck, because such tests are often luck-based (you get correct idea by chance, while 10 other candidates won't). If not, just move on.

Answer 10

Twenty minutes is not enough time to write this program. I assume more time was given for the other program and the theoretical question.

They're just trying to see how far you get and find out what your thinking is. If you get flustered and you can't explain your approach, that tells them something. If you had a great approach but just couldn't finish it, that tells them something too.

Another possibility is that the interviewers were simply inexperienced.

Answer 11

In my opinion, giving a task that cannot reasonably be written in the time specified, especially if it can only really be written in that time assuming no mistakes. However, as a caveat to that, when I worked at Google, if you were doing one of the coding interviews, you were supposed to have a goal question that would take the entire half hour of the coding part of that hour interview slot. The thing is, we didn't expect most people to hit that, and we would have earlier, and easier, versions that we start off with. For example, one question I was fond of involved converting a binary tree to an XML document, and the base case allowed them to restrict the input to, say, standard strings with no spaces, and to not worry about recursion, degenerate trees, and the like. Once they solved that (which took most candidates about 10-15 minutes), we could start dipping into more complicated scenarios and how they might handle them. I only had a handful of candidates who got the hard version of the question coded in the time specified, and those were the ones who got marked as potentially exceptional (only potentially, of course, because some people came in having trained on particular questions that they'd seen on coding sites as Google interview questions).

And, at that, we were explicitly told that the ultimate correctness of the answer wasn't nearly as important as the approach of the candidate (whether they asked clarifying questions, how they communicated how they were going about the task and what they were having trouble with, etc) and their ability to either keep moving forward, or indicate what they were stuck on. Engineers being engineers, not everyone was able to keep to that, but I can remember several cases where the candidate didn't get the right answer, but we could tell their approach was sound, and in at least one case I remember, they got the nod to move forward in part because they recognized that they'd gone wrong, and much of the rest of that interview was them explaining how they could have been testing during implementation to catch it in the future.