Technical interview guide

The goal of the technical interview is to assess the candidate’s technical skills and thought processes when solving technical problems.

Watch out for unconscious bias!

Remember that we all have unconscious bias, and that hiring is especially susceptible to bias. However, when we recognize and accept bias we can be on the lookout and it’ll be less likely to unconsciously guide our decisions.

Learn how.

Research shows that the effect of unconscious bias can be profound. For example, in one study, “applicants with white names needed to send about 10 resumes to get one callback; those with African-American names needed to send around 15 resumes to get one callback.”

This bias prevents us from achieving the results we want, which is to select the best possible candidates regardless of background.

Humans are not only biased, but we almost never realize that we’re being biased. However, when we realize and accept bias, and recognize it, we can be on the lookout for bias and it’ll be less likely to unconsciously guide our decisions.

In that spirit, here are a few ways you can look out and correct for bias during the hiring process.

Review these guidelines before every interview or round of resume review. Studies show that we’re less biased when we’re conscious of our own thinking, so continually reminding yourself to be aware will help.
Remember that we’re especially susceptible to assume that underrepresented minorities — women, people of color, etc. — are less qualified than their white male counterparts. When considering candidates from underrepresented backgrounds, check your thinking about qualification. Ask yourself: am I reading this person’s qualifications the same as if they were white, male, etc?
Continually re-check the guides and scoring rubrics to make sure you’re reviewing fairly. After a while, you’ll start to feel like you’ve memorized the guides and rubrics. This is good since it’ll help you be more efficient, but our memories are fickle things. The more you remind yourself of the concrete, established metrics, the less likely you’ll be to make “gut” decisions that could be colored by bias.
Watch out for assessments of candidates that may be colored by age, gender, race, etc. For example, we tend to be more likely to use words like “aggressive” or “competitive” when describing men, vs “supportive”, “nurturing” when describing women. Are you surprised that an older person has cutting-edge technical skills? Ask yourself if an assessment might be colored by an applicant’s demography.
Don’t check out the candidate on social media, or Google them. A person’s public profile almost certainly won’t have anything relevant to work, and might instead reveal all sorts of irrelevant information (age, gender, political affiliation, race, etc.). If the candidate application/resume links to a personal website, LinkedIn, or GitHub you can check those out — these are more work-focused, and we can assume a candidate has put what they want an employer to see there. If you use Chrome, the Unbias Me extension (written by Fureigh) can help by removing avatars and names on some websites such as LinkedIn.
If you come to a conclusion about a candidate very quickly, before you’ve read the whole resume or finished the interview, spend the rest of the session trying to disprove that conclusion. Snap judgments are much more likely to be prone to bias than considered ones. We tend to jump to conclusions and then look for evidence to support our hypothesis. To compensate, if you find you’ve reached a Yes/No conclusion very quickly, spend the rest of the session trying to disprove that hypothesis. Explicitly look for evidence that you’re wrong. If you’ve decided immediately that a candidate is not qualified, spend the rest of your time trying as hard as you can to find evidence that they are qualified.

Purpose

The technical interview accomplishes two purposes:

Determine if a candidate can break down complex technical problems into sensible pieces. We’re often asked to solve abstract and complex problems which require breaking apart and understanding a larger system.
Communicate and teach technical concepts effectively to people who many not have technical experience. We need to communicate in an understandable way about all aspects of modern software development without getting lost in technical jargon. For our partners to trust us, we need to be transparent about what‘s in our wheelhouse and what isn’t — no faking of experience or speaking about topics which aren’t understood.

The interview should last roughly one hour, and include some segments in which the interviewers provide more detail about 18F to the candidate and openly share their experiences working at 18F — remember, interviewing is a two-way street!

Remember to be as pleasant and friendly as you can be! You can deliver a demanding interview while being kind and empathetic.
Whenever possible, ask questions exactly as they’re worded in the guide to try to get consistency between multiple candidates.
For more information on interviewing in general, check out the interviewing overview guide.

Before the interview

Take a few minutes to familiarize yourself with the candidate’s resume and review 18F only, the good and bad signs for the questions you’ll be asking.

You will receive a copy of the notes template prior to the interview.

18F only, View the notes template

Conversation outline

Take behavioral notes.

When taking notes, note what the candidate says, rather than your impressions. This helps combat unconscious bias and will help you share the reasons for your conclusions and decisions.

See an example.

Try to note what the candidate says, rather than your impressions — that will help you share behavioral reasons for your conclusions and decisions. That is, try to write down what the candidate said or did, rather than how you felt about it. For example:

✅ Good	❌ Bad
“candidate ‘forced engineers to do \$X’” (captures what a candidate said)	“candidate has an adversarial relationship with engineers” (interpretation of what they said)
“candidate has maintained an \$X as an open source module for 2.5 years” (captures what a candidate did)	“candidate is a good open source maintainer” (your feelings/interpretations of what they’ve done)

Begin by introducing yourself by saying this or something similar to it:

Hello! My name is ___, my pronouns are ___, and my role at 18F is ___.

Thanks for interviewing with me today. This will be a behavioral interview, which means I’ll ask a series of questions about experiences you’ve had and how you handled them. There are no “right” answers; I’m interested in talking through these situations with you. I’ve got about [4-5 questions], and this will take us about an hour, perhaps a bit less. Don’t be surprised if others ask the same questions in other interviews; that’s normal. Feel free to think for a moment before answering if that's your style - you won't be judged for it.

There will be times when I ask for more information, or want to dig deeper into your answers. That’s normal: I want to make sure I understand what you did and why. I’ll be taking notes, please don’t let that distract you.

My questions will take about 40 to 45 minutes or so, and then we’ll have the remaining time to answer any questions that you may have.

I’m excited that you’re here — any questions before we get started?

Problem solving

These questions probe for the ability to design, analyze, synthesize and/or evaluate information to produce and defend a desired solution. Preface by saying there’s no right answer, that we’re just looking to talk through the problem with the candidate.

Help guide the candidate to the right line of thinking, don’t allow them to get too bogged down in the wrong line of thinking — help them get back on track.

"Let’s say your team is working for the Public Building Service, an arm of the GSA that is responsible for the maintenance and upkeep of all government buildings. They’ve asked you to create a feature where a building inspector can upload photos of their building inspection findings so they can document them visually and ensure issues are fixed. How would you approach the design and build for this?"
"Tell me about a difficult technical problem that you helped solve: what was the problem, and how was it solved?"

Agile orientation

"Whether or not you’ve had direct experience with agile, in an agile environment, how do you analyze trade-offs between technical approaches to problems you face?"

Position-specific questions

If the candidate is applying for a specific technical role, ask the relevant position-specific questions.

Communication

"Pick a foundational web development concept or technology and explain it at two levels: first as you would to a colleague who's not a software developer, like a designer or product manager; next, as you would to an engineer."

Testing and refactoring

"Tell me about your approach to software testing. Why is it important and when have you done it? Where does it belong in the process?"
"What does refactoring mean to you? Why is it important and when have you done it? Where does it belong in the process?"

Production readiness

Thinking both technically and non-technically, what do you consider when getting an application or system ready for production?
You're tasked with writing a guide for developers about ensuring high reliability for a web application. What topics would you cover?

Security and stability

Tell me about an infrastructure problem that you helped solve — for example, slow performance, unexpected downtime, a security breach, etc. What was the problem and how did you solve it?
Tell me about a time that you worked with a team to remediate a security issue.

Conclusion

Make sure to leave time for the candidate to ask you any questions they might have — remember, interviewing is a two-way street!

After the interview

Thank you for your focus! Use your notes to fill out the feedback form linked in the calendar invitation, which will prepare you for the debrief meeting.