Crackpots #30: Engineer Brain (Patreon)

Hello friends,

Yung Chomsky here. Today I’m going to talk about programming interviews, subcultures, and what it all means to you.

There have been some recent online flare-ups in a long-running debate around hiring processes in the software industry. These jobs have for some time been some of the last remaining positions to offer both high compensation and hiring criteria that are putatively based entirely on ability. In other words — in theory at least — you could land a software engineering job regardless of your background and pedigree, as long as you could demonstrate competence by passing a technical challenge. Since candidates are highly motivated to pass these interviews, companies seeking talent are similarly motivated to select for the best applicants by offering very challenging (and un-gameable) interviews.

Thus the rise of a particular style of interview that focuses on DSA questions. No, this doesn’t mean being quizzed on Robert’s Rules or the ideologies of various caucuses — it stands for Data Structures and Algorithms. This is colloquially referred to as a “Leetcode-style” interview, named for leetcode.com, a website that collects examples of these problems and provides an interface for practicing them. You can head over there to get a sense of what these kinds of questions look like.  Candidates will typically be required to solve these problems on a whiteboard during their interview, meaning they can’t run their code to test it for correctness, and can’t rely on any of the conveniences that coding on a computer provides; they’ll have to do it in a set time limit, in the presence of an interviewer; and they’ll have to talk through their solution, aiming to achieve the most optimal approach in terms of speed and resource usage. A final-round interview for a top tech company might involve several such live problem-solving sessions.

The common criticism leveled at Leetcode-style interviews is that they doesn’t resemble the day-to-day work of most software engineers; that they’re purely an academic exercise, or even akin to a hazing ritual; that rather than being indicative of how good someone will be at their job, these challenges only prove how good they are at test-taking. There’s a counter-argument similar to one I see made in regards to the SAT or other standardized tests: that these types of tests create a more meritocratic process than the alternative, because in their absence employers will be forced to rely on credentials, which are more closely tied to socioeconomic background.

I’m sympathetic to both sides of this debate. I didn’t study computer science, so while I was competent and confident after several years of job experience, I was completely unprepared to navigate Leetcode-style interviews when I first encountered them. I found these problems daunting and frustrating. But once I got over my frustration at the unfairness of it all and committed myself to studying, I found that these problems weren’t beyond my grasp; it was just a matter of unfamiliarity. I was eventually able to pass Leetcode-type interviews and get hired at a big company.

The latest flareup in this debate has happened due to the recent advancement of AI tools, particularly one developed by Roy Lee, the user being quote tweeted in the screenshot above. Roy developed a tool that allows candidates to receive undetectable AI assistance in remote coding interviews. Some have celebrated this development as the welcome death knell for the Leetcode approach to hiring; others were appalled at the normalization of cheating.

One argument that the pro-Leetcode side makes is that these problems aren’t meant to simulate the job duties, but rather act as a proxy for the type of thinking that a good software engineer is expected to have. Now, this may be easy for me to say, given that I was eventually able to pass the test when it mattered, but this is an argument that resonates with me. I think that at least some of what we tend to describe as intelligence is in fact about habits of mind, which are not innate, but learned. And I think that the habits of mind required to do well in a Leetcode interview, or to be an effective software engineer in general, have broader benefits well beyond the tech industry.

I’m not here to tell you that programmers are übermenschen, and that we should all do as they do. But I do want to use this as an opportunity to criticize a tendency that I’ve often seen among left-wing types towards “subculturism.” Subculturism is a term I’m using to describe the behaviors we engage in to locate ourselves within some particular cultural niche, particularly by rejecting signifiers and behaviors we associate with opposing niches. See also: countersignaling. As a contrived example: if I identify as a nerd, I might signal my enjoyment of things like sci-fi, board games, and anime, but also my rejection of interests I associate with jocks, whom I identify as my antagonists. So I can’t be interested in e.g. sports, because that’s enemy territory.

This shouldn’t come as a big surprise, because if we’re being honest with ourselves, the reality of the present moment is that the Western Left is a subculture. And so people who self-identify as leftists will tend to communicate that not only by signaling their embrace of left-wing ideals, but also (what they perceive to be) left-wing aesthetics; and further, by eschewing not only right-wing ideology, but also right-wing aesthetics, sometimes even including activities or habits that are only loosely connected to right-wing ideology, if at all.

If it’s not already apparent, I think this is generally a bad tendency, both on the macro level (i.e. the desire to see Left-wing movements succeed) and a micro one (i.e. the desire of an individual to be liberated and self-actualized). I think it’s bad for the Movement and bad for the Self to throw out tactics, tools, or even hobbies and modes of self-expression merely because we associate them with our opponents and are afraid of being mistaken for members of a different subculture. I’ve seen some deliberate rejections of this tendency; a certain segment of the Left has embraced firearms, for example, despite their association with the Right in the broader culture. But I think it still shows up in a lot of other ways.

There’s a quote from an interview with Andreas Malm, author of How to Blow Up a Pipeline, that I think succinctly speaks to part of what I’m getting at here:

Either we’re against political violence or not. We can’t say we’re for it when it’s something we care about and against it when it’s something we think is wrong.Of course we can. Why not?

That is moral hypocrisy.I disagree.

Why?The idea that if you object to your enemy’s use of a method, you therefore also have to reject your own use of this method would lead to absurd conclusions. The far right is very good at running electoral campaigns. Should we thereby conclude that we shouldn’t run electoral campaigns? This goes for political violence too, unless you’re a pacifist and you reject every form of political violence — that’s a reasonably coherent philosophical position. Slavery was a system of violence. The Haitian revolution was the violent overthrow of that system. It is never the case that you defeat an enemy by renouncing every kind of method that enemy is using.

This doesn’t mean we should give up on our ideological commitments, or our morals; but we shouldn’t rule out effective tactics for superficial reasons, and we shouldn’t tie ourselves into knots in order to better resemble the precise mirror opposite of our opponents. To give another simple example: I wear a Star of David necklace. It expresses part of my identity, and I like the way it looks. There are, unfortunately, many people wearing similar necklaces, or otherwise wielding that same symbol, who support the ongoing genocide in Palestine, among other things I abhor. It has sometimes crossed my mind that the sight of my necklace might make someone think I share that ideology. But that’s not going to make me stop wearing it; I ascribe a different meaning to the symbol, and I refuse to cede that territory.

As some of you may know, I worked as a software engineer for a few years before TrueAnon started, first in Philadelphia and then in San Francisco. I was very excited to get my first job — I studied hard and taught myself to code (and got very lucky). But by the time I left, I had become thoroughly disillusioned, for reasons that probably don’t need much explication to TrueAnon’s audience. Beyond the obvious ways that tech companies are reshaping our society for the worse, there’s a certain personality type that’s common in the field which draws well-deserved scorn. “Tech bro” is almost always a pejorative, and one of the traits I most associate with this stereotype is a certain smugness. This is perhaps the most distinctive characteristic of what I think of as “engineer brain;” the tendency of someone with high ability in one intellectual domain to demonstrate undeserved confidence in others.

Someone suffering from engineer brain tends to value (their) thought experiments and a priori knowledge over (others’) real experience. It’s not hard to see why this type of thinking can be an asset in the world of software. Software systems can reasonably be expected to have documentation which lays out their rules. The rules may be complex, but they are well defined, deterministic; thus if one simply studies the rules sufficiently, they will be able to understand all states of the system.Those afflicted with engineer brain are thus prone to mistaking the map for the territory. Nassim Nicholas Taleb coined the term ludic fallacy to describe “the mistake of using the rules and principles of games to understand real-life situations,” which seems fitting here.

But this discussion about the merits of leetcoding got me thinking about the positive lessons I took away from my time as a professional coder, a few of which I’ll lay out here. Mind you, this is not to say that learning to code is the only way to come by these skills, or that all software engineers excel in these areas, or that STEM is somehow generally superior to the humanities. It’s more that I think that there are traits selected for habits encouraged in successful engineering organizations that can be less common in other fields, and that we shouldn’t let our resentment towards the flaws and abuses of the tech industry lead us to reject its lessons when they can be of use.

In a Leetcode-style situation, one common strategy is to break a large, complex problem into smaller sub-problems. In computer science, the term for this is decomposition. This approach can also apply to design, or more creative tasks — instead of focusing on the desired end result as a whole, focus instead on building smaller pieces that link together. This is a useful strategy any time we have to operate under pressure, like in an interview, or when we’re up against a deadline, or when the task before us feels so large that it becomes overwhelming and kills our motivation. Don’t think about cleaning your whole house, just focus on cleaning your bathroom. Don’t get hung up on writing a novel; just think about one chapter, or one page. Don’t beat yourself up about creating the perfect end result; just get a first draft done. Don’t stress about writing an essay for TrueAnon’s Crackpots newsletter; just write a paragraph. 

In 1945, the mathematician George Pólya published a book called How to Solve It. He was describing methods for solving math problems, some quite similar to the ones that would eventually show up in Leetcode and software interviews, but the mental model he prescribes can be applied more broadly.

He writes that we should solve problems in four steps:

Understand the problem

Make a plan

Carry out the plan

Look back on your work

This may seem simple and obvious, but I regularly need to remind myself not to skip the first two steps. When presented with a problem, I have a habit of being over eager to jump right into solving it. Sometimes this works out, but just as often it leads either to a dead-end, or an inefficient solution. Trying to solve a problem without first understanding it and making a plan is a great way to paint yourself into a corner — figuratively or literally. It’s also a common social faux pas; we hear a friend or loved one expressing pain or frustration, and our first instinct is to offer advice or solve their problem for them, when what they really want is just to be understood.

Relatedly, an often-expressed frustration of individuals working within large organizations — tech companies or otherwise — is the slow pace of progress caused by bureaucracy. This is easy to intuitively understand, especially for those of us who were brought up on the ideas of free enterprise, personal agency, individualism, and Great Man Theory. If I have a great idea, why should I need anyone’s permission to pursue it? Why should I sacrifice speed of execution by seeking approvals and signoffs? But we often fail to see how the same processes that hinder us in the short term can also help us in the long, by providing a structure to our work. It’s easy to get lost in the weeds of a problem when we dive in without first defining a clear plan. And even if the seemingly cumbersome rules don’t directly benefit me, the guy with the great idea, they may still be valuable; as the saying goes, regulations are written in blood.

Contra the above, tech bros in recent years have become fond of the mantra “you can just do things.” And despite the associations with the current usage of this phrase, which is often deployed to cover for reckless or unethical business practices, there is also a valuable lesson in it. I’ve known many creative people who exist in a prolonged state of lament over their inability to bring their projects to fruition because (so they think) they lack the necessary funding, or the right equipment, or the proper assistance. But they’re certain that once they get those things, they’ll be able to finally bring their masterpiece to life and their talents will be recognized. I understand this mindset because I used to get stuck in it, too. And it’s not without basis; making art can be expensive, and some projects require collaboration, and it’s a herculean task to do anything creative when you’re struggling to keep a roof over your head and food on the table. But you can still just do things. Don’t wait to get a record deal, or to find the perfect writing partner, or to afford a fancy camera, or to get booked on a prestigious stage. Make something now, even if it ends up less polished or complex or ambitious than you wish it were. Even if it never finds an audience or makes you a dime, making things is how you get better at making things.

“Minimum viable product” (MVP) is a term I learned about in the software industry. It refers to the smallest, simplest version of an idea that’s functional and usable. There’s an analogy a former colleague introduced me to almost a decade ago that’s stuck with me — it seems like it may have been popularized by Henrik Kniberg. He talks about conceiving of an MVP as the “skateboard version.” His analogy goes like this: Your goal is to build a car, so you decide to break the large problem down into smaller problems. One way to do that would be to build the car piece by piece; you might start with the engine, then add the suspension, the tires, the body, and the steering wheel, until you have the car. But the problem with this approach is that none of the intermediate stages are useful in themselves; there’s no functionality until the very final stage. The alternate approach is to first understand that while the goal is to build a car, the implicit problem is how to get from one place to another, and the first task is to build the simplest, most barebones version of the goal that still addresses this problem. So the first thing we build is a skateboard. It’s not much like a car, but they both have wheels, and the skateboard is immediately useful for getting somewhere, unlike a bare engine. Then after you’ve built the skateboard, you can build more complex versions of your wheeled vehicle: a bicycle, a motorcycle, and finally a car. This isn’t the right approach for every situation — sometimes it’s better to wait until you have a finished, polished product before releasing anything. But it’s a valuable one to have in the toolbox.

Here’s an example that will really test your ability to separate the principle from the context (apologies in advance):

If you have a healthy sense of disgust, reading that may have made you recoil. But the underlying concept is worth considering. What do we do when things go wrong in our work, our creative endeavors, or our personal relationships? Do we get angry and argue about who’s to blame? Do we solve the problem by punishing the responsible party? Or do we simply bury our resentment and move on, trying to forget it happened? Yudkowsky uses the phrase “no-fault analysis;” the one I’m used to hearing is “blameless post-mortem.” This could come up in a situation where e.g. your B2B SaaS has a massive server outage, angering your customers and hurting your revenue. Or maybe you’re a podcast producer and you fail to cut a segment where one of the hosts is quoting a particularly steamy passage from their work-in-progress erotic novel before uploading it to the public. Or maybe you’re on an overseas trip with your significant other, and you misread the itinerary and miss your return flight (something that happened to me many years ago).

First, you solve the immediate problem. Put out the fire. Bring the server back up. Re-edit the episode. Book a new flight. Then go over what happened, not in order to figure out who to punish, but how to learn from it, to improve your process so it doesn’t happen again. This is, of course, easier said than done. It doesn’t have to be businesslike and clinical — I think it’s about compassion, recognizing that we’re all fallible humans, and we’re all working to get better even though we know we’ll never be perfect.

So the next time you hear one of the worst people in the world — or maybe just someone you find personally repellent — say something, ask yourself whether they might have a point. You could find inspiration where you least expected it.