Category Archives: Software Jobs

How Senior Software Developers Think

Senior Developers are expected to be more skilled in the technical aspects of software development. Just by having more years of experience they should be able to solve more problems, have more techniques, be faster, etc.

But, this alone is not enough to make them “senior” in my view. They will be more valuable than a junior developer doing tasks, but you can’t scale a team with a group of expert task doers.

The biggest differentiator between a junior developer and a more senior one is in the scope of their thinking and planning.

To keep it simple, imagine four levels of engineer (Jr, Dev, Sr, Lead). Here are some of the differences aside from programming skill. This distinction has nothing to do with people management—none of these levels have management responsibilities.

  1. Jr: Right out of school. Cannot do any task without some help. Can plan a couple of days of work.
  2. Dev: Can do most tasks independently. Can plan projects that take weeks to do.
  3. Sr: Takes product specs and writes functional/implementation specs and plans. Can plan projects that take months to do. Can coordinate the work of a team.
  4. Lead: Can plan projects that may take years. Thinks about overall architecture. Establishes processes. Can coordinate the work of multiple teams.

There is more to it than this, but the essence is increasing scope of time, planning, and coordination.

Another way to think of it is in what their goals are:

  1. Jr: Complete the ticket: e.g. Fix the bug, deploy the build
  2. Dev: Complete the project: e.g. Implement the export to CSV feature as specified
  3. Sr: Achieve the mission of the project/team: e.g. Increase paid conversion, reduce the crash rate
  4. Lead: Achieve the mission of the company: e.g. Increase profit margin by 10%, enter an adjacent market

To be fair, everyone should be working on the mission of the company. The difference is how they think about the work they are doing and how they evaluate success.

Tech Career Tip: Drive Revenue, Not Cost

I have spent most of my career in software product development, meaning the code I wrote went into the products that made money for the company I worked for. I did a short stint writing internal software for the organization itself and the difference was very stark to me.

When you write software for your organization, it’s often to automate something and the driver is cost-reduction. The problem is that cost can only be reduced so much and eventually you are one of the biggest costs (in a budget owned by someone who likes to cut).

Revenue, on the other hand, can be very outsized compared to your cost. The budgets for product development are often expressed as a percent of revenue, so success increases budgets.

And, often, product development jobs offer some way to participate in that upside (options, RSUs, etc). Getting equity from an IT developer isn’t as easy.

It’s more complex than just “for-sale” or “internal”. When I was in FinTech, I wrote products, but my peers at banks, writing internal software, certainly drove revenue for their employers and were paid very well through generous bonus systems.

Pay is not the most important benefit. When you are critical to how a company makes money, you have bigger growth opportunities, more respect, and generally more clout. Product developers at software product companies have career prospects that lead all the way to CEO. That is not often the case for developers automating internal operations.

Podcasts for Companion Learning

One of the advantages of podcasts is that they are audio-only, so you can listen to them while you do other things. I listen while doing chores, running, cooking, and driving. I mentioned in Soundtracks for Books that it’s hard to listen to something while you are doing effortful thinking.

But, just like a book soundtrack, you can pay attention to audio if the thing you are doing is really the same thing—something integrated with it.

I haven’t seen this much, but I think a big area for podcasts could be in guiding “learning by doing” tasks.

There are lots of video and text tutorials for learning programming. The issue is that you can be tempted to consume them without really doing the tasks yourself. And since you have to look at the book/video/blog etc, it’s hard to also be looking at your editor.

This kind of podcast could not just be played in your regular playlists though—you need to be at your computer ready to listen. It could guide you in a vague way, so that you have to think in order to do the tasks, not just listen while you exercise.

I’m not sure that a programming guide podcast is a good fit for very new learners, who still need a lot of help with the syntax. It would be better for learners who can write lines of code syntactically correct from a short-hand description.

Like I said in Vague Tutorials Would Help with Coding Interviews, I think getting good at taking spoken directions would help in coding interviews.

A Cover Letter is an Argument

A few days ago I wrote that your resumé should make no sense, where I explained that you should customize your resumé so that it is tailored to the receiver to such a degree that sending it to anyone else would make no sense.

A cover letter is similarly customized, but I think that’s more obvious. Never use a generic cover letter. If the application is cold, you need all the help you can get. If it’s not, for example, if you are being referred, then you really need to mention that.

The cover letter is a response to the job description. It is a point-by-point argument for why you are best person for the job as it was described. It is a guide for navigating the resumé. It is a writing sample. Every job description asks us to have excellent communication skills. Your cover letter is the way you prove this.

Before you even start to write it, you need to dissect the job description and pull out the most important asks where you have an excellent response. If you don’t have an excellent response, this might not be the job to apply for.

You will also have one or two things about you that are so great, that you need to get them in the letter. This could be a side-project or open-source contribution, a talk you gave at a conference, some technical achievement at work.

Finally, you should research the company enough to try to find other things that would make you a good fit. Read the company blog or twitter. Get a sense of who they are. If the company is small, you might be able to find team members or the hiring manager of the job they are looking to fill.

With all of this raw material, write a letter that makes it clear that

  1. You are specifically trying to get this job, not any job
  2. You are willing to put in work to get it
  3. You have the required skills of the job
  4. You have excellent communication skills

From experience I can tell you that getting one like this is rare. When I am the one filtering the pile, I will always call anyone that does this and give them a chance.

I got my last two jobs with cold applications and extremely custom letters. Of course, the letter just gets you the interview, but you are going to do a similar amount of preparation for those as well.

Your Resumé Should Make no Sense

If you sending out resumés and getting auto-rejected or never even contacted, let me help you understand why.

Yesterday, I wrote about writing a Job Statement, which is a very specific description of the job you want. You can think of it as the employee equivalent of an employer’s job description.

You are now looking for something very specific. And when you find one to apply to, you are also a very specific person.

So, why is your resumé generic? If you could send this same resumé to lots of different software developer jobs, then it’s going to get filtered out for a lot of them.

Consider the receiver. If this is a well-known company who will get a lot of applicants, they may get a hundred applicants to every position. I worked for small companies in small job markets and could get that sometimes (especially when we targeted new grads at the local colleges).

With such a pile, the reader has no choice but to skim each quickly. Imagine that they will read the very first lines and then skim for a few pieces of key information. If you pass that, they might give it a more careful read. It is also possible that they are using crappy software to score the resumé ahead of time.

Why will your application get chosen?

Here’s one way. Your resumé should be so specifically meant for that job that it would make no sense to send it to anyone else.

Doing this takes a little longer than just spamming job sites with your generic resumé, but the hit rate is worth it. And it’s really not that bad. You are going to start from a long generic resumé and edit it to be more focussed. I personally maintain a few styles because I have more than one domain I am willing to work in (and they are different enough to warrant this).

Read the job description very carefully and figure out the one or two most important things they are looking for. Take note of the words they use, especially jargon or technical terms, because you will use them as well.

The very first real sentence of the resumé, below your contact info, should be a concise argument for why you should be hired for this specific job hitting those two most important points.

Next, should be a concise summary of your technical qualifications, edited to be specific to this job. Maybe label this section “Relevant Skills” if you are afraid you are editing it down too much.

In every job you list, make sure the reader can skim and see the tech stack you used there (bold it). Use the job description as a guide to what you write about the job.

The description of your current job should be very specifically tailored for this receiver, and you can do this to a lesser extent as you go through the resumé (but it won’t hurt to do it completely).

If you need help, please get in touch.

Your cover letter is going to be even more customized. I’ll cover that soon.

Note: If you think your resumé will be auto-scored, the standard recommendation is to make sure your resumé has the keywords they are looking for. Since you are tailoring the it to the job description, you should be fine.

Job Seeking Tip: Build a Job Statement

If you are looking for a job, write a very specific description of what you are looking for. Do this even if you think you’d take any job. Looking for any job doesn’t help you focus your actions, but when you get specific, it’s easier to think of things to do that would help find it.


There are a lot of different jobs and good ones get lots of applicants. The goal is to make you into the perfect applicant for the job you want. This way, you’ll spend less time applying and preparing, and when you apply, you’ll be sure to stand out.

If you don’t do this, you may find yourself spending a lot of time spinning wheels and getting nowhere. You won’t have any good way to evaluate job listings, or even start searching for them.

You will probably apply to way more jobs than you should, and then, you won’t be giving the proper amount of attention to any of them. In frustration, you might just take the first job that comes along.

So, write a job statement

Break down all the aspects of a job and try to figure out what’s important to you.

Answer these questions:

  1. Where is the job located? Is it near home? If so, what is the maximum distance? Any particular neighborhood or town? If you are willing to move, what kind of place? In your state or country? To a city, a small town? Does the place need to be near anything (downtown, a highway exit, a train line, etc). Or does it not matter because you want to work remotely.
  2. How big is company? Is it just a few people? A big public company with international offices? Or do you just care about the team size? If so, how big is it?
  3. What domain? Is the software for internal of external users? Is it horizontal or for a specific vertical (like healthcare or finance)? If vertical, which one? Who are the customers?
  4. What technologies? Any particular language? Web? Mobile? Do you care about whether you use OO or functional style?
  5. What is your role at the company or on the team? Team member, lead architect, team lead?
  6. How much do you want to make? Can a part of the pay be equity? If so, how much? What kind of benefits and vacation?
  7. What kind of company culture? Casual? Business casual? Formal? Flexible hours?
  8. How much travel do you want to do? None, weekly, occasional? For what reasons? Customer visits? Conferences? Working in different offices?
  9. Contractor or employee? Part-time or full-time?
  10. Do you care about the office space?
  11. How about the team’s abilities?
  12. What about their contributions to open-source?

The next step is to prioritize your answers. Once you do that, you can use this statement in so many ways.

  1. To form search queries on job sites
  2. To find Linked-in connections to reach out to
  3. To customize your resume
  4. To drive your self-learning for gaps you might have in qualifying for the job you are looking for
  5. To make a list of companies that match your criteria.

Another effect that isn’t so obvious is that it helps you recognize serendipitous leads. When you are tuning into something specific you start to notice it everywhere. If you mention your search to other people, they will think of you when they see it. The randomness of the world starts to work in your favor.

Please reach out to me if you need help with this (message me on LinkedIn). I can help a lot better if you are specific.

Raising The Bar is a One Dimensional Concept

In the context of hiring, I often hear people saying that they want to “raise the bar” or not “lower the bar”. My problem with this is that I don’t believe that they (or anyone) has any idea where the bar is or who is above or below it.

But, the bigger issue is that a bar that is raised or lowered and that people are under or over is a one-dimensional concept. Using this metaphor for hiring will result in one-dimensional hires. It’s clear from the past few decades of the tech industry what this has led to. We over-index on 20-30 minutes of code performances as the only predictor of success at software engineering.

Even if our interviews include other attributes, they aren’t treated as equal to the coding interview. You can’t even get to a more nuanced interview if you bomb the technical-screen.

So, to change this, I would first say to ban the idea of a bar from your vocabulary and thought-process. Instead, imagine something more multi-dimensional. Start with something like this:

Use the nodes to pick the attributes you think are important to your team’s success. Coding is probably one of them, but so is writing, team-focus, customer-focus, etc. The key is those things are peers, not successive gates.

Along each dimension, you might have a minimum, but don’t just set it high and make it a gate again. Wait to see the whole person.

And, use it to honestly assess your current team. Where are your gaps? Is the right new hire one that fills them?

Remember that whatever shortcoming the new hire might have may be offset by their strengths, and some things (like coding skill) can be improved by training and mentoring.

Alcoa’s 1958 Plan to Make Programmers

In 2019, I went out to dinner with my father-in-law and his retired friends. I met someone who became a UNIVAC I programmer in 1958.

I asked him how he became a programmer. He said he was in Alcoa’s accounting department for a few years right after college. HR came to him and asked if he wanted to take an aptitude test for a different job.

He passed the test, and so they trained him to be a programmer—he went on to have a decades long career in industrial control software.

He was described some of the work to me. A lot of it sounded like data engineering—he said he became an expert in “preparing inputs”. He worked on early projects to computer-control aluminum production.

If you don’t know Alcoa, in the 50’s, they were inventing ways to sheathe skyscrapers in aluminum. They invented pull-top cans.

Kudos to Alcoa for training new programmers—if you are finding it hard to recruit, you might want to follow their lead.

Professional Performances

I’m not a huge fan of technical interviews because I think they are closer to auditions than programming work simulation. I wrote:

A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it’d be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

But, there are times where the work is a performance. For example, presentations or talks. For that, I recommend treating them exactly how performers do—with lots of practice: solo and in front of audiences.

When I recommend this, the push-back I get is that the person doesn’t want to sound like they memorized their presentation.

I agree.

Actors and musicians completely memorize what they are going to perform, but then give a natural performance. Stand-up comedians practice being flustered and reaching for words. The more you practice, the more natural the performance will look. When you do it, you will be in a flow-state.

If you want to see this in action, look at any TED talk—they are highly polished performances. Steve Jobs was also famous for practicing intensively.

But, practice has a much more important effect—it drives self-esteem. If you put the work in, you will see it. You will see that you are doing rehearsals and you will judge that you are likely to succeed. You will feel pride and you will want to do it more.

That sense of pride may turn us from dreading speaking in public to actually looking forward to it. After your successful performance, you will have the confidence that comes from success, which will drive you to practice more and start a virtuous cycle.

Incidentally, this works for interviews too.

How to Use Rejection

One of the more exciting things in life is to be accepted to do something that was competitive, and where you stood a good chance of rejection. That could be our stretch choice college that seemed out of our reach. Or that new job or promotion that we technically don’t qualify for. Or as simple as getting a date with someone out of our league.

It’s exciting to punch above your weight.

But, the chance of rejection can sometimes make us not try. We say that we’re not ready. That is probably true. In fact, the more chances you take, the more likely it is to be true.

But, rejection is a great way to find out how to get ready. It’s not something to be avoided. It’s a tool we can learn to use.

Here are ways we can use the possibility of rejection

  1. To motivate us to practice and prepare
  2. To focus our requests for help

Here are ways we can use actual rejection

  1. To ask for specific feedback
  2. To drive a post-mortem
  3. To improve our approach for next time
  4. To help others in our position