Author: nsledgianowski

I have been a programmer for about 5 years at this point and as part of that I have read 10,000s of lines of documentation, lots of books and solved plenty of problems. I have also read tons of content trying to find solutions to the problems in my life. Add in a lot of time reflecting on what I could do to resolve those same problems and you end up with a massive amount of time spent trying to figure things out and a much smaller amount of time spent doing things to solve problems. 

As I have gone through more and more information, I have found that the solutions to my problems have gotten simpler and simpler. Lots of problems overlap and once you figure out one, the others get easier. Much like if you can solve one NP complete problem you can solve all of them. Because the solution to ‘solve a problem in your life’ is pretty basic. 

I see a lot of ‘older’ guys who give advice, aka gurus, who get frustrated, because younger guys keep asking complicated questions on the same topics, over and over. On the subreddit /r/cscareerquestions, every semester we see the same questions about applying for programming jobs. If you are having trouble finding a job after graduation the answer is the same for just about everyone. 

“I have applied to x number of jobs and no one gets back to me, am I cut out for programming?” — common question

Rote Answer:

1. Can you solve FizzBuzz or Hacker rank easy questions in 30min after practicing? 
2. Get help with your resume, either on reddit or pay a professional.
3. Apply for more jobs, don’t come back until you have applied for 100 more.

Your situation is unique in all sorts of ways, but if you are a college senior applying for programming jobs your unique factors probably do not matter compared to the three points above. 

There is only so much information that is relevant and if it takes a decade to go through the important bits, at some point you have to stop reading.

On my last project as an architect, I found myself drifting into an architecture strategy of keeping everything as simple as possible. In choosing a database I would look at our projected usage, multiply the number by ten and evaluate which database would be the simplest given our requirements. Given the size of an external library is it better to import it as a black box or to write the functionality as a single file module? The project being in Go made a few of the choices easier because Go does not offer many higher level features. Instead of worrying about class hierarchies you just write the functionality you need. 

Keeping it stupid means choosing an architecture that anyone would understand at first look. Other people should always assume that they could have come up with the architecture when they read it. There shouldn’t be any surprises or ‘cool’ technology choices. There is a blog post out there about how a startup or software team can afford to pick one risky technology before going bust. In KIS architecture you never pick a risky technology. 

In the 2018 Software Engineer’s toolbox are dozens of technologies that are both proven and incredibly powerful. We have access to many of the common tools as managed services in the cloud making things even easier. Save yourself the trouble, keep your architecture stupid until its proven that it needs to be more complicated.

I am moving to a new job in a different state. While my job search ended up being much longer than I expected, I learned a lot about interviewing and the salary ranges in Denver.  I ended up with 2 competing offers at the same time and managed to get a look at the maximum amount each company was willing to pay me. 

I started looking for a new job after the company I work for was acquired in 2017. I did this mainly in waves of 5~ applications with around a 50% response rate. Some companies got back to me right away, others took 3 months before starting the interview process. I did around 3 serious waves of applications and in total applied to 20 different companies. Considering that I applied to over 50 jobs before getting each of my internships this was a pretty good rate. Still it took over a year and thousands of dollars worth of vacation time. On the positive side my income will increase into the 6 figure range.

Part of why it was easier this time is that I have 3+ years of professional experience so I am not competing with new grads or junior engineers for jobs anymore. Additionally, my last promotion put me into a line management position where I was overseeing the work of others and led the project, which made behavioral questions much easier. The biggest difference here was the response rate. As a college student my response rate was 10% or less, now it is over 50%. 

Because my response rate was so much higher during this job search, I ended up doing a lot more actual interviews than when I was looking for internships. While time consuming, interviewing is probably the best way to practice interviewing. I have done enough interviews now that they start to flow together. The questions are all pretty similar. Whiteboarding has always been pretty natural for me because of my college background, but the questions repeat too. The last in person interview I did was 2 rounds of white boarding and a couple non-technical ones. But the questions were easy and I was almost bored. Luckily the people I was interviewing with were fun and it was a blast. 

It was also interesting to get a feel for the company tiers and what the technical level of my local area is. Most of the companies here in Denver ask technical questions of around the same difficulty. The hardest of which are Leetcode easy questions. I have only run into Leetcode medium questions from companies like Google or Uber. 

I have done around 20 Leetcode questions in total, which could be accomplished in a couple weeks. Interviewers want to see how you solve problems not how you already knew the solution to the problem. If the company is known for giving hard level problems you want to be totally solid on medium level problems and have done a bunch of hard problems. But grinding hard problems for months is not necessarily a good use of your time. Unless you must get into Jane Street. But I think focusing on just one company is probably bad for your career and mental health. 

While my job search took a long time and cost me some money, the increase to my income is more than enough to make up for it. I also got a chance to take advantage of Josh Doody’s Fearless Salary negotiation. Paying $50 to get an extra $5000 each time you switch jobs is worth it.

The rule of switching jobs every 3 years early on in your career seems to have held true in my case. Even if I had decided not to relocate, my income would have received a solid boost.

 

Often to save money or for convenience people will buy a multitool or generalized tool instead of a specialized tool. Depending on the use case there might be a specialized tool that is only useful for that one thing. One example is the fingertip bandage, it is shaped like a butterfly which makes the bandage less useful for most scrapes. But if you have an injury on your fingertip its hard to beat a fingertip bandage. They stay on very nicely and fit well. 

This concept extends to specialist engineers if your project can support it you want to hire specialists that focus precisely on subsets of your project. You want to hire a frontend engineer, a backend engineer and a data base expert. The issue is that you often cannot find specialists for every component, or there are many small areas that are too small to hire a single specialist for. This is when most companies turn to generalists. 

Specialists are expensive and only want to work on one sort of problem. Generalists are cheaper and will work on anything you want them to. As a result many companies slowly become staffed by generalists except for a few areas where the company itself is specialized. After a while, your company may consist almost entirely of generalists who are used to working on things that they do not know a lot about. The issue is that this effects your company culture and the ideas your company has on how software engineering works. 

A specialist will be working at 100% on day one of a project in their specialty. A generalist replacing a specialist you didn’t want to hire will take months to get to 80% of the productivity that specialist would have had on day one. If your company consists of mainly generalists, most companies do, you may not realize how much efficiency you are giving up by not having specialists. 

In our latest set of Sledgecasts I work through the problem of merging k sorted lists. I eventually converged on the optimal solution except I did not perform it in place. Merging linked lists can be done in place without any allocation which can make a big difference if you are allocating an entirely new list each time you merge.