1. You hear "reverse a linked list", you maybe ask some clarifying questions (expected efficiency, in-place or a new list, etc.).

2. You start drawing boxes with arrows on the whiteboard.

I've never been able to come up with any algorithm for a linked list without drawing a bunch of arrows and staring at them. And while lots of people might be too stressed out to come up with the algorithm, any programmer who has even a little experience with lists should know to start with that.

In other words, if you have any experience with this kind of stuff, it shows up pretty quickly by what you do/what you say.

Would you be OK if instead of writing on the white board, I whipped out my laptop and coded the answer there in front of you? If the answer is no, I would happily walk out of the interview knowing I would not be a good fit for the company.

Not sure why that is.

Are you also self-taught, by any chance?

Best of luck!

If someone isn't able to solve problems, that isn't something you can fix easily.

I'm tired of all these people who do poorly on tests turn around to blame the test. Everyone is nervous during tests and interviews. Those who succeed do so because they can solve those problems like the back of their hand.

Yes, but what you're missing is the degree certain people are nervous. Some people lock up completely due to performance anxiety, which has nothing to do with how difficult the problem is. Those people are also more likely to be found in the computer engineering profession due to the nature of the job.

So if you want a charismatic person with strong social skills, then you're just going to have to accept the bullshit artist who is more PR than talent over the painfully anxious and shy person who knows how to program.

That, or deal with hunting down the very few people who are both social and vastly knowledgeable. Good luck with that.

b) If you want to advance as an engineer (of any sort, I would say), social skills are nearly mandatory. People who just code well-specified problems, no matter how well, are going to be stuck at the lower tiers of the profession. Being able to talk with your customers (internal or external) and understand, and help them understand, their needs is essential to increasing your value as an engineer.

This is why I would never get through Google's interviewing process.

I understand that some people are bad at doing these types of tasks on the spot.

But what about training yourself to get better at working like this, by working through exercises, having friends help you out, etc?

Maybe it's unfair of me to comment because I'm not in the same boat, but surely there is a way for most people who are currently inherently bad at this class of problem to work on getting better at it, rather than just always assuming that a company like Google or Rethink would never hire them.

I'm surprised that people find writing simple programs and talking about them stressful. I find it quite enjoyable.

And also, if they don't ask technical questions, they don't have a bozo filter and I'd risk having to work with bozos.

It helps, I suppose, that I enjoy explaining things to people.

As an example, I love Haskell's type system. I will almost always try to explain to interviewers how Haskell's type system would benefit this or that problem, and how it compares with the languages they are using. If the interviewer is any sort of good programmer, we can usually get into a good discussion on the trade offs of different language features.

Of course, maybe I would be getting even more offers if I didn't use this tactic.