How not to hire a software engineer

All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. "Can you show you know sufficient SQL? Did you write applications before using Rails/Django what have you? Distributed this, Web that - OK, jobs is yours." After all that the productivity of the programmer is solely based on the work environment and how motivated you can keep a developer who is becoming depressingly convinced that his calling in life is to write web handlers and optimize queries to a bloated database schema and watch the guy whose been on the job too long walk around like he's some fusion of John Carmack and Elon Musk.

Why these interview processes act as if candidates are going to be designing graphics engines from scratch for graphics hardware extracted fr om a downed alien spacecraftis beyond me. We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions and used every new OOD technique in the books when a handful few procedural functions would have sufficed.

I'm currently working on revamping the way we do the first interview, which is nothing more than a filter.

We currently ask mainly, let's face it, poor theoretical questions.

I want to ask more experience based questions.

so instead of:

Explain what a database index is

Ask:

Can you give us an example of a time you used a database index? What were you trying to achieve? Could there have been a different solution to reach the same outcome?

If the candidate doesn't have experience with databases that's fine we just ignore this question, at least that's what I would like to do, whether I can sell this is another story.

To be sure if the candidate has no database experience, no cloud experience and no backend development experience then it's probably not going to work out but we can try to be flexible about candidate's experience.

It's easy enough to learn what SOLID means but a lot harder to know when it's a bad idea to use it or when it might be a good idea to compromise.

I suppose I'll be the first to say that yellow as a background color is a horrible design choice. And it's not even using the background color CSS option alone, it's got some weird tiled single pixel yellow image on top of it! What??

Get them to ask a question on stackoverflow without it being closed or put on hold or marked as a duplicate.

I look to see if I can trust them to not do dumb things. That's really it.

What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all).

Do you see what's not there? Programming language competency. Database knowledge. Things like that.

I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had never seen a mainframe. I was told about 20 years ago to write a program in perl, my boss gave me a perl book with the assignment because I didn't know perl and I did it.

This is not a bad way to go about work. Every codebase is new. Every job has a steep learning curve. Every requirement is a conversation which may only be internal, but has to always happen. Every programmer you work with is someone whose preferences, strengths, styles, and weaknesses you need to have intuition on. People good at those things are what make good programmers.

That's why general competency, ability to learn, not to create a mess and not to waste time on stupid things are the only things I care about. That's really it.

Preexisting technical skills aren't as important as how dynamically you can apply new ones.