diff --git a/common-content/en/workshops/your-first-interview/index.md b/common-content/en/workshops/your-first-interview/index.md
new file mode 100644
index 000000000..19795d47d
--- /dev/null
+++ b/common-content/en/workshops/your-first-interview/index.md
@@ -0,0 +1,80 @@
++++
+title="Your First Interview"
+time=10
+objectives = [
+  "Introduce yourself to a prospective employer",
+  "Answer technical questions about code",
+  "Convince an interviewer that you fully understand a project",
+  "Experience a professional interview"
+]
+[build]
+  render = 'never'
+  list = 'local'
+  publishResources = false
++++
+
+Throughout ITP you have had experience building projects, giving demos, and now it's time to put it all together.
+Now you are at the end of ITP you will take part in a very short interview.
+This will let you practice answering technical questions about the TV Shows project you built.
+
+Interviews can be stressful, especially if you have not done one before.
+That's why we're doing one now!
+There is no pass or fail here, and you can share your experiences with the rest of the class.
+
+Being able to answer questions in an interview setting is a vital skill for employability, you won't get a job without this!
+This builds on the earlier "Answering demo questions" workshop, and improve your ability to communicate about code with colleagues.
+This is also practice before the Checkpoint stage, as completing an interview is a mandatory step before going on to the SDC.
+
+In interviews it is important to convince the interviewer that you fully understand the code in a project.
+You need to be able to explain _any_ of the code in your project, even if someone else wrote it.
+We want to practice with a decent sized group project, so you will use your TV Shows project.
+
+
+## What trainees will do
+Here's how the interview will go, it should last no longer than 10 minutes:
+* The interviewer will ask you to introduce yourself in 30 seconds, like you have been practising during the "Introduce Yourself!" energisers at the start of classes
+* As part of your backlog, earlier in the week you shared the project to talk about in a slack thread and organised an interview time
+* For up to 5 minutes, answer questions the interviewer has about the project you shared
+* You should check the sections below to get an idea for the kind of things we are looking for, and what to avoid
+* At the end, the interviewer will give you some feedback on how things went
+
+
+
+## Instructions for the facilitator
+The goal is to give all trainees experience with a short one on one interview.
+Trainees will share their projects and book meeting times throughout the week.
+
+Follow this script so all the interviews are consistent:
+1. (30 seconds) Ask the trainee to introduce themselves 
+2. (up to 5 minutes) Pick one piece of functionality (e.g. "searching for an episode"), and ask the trainee to show the code and explain how it works.
+3. (up to 5 minutes) Share feedback to the trainee as a basis for a short discussion on how to improve their interviewing
+
+Here are some tips:
+* Check out the [TV Show project](https://github.com/CodeYourFuture/Project-TV-Show) beforehand, to familiarise yourself with what they have implemented
+* Ask the trainee to present the code on their machine, and discuss it there
+* We don't want to give trainees undue stress, so keep to the time limits suggested
+* When asking questions, try to focus on more complex, non-trivial, or interesting parts of code
+* See the pointers below for the main thngs we are looking for from trainees
+
+After you've completed your interviews, share any particularly good outcomes or repeated issues from your interviews back to the education team so we can address them.
+
+
+## Evidence of good understanding
+Things for the interviewer to praise and look for.
+Trainees should aim to show they can:
+* Give a high level overview of a function after a quick read through
+* Navigate through a codebase, knowing where everything is
+* Explain the theory or usage behind JavaScript APIs like DOM, listeners, regexps, fetch
+* Offer explanations of code at different levels, e.g. user-facing considerations, developer-facing considerations
+* Explain choices / alternative approaches / trade-offs
+
+
+## Evidence of poor understanding
+If interviewers spot these, it could be a sign a trainee doesn't understand code.
+Trainees should practice and avoid:
+* Being unsure where different parts of code are, or having difficulty navigating a project
+* Just reading what the code does, without being able to explain _why_ and _how_ it works
+* Using JavaScript APIs while being unable to explain how they work
+* Knowing jargon and buzzwords but unable to explain code with simple language
+* Confusion over complex syntax like ternary, boolean, destructuring expressions, higher order functions
+* Can't answer questions about code written by a teammate in a group project