When I read @RedQueenCoder's blog post... it really angried up my blood.

To all of you claiming knowledge of data structures is some kind of signal in interviews? Stop it.

Seriously.

It isn't reasonable to expect a candidate to derive that elegant solution it took two PhDs 8 months to discover.

Algorithm questions are not a way to make sure you’re hiring someone who is capable of coding. Algorithm questions are a way to discriminate against certain kinds of people.

I've participated in many, many interviews over my career. I've read everything Google has ever published about interviewing. I've surveyed the literature. It turns out when you task actual researchers with measuring the effectiveness of interview techniques you discover something: Noise does not become signal through repeated hazing rituals.

Google and Microsoft both abandoned their famous "brain teaser" questions. Why? Because the research demonstrated it is uncorrelated with job performance. Everything you think is great about your interview process? It's almost entirely luck and confirmation bias.

A master has failed more times than a novice has even tried.

I discovered that if I wrote code forty hours a week that I could learn programming. I could type code as easily as I type an email and the logic finally made sense. This was a revelation to me. I had given up on programming because I thought it was too hard and I could never learn it. I found that if I put in enough time and effort I could learn how to code.

I don't have a computer science degree.

I'm happy to have a discussion about the tradeoffs between red-black and AVL trees but that's a privilege I have from writing software since I was 10 years old.

I've implemented a copy-on-write immutable system using atomic compare-exchange to do concurrent in-memory transactions with rollback on 40+GB datasets. (I also added JavaScript to the same product to do in-proc formula calculations). My first program? A DOS program launcher written in QuickBasic. Not impressive in the least.

I'm proud of the 3-way visual diffing of blueprints I wrote for PlanGrid. I wasn't capable of writing that code the day I was hired. Every day is a process of learning new things. In two months I now know more about mach ports than most software engineers will ever know yet I've barely scratched the surface.

I've done such a wide variety of projects that I've run into situations where these data structures were useful. I investigated them, read the compsci papers, and tested them because they were relevant for the problem at hand. I also had the luxury of free time to study things like CPU branch prediction, read papers on implementing associated types by propagation of generic constraints, and written basic glsl shaders.

I was the same smart capable person before those experiences. If the door had been shut in my face I might not even be a software engineer today. The code I wrote in my first "real" programming job was garbage. I think I had only first discovered hash maps a year or two before that. Hell the code I wrote two years ago is garbage compared to what I'd write to solve the same problem today.

Software engineering is not some magic discipline immune from human factors. If you've never written a line of code before, go to Stanford. Graduate top of your class. It doesn't matter. Everything you make will be dogshit because you haven't written enough failures to truly understand software.

A general contractor can't build the Empire State building as their first project, no matter how good they are.

No one would give a shit about Frank Lloyd Wright's first building if he had died right after completing it.

You Get What You Measure

I can teach someone AVL trees in less than a day. We can whiteboard it together. Within a week they can implement it and the associated unit tests.

Know what else? They can learn the same thing from Cracking the Code Interview. In fact they can learn the whole book in a few weeks, maybe a few months. It's just rote memorization.

What does that say about their ability to build well-structured systems and avoid spaghetti code?

What does that say about their ability to collaborate on a team? To fluidly switch between leading and fighting for their ideas while being a follower on others' ideas? To create a safe group environment where all group members feel like they can ask "stupid" questions and everyone gets a chance to speak?

What does it say about their ability to "hit the ground running" and start building features right away?

What does it say about their ability to learn new frameworks, methodologies, and yes even data structures?

What does it say about their ability to interact with designers or clients? To imagine failure scenarios and make sure the code handles them? To write good tests?

Answer: Nothing. It just says they can read an algorithm and memorize it. They can learn which data structures to apply to which word problems.

If you’re struggling to make ends meet because you’re a single parent who can’t get past the velvet ropes to the land of coding opportunity, you do not have time to learn these things. You are told you’re not welcome and you give up.

Everyone starts somewhere.

Stop closing doors.

Stop using stupid hazing rituals.

Look for potential and build on it.

Most of your competitors are busy looking for pre-made diamonds (and failing even at that). Look for the diamonds in the rough. Pair them with experienced mentors and watch them grow.