I've recently been conducting several mock interviews for my friends in college, and I want your tips/experience at conducting mocks.
Typically, my flow works something like:
- Let them book a time on my Meetingbird Calendar
- Depending on the request, set location as whiteboard room, my phone number, or a coderpad link.
- I try to do research on the specific company and position they're applying for, to try to compile some questions that they could expect.
- During most mocks, I conduct the interview as if it were real, and coach them after we've been going back and forth for some time. This could be things they did really well, things they could have done better, etc.
- If they're up for it, I also critique their resumes and do a quick question/answer about the content.
- Always make a reminder to wish them good luck on the day of their interview!
Is there anything else I should be doing, or do you have tips on conducting a mock interview? I'd love to hear them!
Top comments (6)
To simulate the typical senior developers who will do interviews at the "cool" tech companies...
Be as condescending, bordering on rude, as possible. Alternatively, have a poker face most of the time and give the interviewee skeptical looks the rest of the time. You want it to be an adversarial event from the start and you hold all of the advantages.
Ask them to draw out basic data structures (linked list, binary tree, etc) on the whiteboard. Insist that the code they write on the board be 100% perfect and complete, no pseudo-code. Question them about every step with vague comments like "Are you sure about that?" and "Why did you do it that way?".
Google on "tough programming interview questions" and ask a few of them like "Find the Missing Element" or "Design a Tiny URL System". Make sure to act skeptical about their answers, even if they're right. Do this so that they question their ability and competency, maybe even to the point of triggering impostor syndrome.
Go over their resume in detail with them, questioning everything about their experience.
Abruptly cut the interview short, telling them that they don't fit the team's "culture" and have them escorted out.
I wish I was joking, but, in most cases, that's what the interview will really be like.
Your comments reminds me of the Monty Python Interview sketch. ;-)
Nothing says "I don't want to work here" more than that!
Sadly, many companies today take the attitude that all applicants are incompetent liars and the interview is meant to expose them. Maybe they've been burned in the past but that doesn't really excuse it.
I didn't think these kinds of attitudes and techniques were all that common but my experiences in my recent job search revealed that they are. I had this kind of experience at 5 different companies. I'm just glad I finally found a company that didn't interview in such an adversarial manner.
On one hand I can kind of sympathize with employers. Doing interviews I get get the feeling that over 50% of applicants for programming can't program. In any sense of the word either, coding, problem sovling, admin, systems, devOps, data structures, etc. I wonder if other industries are this bad.
On the other hand, there's no real excuse for being a dick. It shouldn't take long to determine somebody is at least worthy of an interview. If the applicant is simply no good I'm in favour of just ending the interview early. I suppoes the dickishness comes from people interviewing non-stop bad candidates and feeling as though they're just wasting their time.
But again, even bad candidates deserve the courtesy of being treated like actual people.
I have an old personal mantra that everything I need to know in life I learned back in music school. (I was a full-time music student in a past life.) I learned a lot by preparing for auditions.
I think there's tremendous value in doing a series of prep sessions, not just one or two mock interviews.
I'd do the first session as a very fast & loose run-through (15 min. at the most) just to get a feel for where the candidate needs the most help. Once that's done, focus on the weaknesses. If the candidate flubs an answer, don't let that become their permanent memory. Instead, tell them how they can improve, and go again immediately to cement their best performance in their memory. If the answers start getting worse, stop that section and move on, and note that the candidate should practice that section for next time.
In the second session, do a full run-through of the interview, as if it were the real thing. If it goes great, stop. If not, go back through the sections that didn't go well.
As much as possible, vary the time, place, and atmosphere for each interview. Don't let the candidate form a rote pre-interview routine. (If they always get a coffee before the interview, fine. If they always get a coffee from the same stand in the quad outside, not fine.) Make them dress for the interview.
I highly recommend watching a video of an instrumental master class or ensemble rehearsal. Musicians eat by being ready to perform when the lights come up. Their preparation methods are instructive.