Why ‘go get another job’ is the answer to all r/cscareerquestions.  

The r/cscareerquestions sub-reddit gets all sorts of questions from software engineers about their careers. And if you spend any amount of time reading through the posts you will find the answer ‘get another job’ given as a response to most questions. Why is getting another job recommended as the solution to so many workplace problems? 

Chance matters a lot more in your career than you want to admit. At the beginning of your career you are not going to have enough perspective to screen companies well. Your first job might be at a company with horrible practices that make your life more difficult. But you will not know the right questions to ask yet. If you do not read blogs or reddit you might not even realize that those practices are unusual. 

Each company has different processes carried out by different people. Different people will get along with you better or worse. You should find a job where you get along with the people who are up high in the ranks. Switch jobs every year until you find a company that fits you well. 

You might be a night owl or a day person. In software engineering you can find jobs that start at 8am or at 11am. Do not stay in a job that doesn’t match your internal clock. You will be suffering for no reason. 

Lots of the questions on the subreddit share the root cause of you ended up in a job that was a bad fit for you. Or you ended up with a job where your bosses and coworkers don’t like you. The job being a bad fit is caused by bad luck and can only be fixed by switching to a new job that is a better fit. You are not going to change the business to fit you better as a Junior Developer. Your best option is to move at the one year mark for mild difficulties and to move immediately when faced with big problems. 

There are enough bosses that you can find one that likes you individually as a person. Don’t spend years at a job you don’t like with a boss you hate and a team that thinks you are a loser. 

Vendoring and Dependency security 

In 2019 it has become standard practice to download dependencies straight off of the internet without verifying the code is secure and free of bugs. Software Engineers typically look up a dependency on github and follow the instructions to add it immediately to their project’s dependencies. More thorough engineers might take a few minutes to read through the code before adding it to their package.json file. 

This era of downloading dependencies off the internet without worrying about the security or integrity of the code has coincided with several notable hacks. The event-stream hack [1] which injected malicious bitcoin stealing code into a library used by thousands of NPM packages is only the latest in a series of hacks which take advantage of our loose standards for adding packages to our projects. 

Vendoring is the practice of embedding dependencies, binary or source code, into our codebases. The practice was popularized by the Go language, but had been used internally by Google and several other companies before that. Vendoring your dependencies adds an additional step, of committing new code to your repository, before new code can enter your software. And if you have all the source code for your dependencies vendor in your repository, you are at least able to verify all of the code in your system. 

Google stores all dependencies inside its custom version control system and has a process to vet new dependencies before they can be consumed by engineers. But most companies I have worked for had no restrictions on what dependencies could be added to a project whatsoever. 

The current status code of trusting without verifying code will continue to result in major hacks. The open-source ecosystem is too big to audit. And most companies do not even attempt to vet their dependencies. The many libraries created by independent developers which make open-source great are the least likely to be audited and most susceptible to custody hacks like what happened in the case of event-stream. 


[1] https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

How long does interviewing take?

As a new Software Engineer it is hard to know how much time the job search should take. Most people  start by applying to 2-3 jobs and wait for recruiters to get back to them. Then 4 weeks later they assume that because no one got back to them they must not be very appealing on the job market. 

The reality is that if you are cold applying to job openings you will have a pretty low response rate. The most desirable engineers in the market get around a 50% response rate. Entry level engineers have to deal with a response rate closer to 10%. That means that for every ten jobs that you apply for, a recruiter will follow up with you once. 

With such a low success rate you have to adjust your approach to spend less time on each job application. I spend about 15 minutes customizing my cover letter for each job. Then upload the resume and cover letter. Once that is done move on to the next job application. Too much customization is counter productive because you could spend two hours customizing your resume and a recruiter might not even look at it. It is more effective to apply to large numbers of jobs with the same resume and cover letter than to apply only to a few. 

Once a recruiter gets back to you the recruiting process really starts. Typically a recruiter will email you and schedule a quick phone conversation where they make sure you know about the position and confirm a few things about your experience and goals. This conversation is usually low stress and unless the recruiter gets the impression you don’t really want the job you will move onto a technical phone screen. 

Some companies will ask you to solve a coding challenge which is essentially a timed leetcode style problem. The problems are similar to what you would be asked in a white boarding interview so your studying will carry over. Hackerrank and leetcode have an almost identical experience to most interview coding challenges to use them to prepare. 

Other companies will ask you to attempt a coding project. This is usually a relatively simple programming project that is intended to be unique enough that there are not any examples online. I have done projects ranging from creating a basic backend REST service to creating a full fledged cryptocurrency exchange. The key to these projects is to be ruthless about keeping the scope down, otherwise the projects will take up too much of your free time. 

The final obstacle before you go to the on-site interview is the Technical phone screen. This phone screen is typically done over video call with a shared notepad that you can write code on. There are some systems like coderpad.io that allow you to edit and compile code with your interviewers. You will be interviewed by 1-2 engineers at the company. Most of the questions will be about software engineering and this will include more leetcode style questions. 

If you made it past all those interviews you will finally end up with the on-site interview. The onsite interview will involve a mix of behavioral and white boarding questions. Every company does it a little bit differently, but it typically takes between 2-6 hours and is pretty exhausting. Make sure to sleep well and prepare thoroughly. 

How much time do all these interview take? I put together a list of companies that I had onsite interviews with and how long it took in total to decide whether I would get an offer. 

These 5 interviews resulted in 2 offers (22.5 hours per offer). Getting a new job takes a lot of work, that is why people stay in jobs that they do not like for so long.


  • phone screen 2 hours
  • onsite 6 hours


  • coding project 6 hours
  • phone screen 2 hours
  • onsite 6 hours


  • onsite 2 hours
  • phone screen 1 hour


  • coding test 1 hour
  • onsite 5 hours

Salt Lending

  • coding project 12 hours
  • onsite interview 2 hours

Make your bosses look smart

What does it mean to make your boss look smart? At a basic level do a good job. Beyond that you want to make things on your boss’s wishlist happen. Fix a bug that is low priority but your boss wishes he could get it done now. Refactor a class that your boss or the lead engineer has mentioned being frustrated with. Don’t make the mistake of fixing something that you think is broken. Focus on things that you know your boss is frustrated with not things that you are frustrated with.  This is not to say that you shouldn’t fix the things that you are frustrated with, but do not expect to be rewarded for fixing your frustrations instead of other people’s frustrations. The reward for fixing your own frustrations is that you are not frustrated anymore. 

At the Vice President and director level bosses want to see proposals that align with their strategy. If machine learning is a market area of interest to the VP, make a proposal that uses machine learning to fulfill a business goal that either makes or saves money.

Learn when to shut up. If you disagree with the strategy find a new job. You are an employee you don’t get to have public opinions on strategy. If people want your opinions you will be promoted to VP or get a fat consulting contract. 

Make proposals that align with the strategy or wishlist. Don’t worry about stuff that doesn’t fall in those categories because it’s probably not important to the business. And if you see an iceberg you should be looking for a new job not wasting time sounding the alarm. Tell your direct boss about the problem and wipe your hands of it. Unless you have a substantial equity position in the company it’s not your problem.

If you don’t know what is on your boss’s wishlist, you don’t know your boss well enough. Start getting to know your boss better this week.