Design exercise
The interview simulates a real-life design collaboration. The goal is to build something together and to understand the way the candidate thinks about design in practice, and to experience their process.
What we would like to learn:
- How they think and ideate
- How they collaborate with product and engineering
- Their facilitation strategy
- How they approach a problem, and what considerations they make
- Can they communicate in an organized way? Can they explain their reasoning?
- See purpose section for each exercise
Prompt
Send the following prompt to the candidate to prepare for this interview:
Part 1: (~15 min) Pick a developer application (e.g., code hosts like GitHub or GitLab, cloud providers like AWS or GCP, monitoring tools like Lightstep or Sentry, etc) and walk us through what works well and what doesn’t. We do not want you to prepare a presentation or script, but should come knowing which application you want to use as an example and be prepared to have a conversation about it.
Part 2: (~60 min) We will give you a specific problem to solve for Sourcegraph and would like you to walk us through your design process. We will be evaluating the process, not the final outcome of the solution. Please be prepared to work in your favorite design tool for wireframes and low fidelity mocks.
Exercise 1 (15 min): Pick a developer application
Purpose
This exercise tests the candidate’s ability to articulate design problems, design decisions, how they would improve a tool, get a taste of their process, and how they would collaborate cross-functionally. The goal is to test their core role knowledge about design, to understand their technical knowledge, and how they think about information architecture.
Questions
Pick a developer application (e.g., code hosts like GitHub or GitLab, cloud providers like AWS or GCP, monitoring tools like Lightstep or Sentry, etc) and walk us through what works well and what doesn’t.
Ask follow up questions:
- Why do you think this was done this way?
- What works well?
- Pick two critical user journeys, one that works well for you as a user, one that doesn’t.
- How would you change it?
- Continue asking why repeatedly.
Exercise 2 (~60 min): Sourcegraph exercise
Purpose/goal
Our goal with this segment of the interview is to approach a problem as if it were a new initiative which requires design, product management, and engineering collaboration. Our PM will present the business requirements and overall objective. Our engineer will act as both an engineer on the project and will also serve as a user who can be interviewed on the subject matter. We will look to the designer to guide the session from a research and product design perspective. During the session, we would like the designer to:
- Understand the business requirements
- Explore the scope of the project
- Determine a project plan for the design aspects of the project
- Explore solutions for selecting repositories in a fidelity and design tool of the candidate’s choice.
Please note:
The chosen problem has been implemented, so interviewers will need to role-play their involvement slightly. Our goal is to make the exercise as close to a collaborative working session as possible. This does not mean our solution is the right or best solution, and we are not evaluating the outcomes of this session against what we’ve done in the past.
We are not providing the interview ahead of time to ensure all candidates have equal time to devote to the problem, regardless of external commitments. This means the session will be contrary to our typically async method of working, but we feel it is more important to respect the candidate’s time than to replicate our process exactly.
We will evaluate the following:
- Can the candidate lead the room, keep the group focused, and facilitate the exercise.
- How does the candidate explore new problems and get the information necessary to complete a task
- How does the candidate handle conflict and deal with adversity?
- Does the candidate help participants structure their feedback and generate consensus?
- Do they summarize the outcomes of the discussion?
- Do they explain the different methodologies available for each stage of the design process?
- Have they demonstrate competency/familiarity with the phase and depth and variety of tools mentioned in each phase.