People suck at technical interviews (2014)

What? while sure you might not need a database if you have under 10k rows, if you want any amount of resiliency storing data in memory is a huge mistake as if the current instance of the application fails your done for.

On 1), I disagree -- if a genuinely senior engineer doesn't know of modulus (totally possible btw), then what they'll do is:

"Okay, let's assume I have some function that tells me whether something is divisible by p. [writes it while using that function] Now, how would I implement that function? Well, I'd search for some existing library function to do that, but if I can't, then here's how I would check divisibility ..."

That's because the senior dev knows how to break the problem into solvable pieces, even and especially where they don't already know the solution to each piece.

Two ways I can think of off the top of my head:

1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs)

2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships.

I'd wager #1 is the more common case.

I both agree and disagree with this as many of the other comments took this in a very different way than I had.

You can still test for creative ability in the traditional coding interview construct through systems design questions. It requires you to have a deep understanding of various technologies, but at the same time focuses more on how you view various trade offs which are crucial in designing complex systems.

When discussing art with its creator, you could have the same kind of discussions about various tradeoffs they made in regards to various technical topics. For a writer, use of alteration in a certain way, or a photographer trying to draw focus to a certain aspect of the larger photograph, in particular to various editing decisions.

The issue here is that the vast majority of new-grads/young programmers are fresh out of school and haven't spent any time focusing on systems design so companies focus on what they know best, asking them to be creative in the domain of algorithms. I also think its the case that since so many people's first interviews were algorithms based the process just continues to be that way.

But, at the end of the day, to say choosing a particular data structure to solve a certain type of problem has no creative aspect to it is wrong.

> A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one.

Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all.

Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too.

(Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.)

> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.

I look for a core concept or two for each area/technology and ask about that:

* For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume.

* Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary.

* For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation.

> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.

That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it?

> The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.

That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years?

I'd be looking for a better job the whole time.