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.

Why?

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.

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.

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 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.

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

I went to see an orchestra perform Beethoven’s Fifth last night, and it reminded me about what bothers me about typical tech interviews. If you want to be in an orchestra, you need to audition. That makes sense because an audition is close to what the job actually is—a performance. This also makes sense for actors, comedians, dancers, etc.

Programming is not a performance

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).

I’ve known this for a while. In fact, when I get asked for interview advice, I usually say this directly: “Treat it like you are a violinist trying out for the orchestra. Practice, practice, practice. Ask your recruiter what kind of code you’d typically have to write during the interview (algorithmic, UI, a full-stack app), and practice that. Practice the tools/IDE, frameworks, language, etc. Think of it more like performing a piece.”

Now, to be clear, I’m not a big fan of this kind of interview. But, often as job-seekers, we don’t have the ability to change this—especially if there’s a specific job we want. I had a 22+ year career, wrote a book about iOS development, and had many public artifacts of my work, but I got my last job by passing several “auditions” that I practiced for. I personally don’t intend to ever do that again, but I wanted this specific job, and this was the only way to get it.

Instead, let’s try portfolio review

What I think would be better is a portfolio review. This is what you’d do if you hired an artist, craftsperson, or other professional where the job is to produce works. Portfolios give us insight into what the person could make given typical conditions and not under time constraints with every mistyped keystroke interpreted as a short-coming.

We already know this. When hiring consultants to do tech work, it’s the norm to look at portfolios, and not to do a tech screen. When I was consulting, I prepared a website with a description of my credentials and links to my work. I was never asked to live-code to get a consulting gig.

The problem is that not everyone has a job that produces public works. Even if the product is public, we need to see the code, since that’s the part a programmer makes. There is some privilege in being able to have time to create these works.

But, I don’t think it needs to be a huge piece—it’s likely that an interviewer could only spend 20-30 minutes looking at it. The important thing is that the work conveys a positive answer to the question: “can this person do the job?”.

I wrote about portfolio-based interviews back in 2011.

If you don’t have a public project, and are thinking of preparing a portfolio piece, it doesn’t have to be a giant project. I think something with a dozen or so code files is about the right size to review. If you are showing me something much larger, then point out a part that I should focus on.

I’m kind of surprised that this hasn’t become more common by now, as it did seem like it was happening organically. GitHub links have been common for a while. StackOverflow introduced Developer Stories in 2016, which are focussed on showcasing your work. I have never seen one as part of an application.

Bonus: They could be blind

When orchestras started using blind auditions, gender balance improved:

Using a screen to conceal candidates from the jury during preliminary auditions increased the likelihood that a female musician would advance to the next round by 11 percentage points. During the final round, “blind” auditions increased the likelihood of female musicians being selected by 30%.

We could probably do our current tech interviews blind using a voice changer over a screen sharing service, but it would be awkward. A portfolio review is easy to do blind.

In fact, tech conferences that use anonymized proposals, often result in a more balanced speaker group. See !!Con:

Proposals will be anonymized to avoid bias. Although we ask for your name, email address, and so on in the proposal submission form, only one or two organizers who serve as anonymizers will actually see this information, and they won’t review your proposal. The rest of the organizing team will review your proposal without knowing who you are.

Here are the speakers that resulted from that process.

A blind process won’t guarantee a balanced result, but I believe we have enough evidence to believe it would improve balance.

What Employers Could Do

If an employer wanted to move to a portfolio review, I’d suggest something like the following

1. Explain it clearly in the job posting
2. Make it clear that the piece does not have to be big
3. Ask for code and writing samples (blogs, StackOverflow answers, etc)
4. Give some idea of the judging criteria
5. Offer to pay applicants to create the portfolio piece if they don’t have one. I would say to do this on self-reported need. Perhaps after passing a resume screen
6. Do it blind
7. Create a rubric that takes many attributes into account (not just “algorithm implementation”). Examples: documentation, tests, consistent code style, reasonable abstractions, correct use of language/framework idioms.
8. Train the judges and have each portfolio scored by many people

And for their current employees—give them time to create public works (open-source, blogs, etc).

I’d love to hear any any experiences on both sides of a code portfolio review. What worked, what didn’t. If you have something like a code portfolio prepared, I’d love to see a link.

The latest GitHub update includes some nice additions to the profiles page. A few years ago I wrote that you should never link directly to your GitHub profile in your resume or online bios:

GitHub’s public profile isn’t customizable and doesn’t do a good job of describing a person’s contributions. I recommend:

1. Create a page with a simple URL on your own domain (e.g. example.com/github) and write a narrative that takes me through your repositories.

2. Link to that page in your resume and in your GitHub profile.

I played around with my profile and even though it’s more customizable, my recommendation still stands: link to a page where you can put context around your profile.

In addition, I think it’s worth using the repository pinning feature to highlight the projects you would want someone to look at if they should get to your profile page some other way.

 

2022 UPDATE: Another added bonus is that you can verify links to your own site on Mastodon. I don’t think it’s possible to add the verification to GitHub.com.

2021 UPDATE: I revisited this recently in my post Use GitHub Profile Pages to Mirror Your Personal Site. Be sure to read that too.

Original

I look at dozens of tech resumes and StackOverflow Careers profiles a day and I’m glad that more of them have GitHub links with some code to look at. In 2011, I wrote that I thought tech applicant assessment should be more portfolio based. I described what I would be looking for as an interviewer — one point was:

I could use an orientation: I need a starting place. The bigger the project, the harder it will be to jump in and take a look around. Give me what you’d give a new contributor.

Now that I’ve been spending time in GitHub with the intent of understanding a developer, I can see that I need an overview of the whole repository. GitHub’s public profile isn’t customizable and doesn’t do a good job of describing a person’s contributions.

I recommend:

1. Create a page with a simple URL on your own domain (e.g. example.com/github) and write a narrative that takes me through your repositories.
2. Link to that page in your resume and in your GitHub profile.

What exactly you do on this page really depends on your specific contributions and what kinds of jobs you are applying to. I made a GitHub tour page to dogfood my own suggestion, but also because, as a consultant, I imagine that some prospective clients look at my GitHub. I decided that a reasonable organization of my page was (approximate) reverse chronological order, but that might not be right for you. If you have a particularly popular project, you probably want that at the top. If you are looking to get a job in a specific technology, you should highlight contributions using it. Most importantly, edit the list down to what someone should look at.

Another benefit of this page is that I can mix-in the non-open source parts of projects. For example, App-o-Mat is not open source, but the app template is, so I can highlight a project that you can’t even see very well on my personal GitHub page. I can also describe a contribution where the code isn’t very interesting, but context is.

Whatever your contributions, I am sure that your own organization of them will be a lot better than GitHub’s default.

UPDATE: I revisited this recently in my post Use GitHub Profile Pages to Mirror Your Personal Site. Be sure to read that too.