As a (former) iOS tech interviewer, I like to mimic how the team is working during the whole process.
Do you do code review? Ask the candidate for one! The code to be reviewed should be quite short and some of the errors should be obvious but it act as a quick filter for your team.
We tested for:
Blocking network calls
copy pasted code
non testable code
very bad naming
dead code
int overflows
Are you looking for someone who can make ship features very fast or are you looking for someone who can make good architecture choices? Don't ask for a code sample if you are looking for the second.
An interview should be more than the interviewer just asking questions. A selection of my personal questions that I like to ask:
What's the day to day?
What's the last time do did late nights? (this is a question because I value my personal time)
How does the company goes from idea to actual product? (to check that engineers are consulted before)
How often do you do 1-2-1/ have meetings with your manager? (so you know that there is someone who can help you with your problems)
What's the biggest tech debt? How/When are you fixing it?
What do you like/dislike the most here? (Every company have issues and I like companies where you are open to talk about it)
What is your perfect candidate? (See if you fit)
What's the last time you did something fun? (fun is very broad here as each person have a very different of fun, for me solving very complex tech debt is fun)
Why are you looking for a new developer?
What do you do at lunch? (do they eat at their desk alone or eat as a team?)
As an interviewer, I also like to ask:
What do you want to become and how can we help you?
What's your perfect position/company?
Why are you considering leaving your current position?
What are the things which will make you quit? (to see that your company is aligned with the candidate)
Always remember that the candidate have a life aside. I like passionate people and it doesn't have to do with work. It can be about bikes, cars, video games, animals, plants, sport, ... I always try to spend 10 minutes about nothing "important". Same for any technical tests, leave the candidate as much time as they need.
For Data Structures, I'm only asking the bases (array vs map vs stack vs queue), except if you need them, no need to know about trees and graphs.
For Algorithm, I don't like them as they can be very easy if you already know the solution. Moreover you won't need them on a day to day basis.
Some notes from my interviews:
Not knowing is fine, Google exists and we are aware about it
Knowing wrongly is worse than not knowing.
Be yourself as an interviewer and interviewee, I'm just here to see if we can work everyday together for the next X Years.
Don't lie, the probationary period is here for that.
This seems like a great approach. Especially like the idea of mimicing (as much as possible) how the team actually works in the interview. If only everyone did that.
As a (former) iOS tech interviewer, I like to mimic how the team is working during the whole process.
Do you do code review? Ask the candidate for one! The code to be reviewed should be quite short and some of the errors should be obvious but it act as a quick filter for your team.
We tested for:
Are you looking for someone who can make ship features very fast or are you looking for someone who can make good architecture choices? Don't ask for a code sample if you are looking for the second.
An interview should be more than the interviewer just asking questions. A selection of my personal questions that I like to ask:
As an interviewer, I also like to ask:
Always remember that the candidate have a life aside. I like passionate people and it doesn't have to do with work. It can be about bikes, cars, video games, animals, plants, sport, ... I always try to spend 10 minutes about nothing "important". Same for any technical tests, leave the candidate as much time as they need.
For Data Structures, I'm only asking the bases (array vs map vs stack vs queue), except if you need them, no need to know about trees and graphs.
For Algorithm, I don't like them as they can be very easy if you already know the solution. Moreover you won't need them on a day to day basis.
Some notes from my interviews:
This seems like a great approach. Especially like the idea of mimicing (as much as possible) how the team actually works in the interview. If only everyone did that.
This sounds like a dream interview process 👍🏽