Category Archives: Software Jobs

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 wrote COBOL in a few weeks. They placed him on other cotton mills to write 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))

    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.

    Time Zones are the Hardest Problem in Remote Work

    I was recently asked for advice on getting US Remote work from outside the US. There are several things you need to figure out, but while most can be worked on, time zone overlap is the hardest to overcome. Even inside the US, it’s an issue.

    When I worked at Trello, we were about 70% remote, but almost all of us were in the US, Canada, or Latin America. We required that everyone work NY afternoon hours (12-5pm Eastern US). In the UK, that’s 5-10pm. Practically, this meant we didn’t have very many people in the UK and Western Europe, and I can’t think of anyone more East than that.

    After we got acquired by Atlassian, we had some contractors in Ukraine who partially worked our hours. When Atlassian announced Team Anywhere, their remote policy, time zone overlap was a big part of the requirement for long-term remote teams. I personally had to interact with people in Sydney sometimes, and time zones made that painful.

    This is just a single company, but time zone overlap was part of the secret sauce that made remote working better for us.

    So, if you are outside the US time zones and are applying to remote jobs, I would think about how much time zone shifting you are willing to do. Perhaps you really like working extremely late (my father worked nights when I was young). If you think you’d like it, then I would say that directly in your cover letter. Also, I would concentrate on the part of the US that is easiest for you to overlap with.

    I Will Give You Homework

    It’s my goal to sponsor (not mentor) people that come to me for help. This means that instead of giving advice, I want to directly help by using my own social capital on their behalf. But, to do this, I have to have some basis for recommending or vouching for them.

    I have two strategies for this—direct hiring and homework. If I have work they could do, I hire them to do it. Usually a small project. Their work on that will be the basis of my recommendation.

    But, I don’t always have work that is easy to bring someone in on. In that case, after hearing where they are having trouble (usually in job seeking), I give them some tasks that I think would help, and ask them to get back in touch to let me know how it goes. If they do something (not necessarily what I asked, but anything that addresses the underlying reason I suggested it) and follow up, then I will feel a lot better about sponsoring them, usually by setting up informational interviews.

    Another Story from an Early Programmer

    A few years ago I had dinner with someone who became a programmer in the 1950’s. Today I had a chat with someone who became a programmer in 1970. Here’s a paraphrase of her story.

    I was an accountant, and my boss asked me to price a computer and database for the sales team. I talked to a distributer and he gave me a price for the computer, software, and services of about $10,000, which was within our budget.

    Before I made the purchase, I made sure it could do what we needed, and I said that the computer would need to be able to calculate logarithms. The salesperson said that this computer could only do addition, subtraction, multiplication and division. To do what I needed, I would need an IBM 360 (which cost a lot more).

    This didn’t sound right to me, so I bought a programming book and learned enough to know that (a) computers were going to be a big thing (b) the people working in it right now didn’t know what they were talking about (c) I could do well because I understood it immediately.

    So, she left her job and went back to college to learn programming, starting with FORTRAN (spoiler alert: it supports logarithms). She ultimately had a career as a programmer and manager, retiring early.

    Costly Signal Theory Applied to Job Applications

    If a particular job is your top choice, you should be willing to do more than is necessary to get it. In evolutionary psychology, this is called a Costly Signal.

    A costly signal is something we evolved to show genuine fitness in a world where there has been an arms race between deception and deception detection. You prove your fitness to a skeptical evaluator by doing something that is relatively easy for you, but would be too hard for someone less fit. It has to be something that is hard to fake.

    Because it can’t be fake, the first step is genuine two-way fitness between you and the job. In a normal job search, it’s likely that you will know this before the employer. So, if you feel like a job would be an excellent choice for you and that you would be the top candidate for it, your behavior should reflect this belief.

    The extra work you do should be relatively easy, but not necessarily easy. If it feels like too much work, then that might be an indication that the fit isn’t good. I would caution that some people undervalue themselves. If you have this tendency, then I’d get an opinion from a colleague or mentor of what they think your chances are.

    Related articles

    Just Started a New Software Engineering Job? Fix Onboarding

    If you are about to start a new job as a software engineer, the way to have a big impact day one is to go through the onboarding with the intention to generate a list of improvements that you work on over time.

    Here are some things to look for

    1. Incorrect or outdated information. If you find these, just fix them as you find them.
    2. Missing entry-point documentation. Even teams that have good documentation often do not have a document that is useful if you know nothing. Often they don’t go back and make a good “start here” kind of document.
    3. Manual steps that could be scripted. Don’t go overboard, but if you see some quick wins to automate the dev setup steps, it’s a good first PR. It’s a tech debt payoff that is timed perfectly.
    4. Dev Setup Automation bug fixes. If anything goes wrong while running the scripts to set up your machine, fix the bug or try to add in any detection (or better error messages) that would have helped diagnose the issue.

    There is usually a lot of tech-debt in onboarding code and documents because no one really goes through them. Sometimes underlying things just change and tech debt happens to you. You are in a unique position to make it better for the next person and have some impact right away.