Category Archives: Software Jobs

What To Do If You Have a Tech Interview This Week (or Tomorrow)

Your goal is to be able to answer questions that you can answer. If they ask a question and you have no idea at all, then you might not get an offer. But, if they ask a question that you definitely know, you will feel bad if you flub it.

So, practice. If you have a friend that can do a mock interview, do it. If you have time to practice leetcoding, set it at a level you can do and just practice coding under a little pressure.

You are not trying to learn more algorithms, you are trying to get better at performing what you already know.

One Time I Recognized a Junior Catalyst

This is a followup to Some Behaviors of a Catalyst where I said that I didn’t think you needed seniority to be one.

More than 10 years ago, I was interviewing college seniors for an entry-level position. Among the group of very talented students there was one obvious front-runner who we offered the position to (and who accepted). But there had been another candidate that impressed us.

They interviewed well and were qualified for our position. But, we preferred candidates with some C/C++, and they had less than our preferred candidate, maybe none, I don’t remember. In any case, that was probably the deciding factor. But in a lot of other ways, they were outstanding (in the literal sense of the word). They stood out.

Here’s what I mean. A bunch of the candidates had worked together on their senior, two-semester, capstone project. We heard about this project from several angles. Over and over, a candidate would point to another person as the reason the project went well. They would, of course, talk about their own contributions, but they would also specifically point out what this other person had done as well. The thing was, the other person was always the same person, the “outstanding” one.

Even with this clue, we didn’t hire them.

About a week after we had made our decision and the offer, my boss called me in. He said a friend of his (another tech business owner) had sent in an unsolicited recommendation for a student he knew. I think he had them as intern or something. In any case, the recommendation was effusive. The student was, of course, that same one who had been recognized by their peers.

At this point we felt as if we’d be idiots not to hire them, but we didn’t have a position. The good thing about junior developers, though, is that they are cheap and you should always have a position if you see a good one. So, we created a position and made an offer. I think this is the only time I recognized a junior catalyst before working with them—the key is that people like working with them and attribute success to them. When that fact comes to light without seeking it, it’s a good sign.

Some Behaviors of a Catalyst

Yesterday I wrote that you should recognize catalysts, but didn’t say how. The problem is that so much of what they do is under the radar, but one tell is that they always seem to be part of successful teams and everyone on the team knows that they were an important member.

Catalysts can be technically great, but perhaps not the most technical person on the team or the best specialist on your corner of the company. In my experience, they are more likely generalists. They likely know the most about the other teams in your organization, which is why they can get things done with them. They often know who to go to, and those people often know them.

It’s not just the other teams, they also know the most about the architecture of other services. They might even have commits in repos they don’t own and in the third-party dependencies they use. When they need to get things done, they don’t limit themselves to just their own codebases.

Their colleagues like them and like to work with them. And the catalyst genuinely liked working with those people too (and they like people in general). They are often your best source of candidates. The best way to hire a catalyst is through a referral from someone on your team that raves about working with them.

Knowing what I know now, if I were to look for them I’d be looking for what Atlassian called “Feature Leads”, which were engineers that led a “feature” project. They often needed to orchestrate the work of several other people and perhaps several other teams. I guess to make sure they were good at it, I’d be looking for people that did it repeatedly at the same place. This work doesn’t rely heavily on their commits, but I’d be interested in people that had commits in disparate parts of the feature, not because of the technical skill it requires to do that, but because it would indicate a holistic view and might indicate a tendency to clear roadblocks, both of which are catalyst behaviors.

As I said in How Senior Software Developers Think, the more senior you are, the more you think of how your work relates to the mission of the company. Catalysts at any level do that. It’s often easier to have success as a catalyst the more senior you are, but I don’t see this as a requirement. Feature leads at Atlassian could be just past the junior level (pre-Staff/Senior level). It was a good indication that they should be promoted, but they didn’t need to have that level to catalyze.

Recognize the Catalysts

I tried to pattern my career after An Unnamed Programmer in Peopleware, whose contributions weren’t always clear, but “had never worked on a project that had been anything other than a huge success.” She was overlooked by her management, so I learned that to do this, you needed to make your contributions clear.

As a manager, I didn’t always know how to hire for this quality, but I knew it when I saw it and made sure they were on the projects that mattered. And I keep track of them, too. I might not know if a new candidate is one, but once you know someone is a catalyst, you can always hire them at your next gig.

The Case for Adding Entry-Level Devs to Your Team

To be clear, by entry-level, I mean 0 years of experience, but with the skills that you would get from a bachelors in CS (or related) and some internships. Going by myself, when I graduated, I had built a compiler, a SQL-like database, a 3D modeling and animation application, image processing algorithms, a robot-arm controller, a theorem prover, etc. I had used version control, worked in the computer center, and had some tech-related summer jobs. This pales in comparison to what I’ve seen from modern CS graduates.

When I was hired at my first job, I fixed a lot of bugs to learn the codebase. My first big task was to reduce the memory footprint of our application by rewriting our windowing code (this was on DOS, so we simulated windows with ASCII Art). I worked on build scripts. I helped port our software to UNIX. I fixed a lot of core dumps. I worked on our printing code (yes, printing to paper). I could do all of this without understanding what Foreign Exchange Options were (yet). There’s a ton of work like this on most teams, and frankly, you are overpaying if this is what you have your senior devs doing.

That’s the main reason you need entry-level devs. There’s a lot of work that is only cost-justified if they do it. They can learn while paying off some technical debt, automate tests, and fix the quality-of-life bugs that make your app look unpolished. They can learn your domain by participating in code reviews.

The second reason is that all of this work is hindering your senior staff from growing. They shouldn’t be doing this work—they should be driving bigger outcomes (as I wrote on How Senior Software Developers Think). You are risking them leaving because they fear having 1-year of experience 5 times.

Finally, healthy teams have a diversity of experiences. An all-senior team may seem great, but they will have more groupthink than a team with some junior developers. It gives seniors a chance to mentor and will frankly make them code better (because it needs to be understood by less experienced team members). Having to explain things makes sure you understand them yourself. Documentation will be better, because you need it to be.

If you know how to retain them, entry-level developers grow with the company. Our CEO had started right out of school (where he was the first hire, I think). I eventually went on to lead the engineering team. At Atalasoft, we hired mostly entry-level, and they went on to build the products that were the basis of our acquisition. My last job, Trello, was co-founded by Joel Spolsky, who famously wrote about how to find great developers – TL;DR: get them at the entry-level. When I joined, a lot of the engineering team (that had built Trello to 7 million users by this point) had been hired out of college.

I understand that there’s risk, but learning how to recruit and evaluate entry-level developers is a core skill that your team should have.

The Entry-Level is the Applicant’s First Job

I spent some time today reading entry-level job descriptions on LinkedIn. There seems to be a widespread misconception that entry-level means “doesn’t have a lot of experience”, but entry-level means “no experience” — it’s right there in the name.

In addition to requiring a couple of years experience, these jobs also seem to require skills that would be very hard to obtain without a job. It’s shortsighted and very unlikely to result in good hires.

Imagine what this employer is thinking: There is a person with 2 years experience at a job where they got all of this great experience, and now they are going to move to your (excuse me) shitty job. They are not.

Let’s assume this person is great—I hate to tell you, but they are not looking at junior/entry-level jobs. Either their current employer is smart enough to know how to retain them (hint: with money), and so they will not be considering you or, if they are looking, they are looking to move up.

The person with 1-2 years experience that is fine with another entry-level job is doing this for a reason. In the best case scenario: they are in a bad job and need to get out—guess what, your job looks just as bad. My evidence for this is that you don’t know what “entry-level” means and are likely going to have unrealistic expectations and be another bad job. They know this. They missed the red flags before, but they see them now.

Posting entry-level jobs that are not entry level is a signal that your job sucks.

Do Software Developers Need a Brand?

When someone hears that you are working on something, your brand is what they think will happen. So, the question isn’t whether or not you need a brand, because you already have one as long as people hold some opinion of your work. The questions to ask are (1) what is the brand, (2) how consistent is it, and (3) how widespread is it.

The most important thing is that the opinion people have about you is generally positive, but there are a lot of options for what that is. It could be that people generally believe you are highly skilled. Or they could believe that adding you to a team is good because you help teams jell. Or perhaps adding you to a startup is a good idea because you have a large network of peers to recruit from who like to work with you. Or maybe you know a domain on a deep level. Each of these are examples of a positive brand, and they all can work well (or even better in combination). Whatever your brand is, it is built from your visible accomplishments.

So, in addition to accomplishing things, if you want those things to be part of your brand, make them visible. If the work can’t be public, then you could still make sure your team understands your contribution, ensure your manager understands it enough to use in a promotion packet, or talk about it on an internal blog. If the work is public, then having some public explanation of the benefits of that work is worth adding to it. If you use LinkedIn, I would say that this should show up in your headline, summary, and job history section. There is no need to make posts for this, but I do think having a trickle of LinkedIn activity is helpful to help people remember you or get them to look at your profile.

A positive brand is always helpful, but a consistent one becomes more important as your career progresses. You can’t always control exactly what you work on, but you can improve how that work is understood by using emphasis. I have done this on my LinkedIn profile and when applying for a job by making custom resumés and cover letters.

For most of my career, I concentrated on doing good work and having positive interactions. But it’s easier to communicate this by fitting that work into a narrative. I emphasize the parts of my career that are more likely to result in relevant work, and I expand it in direct conversation if it makes sense.

I’d like to think that this was all intentional, but it wasn’t really. This narrative is something I found after the fact. There are alternative brands that I could use, but don’t, like “FinTech Engineer” or “Mobile Engineer”, which are positive but not consistent with what I am trying to do. I don’t want to be hired to do those things, so it’s only important to talk about them if a specific engagement needs that in addition to what I try to sell. But, to get the job at Trello ten years ago, I emphasized the “Mobile Engineer” and “Startup early engineer” narrative and downplayed my management experience.

But when developers ask whether or not they need a brand, I think they are mostly asking about the “widespread” part. In that case, the answer is easy. No. You do not need a widespread brand. My career has been successful without one, and I think I’m the norm.

I am not well-known outside of my network. This is true even though I have written a book, spoken at conferences, been on some podcasts, written for tech publications, and worked on a fairly well-known app. To the extent that these things touched people outside of my network, I don’t think it resulted in a widespread brand. But, I do think the people that know me have a positive association with me in a way that is consistent with my narrative.

The more important thing is that your positive and consistent brand be widespread within your communities: inside your current employer, among your ex-colleagues, and among your clients. If you participate in developer online communities, then in there too. To the extent you are on social media, then among your followers, no matter how small a list that is.

Rather than working to grow your brand to strangers, I would first recommend you grow it within your network. The best way to do this is by doing good work in the way you want to be known. Then, build a consistent and widespread brand by tying it into the narrative you want people to have about you when they hear your name.

How to be avoid being replaced by AI

Right now, I am an independent software developer, and so I own all of the code I create. So, of course, I want it to be as efficient as possible to write that code, and I use AI to do that. I get all of the benefit. I am not replaced—I am freed up to do other things.

All of my consulting income comes from work that originated from my network, cultivated from over 30 years of delivering on my commitments. Some of it is because I am one of only of few people that understand a codebase (that I helped create and partially own). There are very few people that could replace me in this work, even with AI. Even if AI were able to 100% reproduce everything I say and write, the client wouldn’t know how to judge it because their judgement of me is almost entirely based on past experience.

It’s not just AI—there are many people who are smarter than me, with more experience, who work harder, and have better judgement. But if they are completely unknown to my clients, they couldn’t replace me.

Of course, I realize that this isn’t something that one could just replicate immediately, but if you are building a software engineering career for the next few decades, I recommend cultivating a network that trusts you based on your past performance and owning as much of your own work as possible. When you do that, all of the benefits of efficiency flow to you.

Network with Alums Just Ahead of You

Yesterday, I wrote about using your alumni network to make you more lucky. In most of my stories, the alumni network that was most helpful were in my year or just a bit older. They are the ones that just got a job and know what works in the current job market. They are also the most like you, so their advice is relevant. And, they know you, and like you, and so they will want to help you.

When I talk to my mentees, I keep warning them that my information is way out of date. I got my first job by looking in the classified ads in a newspaper. That ad led to a recruiter that placed junior software developers. Those parts of my story are from olden times.

But, networking with your college classmates is evergreen. The easiest way to do this is to just be a good classmate, study partner, and extra diligent when working in groups.

Alumni Networks Increase Your Luck Surface Area

When I walked into the second interview at my first job, one of the developers said: “Hi, I think you know my husband.” It turned out that her husband was a college classmate of mine. I didn’t get the lead from him (that would have been smart of me), but at least he must have said nice things when she asked (or I’m guessing I wouldn’t have been hired). It was pure luck, but I’m a big believer that Randomness is the Great Creator.

The woman who would become my wife started at that same company two years later. She was smart enough to get a referral from her alumni network, who had also gotten the job through an alum connection from a third person who had worked her alumni network to get the job through the wife of one of our executives. It was a triple-bank shot, with absolutely no chance of working, but without it, I would never have met my wife.

My luck continued. At my next job, I helped find one of our early customers, who was a prominent alum I had met because he hired a few of my friends (fellow alums of both of us). The work we did for them eventually led to a patent and getting VC money to pivot to a startup. This was more than 25 years ago, and I am still on the board and participating in their successes. More than 90% of my 2024 income came from connections I made there.

From the outside, it looks like randomness, and it is, but there are things you can do to move the odds, and networking with alums is an easy one.