From talking to some people in the UK, my impression is that pay is considerably lower (by 50% or more!), but I don't know what interviewing is like. I'll see if I can get some info on that.
I'm in a difficult position, employment-wise... I graduated from Rutgers with a Computer Engineering degree in 2006 and a high GPA but I literally haven't written a line of code in over ten years and have spent that time with no formal employment, instead taking care of sick relatives. How screwed am I?
(I happen to live within commuting distance of New York City, but relocating is impossible for me because reasons.)
get hired now while the job market is incredibly hot. You should be able to find something even if not ideal. Then you can trade up in a year or two.
Yeah, but can I get something better than the proverbial McJob? The only "real" languages I ever used was some C++ in college and some Perl back around 2000 or so. My resume isn't getting me any interviews from anywhere at all.
Do you have 10-15 hours a week to spend writing code? It's likely possible to frame your absence from the job market in a way which doesn't hurt your prospects too much. Feel free to DM me if you want to talk more.
Thanks for the post! I'm currently in the process of looking for a programming job in the Bay Area. I'm less than a year out of school w/ a B.S. in CS, but I went to a school that does co-ops so I have a little over two years experience if you count that. And I have a bunch of public code on github from interesting projects I've hacked on in my own time.
So far I've mostly been cruising angel.co for job openings, and just recently started looking at listings on StackOverflow. I've gotten ~5 initial phone conversations, but nobody has moved on past that.
I will take the advice in this post into consideration, and make a reminder to come back and post some details about my job when I do get hired.
Nice. I have a question and a couple of suggestions:
Because I'm not sure what the motivations behind asking trivia questions are, I don't know for sure how your answer would be perceived. That is likely how I would answer a question about an API I wasn't familiar with, though filters are more of a structural aspect of .NET MVC than an API (though it's still all functions at the bottom). Not knowing an important structural aspect of a framework you claim to be proficient in can be a red flag - though in my case I knew what they were, but did not know what they were called. (I looked them up after the first interview where I was asked about them, which was a good thing, because I was asked about them again in my last interview.) Another good lesson!
I agree that making the interview pleasant for the interviewer is a good idea. It does seem like a "too obvious to be said" sort of thing, which probably means it needs to be said more often. The question that follows is how to do that, especially if you don't have an instinct for it.
I've also read the advice to practice answering questions on a whiteboard. It's good advice, but in the interview that got me hired I didn't actually do any whiteboarding, so I didn't think to list it.
Thanks!
I have to admit the most surprising part of that post is that you once got by with working 10h for a 40h job. Either the standards for work in some places are incredibly low, or your ability to pull off such a thing is one of the real reasons that such salary bump was possible.
Other than that, good luck with your experiment!
Something that always baffled me - all of this was regularly cited for why otherwise productive employees were fired. And everything was also done by unproductive employees, who never got caught for it.
I could never quite figure out the rules for who gets punished for slacking off vs. who gets rewarded for it.
In fact, all of my jobs (3 in total) until the current one had placed very lenient demands on my time. I think it's more of a management/operational issue, though. While I won't deny that I can solve some problems fast, most of the downtime was from an inefficient work pipeline.
You mentioned data structures and algorithms. What would you consider a skillset baseline for your typical BigCo.? Is that it?
Taking Google as an example, that is what they want at entry-level. If you're more experienced, my impression is that you still get run through the same gauntlet, but then you also get interviewed by a few different teams for more specific skill sets (i.e. mobile will want actual mobile experience, etc).
Keep in mind "data structures and algorithms" is underselling it a bit - you need to know well beyond what you typically cover in an introductory algorithms course.
If you are a software engineer living in the United States, you are probably underpaid. (If you are a software engineering living outside the United States, this is probably still true, but I have no idea what market conditions are like out there, and my advice would sum up to "move to the United States", which I understand may not be very helpful.)
Let me qualify this by saying that if you are working at a place like Google, Facebook, or Netflix, you're probably doing fine - there might be straightforward ways for you to earn more money, but the scale will be smaller and it'll mostly consist of lateral job hopping. Keep in mind that "big tech company" is not what I'm pointing at here - if you work for Microsoft or Amazon there's a very real possibility you fall into the reference class of people I'm trying to reach.
Let me tell you a quick story. A couple years ago, I was talking to a friend of mine, who works as a software engineer for [redacted]. When he told me how much he was being paid ($140k base, total comp around $200k), I was pretty incredulous (this was before I'd read up on typical BigCo. pay scales, see Dan Luu's excellent blog post for more info). Sure, [redacted] was one of the biggest and flashiest tech companies in LA, and my friend filled a fairly specialized niche in a fairly specific industry, but the numbers still seemed insane. During that conversation, he told me, "Dude, I have nearly a decade of experience on you, but you could easily be making something close to this in a year or two." I didn't believe him, of course - that would require doubling my salary. At the time I had ~two years of professional experience and was earning about $80k, which was a recent step-up from a very low career-start of $45k.
A little over half a year ago, I decided for various reasons that I needed to relocate within LA. I'm the kind of person who strongly values having a short commute to work, so I hit up all of my recruiters, gave them a prescribed geographical reason and a salary range that started 30% higher than what I was making then, so $110-120k, and let them loose. The first two months were good - I had enough interviews to keep me busy (considering I was still working full-time), and quickly got into the groove of interviewing again, with an eye to quickly learning the things that it seemed I was being rejected for at each step. I even got to the final round with a company I really liked, nailed it, and then never heard from them again. (Two months later my recruiters would tell me that they went with somebody technically weaker but with more lead experience. It happens. Move on.) Then November rolled around, and until 2018 it was basically a dead zone. Lesson learned - don't try to get hired in Q4. As soon as January rolled around, the calls started rolling in again. At one point I was in process with four companies at once, which is the sort of thing that I didn't really think happened in LA. I managed to line up all of the final rounds within a ~week of each other. Company A seemed like a pretty unexciting place to work, Company B had huge red flags from an operational standpoint, Company C had a pretty abrasive manager (and was edging a bit too far out of my location). Company D seemed awesome, and was one of the only two companies I'd talked to that I hadn't gone to through an agency. Amusingly enough, that interview was first and only interview I've ever arrived late to (only by a minute - but still), and I didn't feel I'd done as well as I had in the other three. Despite that, when I was walking out of it, I let them know that I was in the final stages with several other places and was expecting to hear offers from them soon.
Two days later I got a call from them, telling me that they were putting together and offer and wanted to move forward - so how much was I looking for? I gave them the usual spiel, and the internal recruiter told me they were considering an offer in the $120-130k range, where the lower bound matched the upper bound I'd given to my agency recruiters, and would represent over a 40% salary bump. Oh, and there was a bonus program too, which would bring that to over a 50% increase. I told them I was being considered for roles at several other places with the same salary band. Of course, I would be happy to talk more about it when they had a final offer ready. Four days later I got a call with the final offer, which, at $135k + 10% bonus, was slightly higher than the upper end of their range, and I took it. If you’re keeping track, that’s a 70% pay raise.
For reference, I'm in my mid-20s with a mostly irrelevant non-CS degree from a weak state school, and have a little under 5 years of professional experience. I'm also missing some core skills that basically every company hiring for what I do (web development) looks for, particularly modern front-end frameworks. At $85k/year, I was earning a little bit under the median salary for software engineers at my experience level in LA, but my job compensated for that by having an extremely light workload (I regularly got by on 5-10 hours a week, though unfortunately I still had to put in 40 hours of sitting on a chair) and a very strong benefits package (the one upside of working at a non-profit). I'm not anywhere near a prodigy by this community's standards. If I can do it, you can too.
Here's how:
This is the easy, straightforward solution, if you can put your nose to the grindstone for a couple of months and learn data structures and algorithms well enough to pass a Google interview, and you're willing to relocate to the Bay Area (or have a BigCo. satellite office in your city). There's more than enough advice about how to do this on the internet, and it's not really why I'm writing this post. If you want a primer, Alexei wrote a good one here: https://www.lesswrong.com/posts/Z6dmoLyfBdmo6HEss/maximizing-your-donations-via-a-job
Which is to say - if there's a specific reason you can't work at a big tech company, there are still ways to skip a few paygrades.
Step 1 is getting your foot in the door. This means your resume either needs to pass an HR screen (sometimes automated, sometimes not), an agency needs to refer you (which can substitute for an HR screen, but will probably limit your options when it comes to salary negotiation), or you need an internal referral.
Again, I'm not going to repeat all of the online advice about how to write a resume, but there are a few points worth mentioning. First, the old adage about keeping your resume to one page unless you have a decade+ in the field is basically useless. If you can do it without making your resume look cramped, then sure, but don't worry if it goes to 2 pages (do avoid too much fluff, though). Second, focus on the business deliverables. Instead of writing, "Wrote web services in ASP.NET for the Customer Care team," write, "Wrote web services in ASP.NET that reduced the Customer Care queue by over 50%." The code you write is fulfilling a business function. Let the hiring manager know how awesome you are at that! If you don't have hard numbers, still try to frame your major projects and accomplishments in a way which emphasizes their business impact. Unless you have a specific reason to believe that the hiring managers at roles you're applying to want to see binary trees on your resume, leave specific implementation details out (quick description of tech stack for each project/role is fine). They'll probably be more interested in finding a developer who has an understanding of business needs, and you can talk about the tech stuff in the technical phone-screen or on-site.
Step 2 is interviewing. There is no substitute for practice. This means that, unless you are severely time-constrained, you should never turn down an opportunity to interview with a company, even if the position isn't exactly what you're looking for. This is your chance to:
a) learn more about what employers are looking for in your region, and then study up on it for future interviews. Within a few interviews you should have a pretty good idea of what level of algorithmic knowledge people are looking for at the level you're applying (it won't often be 0, but it also won't be anywhere near what Google is asking for - the hardest question I ever got was reversing a linked list), and also what "trivia" you need to know. This can range from specific implementation details in your tech stack (what is a Filter in .NET MVC?) to software development life-cycle questions (what is feature branching in source control used for?) to more general architectural questions (design patters, dependency injection, inversion of control, etc). There's a lot more you could be asked here; it really depends on what sorts of jobs you're applying to. The important part is that if you get asked a trivia question that you don't know the answer to, step one is to not get flustered or defensive, and step two is to look it up after the interview. If you can manage it, ask the interviewer to explain it to you, and try to come up with a clever insight about it to relate that you understood what they explained. Not knowing the answer to a trivia question isn't an automatic disqualification, unless it's something so basic that it's implausible that you've done what you've claimed to do on your resume without regularly encountering it.
b) become more comfortable with the flow of interviewing. A large part of the process when interviewing for software engineering positions at companies that aren't mature tech companies is crafting a narrative around yourself. Pick a few good stories about technical challenges that you overcame and interpersonal conflicts that you resolved and practice telling them (ideally to people you don't know that well).
Step 3 is negotiating. Eventually you'll get to the point where you've aced the final round and the company wants to hire you. This is, once again, a field that has been well-trod on the internet. Refer to the previous links in this post.
While there are gains to be had from negotiating, the largest gain will almost certainly come from simply increasing the salary band of jobs that you target. While you probably shouldn't waste time applying for senior positions looking for Scala engineers if you're two years out of university with your only experience in Python, you shouldn't rule out applying to roles where you don't meet all (or sometimes even many) of the requirements. Job descriptions are not always written by engineers, and even when they are, they should be treated more like a "wish list" rather than a strict filter. There were seven technical requirements listed for my current role, and I can only claim with confidence that I fit three of them well (and a strong showing on a fourth). One of the others was modern Javascript frameworks, which ended up being a "bells and whistles" thing, as my job requires practically no front-end work at all. Another was a requirement for experience in .NET Core, which basically nobody has (yet). This also turned out to be a "nice to have", but during the technical phone interview with the Director of Engineering, expressing my prior interest in learning it for reasons that lined up with the company's goals definitely helped me form a connection with him. The third was a requirement for experience with specific design and architectural methodologies. These never came up during my interviews! Actually, this is a little funny because it's probably the most important part of the job so far - I'm getting by because I already understood most of the theory and pick things up very fast when I have to use them, but the company had no way of knowing that beyond my word. I have a lot of thoughts on how the hiring process for software engineers is broken, but that's for another post.
You may notice that this post was, with a few exceptions, a bit light on specifics. The nature of the job search is such that it's highly variable and depends heavily on your geographic location, knowledge, experience, and proclivities. While it would be impossible to capture all of that variance in a written guide, real-time advice from somebody who's gone through the same experience would probably smooth the path.
I think the gains from helping people accomplish this are large enough to warrant an experimental investment of my time. I'm not going to ask for money, obviously. The idea is to make this as easy as possible, since I suspect that many people in this position suffer from varying forms of executive dysfunction (like me). If you want to pay it forward by later helping others make the same jump, or by donating to EA charities, great, but I'm not going to require anything like that.
My only ask is that you are a software engineer who has ruled out "go work for a big tech company" as an option and you believe that you're being undercompensated, and that you either live in a major metropolitan area in the United States, or are willing to relocate to the nearest one. If you live somewhere that is not a big city but somehow has many open software engineering positions, that's fine too. Please feel free to pass this along to anybody you know who may be in this position.
I am @T3t on the LessWrong and SlateStarCodex Discord servers, as well as the Los Angeles Rationality server. My (rot13) email is orggrefpnyr ng cebgbaznvy.pbz.
I was originally going to write this post without exact salary numbers, but the friend I referenced in this post correctly pointed out that numbers are very convincing, and encouraged me to use both his salary and mine for illustrative purposes. I also believe that the norm of silence around salary contributes to the information asymmetry problem that software engineers experience when trying to find a new job, so if I can help break it - good.