How the Other Half Works: an Adventure in the Low Status of Software Engineers


Bill (not his real name, and I’ve fuzzed some details to protect his identity) is a software engineer on the East Coast, who, at the time (between 2011 and 2014) of this story, had recently turned 30 and wanted to see if he could enter a higher weight class on the job market. In order to best assess this, he applied to two different levels of position at roughly equivalent companies: same size, same level of prestige, same U.S. city on the West Coast. To one company, he applied as a Senior Software Engineer. To the other, he applied for VP of Data Science.

Bill had been a Wall Street quant and had “Vice President” in his title, noting that VP is a mid-level and often not managerial position in an investment bank. His current title was Staff Software Engineer, which was roughly Director-equivalent. He’d taught a couple of courses and mentored a few interns, but he’d never been an official manager. So he came to me for advice on how to appear more “managerial” for the VP-level application.

The Experiment

His first question was what it would take to get “managerial experience” in his next job. I was at a loss, when it comes to direct experience, so my first thought was, “Fake it till you make it”. Looking at his résumé, the “experiment” formed in my mind. Could I make Bill, a strong but not exceptional data-scientist-slash-software-engineer, over into a manager? The first bit of good news was that we didn’t have to change much. Bill’s Vice President title (from the bank) could be kept as-is, and changing Staff Software Engineer to Director didn’t feel dishonest, because it was a lateral tweak. If anything, that’s a demotion because engineering ladders are so much harder to climb, in dual-track technology companies, than management ladders.

Everything in Bill’s “management résumé” was close enough to true that few would consider it unethical. We upgraded his social status and management-culture credibility– as one must, and is expected to, do in that world– but not his technical credentials. We turned technical leadership into “real”, power-to-fire leadership, but that was the only material change. We spent hours making sure we weren’t really lying, as neither Bill nor I was keen on damaging Bill’s career to carry out this experiment, and because the integrity of the experiment required it.

In fact, we kept the management résumé quite technical. Bill’s experience was mostly as implementor, and we wanted to stay truthful about that. I’ll get to the results of the experiment later on, but there were two positive side effects of his self-rebranding, as a “manager who implemented”. The first is that, because he didn’t have to get his hands dirty as a manager, he got a lot of praise for doing things that would just have been doing his job if he were a managed person. Second, and related to the first but far more powerful, is that he no longer had to excuse himself for menial projects or periods of low technical activity. As opposed to, “I was put on a crappy project”, which projects low status, his story evolved into “No one else could do it, so I had to get my hands dirty”, which is a high-status, managerial excuse for spending 6 months on an otherwise career-killing project. Instead of having to explain why he didn’t manage to get top-quality project allocation, as one would ask an engineer, he was able to give a truthful account of what he did but, because he didn’t have to do this gritty work, it made him look like a hero rather than a zero.

What was that project? It’s actually relevant to this story. Bill was maintaining a piece of old legacy code that took 40,000 lines to perform what is essentially a logistic regression. The reason for this custom module to exist, as opposed to using modern statistical software instead, was that a variety of requirements had come in from the business over the years, and while almost none of these custom tweaks were mathematically relevant, they all had to be included in the source code, and the program was on the brink of collapsing under the weight of its own complexity. These projects are career death for engineers, because one doesn’t learn transferrable skills by doing them, and because maintenance slogs don’t have a well-defined end or “point of victory”. For Bill’s technical résumé, we had to make this crappy maintenance project seem like real machine learning. (Do we call it a “single-layer neural network”? Do we call the nonsensical requirements “cutting-edge feature engineering”?) For his management résumé, the truth sufficed: “oversaw maintenance of a business-critical legacy module”.

In fact, one could argue that Bill’s management résumé, while less truthful on-paper, was more honest and ethical. Yes, we inflated his social status and gave him managerial titles. However, we didn’t have to inflate his technical accomplishments, or list technologies that he’d barely touched under his “Skills” section, to make a case for him. After a certain age, selling yourself as an engineer tends to require (excluding those in top-notch R&D departments or open-allocation shops) that you (a) only work on the fun stuff, rather than the career-killing dreck, and play the political games that requires, (b) mislead future employers about the quality of your work experience, or (c) spend a large portion of your time on side projects, which usually turns into a combination of (a) and (b).

Was this experiment ethical? I would say that it was. When people ask me if they should fudge their career histories or résumés, I always say this: it’s OK to fix prior social status because one’s present state (abilities, talents) is fully consistent with the altered past. It’s like formally changing a house’s address from 13 to 11 before selling it to a superstitious buyer: the fact being erased is that it was once called “13″, one that will never matter for any purpose or cause material harm to anyone. On the other hand, lying about skills is ethically wrong (it’s job fraud, because another person is deceived into making decisions that are inconsistent with the actual present state, and that are possibly harmful in that context) and detrimental, in the long term, to the person doing it. While I think it’s usually a bad idea to do so, I don’t really have a moral problem with people fudging dates or improving titles on their résumés, insofar as they’re lying about prior social status (a deception as old as humanity itself) rather than hard currencies like skills and abilities.

Now, let’s talk about how the experiment turned out.

Interview A: as Software Engineer

Bill faced five hour-long technical interviews. Three went well. One was so-so, because it focused on implementation details of the JVM, and Bill’s experience was almost entirely in C++, with a bit of hobbyist OCaml. The last interview sounds pretty hellish. It was with the VP of Data Science, Bill’s prospective boss, who showed up 20 minutes late and presented him with one of those interview questions where there’s “one right answer” that took months, if not years, of in-house trial and error to discover. It was one of those “I’m going to prove that I’m smarter than you” interviews.

In the post-mortem, I told Bill not to sweat that last interview. Often, companies will present a candidate with an unsolved or hard-to-solve problem and don’t expect a full solution in an hour. I was wrong on that count.

I know people at Company A, so I was able to get a sense of how things went down. Bill’s feedback was: 3 positive, 1 neutral, and 1 negative, exactly as might have been expected from his own account. Most damning were the VP’s comments: “good for another role, but not on my team“. Apparently the VP was incensed that he had to spend 39 and a half minutes talking to someone without a PhD and, because Bill didn’t have the advanced degree, the only way that that VP would have considered him good enough to join would be if he could reverse-engineer the firm’s “secret sauce” in 40 minutes, which I don’t think anyone could.

Let’s recap this. Bill passed three of his five interviews with flying colors. One of the interviewers, a few months later, tried to recruit Bill to his own startup. The fourth interview was so-so, because he wasn’t a Java expert, but came out neutral. The fifth, he failed because he didn’t know the in-house Golden Algorithm that took years of work to discover. When I asked that VP/Data Science directly why he didn’t hire Bill (and he did not know that I knew Bill, nor about this experiment) the response I got was “We need people who can hit the ground running.” Apparently, there’s only a “talent shortage” when startup people are trying to scam the government into changing immigration policy. The undertone of this is that “we don’t invest in people”.

Or, for a point that I’ll come back to, software engineers lack the social status necessary to make others invest in them.

Interview B: as Data Science manager.

A couple weeks later, Bill interviewed at a roughly equivalent company for the VP-level position, reporting directly to the CTO.

Worth noting is that we did nothing to make Bill more technically impressive than for Company A. If anything, we made his technical story more honest, by modestly inflating his social status while telling a “straight shooter” story for his technical experience. We didn’t have to cover up periods of low technical activity; that he was a manager, alone, sufficed to explain those away.

Bill faced four interviews, and while the questions were behavioral and would be “hard” for many technical people, he found them rather easy to answer with composure. I gave him the Golden Answer, which is to revert to “There’s always a trade-off between wanting to do the work yourself, and knowing when to delegate.” It presents one as having managerial social status (the ability to delegate) but also a diligent interest in, and respect for, the work. It can be adapted to pretty much any “behavioral” interview question.

As a 6-foot-1, white male of better-than-average looks, Bill looked like an executive and the work we did appears to have paid off. In each of those interviews, it only took 10 minutes before Bill was the interviewer. By presenting himself as a manager, and looking the part, he just had an easier playing field than a lifelong engineer would ever get. Instead of being a programmer auditioning to sling code, he was already “part of the club” (management) and just engaging in a two-way discussion, as equals, on whether he was going to join that particular section of the club.

Bill passed. Unlike for a typical engineering position, there were no reference checks. The CEO said, “We know you’re a good guy, and we want to move fast on you”. As opposed tot he 7-day exploding offers typically served to engineers, Bill had 2 months in which to make his decision. He got a fourth week of vacation without even having to ask for it, and genuine equity (about 75% of a year’s salary vesting each year).

I sat in when Bill called to ask about relocation and, honestly, this is where I expected the deal to fall apart. Relocation is where so many offers fall to pieces. It’s a true test of whether a company actually sees someone as a key player, or is just trying to plug a hole with a warm body. The CEO began by saying, “Before getting into details, we are a startup…”

This was a company with over 100 employees, so not really a startup, but I’m going to set that aside for now. I was bracing for the “oh, shit” moment, because “we’re a startup” is usually a precursor to very bad news.

“… so we’ll cover the moving costs and two months of temporary housing, and a $10,000 airfare budget to see any family out East, but we can’t do loss-on-sale for the house, and we can’t cover realtor fees.”

Bill was getting an apology because the CEO couldn’t afford a full executive relocation workup. (“We’re just not there yet.”) For a software engineer, “relocation” is usually some shitty $3,000 lump-sum package, because “software engineer”, to executives, means “22-year-old clueless male with few possessions, and with free storage of the parental category”. On the other hand, if you’re a manager, you might be seen as a real human being with actual concerns about relocating to another part of the country.

It was really interesting, as I listened in, to see how different things are once you’re “in the club”. The CEO talked to Bill as an equal, not as a paternalistic, bullshitting, “this is good for your career” authority figure. There was a tone of equality that a software engineer would never get from the CEO of a 100-person tech company.


Bill has a superhuman memory and took a lot of notes after each interview, so there was plenty to analyze about this sociological experiment. It taught me a lot. At Company A, Bill was applying for a Senior Engineer position and his perceived “fit” seemed to start at 90. (Only 90, for his lack of PhD and Stanford pedigree.) But everything he didn’t know was points off. No experience with Spring and Struts? Minus 5. Not familiar with the firm’s Golden Algorithm? Not a real “data scientist”; minus 8. No Hadoop experience? Minus 6. Bill was judged on what he didn’t know– on how much work it would take to get him up to speed and have him serving as a reliable corporate subordinate.

Company B showed a different experience entirely. Bill started at 70, but everything he knew was a bonus. He could speak intelligently about logistic regression and maximum likelihood methods? Plus 5. He’s actually implemented them? Plus 6. He knows about OCaml? Plus 5. Everything he knew counted in his favor. I’d argue that he probably scored these “points” for irrelevant “interesting person” details, like his travel.

When a programmer gets to a certain age, she knows a lot of stuff. But there’s a ton of stuff she doesn’t know, as well, because no one can know even a fraction of everything that’s going on in this industry. It’s far better, unless you’re applying for a junior position, to start at 70 and get credit for everything you do know, than to start at 90 (or even 100) and get debited for the things you don’t know.

This whole issue is about more than what one knows and doesn’t know about technology. As programmers, we’re used to picking up new skills. It’s something we’re good at (even if penny-shaving businessmen hate the idea of training us). This is all about social status, and why status is so fucking important when one is playing the work game– far more important than being loyal or competent or dedicated.

Low and high status aren’t about being liked or disliked. Some people are liked but have low status, and some people are disliked but retain high status. In general, it’s more useful and important to have high status at work than to be well-liked. It’s obviously best to have both, but well-liked low-status people get crap projects and never advance. Disliked high-status people, at worst, get severance. As Machiavelli said, “it is far safer to be feared than loved if you cannot be both.” People’s likes and dislikes change with the seasons, but a high-status person is more unlikely to have others act against his interests.

Moreover, if you have low social status, people will eventually find reasons to dislike you unless you continually sacrifice yourself in order to be liked, and even that strategy runs out of time. At high social status, they’ll find reasons to like you. At low status, your flaws are given prime focus and your assets, while acknowledged, dismissed as unimportant or countered with “yes, buts” which turn any positive trait into a negative. (“Yes, he’s good in Clojure, but he’s might be one of those dynamic-typing cowboy coders!” “Yes, he’s good in Haskell, but that means he’s one of those static-typing hard-asses.” “Yes, he’s a good programmer, but he doesn’t seem like a team player.”) When you have low status, your best strategy is to be invisible and unremarkable, because even good distinctions will hurt you. You want to keep your slate ultra-clean and wait for mean-reversion to drift you into middling status, at which point being well-liked can assist you and, over some time– and it happens glacially– bring you upper-middle or high status.

When you have high status, it’s the reverse. Instead of fighting to keep your slate blank, it’s actually to your benefit to have things (good things) written about you on it. People will exaggerate your good traits and ignore the bad ones (unless they are egregious or dangerous). You start at 70 and people start looking for ways to give you the other 30 points.

The Passion of the Programmer

I’ve always felt that programmers had an undeserved low social status, and the experiment above supports that claim. Obviously, these are anecdotes rather than data, but I think that we can start to give a technical definition to the low social status of “software engineers”.

Whether programmers are over- or underpaid usually gets into debates about economics and market conditions and, because those variables fluctuate and can’t be measured precisely enough, the “are programmers (under|over)-paid?” debate usually ends up coming down to subjective feelings rather than anything technical. Using this technical notion of status– whether a person’s flaws or positive traits are given focus– we have the tools to assess the social status of programmers without comparing their salaries and work conditions to what we feel they “deserve”. If you are in a position where people emphasize your flaws and overlook your achievements, you have low social status (even if you make $200,000 per year, which only means efforts to cut your job will come faster). If the opposite is true, you have high social status.

Using this lens, the case for the low social status of the programmer could not be any clearer. We’ll never agree on a “platonically correct” “fair value” for an engineer’s salary. What can see is that technologists’ achievements are usually under-reported by the businesses in which they work, while their mistakes are highlighted. I’ve worked in a company where the first thing said to me about a person was the production outage he caused 4 years ago, when he was an intern. (Why is nothing said about the manager who let an intern cause an outage? Because that manager was a high status person.) A big part of the problem is that programmers are constantly trying to one-up each other (see: feigned surprise) and prove their superior knowledge, drive, and intelligence. From the outside (that is, from the vantage point of the business operators we work for) these pissing contests make all sides look stupid and deficient. By lowering each others’ status so reliably, and when little to nothing is at stake, programmers lower their status as a group.

There was a time, perhaps 20 years gone by now, when the Valley was different. Engineers ran the show. Technologists helped each other. Programmers worked in R&D environments with high levels of autonomy and encouragement. To paraphrase from one R&D shop’s internal slogan, bad ideas were good and good ideas were great. Silicon Valley was an underdog, a sideshow, an Ellis Island for misfits and led by “sheepdogs” intent on keeping mainstream MBA culture (which would destroy the creative capacity of that industry, for good) away. That period ended. San Francisco joined the “paper belt” (to use Balaji Srinivasan’s term) cities of Boston, New York, Washington and Los Angeles. Venture capital became Hollywood for Ugly People. The Valley became a victim of its own success. Bay Area landlords made it big. Fail-outs from MBA-culture strongholds like McKinsey and Goldman Sachs found a less competitive arena in which they could boss nerds around with impunity; if you weren’t good enough to make MD at the bank, you went West to become a VC-funded Founder. The one group of people that didn’t win out in this new Valley order were software engineers. Housing costs went up far faster than their salaries, and they were gradually moved from being partners in innovation to being implementors’ of well-connected MBA-culture fail-outs’ shitty ideas. That’s where we are now.

So what happened? Was it inevitable that the Valley’s new wealth would attract malefactors, or could this have been prevented? I actually think that it could have been stopped, knowing what we know now. Would it be possible to replicate the Valley’s success in another geographical area (or, perhaps, in a fully distributed technical subculture) without losing our status and autonomy once the money spotted it and came in? I think so, but it’ll take another article to explain both the theoretical reasons why we can hold advantage, and the practical strategies for keeping the game fair, and on our terms. That’s a large topic, and it goes far beyond what I intend to do in this article.

The loss of status is a sad thing, because technology is our home turf. We understand computers and software and the mathematical underpinnings of those, and our MBA-culture colonizers don’t. We ought to have the advantage and retain high status, but fail at doing so. Why? There are two reasons, and they’re related to each other.

The first is that we lack “sheep dogs”. A sheep dog, in this sense, is a pugnacious and potentially vicious person who protects the good. A sheep dog drives away predators and protects the herd. Sheep dogs don’t start fights, but they end many– on their terms. Programmers don’t like to “get political”, and they dislike it even when their own kind become involved in office politics, and the result is that we don’t have many sheep dogs guarding us from the MBA-culture wolves. People who learn the skills necessary to protect the good, far too often, end up on the other side.

The second is that we allow “passion” to be used against us. When we like our work, we let it be known. We work extremely hard. That has two negative side effects. The first is that we don’t like our work and put in a half-assed effort like everyone else, it shows. Executives generally have the political aplomb not to show whether they enjoy what they’re doing, except to people they trust with that bit of information. Programmers, on the other hand, make it too obvious how they feel about their work. This means the happy ones don’t get the raises and promotions they deserve (because they’re working so hard) because management sees no need to reward them, and that the unhappy ones stand out to aggressive management as potential “performance issues”. The second is that we allow this “passion” to be used against us. Not to be passionate is almost a crime, especially in startups. We’re not allowed to treat it as “just a job” and put forward above-normal effort only when given above-normal consideration. We’re not allowed to “get political” and protect ourselves, or protect others, because we’re supposed to be so damn “passionate” that we’d do this work for free.

What most of us don’t realize is that this culture of mandatory “passion” lowers our social status, because it encourages us to work unreasonably hard and irrespective of conditions. The fastest way to lose social status is to show acceptance of low social status. For example, programmers often make the mistake of overworking when understaffed, and this is a terrible idea. (“Those execs don’t believe in us, so let’s show them up by… working overtime on something they own!”) To do this validates the low status of the group that allows it to be understaffed.

Executives, a more savvy sort, lose passion when denied the advancement or consideration they feel they deserve. They’re not obnoxious about this attitude, but they don’t try to cover it up, either. They’re not going to give a real effort to a project or company that acts against their own interests or lowers their own social status. They won’t negotiate against themselves by being “passionate”, either. They want to be seen as supremely competent, but not sacrificial. That’s the difference between them and us. Executives are out for themselves and relatively open about the fact. Programmers, on the other hand, heroize some of the stupidest forms of self-sacrifice: the person who delivers a project (sacrificing weekends) anyway, after it was cancelled; or the person who moves to San Francisco without relocation because he “really believes in” a product that he can’t even describe coherently, and that he’ll end up owning 0.05% of.

What executives understand, almost intuitively, is reciprocity. They give favors to earn favors, but avoid self-sacrifice. They won’t fall into “love of the craft” delusions when “the craft” doesn’t love them back. They’re not afraid to “get political”, because they realize that work is mostly politics. The only people who can afford to be apolitical or “above the fray”, after all, are the solid political winners. But until one is in that camp, one simply cannot afford to take that delusion on.

If programmers want to be taken seriously, and we should be taken seriously and we certainly should want this, we’re going to have to take stock of our compromised position and fix it, even if that’s “getting political”. We’re going to have to stop glorifying pointless self-sacrifice for what is ultimately someone else’s business transaction, and start asserting ourselves and our values.

49 thoughts on “How the Other Half Works: an Adventure in the Low Status of Software Engineers”

  1. Its fairly uncommon, if not rare, for 30-and-under-year-olds to even find their first job in software engineering (which is why the contemporary Silicon Valley is mostly devoid of under-35 American citizens!). So no big surprise that this quite uncommon individual is facing a huge uphill battle in finding a position that ordinarily would go to a 40 or 50-year-old. Yes, age discrimination is alive and well in tech, and its most often against the young, that’s for sure.

    The way that techies are treated in the job market is disgusting. Seriously, 5 one-hour interviews? We don’t take a dog or cat to a doctor, and ask them to do a physical exam on it to prove a doctor’s medical skills before we subject ourselves to such. Why do employers feel comfortable doing effectively the same on software engineering talent? Do the employers not realize that they’re alienating talent big-time by doing this?

    • >Yes, age discrimination is alive and well in tech, and its most often against the young, that’s for sure.

      No. From what I observed in San Francisco for the last 2 years, it’s hard to find anyone working in tech over 35 who is still an engineer. Most contemporary startups and corporations want fresh out of college graduates, because they are the easiest to abuse (pathetic relocation, entry-level compensation, easier to force overtime without wife/kids).

      >Do the employers not realize that they’re alienating talent big-time by doing this?

      Perhaps that is the goal. To them, engineers are mere pawns who should work on managements’ terms, and the interview is effectively selecting for obsequiousness and partly to show who’s boss (throwing impossible/deceptive interview questions). They blame their hiring processes on a mythical “talent shortage” when they cannot find willing slaves.

      • Here’s how I feel when Silicon Valley assholes complain about a “talent shortage”: link.

        There is, after all, a “shortage” of supermodels willing to fuck unemployed, 350-pound men. Those who perceive shortage should audit what they have to offer.

        What do the engineers in San Francisco do when they hit 35? Leave? Become consultants?

        • >What do the engineers in San Francisco do when they hit 35? Leave? Become consultants?

          Most of the 30-somethings either transition to a management role or get out. Also the game is in favor of whoever can hastily put together web apps with the latest trendy technologies, so 10 years of low-level programming experience won’t help much in that regard.

          • But there aren’t many 20-somethings, never mind early 30-somethings that are citizens even in the industry. This is why the H-1B is pushed so hard, it effectively saves the SV tech firms severance when they do the “up or out” game with the workforce. After all, only a small fraction of the workforce can be managers, and the complimentary roles (tech support, sales, IT, QA, etc.) for engineers have significantly been outsourced, crowdsourced, or have disappeared altogether.

        • Well there hasn’t been hiring of domestic talent under 35, so not a lot of domestic engineers in SF actually will hit 35 as engineers. Basically if you got in before the 2001 collapse, chances are, you’ll be working till you retire. Most post-2001 graduates haven’t even been able to find positions. As for what the currently working under-35′ers will do — most likely just pack up and go back to wherever they came from (India, Europe) when they’re no longer of extreme use to the employers.

        • There are plenty of programmers well over 30 still employed.

          You rarely find them at trendy startups working 90 hour weeks. But the banks, insurance companies, defence contractors, utilities, and of course mature technology companies, employ programmers by the thousands, even in San Francisco and Silicon Valley.

      • I haven’t seen any of this in SF or even the South Bay. Practically devoid of under-35 engineers, and the associated trappings of youth. I know a few big brand-name companies might make a big deal of employing a few young people, particularly in the social media space, but the core of most firms doing real engineering (and not the fluffery) seems to be in the 35-50-year-old range.

      • “Most contemporary startups and corporations want fresh out of college graduates,”

        Really? I haven’t seen this. But what I’ve seen is startups and corporations ‘demanding’ 5-10 years of ‘experience’ for mere entry-level positions that actually get staffed with citizens. A few youngsters win the lottery and get hired, but even if you look at the graduation employment stats out of Berkeley CS or CS/EE, they’re abysmal.

        For H-1B’s, its often a different story, they’re hired young, but they often lie through their teeth about their qualifications.

        • I’m not sure why our experience would be so different, but mine is quite the opposite. I don’t work in the Valley, but did work for Google for about 7 years, and spent a lot of time out there. There were *lots* of engineers under 35 at Google, and anecdotally plenty at other Valley companies I met through friends. I was actually pleasantly surprised to see plenty of engineers well *over* 35 while working there as well. I’m not certain how closely the distribution there tracked that of the overall population, but if anything it was skewed somewhat toward the younger side.

        • I mean, there’s selection bias here, because I’m 25 and most of my friends are around my age bracket, but every company I know has tons of young people, and is constantly trying to hire. We have 5 hour interviews and complain about lack of talent because people show up who don’t know what a hash map is or how it can be used to improve performance of your code, or people who can’t read a code snippet and give a general overview of what it’s doing.

        • As a recent undergrad from Berkeley EECS, I’d say at least half of my graduating class found work immediately, or were offered full-time positions even before graduation. I may certainly be wrong about this but it feels like Silicon Valley is very hungry for college graduates.

        • Just curious Mark, are you based in SV? My experience is exactly opposite. And as for H1-B perhaps consultants slinging sql code in the midwest may be gaming the system but most H1s here are typically US educated.

      • >Perhaps that is the goal. To them, engineers are mere pawns who should work on managements’ terms, and the interview is effectively selecting for obsequiousness and partly to show who’s boss (throwing impossible/deceptive interview questions). They blame their hiring processes on a mythical “talent shortage” when they cannot find willing slaves.

        That is the most wrong outlook on an interview I have ever seen. Interviews are about seeing what your metal is. What the logic is, “If I can find someone who can come up with the equivalent of Godel’s Theorems on their own in 15 minutes, then I know I have a star. Otherwise, I’ll see how well people do against a tough question.”

        If you set the bar low, you won’t know much if everyone jumps over it. If you set it high, you’re pushing people to their limits and knowing what they’re about.

        And people who talk about a “talent shortage” either A) don’t want to pay for it (which is expected on management’s part) or B) don’t know what they’re looking for. It’s not because there’s a conspiracy and looking down on engineers.

        • I feel like the dislike for difficult interviews is misplaced. Personally, I like them. I’m not going to get all the right answers, but I have an edge over 99+ percent of the population. I’m not going to complain about mentally difficult problems. Companies *should* care about general problem-solving skills.

          What I don’t like is when there are flat-out unreasonable expectations or (much more common) when the interviews are biased in favor of a narrow set of experiences. Algorithms are fair game. But I don’t think it’s reasonable to be docked because I haven’t seen the particular web framework that a specific company uses.

          The reason I point this out is that, as manager, you get the “you’ll have time to figure it out” pass. As a programmer, you get the “we need people who can hit the ground running” nonsense.

    • I’ve only see the reverse of this, older engineers are considered fossils. In the last 5 years out of 75+ programmers I’ve worked with, maybe two of them were over 40. I’ll agree that age discrimination is alive and well, but you seem to be seeing the opposite of what I’m seeing. (I’m in Colorado, not San Fransisco).

      The trend I’m seeing worries me because as I get older I could have more trouble keeping a steady programming job. I’m starting to consider how to move into management, just to keep a salary in the future, even though I’d rather write code.

  2. “At low status, your flaws are given prime focus and your assets, while acknowledged, dismissed as unimportant” this is the exact description of my latest performance review. All good work went unnoticed, but every itsy-bitsy issue inflated as much as possible.

    • In many cases, I feel like that’s the institutional point of performance reviews (aside from intimidation and papering over terminations). Pointing out minor mistakes is a status assertion, and that’s what they usually devolve into. It’s a reminder (to both manager and managed) that the boss is boss, because most middle managers are conflicted about the “boss” role (for an organization that is, for one in the outer but not inner party, increasingly hard to believe in) and the power relationship needs reinforcement.

      • When the resume queue contains a hundred resumes, often highly qualified, its quite easy for bosses to be arrogant and behave badly. That’s why any claims of a talent shortage in the tech sector needs to be taken with a grain of salt.

        • Meh. Hiring is hard. Figuring out whether someone is going to work out well is hard. If you choose wrong you can cost your department a lot of time and money, and can cause yourself serious repercussions.

          People want to hire the perfect person, and I don’t blame them for that per se. But in practice what that means is that they turn down 90% of people, many of them who are perfectly qualified but who don’t INTERVIEW WELL (which is just as hard a skill to learn as any other, and much harder for some people than others) and then complain of a shortage of qualified candidates.

          What we really have is a shortage of people who are capable of assessing candidates with any kind of ability.

          • There’s the rub. As a hiring manager I know what the job requires but when I started in my role I had precious little experience when it came ti pulling out the information that would indicate a good employee. Conversely a trained HR professional may be able to find the “quality” candidate but never seem to really know what the job requires even through I had to have them vet the candidate posting. These days when I need to fill a position I reach out to my contacts. From that group I can usually find a good fit or at least a good reference.

          • “What we really have is a shortage of people who are capable of assessing candidates with any kind of ability.” – I thought that the article was great until i read this. Probably the most insightful comment of all.

            • The comment is a cop out.

              Hiring a bad manager can cause just as many problems as hiring a bad software developer. And we don’t have any foolproof way of hiring amazing managers.

              With that in mind why do we pass on developers who are 90% perfect for the role?

              Because we have low status.

              It is doubly stupid because I have never met a developer (or person really) without flaws. So we just end up hiring people with similar flaws to us and hiring people who can hide their flaws well.

      • This is certainly my observation, at least for ambitious managers who feel uncertain of their own status.

        Better managers actually take their “coach” role more seriously.

        And when it starts to happen, there is usually no recovery.

        Sometimes you can outlast a bad manager. Sometimes you can transfer. Sometimes you can just put up with it. Often the only solution is to find a new job.

        Outlasting usually makes sense for a job where firings are rare, such as civil service, or one of the rare employment for life companies.

  3. I think you failed to see why these career-killing legacy maintenance projects exist in the first place. Contrary to popular opinion, executives are not that stupid not to realize that 6 man months spent on a measly linear regression is a waste of money that could have found their way into their pockets. The real reason behind these projects is getting free work on the stuff that matters.

    In some less prosperous places, in order to save what’s left of their careers, engineers go to their superiors after work and ask to work for free on projects that can help them have employment prospects after 40. Clojure programmers are too expensive? No problem, keep a lot of Java AbstractVisitorSingletonFactoryFactory code around and you will get your new projects done in Clojure for free.

    You said that companies have trouble finding out who the good programmers are. You are wrong, this is their method. This doesn’t happen in the USA yet because you still have some minimal amount of status? Just wait a few more years…

    • I’m not sure that I buy this argument. I like its hyper-cynicism, but (a) I don’t think corporate executives are that organized, and (b) that strategy’s not going to work very well. I’m sure some middle managers use the crappy legacy projects as props to play power games, but I don’t think it’s common.

      Legacy nightmares exist because of scope creep. Executives get more visibility and political support by allowing more people to throw requirements on the project, but the end result is design-by-committee and incoherence. It’s not that they’re too stupid to realize that the projects are waste. It’s that they don’t care about the long-term viability of the project, and are willing to sacrifice it to have more friends (and attract more requirements, to the detriment of programmer and product).

      • I’ll tell you what happened in my area: a few years ago, everyone was crazy about mobile development, Android and iOS. Every programmer was learning these new technologies hoping to get out of enterprise Java roles. After a few months all mobile development positions disappeared from the job boards and never appeared again. It made no sense, especially considering the fact that everyone and their mother wants an app now.

        It all comes down to status: how would you convince a low status programmer to do overtime when he knows that he’ll get better status and pay by learning mobile development? Not doing mobile is out of the question as the stakeholders demand it. The answer is to make this type of work unpaid and force him to go through an extremely low status period that few people can tolerate. It’s a win for executives as they get their best people doing the important projects for free.

        I think you find this hard to believe because in the US tech hubs people are not yet desperate enough to work for free. Today you can go to data science interviews and however absurd the requirements are, you can still hope that you’ll eventually make it. Maybe you learn statistics in your spare time to get a better shot at them. You’ll see how well this strategy works the day all data science opportunities vanish into thin air.

  4. Michael,

    Have you ever thought of a career as a Headhunter? You seem well suited for it and this article details very well how you would go about the job.

    You could conceivably find good companies with good practices that you could help find great candidates. You could try to be the change you want to see in the Software Industry.

    But, this is just an offhand suggestion. It up to you to choose what you do. I just wanted to say your insights into the industry are very interesting and very spot on.

  5. Imagine getting invited to speak at some prestigious or semi-prestigious conference. You prepare your speech, slides, pick out your best suit, make sure to look and appear your best. You fly in, check into your hotel, step up to the podium, and start speaking. One rotten tomato flies by, smacks your slide. A few minutes later, someone from the audience tells you to “Shut the fuck up, homo!”, and another screams “Yeah, you’re gay!” The audience chuckles. It gets louder and louder, and the tomatoes keep flying, but you persist, stumbling through your words. The audience is having a grand time. Maybe the organizer of the conference steps up to calm everyone down, but then asks you some difficult algorithm question which has nothing to do with your talk. You answer correctly, and he’s shocked and a little disturbed that you didn’t struggle enough with the question – Oh my god, you’re too smart, you made the boss look bad! He calls security, and you are thrown into the parking lot, with everyone cheering as you leave. Your hotel and rental car have been cancelled – and one of the guards took your wallet, and you’re halfway across the country, good luck getting home.

    What did you do wrong? Nothing, except for mistaking the true purpose of the conference. People didn’t give a flying fuck about you or what you had to say, because they don’t do much of anything themselves, and why would they need your help to do nothing? The problem is that if they do anything beyond the bare minimum, the boss will call security and throw them out, because they exposed the lie: people aren’t there to work, or build good products, or innovate, or even make a company more profitable. They’re there to make the boss feel important. Your humiliation is nothing more than a ritual to distract everyone from this depressing truth.

    And that’s the adolescent nature of software interviews. In some cases, adolescent behavior is not even metaphorical: one time, my team made an applicant (a grad student) cry, and laughed hysterically about it. Always, team members would talk about the *unbelievably stupid* answers that developers with 20 years’ experience would give – which, actually, were right, but unexpected and not taken from the textbook (don’t EVER try to be original in these interviews!). We even had an MIT EE/CS Ph.D. who was discouraged *from even interviewing* because they didn’t have the requisite language (even though they had several others), but we got to say, “We reject MIT and Stanford Ph.D.’s because our people are THAT smart!”

    But then you looked at the big picture … did they produce anything? Well, everyone on my team who produced anything was dragged into a PIP and encouraged quit – they showed that others on the team were doing the bare minimum, and had to go. Credit for the accomplishment was then given to the boss’ favorites.

    It’s easy to spot such jobs, you can almost smell them. Do your interviewers dress in ratty t-shirts and torn-up jeans, yet have a stiff, judgmental, slightly frightened posture? Do they say, “oh, it’s no big deal if you don’t know this” – it never is, by the way – not knowing something is the kiss of death in these situations. Do they brag about the people they rejected? Do they overplay what they’re doing, say they’re “changing the world” or “creating a revolution”? Is the salary low but the office is spotless and littered with infantilizing nerfballs and arcade machines? Then yes, you’re applying to one of those jobs. As they say in the movie “War Games”, the only way to win is not to play. Stick to modest jobs in small companies with limited and clearly stated ambitions – you trade glamor for sanity.

      • I was intending to show, in this imaginary scenario, that many interviews are like the above-described scenario, and the “homophobic comments” were put there to describe the juvenile attitude of the audience. Read more carefully.

        • Or, much like I did, start your own company and ask the applicants the “right” questions while keeping the office spotless yet full of software and hardware 😉. In one of my previous jobs, my direct manager was literally abusing my skills in order to grow his own career. I knew it, but being the son of a poor plumber, I had no choice but to entertain his needs. Until one day I was put in a situation whereby my work was so obvious, he could not deny – by any chance – it was me all the way. That resulted in, you guessed wrong – in me leaving the company.

          What are we supposed to do in order to turn the table upside down? Those living in “High” status and do absolutely nothing with their hands vs. us, who are DIY smart people and they are financially beating us? I don’t think that going defensive or offensive would do us any good. Instead, we should analyze what’s moving others and try to circumvent the problem.

  6. Surely there must be some company out there exploiting this disconnect by luring the best and brightest software engineers away from the companies that aren’t treating them well.

    Presumably there are N-more “Bills” with similar skill sets who will also not get offered a job at tech company X, despite the fact that he would be allow for an extremely positive ROI. So who will hire them? If there are companies that can recognize them, it follows that ends up being a significant competitive advantage, no?

    Is the problem that we (in the industry sense) still have no clue on how to evaluate/interview/compensate software engineers?

  7. I got a job out of college as an SDE with Amazon. I’ve been working for a year. What should I do to keep myself out of the holes this article and these comments are bringing up?

  8. Everything you described about software engineering could very well have applied to chip design in and out of the valley. Unlike software engineering, chip design has had its day in the sun and it has collapsed into a shadow of its former self because of its success (perhaps).

    Engineers, of many sorts, don’t really help each other as they consider it a race against other engineers, as you mention. Engineers believe that they can change the world (ie. their passion) and they get little for that. But it goes a bit farther than you might believe. Engineers managing engineers at any level very easily adapt their corporate ‘review’ practices to what you describe rather than support their colleagues. And as the growth of any engineering field slows, first ones in throw the rest overboard. Note that the folks that control things almost never move.

    Engineering should have a real professional organization. Something beyond ACM or IEEE. While these groups improve the discipline over which they stand, they do very little to help the rank and file. Could you imagine a professional medical or law organization doing as little for the little guy as do IEEE and ACM. Maybe more like a plumbers’ union.

    Or at least a course in the engineering curriculum describing just what you wrote about and perhaps what to do about it.

    Thx. Good experiment. Good observations.

  9. Just want to say I really enjoyed this. I love the comments about the sheep-dog mentality. We have a few of these types of managers at Sailpoint and it’s what has set this org apart for me. Thanks for the write-up.

  10. > these pissing contests make all sides look stupid and deficient

    Pissing contest over not only tech skills, but also social skills. “Your coding is horrible and you are more awkward than I am!”

    The atmosphere can be sort of like Mean Girls and Tina Fey’s character’s line comes to mind.

  11. Pingback: How the Other Half Works: an Adventure in the Low Status of … | COPY SOFT
  12. Serious question. What did Bill use to find these two unrelated job openings?

    More generally, what do people think are the best places to find job openings? I assume it is different for purely technical roles vs. management-track ones?

    • I’m not sure. I knew that he was trying to go into management and he mentioned the VP-level role, and that’s what got the experiment into my head.

      If you can find jobs through referrals, that’s usually best. Elite headhunters are next. Typically, the jobs that end up on job boards are the picked-over (but sometime there’s a diamond in the rough.)

      • Thanks. Referral -> Headhunter -> Job Board was my understanding of the pecking order, but I’m always open to new data.

  13. I would certainly take issue with the statment that altering one’s resume to give the impression that one has more experience in management than they really do is not dishonest. But there are other issues with this “experiment”. Two data points is far too few to make conclusions regarding hiring practices in general. As someone who has done a lot of interviews over the past year, I can tell you there is a wide variety in terms of how companies interview candidates. I’ve seen high prestige companies make offers after only a short hour long interview, and I’ve seen lower prestige companies put perspective employees through an insane amount of process and still reject qualified candidates.
    And if a company is asking about struts in their interview, I highly doubt they are that sophisticated.

    • “I would certainly take issue with the statment that altering one’s resume to give the impression that one has more experience in management than they really do is not dishonest”

      Sure, but nobody has done that. Changing your title to better reflect the terminology used by a different company is not dishonest. Nor is it dishonest to change your title on your resume to better reflect what you actually have done.

      At my workplace we use the title software developer to encompass tech leads, architecture, devops, junior developers, senior developers, and product management (but not project or people management).

      If I’m doing product management then putting it on my resume is more accurate and less dishonest than putting “Software Engineer” just because that is my official title.

  14. Thanks for a really fascinating and well thought through article. Resonates a lot with my experiences in the UK. What can we do to strengthen the position of developers? I’ve always personally tried to steer well clear of office politics, but maybe that’s a delusion:- if the tradeoffs being made affect you then you need to stand up.