Hello, my friends,
Today I am gonna teach you an amazing magic trick. I am gonna teach you how to predict the interview.
How do you like that?
Okay, I want you to apply for a position you like.
Next, I want you to sit comfortably in your chair and relax and let me show you the magic.
Now, say after me Interviewto Predictum.
Okay, all joking aside. There’s something I’ve been doing unintentionally for the past year that helped me a great deal in my interviews. I thought I write about it since it may be helpful for somebody out there.
In order to make sure things I mention here do work, I applied things I mention here in an actual interview and I kept notes.
So here come my amazing discoveries.
But First Comes The Warning ⚠️
WARNING: We don’t take responsibility for the outcomes that result from applying what’s mentioned in this post. Please proceed with caution. Also, note that we don’t encourage nor approve underage wizardry, kindly have some wizard of age with you the whole time.
My Small Big Data
Some interviews are easier to predict than others. Yet, if we did our best we are most likely to end up with a good enough prediction.
The first thing I did is collect as much data as I possibly can about the company, their interviews, their selection process, and the interviewers. Some data are easily handed to you; like the interview duration, the process, and in most cases the interviewer’s name (in my test interview I didn’t know the interviewers’ names until they introduced themselves at the beginning of the interview).
To find my small big data, I searched:
- the company’s website,
- the company’s LinkedIn page,
- the company’s reviews and interviews on Glassdoor,
- for my own connections that work/ worked at the company,
- and the wide wide web.
I know… I Assume… I Ask…
You know how in problem-solving, we sometimes make assumptions. These assumptions aren’t facts and they may be wrong. But making these assumptions makes it easier to tackle an unknown problem. That’s exactly what I did. I made some assumptions based on the things I knew for sure. And for what it’s worth, my assumptions weren’t wrong.
So, let’s start from the beginning. A week after I applied I got invited to a 30-minute call with a tech recruiter whose name is Jane Doe.
What do I know for sure?
✅ The duration of the interview is going to be 30 minutes or less.
✅ The interviewer’s name and position.
✅ The interviewer’s background (because I did collect my small big data).
✅ The data about the company and its products.
What did I assume?
- There will not be any technical questions (since she is a recruiter).
- I will be asked about my experience.
- I will be asked about the company.
- I will be asked why I am applying to an overseas company.
I did get asked all of these 👆🏻 questions.
The part that comes after making assumptions and preparing for them is preparing questions for things I couldn’t find data about and/ or I couldn’t assume.
What questions did I prepare?
- What are the next steps? (I didn’t ask this one, because she explained the process to me before I needed to ask)
- A question about how the product works.
- What architecture do you use?
- What language do you mainly use? Swift or Objective-C?
- Questions about the iOS team.
I added the answers to these questions to my pile of data, and on to the next step.
Accumulate and Repeat
Next, I got invited to another 30-minute interview with an iOS Engineer.
What do I know for sure?
✅ The duration of the interview is going to be 30 minutes or less.
✅ Only the interviewer’s position.
✅ The information I learned in the first interview (architecture and language used…).
What did I assume?
- There’s a good chance I won’t be asked any problem-solving questions (due to the short interview duration).
- I will be asked about my experience.
- I will be tested on my iOS knowledge.
- There’s a good chance I might be asked architectural questions.
There was no problem-solving and I got asked about my experience, my iOS knowledge, and architectural design patterns.
What questions did I prepare?
- How much of the code base is still in Objective-C?
- More questions about the iOS team.
I accumulated the answers to these questions and his questions to me to my pile of small big data.
I did the same with the last interview as well, taking into account the things the second interviewer asked about and the questions of the technical test I had to pass before I get to the second interview. Because though the next interviewer won’t ask the same questions, they will probably want you to demonstrate your knowledge on topics that matter the most to them (topics you’ve been asked about before).
Work With What You’ve Got
Sometimes the information you can find about the company on the internet is very limited and sometimes the data you get from your first screening call is not of much use. You just have to work with what you’ve got and piece things together as you go.
Try putting yourself in the interviewer’s shoes and ask yourself what are you looking for in a candidate and drive the questions from there.
Another approach is to focus on the product and its features and ask yourself what are the concepts behind them and guess their questions.
It’s Not Failproof
It goes without saying that predictions are never failproof. They can very well be wrong, but preparing them is a good way to focus on the specific topics that are somewhat likely to be brought up in your interviews.
I don’t know about you but I feel that with a few specific topics I have a better chance of being well-prepared than the ocean of endless topics out there.
Plus, I believe that we learn a few valuable things when we make the wrong assumptions. We learn to better read and understand the interviewer’s position. We learn about the factors we didn’t take into consideration when we made our wrong assumptions. We learn to learn from our mistakes.
Interviewing is tough, my friend, but so are you 💪🏻!
Let me know how you prepare for interviews and if you found these ideas helpful.
Happy interviewing 👔!
Top comments (2)
Nice post. I think you've really hit on an element of interviewing most don't take into account.
Thank you, Ben!