Category Archives: Software Jobs

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.

How to Signal That You Are Open to Work on Linked In

If you do not currently have a job and want one, you can mark yourself with an Open to Work badge on Linked In. If you have a job, but are open to opportunities, there are ways to signal that without saying it outright.

The first thing you should do is make sure your current job and relevant ones are up-to-date. To show that this was a recent update, perhaps work in the month and year of a recent accomplishment. Generally, updating your resume is a signal that you are open to opportunities. I recommend customized resumes when applying to jobs, but that’s not possible on your Linked In profile, so customize it for the job you wish someone would approach you about.

Make sure your settings are set up so that you are accepting contacts, and that you are open to being contacted. This isn’t as visible as the green Open to Work badge, so it won’t draw attention from your current job, but it lets people know that you are ok with messages.

To draw some attention to your profile, you should have some activity. Reposts and comments are probably good enough.

Finally, it doesn’t hurt to expand your network. Visit profiles of people that might be interesting to work with and try to connect to them. You might find a chance to build a positive association with them over time. If you have people in your network that would write a recommendation, ask them for it.

Every time I talk to people that don’t use Linked In, they assume that you have to become a LI Influencer to get any attention, but for software developers, it’s enough to just be on it with a filled out profile, a decent network, and some light, but consistent activity. There are lots of people looking for you, and so you just need to make it look like you want to be contacted (if you do).

Job Seekers Should Have Some Linked In Activity

If you are looking for a job, and have a Linked In account, it helps to have some activity in your account.

You don’t need to be a Linked-in influencer, but if there is no activity (or the last thing is very old), then I would assume that person doesn’t even use Linked In. When I’m looking for developers, I skip those profiles because it doesn’t look to me like they want to be contacted. If you are open to being contacted, create some activity—all you need is a few comments and reposts.

If you are looking for something to post, just post that you are looking for a job and what specifically you are looking for. Be specific. Build a Job Statement, and then use that.

I suspect that Linked-in will put you higher in search results as well.

    The Most Consequential Clojure I Ever Wrote

    In my congratulations to Rich Hickey, I mentioned that clojure influenced my code, but that I never wrote any professionally. I did, however, apply to a job opening at FogCreek/Trello with clojure code. They gated the application process with a programming question.

    I call this code the most consequential clojure code I ever wrote because it got me an interview at FogCreek, which ultimately ended up in me working at Trello for almost seven years, during which we were acquired by Atlassian.

    Since the question has been publicly answered many times, and is no longer used, I’ll reproduce it here:

    Find a string of characters that contains only letters from “acdegilmnoprstuw” such that the hash(the_string) is 910897038977002.

    If hash is defined by the following pseudo-code:

    hash (s) {
    h = 7
    letters = "acdegilmnoprstuw"
    for(i = 0; i < s.length; i++) {
    h = (h * 37 + letters.indexOf(s[i]))
    }
    return h
    }

    For example, if we were trying to find the string where hash(the_string) was 680131659347, the answer would be “leepadg”.

    I chose to use clojure because I didn’t know how big the value of h was going to get and wanted access to clojure’s implementation of BigInteger, which is seamless. All integer math in clojure promotes up to whatever size integer it needs. Once I thought of using clojure, I realized that it would be seen as a fun choice by the developers reviewing the code since FogCreek had a reputation of hiring developers that were interested in weird programming languages (see wasabi).

    If you don’t want any hints on how to solve this, stop here.

    So, they are asking you to invert the hash() function. In general, hash functions should not be invertible, but this hash is made by using simple lossless integer arithmetic with * and +, which both have inverses (/ and -). Each step of the function is invertible, so the function itself is invertible.

    I decided to start with just implementing their pseudocode in clojure.

    (defn fchash [arg]
      (let [letters "acdegilmnoprstuw"]
          (loop [h 7 s arg]
              (if-let [c (first s)]
                  (recur (+ (* h 37) (.indexOf letters  (int c))) (rest s))
                  h))))

    And to make sure this was correct, I evaluated (fchash "leepadg") to make sure I got 680131659347.

    There are a few tricks to inverting the code.

    First, you need to figure out when the loop is done. You don’t know how long the string is supposed to be, so you need to detect somehow that you are done. For this, note that the hash is originally seeded with the number 7, so we expect that we’ll eventually get back to this number in the inverted version.

    Second, you need to figure out what number was added after the hash was multiplied by 7. To get that, you can use mod 37 because the number must be less than the length of the letters string (which is 16) and 16 is less than 37, so using mod gets you the number that was added to the hash after it was multiplied by 37.

    That should be enough to attempt an answer (in whatever language). If you want to see what I submitted, look here: Clojure inverse hash.