“If software engineering is so in demand, why is it so hard to get a software engineering job?”, PART II
Answer: It is because the job title is prestigious, the salaries are relatively high, and a lot of people are willing to fight each other for that
At 202,000 views, this post is still the blog’s most popular by far, continuing to get more traffic than everything else I have written every week — my CodeSignal post is one of the first weeks I have had in a long time where a new blog post outperformed this one. Why did an article called “If software engineering is so in demand, then why is it so hard…” get so popular? I still do not know, but if I deleted every single blog post I had here and only kept that, I would still be getting about as much attention on this account as I had before.
I have had a few months to think things over. Here, I wanted to provide a (hopefully) more thorough response to everything I wrote in the original article. After all, I had no idea people would scrutinize it so much.
The Introduction
I wrote this in the introduction:
In all seriousness, though, the response about economics is worth discussing. Job pay is heavily influenced by supply and demand. While there is a very high demand for software engineers, there are now 4.4 million software developers in the United States alone [Edited. The original sentence said “4.4 million software engineers”].
This was the source, but I think I got it wrong…and there was an entire Reddit thread dedicated entirely to debating the statistic. So we have this source which is more official and claims there are 1.47 million software engineers in the United States.
That was a mistake, and I acknowledge it.
Other Reasons the Process is Hard
Other than the title, this was the part of the article people cited the most. I described technical coding interviews as “their own game,” went on about the broadness of the field, and then vented about how you can use a programming language the interviewer is not familiar with. A very popular tech YouTube channel titled a video the exact same thing as my article, then read off these points almost verbatim without acknowledging me at all…but I have already written about this.
A more mature response would have been that this process is not hard for everyone, it is just hard for some of us. And there is a little more variety than that. Some companies do not do coding interviews. Some companies use take-home challenges. And yes, as with all things, there are going to be the hated ones who can effortlessly pass through these sorts of hurdles.
Here is a consolidated everything resource.
The Next Two Sections Were Supposed to be a Joke
It just so happens that this article was true, along with the anecdotes, and that was a huge relief. I was worried people would call me out for saying something that was not true, as Curt Corginia was originally just supposed to be a parody account. I was disappointed more people did not laugh at the website link at the bottom. I made a fake company website on April 1, then wanted this account for little more than writing fake corporate media. Then I read a book by Sonmez, and he encouraged us to blog consistently. I thought an article like this was too embarrassing to put next to my real name, so I had Curt Corginia publish it.
I got so many followers overnight that this became my most popular account.
All of this is to say that the sections on HR and the behavioral interviews were more tongue-in-cheek than serious. You can find way better advice in other places.
Okay…fine…if you want serious advice on the behavioral interview, I am not sure I can provide it. These are extremely subjective and I am not sure how well I perform on them. I do find that I can often pass them, but I have never received feedback on them.
Professional experience goes a long way. I get to talk about projects that are impactful and interesting.
The Weird Hashmap Story
I had a job interview. They asked me this.
I had no idea how to solve it. I tried coding without first talking it out, and that was my first mistake. Then I decided to use a hashmap, which made no sense, and then pivoted without a section break and talked about this problem. The anagram coding problem stands out to me because it was from a coding interview I did well on, and passed.
In my experience, you generally have to get the correct answers in coding interviews in order to proceed. This sounds obvious, but it took a little more research…I had thought that maybe there were companies that were more concerned with your thought process.
- I did have ONE EXPERIENCE where they asked me to solve a coding question, I did not finish, and they let me advance anyway. This is rare
- I solved the anagrams problem and proceeded
- I scored in the 700s on CodeSignal and proceeded, which I already wrote about; I have passed other automated coding tests as well
- My personal favorite: An interviewer gave me 15 minutes to simply talk about how I would solve a coding problem. If only all of them were like that
Failures
- On this problem, I had a solution that I THOUGHT made sense but it seemed to swap two of the values — so it assigned the wrong weighting to two different things. Obviously this was wrong, and I did not proceed
- I received this problem and THOUGHT I was doing pretty well on it…again, did not finish. Did not proceed. I worked through it again and was going to blog about it pretty soon. This is a pretty good problem
- TwoSum closest to zero. I wrote something that got the correct answer, then proceeded for some reason and outputted incorrect answers. This was wrong, and I want to blog about this, too, to see if I really was that close
When I watch YouTube channels like Pragmatic Engineer, things seem a little more obvious to me: They describe really finishing problems, then working through edge cases and discussing how problems would be production-ready. So maybe these interview results are deserved, and the coding interview process is more fair than I gave it credit for. I do think I am better at this than I was when I started the blog, but the big complaint I keep finding myself back at is that we could have all spent this time actually building useful code, instead of grinding LeetCode.
A Positive Attitude
A wise, mature person would treat the software engineer interview process as a pure learning experience. He, or she, would enjoy learning about companies out there for the sake of research, interacting with key players, and mastering the art of whiteboarding. It would just be like a fun game.
I don’t think of it like that, but a mature person would. Do what I say, not what I do.
I wanted to emphasize this quote again. When you put yourself on the market, you get to see what the industry is like. You get to see what skills companies are looking for, ask them about their processes, and then talk to people you may one day work with.
You could say that an interview is like asking for a professional mock interview, but getting it all for free. The only issue I have with this mindset is that companies often refrain from providing feedback. One popular blog post argued that you should ask for feedback in the last five minutes. There are a couple drawbacks here. One, you lose time you could spend asking them questions you legitimately have about their work. Two, you need to phrase it correctly. “How would you have done this differently?” puts them on the defensive, like you are admitting that you probably failed and want their approval. “How would you have solved this?” is much better.
It does suck when companies provide no sort of feedback. I think I can kind of see why. Here I am, having received feedback like “did not go at the pace we expected” and “did not get the correct answer,” and I am seething, thinking about how if I were the interviewer I would have provided better hints, or treated the exercise more like collaboration and less like a test, and how it is weird that they complained about my pace in one interview when they very clearly said I should talk through my thought process.
If CORGICorporation were a real company and not something I made up on April 1, I could have implemented these practices.
Feedback tends to be negative after rejections. Maybe this is just my personal experience, but I imagine this is because companies need legal justification. I have yet to receive rejection feedback that says, “This was the best candidate we have ever had. Knowledge just glowed with him. The only reason we did not hire him is because we were not worthy. This guy belongs at Google, not here.”
If you actually paid for feedback, I would hope you would hear negative feedback and positive feedback.
Closing Thoughts
I wanted to compare coding to math, and that blog post has been put off for a LONG time. I even asked people from college for advice on it. I really want to write that post when I can.
Then there is a fair amount of interview ground to cover. There is that O(1) problem I mentioned. There is TwoSum closest to zero, which is kind of like the other five million TwoSum variations they like to ask. There was an interesting coding interview where they actually provided an HTML, CSS, and JavaScript file and asked me to build a new UI feature.
Also, system design. If I start covering system design, that will be material from now until the world ends because World War III is imminent.
I still want to build a really good coding resource, but this will have to do for now.
