Thread by @noahsussman

I said I would write more about breaking into a dev role so here goes.

One of the things that absolutely destroys entry-level programming applicants is the fear that they won't be able to do "the job" once hired.

This fear is unreasonable and unfounded and I'll tell you why.

https://twitter.com/noahsussman/status/1170147370820149248

First, it is extremely unusual (ime it never happens!) for an entry-level developer to be hired and then placed in charge of some kind of complex high-risk project.

You're going to be the most junior and the most recent hire. You're not going to be in charge of *anything.*

There are just tons of jokes about how programming interviews are like "show on the whiteboard that the Traveling Salesman problem is at least NP Hard" and then after hire it's like "move this button 3px left."

They're funny because THIS IS 100% TRUE.

Programmer job postings and interview questions are contrived. Meaning we get to just pull things out of our collective asses. There is no upper bound on how demanding an interview can be! They can be really tough!!

However. Once hired you will be building a Web application.

While interviews can be as challenging as the team chooses to make them, there is a very hard upper bound on how complex a Web application can actually be.

You may have already encountered some of the gigabytes of literature about how software complexity destroys products.

In other words: during the interview you are at the mercy of nerds who can just make up whatever shit they want to challenge you.

Once hired you will *only* be working on problems that are significantly below that threshold of complexity where products start to implode.

So even if the team gave you their hardest problem on your first day (which they won't because you're the most junior and most recent hire) it would not be as difficult or complex as most of the problems you hear about people being asked in job interviews.

The vast majority of the code in your average Web application is NOT hairy algorithms that run the core business. Getting the UI, middle tier and back end to communicate properly requires a huge amount of code and that's almost definitely what you're going to be working on.

Additionally since you are the most recent hire (regardless of your seniority) it's unlikely your team will trust you with a tricky problem that involves the whole stack. Instead they are going to give you the simple, unglamourous tasks that more senior people find boring.

In fact it is extremely likely that you will find yourself living one of those programming interview jokes: moving all the "add to cart" buttons 3 pixels to the left is actually the kind of task that Web sites require, all the time.

This is one of the reasons we all say programming interviews are fucked 💩

During the interview process you are at the mercy of a bunch of nerds who love complexity and try to foist it on you at every turn.

After hire you and the other nerds have to move buttons 3px left.

The fairest programming interview I ever administered to candidates was a take-home test that did in fact ask you to move an element from one side of the page to the other. It was a perfect filter for talent and we got some of the best devs I ever worked with.

But that's not all

The org with the "move this column from the left to the right" take-home test was one of the first orgs that put me in the interview loop. I was shocked, completely dumbfounded, to find that THE VAST MAJORITY OF CANDIDATES COULD NOT COMPLETE THE TASK.

They could not move a div.

So now we get to talk about something they won't tell you in boot camp, and that a lot of mentors won't tell you either (because they either don't know or don't want to know).

A huge number of programming job applicants cannot program. At all.

I have heard repeatedly that there are classes you can take that will prepare you to lie your way through a programming interview. I have not been able to verify this but I have personally interviewed dozens of non-programmers who presented as *senior* engineers.

Whether or not there really is a cottage industry in training non-developers to fake their way into dev roles, it is for sure the case that this world contains many grifters. And it is the case that tech is a field known to be full of sensitive, socially challenged people.

I can certify from 20 years' personal experience that tech interviews attract grifters who will say anything they think they need to say in order to secure a dev job, even though they can't program at all. Once hired it's a tricky HR problem to get rid of them and they know this.

As a result of grifters knowing they can often talk their way through tech interviews, it is common to find programmers and tech leads who cannot program. At all. And who do not produce *anything.*

The bar is so much lower than you think it is. Pathetically low in fact.

I could (but I won't) name several people currently in senior dev or teach lead roles in NYC, who I have worked with and who I know for a fact cannot (or just do not) write code. They are generally charismatic, well-spoken, and they never deliver. Anything.

A few years ago a company I was consulting with hired a VP of Eng. *After* he was hired he mentioned he'd worked with me years before. I asked around and found that yeah, this is that manager that [redacted] had to fire back in the day because he promised but he never delivered.

Sure enough, he never delivered anything. He was at every meeting, he was on every call. He checked in with me every week to get my updates and estimates. And that was it.

The CTO spoke to him about it. Many times. Over the course of A YEAR.

Where is that VP of Eng. now you ask?

This thread is for people new to tech so I'll assume that YOU assume 😀 he suffered some kind of consequence.

Was he placed on the tech blacklist, which surely is a thing that exists?

LOL.

LOL I say to you. LOL.

Last time I checked, this serial grifter, who had *just* been fired for never-delivering-anything-over-the-course-of-an-entire-year… was in an executive role at one of the most recognizable and respected IT consulting agencies in the *world.*

This is one example out of dozens.

So the serial grifter with a string of VP of Eng. titles is an extreme (but common, so common) example of how the bar is lower than you think it is.

But grifters are not the end of the story.

Now let us speak of the Dunning-Kruger effect…

en.wikipedia.org/wiki/Dunning%E…

I said above, and many others have said, that many programming interview questions are at a level of difficulty and complexity far beyond what is required to run a Web application day-to-day.

But why. Why is it so?

Dunning-Kruger is a common reason.

How does the Dunning-Kruger effect relate to superfluous complexity in programming interviews?

Welp. There's engineers out there who truly believe they're doing a much more sophisticated job than they actually are doing. Which is after all what "Dunning-Kruger effect" means.

From talking to them, it seems one of the most common fears among those trying to get their first dev role is something like:

- I won't understand what's going on

- Everyone will think I'm stupid

- I won't be able to come up to speed fast enough

You're assuming A LOT here.

The biggest assumption you are making is that everyone on your new team will have a level of expertise commensurate with both their title and the number of years they have in the field.

You think this because you aren't yet taking the Dunning-Kruger effect into account.

I recently worked with a very senior architect who had never heard of the idea of logging application errors. It didn't make any sense to him when I suggested it and it took I think *five* meetings over the course of A YEAR before he finally accepted the idea.

This architect had been at the company for quite a few years. When he was hired he was fairly junior and it would have been acceptable for him to not be immediatley familiar with every aspect of application logging.

But he never got any better at it. Why?

Dunning-Kruger.

You see, engineers affected by Dunning-Kruger do not learn, because they think they already know everything.

They remain stuck at a relatively junior level of knowledge throughout their careers (barring some kind of awakening of self-awareness, which ime rarely occurs).

How, you might ask, could an engineer remain at a "fairly junior level of knowledge" and survive in the industry? It is because the Web is not particularly sophisticated as computing technologies go.

You can cruise along knowing a little bit and bossing others around and be fine

So it's not at all the case that on your first dev gig you're going to be the least knowledgeable person on your new team. You might be the most knowledgable! After all, you're the one that's been studying all the newest stuff and practicing it dilligently.

Another aspect of Dunning-Kruger is people affected by it tend to take their own advice a lot.

You, new to the field and to your role, will likely be listening *very* carefully to everyone around you.

Web programming is a lot more about listening to people than it is about code

When I had hardly any experience, people in management praised my dev skills. At the time it fed my impostor syndrome 😞 couldn't they see I was JUNIOR?? Surely they *would* soon see and then I'd be In Trouble.

But in fact they were right: I was the best listener on the team.

I think one reason I listened so well was that I'd come from a "career" in food service and retail, where if you don't listen carefully you get fired fast. And also I was trying to learn to be a better dev.

Listening is *the* difference between a so-so Web dev and a great Webdev

The Web is not, in fact, about technology. The Web is a medium through which people connect and get things done. It does not matter how smart your code is if it enables people to do the wrong thing or to do something they didn't want.

Listening is the differentiator, not code.

A focus on listening-over-coding could even help you in the interview.

I know that if a candidate deeply groks my requirements and mission, I'll push back very hard against objections to hiring them based on technical deficiencies.

I can train anyone to code.

I cannot train anyone (so far) to be a great listener and to think deeply and understand the requirements of myself, my bosses and my stakeholders.

I'll take a good listener who bombs on the whiteboard over an arrogant technical wizard every time.

I would ask you, the entry-level dev, to take a big step back and review your interactions with more senior developers. Especially those where you were completely overwhelmed by the complexities.

Could you have encountered someone who had Dunning-Kruger? Can you rule it out?

The best engineers are not only good at listening but they are good at explaining as well.

If you have been overwhelmed and intimidated by a senior engineer please consider the Dunning-Kruger effect. It's likely that person knows less than they think they do. A lot less.

One of the unfortunate things about being a very senior engineer is that you have to ask other engineers to explain themselves and often you find they can't do it. Often you find that they don't even know the meaning of the words they are using. It is a common occurrence.

Am I cutting on my fellow engineers at this point? Am I putting them down?

I don't think so. What I have said simply by way of explaining the observed state of tech, where legacy code is rampant, data breaches are common and syntax errors regularly take down million dollar sites

As an entry-level dev you are entering a field that is rife with grifters who pretend to know what they are doing, and people affected by Dunning-Kruger, who think they know what they are doing but don't.

You'll be the most junior but not the lowest skilled. That title is taken.

At this point you may be asking: what the fuck? How can this happen? How can it be the case that the bar to being a decent Web developer is so low?

There are some popular theories.

First consider startups. These are expected to fail. 10 out of 11 startups do not succeed, on average. So if a startup hires a senior engineer who doesn't care or doesn't know enough to keep it afloat, and it tanks, that is *normal.* It won't raise any flags.

Now consider large orgs. These have hired many devs over time and so on average their chance of having hired a grifter or a Dunning-Kruger sufferer, is high.

If the leader of a group does not care or does not know enough to keep their team afloat, they can lean on other teams.

Finally consider that Web orgs are corporations first. Shareholder value is the primary concern, not customer satisfaction and certainly not code quality. A shady or an underskilled engineer can be forgiven a lot as long as they make everyone look good in front of shareholders.

To sum up: as an entry-level dev applying for your first job you probably believe that you are entering a shining utopia of smart people doing Hard Things.

You are not.

You are applying for a better-paying job in a field that is just as fucked up as the field you are leaving.

*tech lead

There is no such thing as the tech blacklist. You know that episode of Silicon Valley season 1 where they hire the brilliant hacker and it turns out he's screwed up a bunch of gigs but no one wanted to admit it because it would be admitting they hired someone bad? Not fiction.

To be clear: people keep blacklists. But those are personal or factional and never made public.

What do I mean by factional? I mean if you hate me, then the people who hate *you* will not respect your blacklist. Tech is like this.

Blacklists are never made public because again to quote a not-fictional line from Silicon Valley, in tech we believe that "failure is contagious."

It's considered paramount to maintain the illusion that everyone in tech is smart and talented.