Tech Hiring: The Streetlight Effect

Programmers of a Certain Age

If you’re a software engineer of a certain age–working before the first dot com, let’s say–you might remember when software engineers were mere programmers. You might also remember that programming was a job and not a lifestyle. You weren’t in “tech,” you worked for the electric company, writing the code for their billing system. A pretty fun job, and a solid middle class living.

Regardless of what we call ourselves now, telling computers what to do remains a good way to earn money (for now, until the robots take over). A “tech” job is a ticket to the middle class or, depending on where you work and live, the upper middle class.

As a result, lots of people are out there trying to “break into tech.” At the same time, companies always seem to be hiring (even during these Unprecedented Times™️), often lamenting how hard it is to find “good talent.”

The Streetlight Effect

To recap: a bunch of places are trying to hire for jobs that a bunch of people want to do. And yet, these places find it difficult to fill the positions. I’m glossing over some nuance, but it’s pretty hard to see this situation as anything other than a problem companies have created for themselves.

There’s an old story about a drunk man who loses his keys in a park, yet searches for them under a streetlight, because that’s where the light is shining. It’s a decent metaphor for the current state of tech hiring. The light is shining on a limited number of people who went to particular schools, who work at certain companies, who are connected to the right people, or who meet some other easy-to-pattern-match criteria.

On the whole, companies don’t hire outside the boundaries of the streetlight. How strange that “innovators” straight-up ignore what seems like an obvious advantage: finding great people in places your competitors aren’t even looking.

The Old Days, Before Dot Com

So back to the pre-dot-com days of programming. There was no expectation that new hires would join the company fully formed and ready to commit code on day one. Aspiring software developers did not simply sit around in coffee shops training themselves on side projects, since laptops cost $3,000 and dial-up ruled the land.

Thus, companies had to invest in creating the workforce they wanted.

Nowadays, when someone rants about laundry-list job descriptions or multiple coding-style interviews, they’re often perceived as wanting to “lower the bar.”

It’s maddening. A lot of this perception is gatekeeping, but some of it is the result of a field that skews young and isn’t aware of its own history. Through many conversations, I’ve realized that people are so mired in the current status quo they genuinely can’t envision tech hiring in any other form. They don’t realize there was ever another way.

For that reason, here is the abbreviated process for how I “broke into tech,” just as one small example of another way to cultivate programming talent.

One Company’s Investment

Several months after graduating with an English degree, I got a programming job offer. It was from a consulting firm that hired people with sound logic and communication skills and onboarded them at a six week COBOL bootcamp in Boston.

The company paid us to go to bootcamp, not the other way around. They very sensibly decided that a good way to get COBOL programmers was to hire smart people and teach them to be COBOL programmers. As a bonus, the instructors also taught the company’s corporate ethos, molding us into just the kind of junior associates needed to round out project teams.

The training program wasn’t an act of kindness–it was an act of capitalism. The company invested in new employees and in return were able to put us on client projects for decent hourly rates. Trainees got good starting salaries and were able to learn on the job. We worked hard to prove ourselves, and our clients benefited.

Interview Process

This was the interview cycle:

  1. Conversation with a recruiter who asked about general skills and accomplishments; no expectation that those would be tech-related.
  2. Written communication test (can you convey ideas effectively).
  3. Written logic test (high-level, flowchart-type stuff).
  4. If the above went well, final interview with a partner.
  5. If the partner interview went well, candidates got a job offer, contingent upon passing a computer-based, multiple choice test of COBOL concepts. Company provided a book to study from and a place to practice.
  6. Once you passed the COBOL test, the offer was confirmed: you became an employee, and began six weeks of paid training.
  7. After training, you were assessed on two measures: a re-take of the COBOL test and the instructor’s appraisal of your ability to learn, communicate, and get work done.

Time to Revisit?

By no means were things perfect, and the program certainly wasn’t a gatekeeping-free utopia. There was a college degree requirement, for example. And having to spend six weeks training in Boston meant few caregivers could participate. And while there were many women, we were mostly white.

So the company’s hiring pool was smaller than it could have been, but it was much larger than the pool most places fish from today. They assessed for potential, employing hundreds, if not thousands, of people this way, proving that engineering is a teachable skill and is more than writing code.

Fix the broken bits, and this model would be a starting point for companies of a certain size to find the smart, talented people working their asses off for a shot at the jobs so many of us lucked into all those years ago.