Every interview process is different and often it is difficult to imagine what one can expect, especially if you are a beginner or generally don't go through interviews very often. I decided to share my experiences with technical interviews.
All of the interviews except the first one happened in Finland.
A talk over a cup of coffee.
I told a few things I was doing in uni and got a part-time job without a contract. Shortest and easiest interview, the worst job which drove me out of the industry for years.
Whiteboard interview.
This one was for a summer internship at a university. I was asked about a few simple algorithms and I had to come up with some data structure for the base of the future project (building animations in javascript).
Paper programming.
It is almost like a whiteboard interview but messier. I was asked to write a function to calculate Fibonacci numbers and that was it for this part.
Home tasks.
I was going to be a graduate with little experience and a desperate need for a job, so I gladly took every opportunity to show I have some skills. I got my first full-time dev contract this way.
The best thing is when you get good feedback on your work. The worst is when the feedback is simply "you are too junior" or "your code quality is below our standards". Or even simple "sorry, but we decided not to continue with the process". I understand it might be taking some time to write feedback, but so does the homework (and a lot more).
Technical discussions.
Usually, all technical interviews have this in one way or another but sometimes it is just that and nothing else. No tasks and problem solving questions.
This type, if you are a junior, can be a bit stressful. I was bombarded with all kinds of questions from different areas, to probe my knowledge. It is easy to lose confidence in yourself when you answer "I don't know" too many times. It is nicer when you actually know some things well and have at least heard about many other things.
One, recent, was a bit weird. Most of the time I was listening about their system and asking questions about it. No one tried to specifically test my knowledge of anything.
Code challenges / pair programming.
This is the most challenging but also the most fun, in my opinion. I had this type of tech interview twice, but in the same company. I had to write code in a shared environment with some scaffolding for the task and tests needed to be passed while thinking out loud and asking questions if necessary. Tip: it is much better to bring your own laptop to avoid additional stress because of unfamiliar layout/OS.
I failed the first one because of little experience with modern javascript and also because I was very nervous and uncomfortable with this format. Thinking out loud is tough if your head is full of doubts of yourself and you have no idea where the curly braces are hiding.
The second one went a lot better even if the tasks I was given were a bit harder. I knew what to expect and did not feel like I must be perfect on every step of solving the problem. Console-logging is okay.
Showing your own code.
I asked for some advice about this in a recent post. For some reason, I expected scrutiny and going through most of the project (at least structure and tech stack) but ended up showing one component and one test suit, and one part of the backend. It was nice because I could show my latest code which was better than the rest of the app. :D
Doing a code review.
This one was the most fun and my favorite so far! I was left alone with some really bad javascript code for 10 minutes. After that, I told everything I thought was wrong with it.
I think this is a lot better than a "code on demand with somebody over your shoulder" way of testing a potential candidate. Also, less stressful because of the perceived role switch: now you are the one who evaluates somebody else.
What about you?
Which are your most and least favorite tech interviews of those you had?
Top comments (11)
Does "culture-fit" interview count? Cause that's honestly where I love to figure out that I'm being seen as more than just a guy can code and get to know my future co-workers/team.
I have a friend who is a technical recruiter and he's told me so many stories regarding how companies would pick a less qualified individual based on culture-fit.
This is interesting! How does a "culture-fit" interview usually go? What kind of questions and topic would one expect?
Hmm... I can only speak for myself and from my experiences. Most of the companies that I apply to are small companies with a team of 10-20 people, and some of these companies would have a planned half-day "interview". In a sense, you can call it a very informal technical discussion. You'd spend the day with different people talking about whatever you feel like, this can range between "What have you been up to?" to "Oh, what do you think about -Insert Latest Technology-?" to "What's your favorite food?". It's meant to be a more relaxed environment and while others may frown upon it since these kinds of interview is irrelevant in gauging a person's ability whatsoever, I enjoy it because I actually want to build meaningful connections with my future coworkers if I'm going to spend majority of my time with them.
Sometimes work isn't fun, but at least I want to be around pleasant people that I enjoy working with.
Let me instead go over my interviewing. What I've decided is best is to find a way to get the candidate to talk, something that interests them. It doesn't really matter what as long as it is work related.
What I find is this is also hard. People don't go into an interview prepared to talk about their opinions and interests. If they did, they wouldn't be prepared for most interviews. I think this matches closely with your own code example, we don't need to see your history of learning, tell us about what you're proud of.
I don't like coding changes, I try not to use them, but I can understand how technical talks can be intimidating out of school.
I do use the code review portion, may include bug if hiring for a position where that seems appropriate but I've only been interviewing for SDET positions and does not seem useful yet.
After my first year of schooling for software development, I had an interview for an internship for the Department of Defense in Canada.
They asked me to sketch on a whiteboard a sorting algorithm.
Needless to say, I had no idea what to do! 😂
Usually interviewers have already made up their mind before you even walk in the door. It's mainly a formality and confirmation of their decision of candidates.
Wouldn't say so, we can conclude a person's coding abilities by looking at their code at Github or task they've received (this can be tricky tho) but you can't decide about hiring/not hiring upfront until you really met that person and see what's he/she like.
There is a bunch of other things that need to click in, besides obvious requirement of knowing how to program and how to think, stuff like a cultural fit, teamwork abilities and (the important one) is he/she Star Wars or Star Trek fan :)
I don't think, that you can conclude a person's coding abilities by looking at their code at Github, because it is easy to copy other peoples' code.
My best coding interview was live coding.
I had to build a React todo list from scratch, including setting up create-react-app, looking at my TDD workflow, git workflow, how I solve upcoming problems etc.
Yeah I agree, we can conclude that to some level, we do some testing on site too. Also, if the candidate has done some sort of interview task, we're going to go through code together and talk about it. Those who just copy-pasted code from the net, without understanding it, are easy to spot.
Live coding is good in a reasonable amount, but if someone is expecting from me to code an app from scratch while whole interview team is lookin' at me, I'll just bail out, it's just too weird.
I think it's very insightful.
How does the person react to this stressful situation?
How does he help himself when errors come up?
Does he actually do real TDD?
Does he really think about the architecture or does he start writing some useless stuff?
Can he talk about what he is doing?
How does he react to another person saying something?
Does he write clean code?
Then why would they waste time and money on the interviews that are followed by rejection.