There's always discourse (on twitter, reddit, HN etc) about hiring, JDs, interview processes etc. Mostly about how it all sucks (which is true to various degrees).
My colleague left (_1_ day after his probation ended; I was _unhappy_) and I got to write his replacement's JD. I've become increasingly aware over the last few years of the implicit and explicit bias in tech hiring, and vowed that if I was ever in a position to do something about it, I would.
Since I've got a BA, not a CS or EE degree, I've always felt like I didn't quite fit in in the industry. This, despite having 2y of CS and Physics in my BA where I wound up majoring in Maths and Modern History. For a long time I put myself in with the "non-traditional entry to tech" pool.
After leaving Oracle in 2019 I talked with AWS and GCP recruiters, who all emphasized questions on CS theory, recommended specific study guides for their interview processes... which I read .. and I still couldn't answer their questions. They made me feel incompetent so I eventually stopped responding to them.
At that point I'd been a successful Solaris kernel engineer for many years. I learnt good software engineering theory and practice from some of the giants in the industry. Just as important, perhaps even more so, though, was the _culture_ I imbided. I'll ramble on about that some other time.
In q3 2019 I had an interview with a different FAANG-like entity. It took seven hours, and I thought I got out lightly. There were three questions in that time which got me mad. One was from a ~3y PhD who asked why I hadn't written a Python generator (had not had a need too). The second was from a former CS prof, who was disgusted that I had never implemented a thread stack.
Him: How can you call yourself a software engineer if you've never implemented a thread stack?
Me: In the Unix kernel space, that's a solved problem. And solved by people who are much smarter than me.
(We then spent the rest of the hour-long session whiteboarding (ugh) stacks with queues and vice versa).
Seriously - I've met and worked with some of the people who worked on threading in the Solaris kernel. They are incredibly smart and excellent engineers. More importantly to me, though, they showed me both how and why the implementation worked. Never in a "I'm so smart" fashion, but always matter-of-fact, "I worked it out, I need to know that you can do it too".
The third question was from one of the overseas members of the panel, who after expressing horror that I didn't know how the internals of Apache Spark worked, demanded that I size - off the cuff - an ElasticSearch-based solution to a text-processing problem that they had just described to me. Including how much ram, how many cores, how much disk and network capacity..... I told the interviewer (and, later, the hiring manager who asked me for feedback on the whole process) that I didn't think that was a reasonable question under any circumstance.
Anyway.
After than FAANG-like entity I wound up at my current employer. I had two interviews, one with hiring manager and team lead, the other with the rest of the team. Rather than the torture session I anticipated, these were two very pleasant discussions. We talked about what they did, what I'd done, got to know each other. When I met the wider team via zoom on my first day (we were in lockdown so that was my only day in an office for another 4-5 months) my Director started the meeting by welcoming me and asking me for a short intro. I was delighted and relieved to discover that the people I'd interviewed with were representative of the rest of the org.
A few months after I started we got some interns via a bootcamp called Coder Academy, and I was asked to be their onboarding buddy. We had lots of sessions in their six weeks, talked about anything and everything, and I was truly delighted when my boss announced on their last day of interning that we'd hired them as employees.
These three (two in my team, one in an adjacent team) people brought home to me just how much I knew, and how much of what they wanted to know I had learnt in my two years of CS - three decades previously. What's that I hear? The claim that you _must_ have a degree in order to succeed in this industry? Utter tosh. Bollocks. A complete lie. These three (and this is my personal experiences, I'm not alone here - check twitter!) demonstrate that there is more than one pathway in to tech, and no singular definition of success.
Back to job descriptions.
My and my colleague's JD's were not wordsmithed. They were also chock full of "must have" and specific tech stack references. I've been in this role for seven and a half months now, but even in my first week I knew that general principles, an inquisitive nature and a desire to make this SCALE were more important than any particular piece of "do you have this certified piece of knowledge right now".
I spent maybe two hours re-writing the piece. I asked a very good friend (ht @girlgerms) for help and she gave me an excellent phrase to use, which was along these lines:
Your work history should show that you are already skilled in, or have the ability to quickly become skilled in these areas
With this way of expressing our needs, it was a fairly small jump to using the indirect language of "generic technology space, we're using (X)" to round out the requirements:
- Data Pipeline Technologies such as (but not limited to):
Apache Kafka, including Confluent or Aiven’s managed offerings
Relational Databases and SQL. We primarily use PostgreSQL and MS SQL
Containerisation
In my part of the company we're gearing up for a hiring spree, and my group (I've been reorg'd into another team) needs two "data devs", one Java dev, a business analyst and a product manager. Several other groups within our org are also down at least one, sometimes two developers - so there's a lot of activity right now around writing job descriptions. In the first two weeks of April I spent several hours with my new manager working on wordsmithing our requirements, putting a lot of effort into removing language that we believe actively discourages people who do not look like us (we fit the stereotype) from applying for these roles.
Just before Easter the manager of another team within our org sent an operations-focused JD around for comment, and it was ... ok. Ok in that it asked for specific tech and a degree, but that was about it. This JD fit the stereotype, and it was meh in the 90s, it's definitely not good enough now, 20+ years later.
I suggested he change some of the language, focus on principles rather than specific tech, and entirely remove mention of requiring a degree. Yesterday afternoon he pinged wanting a bit of clarification so I went into more detail, and I am delighted that his second draft (again, sent to our Director and our peers) did just that. There's still some wordsmithing required, but overall it's a much better document.
Yesterday morning I had a chat with our org's Recruiting Partner about my former colleague's replacement. He clued me in on a few of the vagaries of recruiting, which was really helpful, and then we talked about interviewing. He was relieved to hear that I flat out refuse to do whiteboarding, live coding or leetcode - for myself, and for candidates. He also asked me why any candidate would want to work with me on my team. I admitted that I hadn't thought of an answer for that question - but I came up with something that I think is an ok platform to build a better answer on. By the time I get to interview any candidate I'll have worked on it a lot more :).
That's enough rambling and self-aggrandizement. Time to wrap this up.
I'm now in a position where I get to directly and formally influence how my company presents itself to potential employees. I do not believe that there is a candidate "pipeline problem" - there are plenty of candidates out there who could fill any of the roles that we have, _we_ have to make ourselves attractive so that they'll consider us in the first place. _How_ we do that starts with what we write, and for too long (waay too long) our industry has been focused on some specific hiring language and practices which are both implicitly and explicity exclusive. I want that to change, so I'm making changes.