Coding Interview Tips

Having said that, if (as many of us believe) these sorts of interviews aren't a very good way to correlate candidates with desired job skills, then the situation is bad for companies, and for the efficiency of the industry as a whole, despite being a good thing for that set of people who are willing to gain an advantage through preparation. There are probably more useful things than preparing for interviews that people could be doing for that couple hours a day.

I'm not sure it's frustrating so much as it is humiliating. Programmers (especially good ones) have egos that are somewhere between healthy and oversized. Interviewers assume you know nothing and make you qualify yourself at each and every interview, as if you were a fresh college graduate who hadn't already made his bones[0] at a dozen other jobs[1].

A good developer would be smart to realize that this is a part of the project of finding a great new job, and would apply themselves fully to the subtask of preparing for and succeeding at an interview.

Sadly enough, I couldn't agree more. Complaining on the internet is not a sufficient strategy for changing the face of tech hiring, so if you want to work, you have to deal with things as they are. Then again, the best way to find new jobs is through aggressive networking, not being able to reverse a binary tree on a whiteboard. So a good developer should probably focus on that instead.

[0]: yes, that's a very entitled attitude. On the other hand, if we had gone into an apprenticed trade, like woodworking or plumbing, it's expected that you already know your job by the time you hang your own shingle. It's a sad day when plumbers get more respect than programmers.

[1]: Just to nip this one in the bud: Yes, people lie on resumes. A short conversation about their work history where you ask for specifics should be enough to verify whether they actually did what they said they did. If they're good enough to bullshit their way through an interview, they're good enough to bullshit their way through a whiteboard programming session. If, for some bizarre reason you make a bad hire despite all the other filters you have set up, fire them and chalk it up to a mistake. If you do it over and over and over, re-evaluate how you do interviews.

I also consider having the traditional interview process a huge red flag, since it's a good indicator that once hired, you may have to work with the kinds of employees that this kind of interview process tends to self-select for (i.e. extrovert bro-grammers who are experts at gaming the interview process but who won't necessarily know how to build a compelling, maintainable product).

That's not how the real world works.

That said, as a senior software engineer, you should be able to get on a whiteboard and brainstorm and defend some architectural designs.

Even then, it's so much more important that you're all on the "same page" and can collaborate on problem solving, rather than they hoping your freaking Richard Feynman and will solve cold fusion for them

Give a person a specific task in a specific environment, and stand over them, and generally all you see is that they can bumble through something pretty unfamiliar under a high degree of stress and social pressure. This is a useful skill approximately 0% of the time in a real job. Or if it is a useful skill in the job, your team has more fundamental problems than hiring to worry about!

Give them a problem to solve. Full stop. Let them take their time, do it at home before the interview perhaps, or in a quiet room on their own with their own laptop, or whatever tools they want, internet access etc, with no real time limit. If they 'cheat', you'll know because when you discuss their solution in depth later it'll be clear as day. This will test what you're really after, their ability to solve problems - allowing tools, the web, whatever else to work for them and not be arbitrary hurdles to jump over under pressure.

If you're talking about balanced trees, I sort of agree with you. That's the kind of algorithm where it makes sense to write it once, test it thoroughly, stick it in a library and never worry about it again. But there are plenty of other uses for tree-like things. Think filesystems, or the HTML DOM, or JSON documents, or (generalizing a bit) dependency graphs, and so on...

I actually like tree problems. You can take something with practical significance (laying out a web page, or syncing two directories, or simplifying a boolean expression) and strip away the details of the situation to get to a core algorithm that depends only on the tree's structure. In my experience, the biggest factor in how well interviewees cope with kind of question is their ability to reason clearly about what their code is doing, instead of just pattern-matching from their previous experience.

So long it's not a pop quiz type thing.

I just changed job, and the system I have inherited doesn't seem to have much in the way of automated testing at all, but it works, and it runs. The logging is really thorough which helps a lot. The bugs I have encountered far wouldn't be caught by tests.

Man, this is so true. I've had great conversations in interviews where it was stated up-front that the goal was to cooperatively dig into ambiguous specifications. This is (often) an actual part of working as an developer. Speaking with someone who's being deliberately vague about what they want is not, unless that's what you think of people "on the business side," in which case you've got a bizarre understanding of how this industry works that would be a big red-flag for me as a potential colleague.

Tech companies conduct interviews like 5-year-olds play soccer - everyone chasing the same prize with the same myopic strategy. And it's not that it can't be done better, but that everyone is afraid to take any _risk_ in order to improve it (if we don't chase the ball, someone else will get it and we won't!). No matter how broken the current system gets, we muddle through somehow and chalk it up to necessity (how else would you find good engineers?). Then we try to forget the whole thing even happened until we end up looking for a job again.

I used to be good at those kind of tests 15 years ago. Now I am orders of magnitude more competent at designing implementing and deploying systems I have way more knowledge in all of those areas, but I get tested on that nonsense. I hardly ever write algorithms (occasionally), as I will look for an appropraite library first.

In general the coding was not the most important part of the interview, just a check for experience and competence. For contrast, when I got my job with NASA 10 years ago the interview was almost entirely coding, and coding minutia in multiple languages. Maybe 30% design and algorithms and 70% code over 3 days of interviews.