The Technical Architect interview process
A description of what GDS Technical Architect job interviews are like, and how the interview process works.
Introduction
Our interview process currently consists of 3 stages. These are:
- A review of your application.
- A phone interview.
- A face to face interview.
The recruitment process for technical architects is different from the GDS developer recruitment process.
The face to face interview involves a role play exercise rather than the pair programming exercise used in developer interviews. This role play exercise is technical but also assesses how candidates interact with non-technical stakeholders or domain experts.
Applying
We ask candidates to apply with a cover letter and CV. The cover letter is important and will help your application reach the next stage of the recruitment process. Although it may feel like your CV gives us all the information we need to understand your history and skills, it can sometimes be difficult to interpret.
The cover letter is your chance to:
- highlight any experience that meets the job description
- talk about what you want to get out of working with the Government Digital Service (GDS)
Phone interview
Our phone interview stage is relatively short and has a technical focus. The questions we ask are on issues arising out of building and operating services within GDS.
This stage checks whether you can work with the technologies we use rather than discussing your career and experience to date.
At the end of the interview, you can ask us questions about the role of technical architects, working at GDS in general or how the interview process works.
With this question time included, most phone interviews last around 30 minutes.
To prepare for the phone interview, you can look at the open repositories in our Github repo to see the kind of technologies we use and how we structure projects.
GDS blogs frequently talk about the kind of work we do. It’s worth reading through the posts to get a sense of our work.
Face to face interview
The face to face interview is made up of 3 stages. These are a:
- number of competency-based questions around the civil service competencies
- presentation exercise based around a fictionalised historical problem GDS has dealt with
- series of short technical questions
We will then take you on a short building tour.
The interview is usually 2-3 hours long but can vary in length.
Competency questions
We use competency-based questions so you can illustrate your skills and experience. They allow you to demonstrate your capabilities through short anecdotes about things you have done.
They do not have to be drawn from work situations as long as they are relevant to the question.
Examples of competency-based questions would be: “tell me about a time you had to persuade people to take a course of action” or “describe a situation where you had to deal with tight deadlines”.
Answering competency questions
While most successful software projects result from effective teamwork, it’s important to tell us about how you contributed to the project in competency-based interviews. You should use “I” not “we” when answering questions.
You should tell the interviewers what you had to do to complete your work, including:
- what you had to learn
- how you successfully resolved situations
Don’t worry about sounding egotistical. Interviewers find it useful to understand what skills and knowledge you bring to teams.
When answering questions in the interview it’s important to know you can:
- ask for a little time to think about your answer, if you need it
- ask for clarification to make sure you’ve understood the question
- summarise your possible answers to check you have understood the question, and let the interviewers choose which one they think is most relevant
- follow the interviewer’s lead if they ask a follow-up question - try to provide more detail around what they are asking
- check with the interviewers if you feel there was a problem with your answer - they may ask a supplementary question, or tell you the answer was fine
The STAR framework
If you haven’t done a competency-based interview before you can use the STAR framework, the acronym for situation, task, action and result.
- Situation - explain the background and context to what happened.
- Task - explain what you needed to do to resolve the situation (this could include the people, skills, knowledge or work involved).
- Action - explain what you did to resolve the situation and complete the tasks you identified.
- Result - explain the result of your actions and how the situation was resolved (you can also explain what lessons you learned and anything you may do differently in a similar situation).
Presentation exercise
As technical architects, we are often asked to review technical proposals or problems and provide feedback or outline solutions. We test the necessary skills you need to review and feed back in the the presentation exercise. For example, we may ask you how you’ve conducted a project review or decided on a budget request.
During the presentation exercise you can expect:
- to receive a written statement of a problem
- one of the interviewers to leave the room and the other 2 interviewers to take on the role of non-technical advisers or domain experts on a project
- to have 30 - 45 minutes to question the domain experts and produce a design that meets the problem statement requirements
- to verbally brief the returning third interviewer on your proposed solution
- to answer questions from the third interviewer to clarify their understanding of your proposal
Tips for completing the presentation are to:
- read the statement carefully (there are no tricks or hidden information, but like in the real world, the problem does not have an obvious, easy solution)
- take advantage of the advisers and ask them as many questions as you need to so you can understand what constraints a workable solution may have
- make sure you understand where you are compromising - all software projects require a trade off between requirements, deadlines, scope and capacity
- think about what is required to support the solution and deliver
- use the information you’ve gathered to prioritise and plan how you’ll meet the priorities
- consider what the most important things are to understand about the work you’re proposing, and make sure you convey them in simple and direct way during your presentation
- think of how you will present the complex problem - you should give a high-level overview and then answer any questions with more detail, like you are briefing your boss on an elevator ride
Technical questions
The technical questions during the interview are like the ones in the telephone interview. We ask short, open questions relating to the development work and design problems we’ve experienced at GDS.
You will need to decide whether you give a broad or an in depth answer. You can discuss the kind of answer that would be appropriate with the interviewers.
Candidate questions
Interviews are a two-way process. At the end of the face to face interview you have the chance to ask us questions. Take this opportunity to find out as much as you can about the role so you can decide whether you would accept an offer to join us.
We are happy to tell you about:
- any aspect of working life for technical architects
- working at GDS
- how we deliver and operate services, our agile delivery process and the way our multi-disciplinary teams work together to own and solve problems
- our current public projects and plan
- how people have been successful in the role before you
We will try and address any concerns you may have about the role, but we cannot discuss salary, annual leave or other contractual subjects at the interview. We need to complete the whole interview process before we can begin the negotiation.
Starting at GDS
If you are successful we will negotiate a start date with you. Once the date is agreed, we will talk to you about particular placements and projects that may be available when you start.
If you have a long notice period, we will try to arrange a meeting with you and your prospective new teams. This will help you understand what role you will play in your new job, what the team is working on and the challenges they need to overcome.
We will invite you to any community events happening during your notice period, so that you can get a better understanding of GDS before you join.
You will also be given a point of contact from the technical architecture community who can help you with any practical issues or questions you have while you are waiting to start.