Tech Hiring is Broken

This post is more of a stream of conscious than my normal tutorial/announcement posts that I put out, so if you don't like that, you probably should stop reading now 😄

I started my career in 2018, at Azuqua. A now defunct startup that was acquired by Okta in 2019. Prior to that, I was in high school working on open source software on the side. I wanted nothing more than to get a job in tech. Thankfully, Azuqua gave me a chance. I recall my interview loop being mostly soft-skills and one section meant to determine if I knew basic programming constructs of the language I said I specialized in, which was Javascript at the time. "How would you implement async.each?". While by no means a complicated question for an experienced programmer, it was a great way to determine how I communicated and thought through things, which is exactly what we should be striving to get signal on during hiring.

If you were to interview anywhere today (especially FANG), questions all follow some similar format of "Here's my slightly unique problem, which algorithm would you use to solve it". Usually boiling down to some implementation of BFS/DFS (explaining the nuances) or some other datastructure (e.g., heap). While those could give you signal on how a developer works technically, it presents some problems:

1. Everyone knows you're going to ask these types of questions, so they can easily "grind" out this, while still being not a very technically strong engineer
2. How often do we, as developers, need to pick an algorithm to solve a problem?
   1. Sure, in DevX/SRE roles like I've been in for years now, it's even less. But even in the product facing world, I would doubt you're doing this often.
3. It biases towards engineers with a traditional college education, which is where you are learning these traditionally.
   1. If I had been asked how to implement DFS for my first job, I would not have succeeded, but yet I was working on plenty of high value, high starred projects.

That's just with the type of problem, asking someone to design a solution in isolation still doesn't give you signal on their collaborative skills (unless you think presentations are all that matter?).

What I think is better

I bet if you ask someone who's gone through interviews or given these this question, they might say the same thing: pair programming. Pair programming, specifically with a real world modeled problem, is the closest you'll get to seeing what a person is like to work with. Ideally, this would be a section where someone can work on the implementation themselves with maybe a shared slack channel to ask questions in, but doing it live over Zoom or in-person works as well. Doing this allows you to see how someone communicates, potentially their system design skills, and most of all – in a realistic manner. Now, I suggest this knowing it is a lot more time and energy up-front to design and possibly maintain these sets of problems, but I can't help but wish we as a industry were going this route more. For now, it seems like only startups are.