The rules of the game
Discover more from Normcore Tech
The rules of the game
How do you become a Senior Person in Tech?
My husband and I have finally started watching Queen’s Gambit on Netflix, making us officially the last people on the face of this earth to do so. It’s amazing what a phenomenon this show has been.
But, if you’re a Normcore reader, you probably were not so surprised.
There’s a lot to dissect in the show, including, very importantly:
But, one of the things that struck me most about the show came in the first or second episode, when Beth Harmon enters her first chess match. She comes up to the table to register. The guys doing registration there ask her if she has a clock.
“Clock?” she says, puzzled.
When you play in chess tournaments, you play the game with a clock so that games don’t take 8 hours, like they used to back in the old days.
The chess clock continued to evolve, and in 1900, it reached what we now recognize as the classic form of the chess clock and the type used in The Queen's Gambit: two dials, with a button for each player which, when pressed, stops their clock and starts their opponent's.
She doesn’t know any of the rules when she starts. She just knows how to play chess as she’s been taught by the janitor in the basement and is hungry to win. And that proves to be enough in the beginning: she beats the pants off almost everyone she encounters in her astronomical and troubled ascent to the top of the game.
As we were watching the show and various characters kept cluing Beth into the norms of the chess world, I was thinking a lot about this idea that someone can be enthusiastic, smart, eager, and understand at a basic level what’s going on, but still get tripped up on technicalities. And, if no one tells them what the important parts are, they’ll kind of flounder along.
Of course, I was thinking about how this applies to the tech world, and, more specifically to the tech interview process.
Everyone knows tech interviewing is broken - there have been millions of posts on this phenomenon. White board interviews are bad and take-home interivews are bad, Zoom interviews are bad and written inteviews are bad and GitHub interviews are bad.
Or rather, they all optimize for very different things. This is partiuclarly true in the data sphere, where job descriptions are still pretty new and fluctuate very frequently.
I was thinking about all of this as I re-read Dan Abramov’s ( a very prominent developer on the React team at Facebook) post about things he didn’t know as of 2018.
First, there is often an unrealistic expectation that an experienced engineer knows every technology in their field. Have you seen a “learning roadmap” that consists of a hundred libraries and tools? It’s useful — but intimidating.
What’s more, no matter how experienced you get, you may still find yourself switching between feeling capable, inadequate (“Impostor syndrome”), and overconfident (“Dunning–Kruger effect”). It depends on your environment, job, personality, teammates, mental state, time of day, and so on.
Some of these struck me as pretty crazy. For example, I’d probably expect someone who’s a senior developer to have a good intuition for bash and the command line (his first bullet), I’d expect someone working at Facebook to be really good at algorithms, and of course, I just naturally assume that everyone knows Python, the best language.
But my assumptions are all based on this monolithc view of what a “senior” person is, built up from observing senior people around me, reading dozens of job ads, going on interviews, and reading conversations online about it. If you ask ten other people what being senior means, they’ll probably tell you something different. We might overlap in 2 or 3 areas and then branch off.
The thing is, even though there is one way to get to Grandmaster, there is no one single way to interview and become a senior developer or data scientist. The difference with the tech world is that there is not one single set of rules like there is in a chess game: everyone is playing on a different board, with an ever-growing number of pieces.
As I’ve written, this was not the case a while ago,
The early years of programming were mainly focused on moving from this really physical programming infrastructure, of writing bits of logic on punchcards and running them through enormous machines, with the first programming language being assembly, the language that horrified Ullman so much. Assembly is very close to bytecode.
As the machines became smaller and more accessible, more programming languages came about. By the late 1980s or early 1990s, when Ullman was well into her career, your average programmer might know, in addition to assembler, COBOL, SQL, Fortran, and maybe the newcomer, C.
In a lot of ways, the world was much smaller and less complex. We didn’t even have version control!
But it now is, and all of our interview processes mostly try to take into account this given accumulated set of skills. We don’t do anything to assess for some of the most important qualities, the ones that get Beth started: intuitiveness, desire, enthusiasm, and generally ease of working with the person (unfortunately, Beth would fail that test quite a lot.)
In short, in a lot of the industry, we don’t look for this, a lot of the time, because, in the growing set of skills, this is the only one that generalizes:
And we should be.
What I’m reading lately:
What’s a book you’d like to read but hasn’t been written yet?
The Newsletter:
This newsletter’s M.O. is takes on tech news that are rooted in humanism, nuance, context, rationality, and a little fun. It goes out once or twice a week. If you like it, forward it to friends and tell them to subscribe!
The Author:
I’m a machine learning engineer. Most of my free time is spent wrangling a kindergartner and a toddler, reading, and writing bad tweets. Find out more here or follow me on Twitter.
The rules of the game
would suggest dropping the credential requirement if you’re serious
Oh my. So true. Great article Vicki and I love the comparison with chess!