Technical interviews in the US compared to the UK

I've interviewed people in the US, and the first time I asked candidates to reverse a linked list, I was shocked by the results.

Candidate A had a long track record of success, at least on paper. He was obviously motivated, responsible, and likable. He had done a lot of hardware work, and claimed to be a decent (but not top-notch) C programmer.

Candidate B was straight out of college, and he had a weak résumé. We suspected that he had some coding talent, but he didn't have much experience, and we had no idea whether or not he was reliable.

We were leaning heavily towards candidate A. He interviewed brilliantly and seemed like a good fit. Then I asked him to reverse a linked list, and he responded, "Do you have a copy of K&R? I don't remember what kind of braces C uses for functions." After about 30 minutes, he was still trying and failing to find a solution.

When I asked the same question to candidate B, he shrugged, and wrote out a correct solution without stopping to think. So we hired candidate B, and he did excellent work for us for years.

And this is not a one-time incident. It's amazing how many people can bluff their way through an interview without knowing how to sum the numbers in an array. Résumés are full of lies, phone screens are hard to do well, and references are hand-picked by the candidate. So I'm a big believer in coding questions.

I also believe in coding questions but the linked list question in this situation wasn't a good one to use for both candidates.

Why? Well of course the kid straight out of university would answer a question on data structures correctly, he probably did the class for that only a few months prior.

In your example, Candidate A was obviously a no-hire after not even knowing what braces a C function uses but a lot of people similar to Candidate A who can actually code are being presented with questions about linked lists and similar structures no-one who has written code for years would remember, let alone use in their daily work lives.

I want to say again, I'm 100% for coding questions but I think they should reflect more on the type of work you need the candidate to do in the job rather than some academic examples you feel you must ask just because Microsoft/Amazon do.

I wouldn't consider reversing a linked list a data structures question, it's a coding question. Everyone knows what a linked list is and that you have to iterate through it and flip the "arrows". The tricky part is being able to maintain all the pointers and know how to order your operations and handle any edge cases. That's what questions like these are supposed to check for, can you actually articulate into code a solution that you understand on a high level in your head.

It's absolutely a data structure question. You have to know what functions are available to you from within the data structure.

For instance, in a singly linked list you only have the function "getNext()" and "getHead()"; in a doubly linked list, you have additionally have the function "getPrev()" and "getTail()". If parent asked me this question in an interview I'd probably jokingly say "well, you didn't specify doubly or singly, so I'd just call getTail and then getPrev until I was done!" And then I'd write a recursive function for a singly linked list because everyone likes recursion.

How could you possibly answer this question if you didn't know what a linked list was? If you never took a data structures class, you probably used "lists" but you have no idea what the bare bones construction is. Just using lists doesn't mean you know how to write one from scratch.

If for some reason you don't know what a linked list is, you can always ask.

I think it's about admitting when you don't know something just as much as it's about being able to reason through the problem and give a correct answer.

All else equal, I'd much rather hire someone who didn't know what a linked list was, but asked and answered correctly, than someone who pretended to know and limped their way through the problem, even if they did eventually give a correct answer.

Linked lists are so fundamental, not knowing what they are is a big red flag. Anyone with even a modicum of curiosity about this field, college educated or not, should know what a linked list is, its complexity, and how it is structured.

I meant it's not a data structures question in that it doesn't ask anything particularly prodding into understanding deeply something intricate about a data structure. I assume any CS student knows what a linked-list is and can figure out that it has a getNext() function. It's more about coding than understanding a linked list.

but a lot of people similar to Candidate A who can actually code are being presented with questions about linked lists and similar structures no-one who has written code for years would remember, let alone use in their daily work lives.

Your reference to "remembering" is entirely irrelevant. What is relevant here is whether the candidate can reason through the problem - and more power to the candidate if s/he's been out of school for N years. What I strive for with technical questions is not to find out how well the candidate remembers their Knuth( although finding someone who actually read Knuth is nice ) - it is to determine how well they think through problems. And with no offense intended, if you can't at the very least come up with some ~3N complexity stupid-but-it-works stack-based solution to the problem of reversing a linked list, you probably shouldn't be a professional developer.

No offence taken, I do actually know a lot about linked lists, trees, graphs and so on. Partly from past experience, partly from reading technical articles and partly because I've researched the type of questions asked and therefore brushed up on these questions.

I guess the main argument I have is that I don't believe these are the best way to find out if a developer will be good at the position being offered. But I can't think of a better solution (other than getting them to work a trial period) and others seem to like this way of doing things. Therefore I will learn and adapt, which is the way of programming anyway :)

I completely disagree. If you view data structures as something that you "remember" from your university days, then you are more of a "tool user" than a programmer. No matter what a candidate has managed to accomplish using their IDE and copy/paste adventures, if they can't reverse a linked list on the spot they are a blindingly obvious "no-hire".

This should be the sort of thing anyone looking for a programming job should be able to do as the programming equivalent of muscle memory.

No not really, most professional developers, even using languages with little to no supporting libraries/APIs rarely, if ever, have to write code to reverse a linked list. Of course, given the question in an interview a decent programmer should be able to reason their way through the problem. This is not what I am debating. As a curiosity, I might wish to understand the inner workings of an STL map container, but 9 times out of 10 in a professional environment it is more appropriate that I understand how it should be used, it's pro's and con's and all it's supporting functions. However, even the most novice of programmers can find those answers out with a quick search online.

I guess I just don't like questions where you are required to remember facts you no longer use rather than reason your way through problems you might encounter in a real job.

Here's the thing -- I (and a great many people I've worked with, interviewed, and was interviewed by) don't believe things like reversing a linked list are facts. They're basic skills that are either present or absent.

If you aren't able to do such basic things correctly on the spot, I simply can't trust you to check in complex/highly concurrent/etc code that works. As an IC developer I don't want to deal with your code or clean up your mistakes. As a manager, I can't trust you to write code unsupervised.

This quote in particular would be a massive red flag and probably the end of an interview: "it is more appropriate that I understand how it should be used, it's pro's and con's and all it's supporting functions". In most companies, what's being sought is not someone who can just use the tools as appropriate. It's someone who can develop new tools and solve problems for which there isn't a pre-canned answer available. If you don't know how to solve the problems for which trivial answers exist, how can anyone expect you to be able to reason through truly novel and difficult problems.

The sort of attitude you're espousing is perfectly fine for large ERP/custom corporate app/corporate website/etc programming work. It's just not what people in the valley are doing.

I understand what you're saying but feel we're comparing different things. Yes, in an interview saying the thing you quoted would obviously be a red flag, and something I would never say. I understand the need in interviews to impress using your problem solving skills. However, I believe that in your day to day job as a programmer, that quote is more appropriate - that you understand how particular data structures should be used rather than it's inner workings. In this case, if we assume that the reason you're being interviewed is so you can do well at the day to day stuff, then my quote makes more sense.

I get you though; you want someone who can solve many new problems but it highly unreasonable to put a programmer in an unrealistic situation like an interview and expect them to perform just as well as they would on the job. Unfortunately I have no answer on how to improve the interview process but it still bothers me that a better way hasn't been found.

Not many people even use linked lists anymore anyways, unless they are programming low-level things and even then it is often more efficient to use a growable array, something like List<T> in .net or vector in C++.

Reversing a linked list is not about how linked lists work. It is a very simple question which verifies that a person knows what the pointers are and how to use them, can write simple loops which manipulate pointers and can handle simple things such as 1 element lists, 0 element lists etc.

The theory behind the technical questions is not whether you can reverse a linked list, but rather:

  -Do you know basic computer science concepts
  -How are your problem-solving skills
  -Can you move beyond "obvious, yet flawed" answers
  -Do you exhibit passion (passion to get to the right answer, enjoyment of problem solving, etc)
  -Can you present and justify solutions
  -Integrity (If you've seen the problem before, tell the interviewer, don't 'fake solve' it!)
  -Are you thorough (probing to understand problem, handling error cases, boundary cases, etc)
  -Can you communicate/collaborate with the interviewer

Anyway, that's the theory. In reality, many interviewers use whiteboard questions as a crutch to an easy interview loop and don't really understand why they're asking what they're asking.

My biggest piece of advice is to remember the technical interview isn't just (or even mostly) about the technical aspect. Communicate constantly, verbalize your thoughts, ask questions, show passion. I've hired plenty of people who have done not-so-well at the technical portion, and I've given a 'no hire' to plenty who have aced the technical portion.

Thanks for your input. I get most of the reasons you listed and feel that I do communicate well (I've been in charge of small teams/mentored etc.) and don't get flustered when asked these questions. But a lot of the time they require some kind of "leap" from the problem to the solution. Usually it's some obscure data structure I should have used or an adapted sorting algorithm which in my 10 years of developing software I've never had to use before - and I've worked in some diverse industries.

I've got another day long interview in a couple of days and to get there I had to do 2 phone screens and a 3-day long skills test at home. I get it, you have to get the right people but in a country where you can just sack someone at the drop of a hat it seems so over the top. Even more so in comparison to the UK where firing someone is extremely difficult.

You may "quit at the drop of a hat" as well so it works both ways. In the US, it's called "at will employment" so if you get stuck somewhere you don't like, you may leave. But if you want to use the company as a reference for future jobs, be nice to them and provide a few weeks notice, etc.

I don't know where you've interviewed in the UK, but the type the of interviews you've described in the US are pretty much the standard in the UK at major tech companies and in the financial sector.

The purpose of questions such as reversing a linked list is to test your understanding of fairly fundamental computer science, to see if you're someone who understands the technology you're using or if you treat it as a black box. For more technical companies they need people who fall into the first category hence ask that type of question.

I completely understand the reasons why they ask the questions. I just don't think they work that well for finding out if a candidate would work out to be a good employee.

As for interviewing in the UK, I've interviewed at many large and small companies and yes, they do have technical tests but I have come across none so in depth as the ones I'm encountering over here.

The strangest thing though, all these places have loads of spaces open for programmers yet such a rigid system that seems to require 100% scoring that most programmers, regardless of how valuable they might be, end up being ignored. The worst is for someone like myself who has been out of university for so long I don't remember how to answer some of the very exam-like questions yet you give me a coding problem and I can solve it.

As someone who does a lot of interviews and has switched jobs six months ago, I understand how it feels, on both sides. I've written my fair amount on the topics too (http://allenc.com/2011/04/how-to-score-a-google-onsite-inter... and http://corner.squareup.com/2011/10/why-we-pair-interview.htm...).

I think a part of it is ego, especially nowadays - some really good engineers are doing their own startups now, and when these companies start hiring they're looking for people just as good as they are, which means taking a page out of the Google/Facebook style interview process. I've met and worked with people who, while with great intentions, think great software engineering comes from graduate-level CS studies.

That said, resumes and achievements aren't great indicators of success because so many people have good-looking job histories and many can also sound good just talking about their experience. For me, front-end web eng. has become a pain to hire for; too many candidates put down things they don't know enough about, and unless they have fully-viewable source online it's hard to tell whether they accomplished much of anything in their past projects.

I do think our current standard of heavy whiteboard interviews is misleading, though, which is why I prefer pairing interviews when given a choice. Working with an engineer is a great way to measure cultural fit.

And finally, companies are super careful with filling a position because while firing someone is at-will, the cost in bringing that person up-to-speed, dealing with the bad player's code and work, the messiness in letting that person go (in planning, morale, etc.), not to mention salary and severance make everybody err on the side of caution.

As someone moving from the U.S. (possibly) to London in a few years, that's actually pretty comforting. I'm mostly self taught so any hardcore CS problems will throw me. I CAN reverse a linked list, but only if it's a doubly linked list :). (Ok, kidding, I can reverse a singly linked list, but ask me what heapsort is and I would definitely have to look it up.)

This is precisely why they use reverse a linked list- it's common enough that everyone understands it, and if not, it can be quickly explained, and everyone understands that you 'just need to flip' the arrows, yet we get many people who don't get it.

I find in the interviews that the Americans like to ask questions based on what you learnt in college. It's almost like a test on your university abilities. The tests on your ability to do the actual job seem to be rather scarce. Your ability to remember different sorting algorithms is much more important.

> It seems they expect interviewees to scream out loud that they are the greatest programmer the world has ever seen!

It is the American way to tell everyone how great you are and then once you have kids, you have to tell everyone how great they are. I suppose it is to be expected in what was/is a competitive capitalist market. If I interviewed in the UK and told everyone how great I am, it would be a sure fire way to not get the job.

Some US companies have a tendency to ask questions that are tricky or are obscure. Even worse is the interview that is completely overloaded with buzzwords and jargon.

If you can't spend 1-2 days revisiting old basic algorithms like this, you are not even self-motivated or capable of learning on the job to probably join the "bigger names" like you mention. Interviews like these test how well you are at basic comp. sci problems. I used to be like you and from a much more distant country but eventually I realized these questions have a lot of merit: if you don’t know these basics all you are capable of is gluing some APIs and solving some of integration/compatibility problems in different platforms. Not a good fit for companies who are creating those APIs, platforms and breaking new ground. Also, think about it from a statistics point of view: you are more likely to get false positive with people who can’t pass that simple question those who can.

For what it's worth I don't really care much about your resume other than the fact that it is a signal for if you _may_ be a good hire. My job as an interviewer is to test if you are a good hire and you need to be able to pass that test. I ask easy programmings questions as a smoke test of technical competence. I banter about your interests and past achievements to see if we are able to communicate and get along (as well as probe for bullshit). I ask hard problems to see how you think and your motivation to get the job done.

Having been in a big company, the primary reason we did lots of coding is to ensure that we have enough signal that you can code. One bombed interview may not mean much, but any more may be an indication that you cannot get the job done without some amount of babysitting.

I don't think the original poster was questioning the interview process so much as pointing out the cultural differences that exist.

To say that not passing two interviews means he can't get the job done without babysitting is ignorant. Looking at most of the hiring posts on hn, it becomes very obvious that they want to do a cultural fit. Defining a cultural fit is going to differ depending on who you ask.

Ive laughed at these type of questions and told them "How 90's of you". Of course I work in a more entrepreneurial field where getting the job done is more important than fretting over a linked list. Just my two cents.

The linked list question is just a proxy for basic competence.

Without such basic competence, it is probably not possible get "the job done" well.

I can see where you're coming from, sometimes I'm half expecting them to ask me how I'd move mount fuji ;)

Hello, I´m European as well, and I often thought about doing something similar (i.e. moving to US for a period of time looking for work). I have already been in Silicon Valley for an internship (with a researcher visa) years ago and loved the place, but I always thought that getting a working Visa would be hard, since the company basically has to petition for your visa and pay all the associated legal expenses.

In your experience then, is it something that can be done (I guess so given that you had 3 interviews already).? Or do companies gives you a hard time if you don´t have a work permit to start with ?

Thanks.

Hey, well I've been married to an American citizen for 5 years before coming over here so I got my green card recently after applying about 6 months ago. Because I don't require any sort of sponsorship I think I have more opportunities than someone who does. I'm afraid I can't really say for sure if you will have a harder time trying to get interviews when requiring sponsorship, but my opinion would be that yes, you will find it more difficult.

Ah, that explains it :)

Thanks for the answer anyway...

Yes it can be done, but its extremely tough if it is your first visa application (much easier to do a transfer). In that case you'd want the company to petition for you while you were interning (h1-b cap opens in April if I remember correctly) so that after your internship you could get approved and start in October (thats when you're allowed to start working).

The trick is to know all the ins and outs of the process (or get an experienced immigration attorney to advise you), so that if any issues come up you (preferably your attorney) can walk them through the process. It really isn't that hard, but not a lot of people bother to sit down and learn how to do it correctly.

The other thing is that if you can pay the associated costs on your own, then you can insulate the company from the process to a large degree ... I'm not sure that option is still available though, as I think it has been changed to require the company to pay all the fees on their own.

I started replying, and it turned into a long story: http://trapm.com/how-to-get-hired-or-the-silly-but-adorable-...

Hey thanks for that, a good read. The part that stuck out the most for me was pushing questions back to the interviewers. I tend to do this naturally as well but I came about this method differently than you. I see interviews as a chance to sell myself to the company but almost and equally as important, for the company to sell itself to me. Mentally, I take the approach that I'm a good engineer and could work for many different companies so what can this company offer me? You can usually tell quite early on when interviewing with a company if they believe somehow that they're doing you a "favor" by even talking to you. I avoid those places like the plague.

Yup, it's a really nice natural filter. If the companies don't feel comfortable doing themselves what they've asked you to do, you should probably duck out of there with a polite declination as quickly as possible.

Has anyone ever had to reverse a linked list in "the real world" (tm)? Is that a singly-linked or double-linked? Can I use Google, which is what any sane developer would do in "the real world". I don't remember squat about data structs 301. So what. What does the typical developer do daily? I would be much more interested in how they approach bugs. What approaches do they use? Any tools they carry on a flash drive? What drives them crazy? What do they love? What are they learning?

Bloody hell,one piece of advice-don't ever use "bloody good" or any other phrase with the word bloody in it.That's the real world,not a Harry Potter movie.Good luck!