After interviewing 7 software engineers...

To be honest, until now, I don't think that I'd interview others for a software engineer role. This article won't talk about interview tips or some hiring traps, but purely what I thought when interviewing someone and how I respond to things that I found during interviewing those 7 software engineers.

A job vacancy (might) shows up because a team needed another workforce on their ongoing project and/or projects that are about to begin. So, there are some variables whether someone would be accepted to a certain job that they applied to. I might be able to mention some, but other more experienced people might have a different take on this.

• Technical capabilities/skill -- your knowledge about software engineering, from theoretical part, fundamental, to code.
• Interpersonal skill -- how would you explain something to someone, either it's explaining a problem, solution, or even how you'd respond to something.
• Motivation -- why do you want to work, and what's the motivation behind it. Sometimes the interviewer would ask something along the line of, "why should we hire you?"

I can't think of anything else, because on a job interview, it's usually around: behavioral interview and technical interview.

Then, how would someone who acts as the interviewer prepare themself? I mean, just like being interviewed, you need to present your best self to the outside world, right? This might be different for everybody. But, from what I've gone through, there is some kind of pattern on the interview questions. Either it is a fundamental question, an open-ended question (meaning there are no right answers or multiple possible answers), to a trick question. As another human might be, we inherit the questions that are given to us before, for us to ask on the person that we're interviewing. Meaning I collect questions from the internet, browse quiz questions, and create case studies (because I was asked to help on the technical interview part).

Collecting those questions is not a problem at all, because there are lots and lots to ask. From language features (example: Can you explain what pointers are, and how do you use them?), SQL (questions surrounding query, database locking, transaction, and optimization), to case studies which answers might be an open-ended one. I've used to do coding tests during my past job interviews at the end of the session, and so I usually spare 10-15 minutes to do some coding tests. But, bear in mind that not every interview session is perfect. Maybe, there are a few sessions that reached the coding test, maybe there are a few others in which I can only ask some questions because they have a long answer to each question, so I can't really measure the capabilities of this person.

Being an interviewer, I became aware of time constraints. A session might only have 1 hour, maybe because a few colleagues of mine got some other things to do after this one, or maybe the interviewee only available on that exact hour. During that session, we have to respect everyone's time, right? Because of this constraint, we have to pick the right questions to be asked for, in order to be able to measure their overall capabilities.

When we ask about some questions, we don't really mean that you have to understand everything before joining the team, no. Sometimes, we just want to know if you are aware of some specific thing, and that specific thing -- if you don't really know about it well enough -- might be taught (by us) when you had gotten the job. I mean, who really has the privilege to do a microservice with a job requirement that says "fresh graduates"? I found some people that lied about them knowing some things by saying they know those stuff, but when I ask more detailed questions about the matter, I can absolutely confirm that they lied. It's okay to say something like, "I am aware of Kubernetes, but I haven't used it myself", or even "I haven't heard about Jenkins, may I know what it's for?".

I don't really think that I've made a perfect coding test session as an interviewer, but when I assign someone to do a live coding test, I don't care whether the challenge is completed. What I care about is their thought process on solving a particular problem. Would they go to Google to see some StackOverflow solutions? Would they read normal documentation about the language? Would they find a tutorial about how to do a recursive function? Or would they just code non-stop like a beast? But, that's not it. Sometimes, I like to disturb them by asking some things that are unrelated to the interview, just to know how they would handle disruption. But, I guess, I won't do that anymore. Some people are just too respectful when I do that, so they would stop the typing and look at the camera, and answer my dumb questions. Haha!

Moving on, before, I said that some sessions might not arrive to the coding test part because of time constraints, but in some cases, we don't move to the coding test because you're already rejected. Bingo! The decision of whether you passed the interview is usually decided right there. Just maybe without us telling you about it. I personally might rush some questions and said, "Okay, that's enough for me", and would go text my colleagues that I think the current interviewee does not fit the job well. It's not always that easy, of course. At some people, we might second guess their ability. Moreover when they answer everything correctly, but don't have enough time to do a coding test, in which we would think of giving them a homework coding test with a specific duration. If a homework coding test isn't possible, it's not easy to decide whether they're in for the job.

That's what I think, for now. I don't know what I'd think when I've interviewed 50 or more people. Also, you can ask anything, there's a comment section below for a reason, you know.