I have a unique opportunity to talk to both sides in the interview process, and I am now sharing my experience that might help development teams prepare for their next interviews with clients.
1) Engage in a brief introduction.
I usually start my call by introducing the participants in the interview to each other and asking the developer to briefly tell them about himself. What I expect is a short, 2 or 3-minute story about his core technology, latest project, and something he is most proud of from his experiences.
What the client doesn’t want to hear is a 10-minute story about your childhood, dog, and plans for the weekend.
Don't be like Julie
I always note the meeting duration in the calendar so all the participants can plan their time. Please keep in mind that this is supposed to be enough for all stages of the interview process: acquaintance, technical questions, and candidate’s questions to the client.
When I see clients looking at the right corner of the screen (checking the time left), I jump into “the story” and try to set the right direction of the conversation.
2) Choose the most relevant projects from your background.
You might be surprised, but the client's side has seen your CV before the call and would ask about what seems eye-catching in your profile. Be intentional- please do not tell them about all of your projects starting from simple HTML/CSS back in the 2000s.
3) Never say that you are familiar with the tool/framework if you don’t have experience with it.
In the end, everybody finds out the truth. Be honest and say how much time you’d need to learn it or reject the interview/interesting if it does not seem possible for you.
4) Do not promise to perform the test task faster before seeing it.
Frankly, I’ve made this mistake a couple of times when I was obsessed with closing the deal. I wanted to get the project so badly that I agreed on the client's terms of the test task, and when the developer started to work on it, he could see that he couldn’t make it on time.
Ask to share the details of the test assignment so you can make an appropriate time estimate first.
5) Don’t be afraid to ask the interviewer to repeat the question or for clarification.
We are non-native speakers, and it is OKAY if you don’t understand everything. Also, people might have different English levels, accents, etc. - do not try to guess the question, just ask.
6) REQUIRE a brief description of the project ahead of time.
It helps you prepare and think of your relevant experience to be clear in the interview. If you know the technical stack of the project, you can be intentional with providing details about specific relevant projects, challenges, or successes.
7) Could you tell me something about your project?
First of all, your sales manager was supposed to share the details about the project with you, so you are expected to know “something” about it already. Secondly, it sounds like you are not interested and just doing a favor by being involved in this interview. If the client has shared information initially and you do have all the details, simply say that everything is clear.
8) Know your availability.
It is always better to know your readiness for a test task and the earliest possible start date. It saves time for all sides of the interview process, including your sales manager and PM. To me, when a developer says: “you’d better ask my PM,” they sound unprepared and helpless. Come on, you should know your own schedule ;)
9) Plan your schedule.
I recently experienced an awkward situation when a developer logged on to an online interview wearing his outwear, sitting at some coffee shop with loud music playing, and people in the background.
This looked very unprofessional, like the candidate didn’t care about the client's impression whatsoever. If you are not sure if the project fits your scope of interest, please reject the interview. This will save time to you, me, and my client.
P.S. To be honest, I was so extremely disappointed with the circumstance that I just turned my camera off, as you could literally read the embarrassment on my face.
10) No pouring water.
This reminds me of the time when I was a student. Usually, you start to tell bullshit to the teacher when you don’t know the exact answer to the question. My advice to the candidates: honesty goes a long way; just say that you are unsure if you have such an experience. I recently attended a technical interview when a candidate talked about a challenging project. It took around 5 minutes for him to tell. However, when the client asked what exactly the candidate considered challenging, the developer couldn’t explain and finished up with, “well, seems not that challenging actually.”
To sum up, I wrote this article based on my own experiences, and it shouldn’t be taken as a guideline on how to pass the interview. Some of the points are not super critical, and you can decide whether to take them into consideration or not.