This week I have an interview for a developer position and they want me to bring one of my recent projects and walk through it with the interviewer. I wanted to share the process I am using to prepare for the interview.
Step 1: Choosing a Project
While this might sound like the most simple step, I think there are a few points to consider here that will help put your best foot forward. I had four questions I asked myself when choosing a project.
Is this project a good example of the work I can do currently?
Can I connect this project to the company I’m interviewing with?
Does any part of the tech stack of my project overlap with what the company is using?
If I could only highlight three things in the project during the interview what would they be?
Reviewing the projects individually and asking these questions definitely weeded out some projects with no chance. It also helped to frame the projects in terms of the upcoming interview.
Once you’ve chosen a project, or have two which you can’t decide between we can move on.
Step 2: Make a list of features/talking points
Take some time reviewing your codebase and the user interface of your application. Jot down notes and talking points you don’t want to forget. See if you can find a ‘happy path’ through the application where you cover all features in a logical or sequential way.
I created a few flow charts to find the best flow and keep track of how to step through the application for maximum efficiency.
Step 3: Record/screen capture a run-through of the project
This is definitely the toughest and most embarrassing part of the process but is often where I learn the most about myself and make the biggest improvements.
It reminds me of my mom’s advice to practice for a school presentation in front of the mirror.
Simply going through the steps is going to show you where you struggled for words and where you need work.
A note on the embarrassment factor: seeing and hearing yourself is always 10x worse than when you talk to someone else and can be a real eye-opener into how you sound or if you need to slow down etc.
Some people develop a script of what they want to say; I don’t find this helpful. I want to keep interviews as conversational as possible. Being scripted often leaves me stiff and caught off guard by questions that interrupt the flow.
Instead, I keep the final iteration of my flowchart on hand where I can quickly reference something I want to cover next without having to write out the details of what I’m hoping to say.
Step 4: Brainstorm potential questions you are going to be asked
Every interviewer is going to be different but think of some questions you might ask if this application was presented to you.
Are there any pieces that might be confusing if a user has never seen the application before? How do you handle user errors? What was the most difficult part about creating the application? Did you work on the design beforehand or just jump right in? Was there something that changed halfway through the project that you weren’t expecting? How does <SOME_FEATURE> work.
Look over lists of interview questions online and see if you can adapt them to your project. Get a friend, family member or roommate to go through the application with you and see what they ask.
The more fresh eyes you can put on the project the better.
Step 5: Know the code base inside and out
As I reviewed each of the projects in my portfolio it took me a little time to get comfortable again with the code I had written. When looking for the code that powered a certain feature I sometimes struggled to find the file or information I was looking for.
This is definitely something I don’t want to happen in an interview. Take the time to review the layout and structure of the application so there are no moments when you can’t show your interviewer that you know your stuff.
