Not another Interviews’ article: Think it through
[Previous Chapter — Applying: The CV| Next Chapter — The Questions]
First of all let me share my personal point of view of what an interview should be before proceeding to anything else so… take all of this with a grain of salt.
For me, this is the most important part of the article. It defines the whole logic and motto of an interview, interviewer and interviewee and will define the things that will matter most.
In my opinion an interview should achieve the following:
- Rank the knowledge of the person being interviewed — This is obvious - We need to have a good process to get to know the person and try to understand what’s their knowledge about the technology we are interviewing for. How should we do it? I don’t think there is a mathematical formula for it, but Google did the math anyway: 3 interviews is the sweet spot. What you do in the 3 interviews is whole new story, in my opinion the best option is having a conversation with theoretical and practical questions and a live code part. Those create the process that I believe generates the best technological analysis. Also a good thing to understand is if the person is passionate about their work and tries to be up-to-date on that subjects.
- Understand the cultural fit of the person towards the culture of the company — Every company has a culture so you either think and work on it or it grows by itself unmanaged (if you want to read more about this, here is a good book about culture). The awareness that having a carefully cared and strong culture is a good way to guarantee that your company will grow healthy is something that fortunately is growing. Probably the most important step to maintain a culture is avoid hiring people that don’t fit. (Oh, and let’s not get confused. It’s not about not hiring people that don’t agree with you, it’s about hiring people that care about the same values your company does). So really focus (also) on that while interviewing someone.
- Provide exposure to the company to also give the person opportunity to get to know it better — As you are trying to understand if the person fits your company both by knowledge and culture, you should also share enough building blocks of how it work to help the person understand also if she fits and would indeed like to work there.
- Make it an enjoyable conversation for both parts (if possible the interviewee should be more eager to work in the company after the interview than before) —Facebook’s interviews were the ones that really taught me this. The interviews and the whole process can be awesome for the interviewee independently if the person manages to get accepted or not. It’s just a matter of mindset of the interviewers.
I believe these 4 gold rules are the building blocks of a good interview. Most of the companies only focus on numbers 1 and maybe 3. Very very few focus on 2 and even fewer on 4.
So what does it really mean to follow this principles? What do I really do?
Interviewer Point of View
A good interview starts before the interview itself (whattt?). Well it’s quite simple, it’s very import to give a clear feedback to the interviewee of what will happen. Why? This will avoid anxious people from becoming more nervous just by anticipation and it will allow the interviewee to practice for the interview.
Why is this good, I suppose you are asking yourself? Well, you want someone who knows how to code, not on a whiteboard with pressure and people asking questions, but on real life. It’s not the same, both need practice to perfection. A simple example, if you are planning on asking some white board coding questions, the interviewee should know to be able to practice writing some code on the whiteboard. Going for an all-white-board-coding interview without having practiced is a very risky move as it might make the person seem very clumsy and increasingly nervous. Companies like Google and Facebook to prevent this send the interviewee an email explaining how the interview is going to be and point to some good material to practice.
The interviewee is has arrived and has prepared properly, what now?
Before thinking about what questions I will do I always remind myself that it’s a human being that’s in front of me. It is not a resource it’s really a person, although sometimes companies forget it.
That person has feelings and expectations and she’s probably nervous. So I’ll always try to be nice and think how I would like to be treated if it was the other way around.
Introduce myself, say what’s my position in the company and what I really do. I really don’t like to go all “terminator style”, shooting questions first and having a pep talk later.
I have a little pep talk first to calm the person, and explain that we are doing some questions to determine their knowledge. I explain that saying “I don’t know” is not a problem, nobody knows everything.
I’ll normally be my laptop to take notes to keep after as an “evaluation”. To make it less weird I always ask a (rhetorical) question like “I’ll be using my laptop to help me take some notes during the interview do you mind?” That’s one of the things that sets the tone to it. I didn’t need to ask, but I do. Also, I try to avoid always be looking at it. I try to look most of the time to the face of the person, isn’t it horrible when you speak to someone who is looking continuously at the laptop?
My job is really simple:
- Ask questions.
- Be nice. (Don’t be an arrogant asshole)
- Don’t be lazy (You know that CV that you didn’t even look at?)
Always remember the AQ-BN-DBL above. Oh and about that asshole side note… it’s easy to become an asshole when doing a lot of interviews and as an interviewer you always have the upperhand. Don’t.
So how do I apply the 4 golden rules?
Technical knowledge
I don’t really believe in written tests (sorry teachers!). Why? Because they are not dynamic, they don’t adapt the questions to the interviewee’s past experience. Also let’s be honest, the person or people that do the tests normally like to do “hard tests” to filter only “the best”... or at least is what they brag about, normally it means they start to put all kinds of stupid questions and traps that say nothing about the interviewee knowledge.
I really believe the way to go is to talk to the person. It doesn’t even needs to be in person, skype works perfectly for a first interview.
Start by asking the interviewee’s past experience and what did he did before (related to the position his applying). It is also a good way to warm up, as I can ask some simple questions about their past projects. After that I move on to the more standard questions (which I’ll list with much more detail in the next chapter).
I begin those with theory questions. Why? A lot of people that I interviewed had a lot of programming experience, but they didn’t really knew simple things like:
Those questions can be a lot of times even language agnostic, or at least platform agnostic.
When I had a nice ideia of the person’s knowledge in that matter, I go to practical questions. Focus on the language and platform.
How would you fetch a list of restaurants (in json format from a server) and present it in a list?
This will show me if the person understands the platform concepts:
- Not making http requests on the UI thread
- Using a RecyclerView (or at least ListView) to show the list
- What to use to do the request? AsyncTask, Service… ?
I like to go to the little details on this.
How do you commute from the UI thread to the background thread? Where do you do it?
Finally I can ask the interviewee to do some simple algorithm live code questions. Why only at the end? If they knew the answers until know they are confident and will more easily do the exercise. If not… well, some interviewees will not be as savvy as you’d like, get ready for that.
Can you write me a method that receiving two strings String needle and String haystack returns a boolean that is true if needle is contained in the haystack, false if not? Oh, and to make it more interesting don’t use the String contains method, do it as if you are implementing the String contains.
public boolean isNeedleOnTheHaystack(String needle, String haystack) {
<do magic here>
}
At the end of this you should have a good idea of their knowledge.
A final interesting question is what does the person normally read to be up-to-date with technology. This will easily show if the person likes and makes an effort to always be up-to-date or not.
An important note. I always do a full interview even if during the first part of it I already believe the person will not achieve what was supposed to. Besides the point that I can be wrong and change opinion during it, it is also a demonstration of respect. Finishing it way before it was supposed to is saying that “I’m wasting my time with you” which is not very nice. Also it shows the person the full interview, which will help either some months in the future retrying the process, or when trying another company.
Culture
Culture can have a part of the interview for itself (I really think it should), but during the technical part you will really get a lot of hints. How did the interviewee reacted?
- Was he nice?
- How was he when being confronted with something he didn’t knew?
- Was he humble even when he got everything right?
- Did he show some knowledge about the company showing he indeed wants to work here?
- Did he ask questions? Which?
Although depends a lot on the company culture mostly the search is for someone nice, humble and who would be easy to work with.
Exposure to the company
Besides showing the interviewee around before the interview I think a good policy is to have some time at the end of the interview for questions. At that time he can ask anything.
It’s also a good cool off moment. (I will take more about this in the Aftermath part).
Make it a nice time
By doing everything above I try to make it really a nice time.
Oh, and for the record, I don’t apply myself to make the interviews nice just because I’m some kind of Good Guy Greg… it’s because I really believe it’s the right thing.
Interviewee Point of View
It almost seems ridiculous to say this… but it’s quite easier to be interviewed.
- Be honest
- Be nice (karma is a bitch)
- Be humble
- Do you homework: study (review the technology and make sure you are up-to-date with even the things you don’t use on a daily basis)
- Do your homework: Know the company — remember that what you do and even what you dress should fit the company’s culture
- Do your homework: Practice makes perfect (if you know the interview will probably have live code exercises, do some at home)
- Don’t be a bullshiter
- Be passionate
That’s it.
Actually… a friendly advice, if you are applying to a company that has a tough interview process, try other similar companies’ process before applying to you “dream company” to improve your skills on interviews.
It might seem that you are wasting your time and the time of the people interviewing you but… in the worst case scenario you will have an offer from you dream company and one of those not-your-dream-companies.. who knows, maybe the guys at one of your not-you-dreams-company have done the interview really right and you now really want to go there instead!
Let’s proceed…
Looking for Android / Java / Kotlin questions?
[Next Chapter — The Questions]
Looking for a more generic interview info?
