Skip to content

Instantly share code, notes, and snippets.

@uglow
Last active November 10, 2021 00:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save uglow/f86a0d9954834670fbade1e31949484d to your computer and use it in GitHub Desktop.
Save uglow/f86a0d9954834670fbade1e31949484d to your computer and use it in GitHub Desktop.
Hiring process for software engineers working with web technology

Web & API Hiring process

This document outlines the process for hiring a software engineer who will be working on developing user interfaces for the web-platform and/or developing APIs.

General approach

  1. Introduce ourselves and set expectations that tech interview will take 30 - 90 mins with the aim to find out where candidate is strong and where they are weak (3 min)
  2. Introduce company - what we do, clients, working environment, practices (3 min)
  3. Ask what they are passionate about, things they are proud of in their career so far, how do they learn new things, presentations they've made, blog articles (etc) (6 min)
  4. Technical interview (20 - 80 mins)
  5. Candidate questions (if any)

Technical Interview

The purpose of this phase of the interview is to measure (in order of importance) the candidate's:

  1. Level of experience in different technologies (beginnner, intermediate, senior, expert)
  2. Ability to work with and/or lead others
  3. Attitude and character
  4. Consulting skills

Approaches

There a few ways to measure the technical competency of a candidate. I've tended to rely on Domain Questions but included a small technical challenge as well.

The approach used needs to be adaptable to people with different levels of experience. For example, a junior engineer is not going to have much experience deploying an application to production, so don't focus on that. But an experienced engineer should be able to talk about 12-factor applications. Adapt the interview as you learn more about the candidate's experience.

Domain Questions

The general approach is to ask questions for different technical domains to assess their competency. Domains include:

  1. General software development
    1. Process of developing software within a team environment
      1. Branching & merging
      2. Design (layered applications) & patterns
      3. TDD (or not)
      4. Coding
      5. Testing
      6. Versioning & sharing code
      7. Deployment
      8. Monitoring
    2. Refactoring - how to you do it?
    3. How do you know your code is working?
  2. API development
    1. Design
    2. Data modelling
    3. Frameworks & tools
    4. Patterns
    5. Testing
    6. Deployment techniques and strategies
    7. Monitoring
    8. Security
    9. Performance
  3. Web user interface development
    1. Designing responsive/adaptive web apps
    2. Frameworks and tools
    3. Patterns (e.g. Component architectures)
    4. Testing
    5. Deployment techniques and strategies
    6. Accessibility
    7. Performance
  4. Language knowledge & techniques
    1. Programming paradigms (functional vs OO, strengths & weaknesses)
    2. JavaScript (or Java, Rust, Go, whatever)
    3. HTML
    4. CSS

Review their code

This step requires that the candidate is asked to provide an example of their code before the interview so that it can be reviewed before the interview.

Ask the candidate to outline the code-structure on a whiteboard first, then walk through the code.

Ask questions such as:

  1. Why did you choose that implementation?
  2. What would you do differently? What did you learn?
  3. How could the code be improved?
  4. What would you change if <new feature> was needed?
  5. How would you test <unit, feature, system>?

Coding test/challenge

This step requires that the candidate is asked to solve a technical problem ahead-of-time and submit it before the interview so that it can be reviewed before the interview.

Similar to the previous approach. You could ask them to pair-program (if you have appropriate hardware). The technical problem should be sufficiently large to be useful, but not so large that it takes more than 4 hours to complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment