On Grifters In Tech and the Dunning-Kruger Effect: A message to entry-level Web developers.
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 (almost always) unreasonable and (almost always) unfounded.
I’ll tell you why.
First, it is extremely unusual 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 is extremely unlikely 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, unglamorous 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 organizations 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.
By the way: we gave you the HTML and CSS of a Web page plus a JPEG that showed what the page should look like when you were done. It was not a trick question, it really was just moving a div.
We came up with that interview question by hiring someone who actually could not do this (move a div from the left side to the right side of the page), and then having to fire them on the grounds they couldn’t perform the responsibilities listed in the job description. I was not present for the firing discussion but I suspect we paid this person 2 weeks’ severance and that the official reason for the firing was much more “it’s not you, it’s us” than the truth. It’s tricky to fire people without triggering a lawsuit, especially so recently after they have been hired.
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.
Once I even heard a rumor of a class you could take that would prepare you to lie your way through a programming interview. I have not been able to verify that, 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.
Typically, a year’s worth of paper trail has to be laid in order to fire someone for cause without triggering a wrongful termination lawsuit. Also it can look bad for the hiring manager, who might not feel like they have the political capital to survive the hit to their image that (in many organizations) comes with admitting you made a major hiring mistake.
Plus, the grifter may have made some powerful friends while you were laying the paper trail. You have to do your job. The grifter has nothing but time, which they can use to do all the political maneuvering they want.
Grifters also may find ways of creating a convincing impression that they are delivering, even though they aren’t. Taking credit for someone else’s work is not all that hard, especially if the person who did the work has now left the team or the company.
Regardless of motivated (or not) the grifter turns out to be, a lot of teams are overworked; many to the point of near burnout. Laying a paper trail takes time and consistency which are scarce resources in a lot of software shops. Grifters know all this and they know how to leverage it.
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 post is aimed at 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…
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 are 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.
Now, based on years of talking to them and reading their posts, 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
Entry-level developers, you are 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 once worked with a very senior architect who outright rejected the idea of logging application errors. It didn’t make any sense to him when I suggested it and it took my explaining in I think five meetings over the course of A YEAR before he finally accepted the idea.
Even at that point, the directive to log all application errors went into a memo which, last I heard, is still largely ignored because apparently he wasn’t the only senior person on that team who wasn’t sold on the value of a basic best practice: error logging. Meanwhile (since I’m in QA) I can certify that it was extremely difficult to debug production errors throughout that stack.
That architect had been at that 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 immediately familiar with every aspect of application logging.
But why did he never get any better at it?
The Dunning-Kruger effect is why.
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 in my experience 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 diligently.
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 foodservice and retail, where if you don’t listen carefully you get fired fast. And also I was trying to learn to be a better software developer.
Listening is the key difference between a so-so Web developer and a great Web developer.
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. In fact I think what I have said goes a great way toward 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.
