Category Archives: Software Jobs

Apples and Oranges are (Relatively) Easy to Compare

I don’t like stack ranking because it’s hard to compare people into a rank ordering.

One of the most surprising things I learned in math was that complex numbers had no natural ordering. Meaning, less-than and greater-than are not defined for complex numbers. It makes sense when you think of it for a minute. The same applies to other multi-dimensional things like matrices and vectors.

So, why do we think we can rank order people? I’m specifically talking about companies that do this for their employees, but it comes up in other contexts (e.g. class rank).

People are hard to compare, but when we say that it’s like comparing apples and oranges, I disagree. Apples and oranges are both fruit, they both have around the same number of calories, they are about the same size, shape, and cost. They are easy to turn into snackable pieces (slices or segments). Even for me personally, I like them both about the same. On a lot of dimensions, they are about the same. When that’s true, the comparison might turn into just a single dimension where they vary more—maybe only in specific situations.

For me, the main way they are different is in how they travel. Eating an orange is more of a mess and harder to deal with outside of my kitchen. I’m much more likely to grab an apple to throw in my hiking bag or take to the beach. Another way is in recipes. I know a lot more apple desserts than orange ones. It stands up to baking better.

But, how about apples and raisins, or apples and candy, or apples and tempeh, or apples and bicycles. Those are harder to compare because they vary on more dimensions. In the bicycle case, they don’t even share dimensions except generic ones—they are both objects that have size and weight.

Getting back to stack ranking (which I still don’t like). Inside of a team it makes no sense to me. You would have a mix of levels and experience. That mix makes the team valuable, and arbitrarily favoring a dimension hurts the mix.

Like comparing apples and oranges (which is easy), it would work better if you could remove dimensions and only compare one or two. So, for example: compare just your backend senior developers with each other on just system design skill. You could reduce the set to just those with two years at this level. This might be useful when considering a promotion. In this situation, you might value mentoring and consensus building skills more than in-depth knowledge of TypeScript. So, it’s situational (like which fruit to use for a pie) and has reduced dimensions. Another advantage is that you don’t need a full ordering to complete the task.

Leet Code at Work

I prefer work simulation questions to leet code questions for tech interviews. I like to ask interviewees to write code that is similar to what we actually did was better than, for example, finding a successor node in a BST. At Trello, our tech interview would have you refactoring code in a way that is very common in iOS or implementing a UI from a spec. At Atalasoft, we had a lot of image processing algorithms in our code base, so I wanted to see you do something simple with pixels.

The other day I was thinking about my career and trying to remember if I ever did have to code a custom algorithm given a specification, and I did come up with a few examples. I’ve written before that my career happened to have a lot of math in it, and those same jobs sometimes also needed me to implement algorithms.

But more often, I chose algorithms (or knew that I needed to). I think that’s a more universally useful skill. It’s often the case that something just isn’t fast enough. A lot of published and common implementations of algorithms work well for the general case, but you may be able to make some assumptions in your specific application that allow you to do something better. Or your particular workloads might make a different set of trade-offs more appropriate.

To do this, it’s good to have broad knowledge of a bunch of choices, just so you know what techniques might be possible. These days, I think AI can help you a lot with this, but it helps to know what to ask for and when to ask for it.

Why LinkedIn Works For Me

With all the talk of migrating to either Bluesky, Mastodon, or Threads, I’m happy that I “migrated” to LinkedIn two years ago.

I joined LinkedIn in 2003, but it was mostly a place to keep my resume for job searching and to message former co-workers.

But, now I use it more like a combination of a social network where I want to stay connected to real-life colleagues and a place to try to get business by networking with potential clients.

My goals with LinkedIn are:

  1. I want to be ambiently aware of which of my ex-colleagues might be looking for jobs and which might be hiring, so I can introduce them to each other. LinkedIn (for whatever flaws it might have) is the best way I have found to do that.
  2. For my business, I want to reach software developers when they are thinking about work and career growth. I want to reach software company tech leaders when they are having problems that I might be able to solve. That happens on LinkedIn and not many other places.

To do those things, LinkedIn has several advantages over other social networks for me:

  1. I see no political content or ads. I checked the box in Settings to turn off political content, and that’s been effective.
  2. LinkedIn shows a normal, time-based (non-algorithmic) feed if you request it in Settings, and it stays that way.
  3. People here seem to be real, not bots. If someone auto-posts their work’s content or is posting a lot that I don’t want to see, I unfollow them, unless I know them well.
  4. Comments on my posts, even by strangers, are civil. Generally, people are positive and casually professional.
  5. My ex-colleagues are here in large numbers, and mostly they talk about work/career things.
  6. There aren’t a lot of posts, and almost every one of them is an update from someone I care about talking about what’s going on in their career. When I read them, I don’t think of myself as doom scrolling — it’s the opposite: it sparks joy to see my friends succeeding.

Twitter was never any of those for me, and so it was easy to give up. It didn’t help me accomplish my goals for using a social network, but worse, it was addictive and a waste of time, so I had to block it. I’m sure Bluesky and Threads are a better Twitter, but I doubt they are a better LinkedIn for how I use it, and as bad as Twitter in all the ways that matter to me.

Not Rejected, Just Not Picked

When I was interviewing software developers in the 1990’s, it was very common that people would apply that could not code at all. I don’t think they were nervous or that the question was unreasonable. We were a C shop and the question I opened with was in K&R and just a simple question about arrays. Many candidates could not give any answer. I wasn’t the only one seeing this, which is why FizzBuzz was created.

These days, I hardly ever see that. Nearly everyone I interview can code and can answer the simple questions. Many can answer any reasonable question. This means that we often had more than one good candidate.

But we still had only one job.

The problem is similar to what I wrote yesterday about layoffs. You might need to layoff a person you would hire if you had the budget. In both cases, that person is not really rejected, they just didn’t get picked from (what was probably) multiple good options.

Hype and Career Bets

My professional career started in 1992. Since then, there have been a lot of hyped technologies, but I only really have acted on very few of them. Most of them, I let go by without taking much action.

I only took big career bets on the web and smart phones. Before I learned how to program for them, I used them every day. Then, I taught myself how to develop for them and changed jobs to do it full-time. In both cases, going from a place where I was very comfortable to a startup.

I passed on nearly everything else: social media, web3, blockchain, big data, ML, functional programming, NoSQL, cloud infrastructure, VR/AR—I know them “enough”, but they were not big factors in my career. Partly it was because I was still benefitting from being an expert, but mostly because I wasn’t personally excited by them as a user or as a software product maker.

I’m thinking about this, because we’re in an LLM hype cycle now. I use products based on it nearly every day. I feel like I did when I used the web and smart phones. I’m getting a lot of value and I want to know how to make things for it.

Knowing What You Don’t Want

When I wrote that I think job seekers should write a job statement to help narrow your search, I listed twelve ideas for what to put in it. Many of the ideas are either/or type questions about company size, industry and so on. What I didn’t consider in that post is how useful it might be to just rule things out.

After working in IT for a non-profit for two years, I realized that I only want to drive revenue, not cost reduction. I also decided many years ago not to work in AdTech or Social Media. I now think of my job statement as being a positive statement about only working in B2B SaaS, but it took me a while to narrow down to that.

Ruling things out helped me get there eventually.

QA is Valuable When Releasing is Expensive

In 1992, at my first job, to release the software, someone took a few days to make 100’s of floppies, and then we all stuffed envelopes so we could mail them all over the world. Our customers were banks who only adopted new versions carefully. Releasing was expensive, so releasing with a critical bug was unthinkable. It’s not surprising that the person who did the most QA work was one of the leaders of the company who was a former customer and had deep domain expertise. To help him, we built custom test automation tools.

These days, releasing is so cheap, that it feels like software companies are fine with releasing a bug. Between the time that Apple sent out iPhone 15’s and the time most arrived, they released iOS 17.0.2, which fixed a critical bug transferring data. Apple has a support doc showing how to recover, so we know it happened to customers, but most people were guided by the installer to update their OS, and it was fine, I guess.

That’s an OS release, which used to be hard. Meanwhile, the cost of releasing a web app has been near zero for a while, and it’s a joke in the industry that the customers are the QA team.

If I were looking to do QA in this environment, I’d seek out software that is expensive to release.

It takes very little to stand out

One thing I tell mentees, particularly those in college looking for internships or their first job, is that they have to think about what the job application process looks like from the other side. When an employer opens a job position for an entry-level position, they will be inundated with resumes. The vast majority of them are indistinguishable from each other. They have the same classes, GPAs in the same range, similar job histories. You have to be honest with yourself with whether you’d stand out in that pile.

What you should do depends on the situation, but the general idea is to do more than your peers. The good news is that your peers (when you are entry level) are pretty clueless. It takes some effort, but it’s doable.

Do research, follow up, network, find peers that were successful and get intel on interviewing. Just don’t assume that you are done once you send in your resume.

Using Recruiters for Entry Level Developers

I graduated in 1992 and got my first job using a tech recruiter. It was for a small company in FinTech with less than 20 people when I joined. While I was there we hired a lot of entry-level developers, mostly from college recruiting, but we did use recruiters too.

30 years later, I think it’s rare to use a recruiter to hire entry-level developers. There is a lot of supply. There is certainly as aspect to recruiting in what the code bootcamp schools are doing, but from the hiring end, I haven’t been at a place that used recruiters for junior developers for quite a while.

But, one exception I noticed is in FinTech. John Easton, who got me my first job, and who is one of the best recruiters in NYC, seems to frequently have entry-level FinTech jobs. Here’s one he posted today.

If you are in the market for this kind of work, especially if you are in NYC, I’d follow his account.

1960’s GE Trained Programmers

This is the third installment of a series I didn’t know I was writing

Today, I met Tom, who got his start working for a cotton mill owned by his father-in-law. In 1964, the mill was buying a mainframe, and his FIL convinced him to apply to GE to become a programmer: “He told me it was like putting railroad tracks together”. It wasn’t.

GE hired him and then trained him to write COBOL in a few weeks. They placed him on other cotton mills to code order taking software.

That led to a lifetime in programming. He started a company that automated letter writing for members of congress (writing “customized” form letters back to constituents based on their interests). Al Gore was a customer.

Today, he still runs a company that advises mainframe programmers on performance and other matters.

But, it all started because GE was willing to hire and train someone with no experience. It’s a lesson that I continue to hope will be relearned.