How to win the coding interview

I came here to make the same comment (pardon the pun.)

This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag.

He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post.

Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quickly as possible. People love saying here that it's not a test scenario. But it is. The interviewer has a preconceived notion of what you should and shouldn't do and you need to meet that notion.

As an interviewer, recognize it's easy to think you're smarter than the other person when you already know the answer. Don't be pompous. Don't assume you know better. Try to set expectations very clearly. Try to really listen to the interviewee and understand why they're making the choices they are.

Personally, I would be frustrated by this interview. I feel like this article is a thin justification of a lot of standard interview practices that don't actually work. It and his further comments take a condescending tone that makes me worry he wouldn't be open to approaches he hasn't seen.

Reminds me of a time an interviewer basically gave up on an interview because I told him there were O(N) algorithms for sorting strings with a fixed alphabet. He said "Best case sorting is O(nlogn)" and I could hear in his voice that for him the interview was over. I knew what radix sort was but in the moment I couldn't actually explain or implement it without looking it up and things just went downhill from there.

Basics of RegEx, in my opinion, is a very subjective thing.

Personally, I'd interpret it as 'able to write a simple expression with a few minutes of googling', where simple expression is something like 'up to 5 lower case letters immediately followed by a digit'. It'd would be a reasonable indicator if someone has used them outside tutorials and class rooms in the past year or two.

However, you (or anyone else) might have a very different interpretation.

I am currently looking for work and already kind of tired of the technical interview process. I have been programming for 15 years professionally. We could save a bunch of time and money if the recruiters and engineers just looked at my resume and looked at my work. The truth is 99 percent of the work I would do is nothing like a technical interview: I have time (with leeway to work overtime), and I have Google/Stack Overflow. Never encountered a problem I could not solve, but there are plenty of problems I have not memorized the solution to.

I don't mind a general interview - I can "talk the talk" - I just hate being asked questions with very specific answers that would require most people to study or memorize beforehand. If I can Google it in a few seconds, it should not be an interview question.

My first dev job was like this as well, also in a tiny company hiring at a slow rate (I was the only person hired in my time there, and also the only employee). I think that this sort of thing worked for the company I was employed at because the work wasn't very technically challenging so I was able to get on with things quickly and it became more about cultural fit.

It's interesting that the parent is suggesting this for when you have a lot of experience rather than when you have none.

Given the number of people I've interviewed over the years who have 10 years experience and look very strong on their CV, but still struggle with our basic "coding challenge" (on par with FizzBuzz but more aligned with what our company was doing), even before we get to the real interviewing (with another alarmingly high dropout at this point as well), I can't see hiring for a trial being an effective strategy. We would be sinking way too much cost and effort in to it.

It may also result in poor hiring choices because one person's ticket/feature/whatever may have hidden challenges, and another person's might be easier than initially assumed. There's now more randomness involved in what's an already too random process.

Maybe interviews should be a bit less involved, and companies should be more willing to take advantage of the probation period (and employees too, I've seen a handful pass their probation and regret it).

Thanks! :) The Vic 20 at about the same age here too; assembly was great, but staying for well over a decade on ColdFusion just because there was a lot of work in it (and, comfortable) was not.

I forgot to mention some PHP thrown in there, but I'm glad to have been making the transition to C# in the past year. Working with a strongly typed language is quite a revelation, and some fantastic things are happening with the language and framework these days too (dotNetCore).