How do you perform technical interviews for developers?

[RastaLulz]

Recently I've started interviewing developers for my team again, and I'm curios how others go about performing the technical portion of the interview process.

For instance, in the past we've generally done the following:

• Applicants are screened by the PM.
• If they make it past the initial screening, we give a simple assignment to do (e.g. create a simple HTTP client that interfaces with a REST API).
• If I think what they've provided is satisfactory, and their resume matches aligns with I'm looking for, they're offered a technical interview.

* I might review the resume before they're given the coding challenge.

As for the technical interview itself, it generally goes something like:
1. Brief introduction.
2. Go over any points I find interesting on their resume, and have them fill in more detail.
3. Go through a list of technical question ranging across many different topics (tools, general programming, JS, Vue, REST, CSS, MySQL, etc.) to try and gauge their strengths and weaknesses.
4. Have them work through a set of challenges while sharing their screen, and have them talk through their thought process.
- They can use Google and what not during this portion.
5. Have them ask any questions that might have for me about my team (from a technical perspective).

The time it takes the technical interview varies greatly. Getting to #3 can take ~30-40mins. Then depending on how well they do, #4 can take up to an hour or so. Sometimes we just end at #3 if we aren't impressed.

I've also had interviews in the past (where I was the interviewee) where:

• I simply walked through some of the repositories I had on GitHub, and talked about why I did certain things. I also answered a few technical questions.
• Another place had me work alongside them at their office for 90 minutes while I created a basic CRUD app with PHP (and HTML), and then reviewed that at the end.

If you haven't performed any technical interviews, but have been on the other end, I'd also be interested in your experience(s).

 

[Adil]

I've done one technical interview for someone who was tasked with maintaining some software we had built. In that technical interview I went over basic concepts, such as:

• HTTP
• JS/CSS
• What do you know about technology X?
• Can you tell me how you'd go about process Y?

My general findings when interviewing for a position I'm applying to:

• Phone screen covering basics about tech stack (e.g. what's a class in Python, what does XYZ do in JS, etc)
• Technical assessment (sometimes done in step 3)
• Technical interview onsite (or remote)
• Offer

The technical interviews are usually very gnarly and really test aspects of my understanding. In one recent interview they wanted me to describe in detail how I debug bugs in production and the design decisions behind my assessment.

One thing I have noticed - it's good to ask for specifics on a language but the more fruitful path is asking about technical problems that are language/framework agnostic. Those are the most enjoyable for me anyway

 

[Parsov]

The best thing to do would be analyze their CV to see if their experiences matches what you are looking for. If it's the best match send them a site where you keep your tests (example: hackerrank). Depending on the complexity of the task give them x hours of time to complete it. This way you don't really need to look over them and wait for 40 minutes for them to do the tasks and they'll most likely feel more comfortable doing the tests if someone is not looking over them every 2 seconds. Instead you can go about your day while they do the test. On these kind of websites you can put both coding questions and technical questions. After they are done you can go over their solution and see if they have copied it from Google or not. And if what they wrote is neat and efficient. If you are happy with the results call them in so you can speak with the candidate in person.

Ask them about programming architectures, frameworks, tools and ask how they would fix (insert problem here).
Don't ask lengthy questions though no one likes them. What i would do is review their online test again before they come in and ask a similiar problem to what they faced. And see if they can tell me the solution. If not it means that they didn't really do the tests with their own experiences.

If they directly come to the office with no online application. You can still give them a computer you don't use to go on that website and solve problems. However I would recommend you do easy tasks so that it doesn't take more than 20 minutes.

 

[Jepzter]

I've been on the other end a few times. Not sure if it's just where I live and it might be because of a high demand of developers but not enough developers to hire.

Steps

1. Normal interview, asked a lot of questions about who I am, personality, hobbys etc by HR, nothing special here really.
2. Given a task to code something from home. Most of the time it has been creating a REST API communicating with database (this should be done in a concurrent way preferably but not required) and then some BDD testing and/or unit testing.
   
   Sometimes this step was never a thing, instead it was a basic technical interview with some basic questions. No whiteboards or anything. Could be questions about how much I knew about event driven systems, microservices etc.
3. Interview with scrum master. Nothing technical here, just them figuring out if it's a good fit for the team. Now that I am in a team I know we get to review some applicants code from step 2.

For me I think this is a good approach. I would never land a job in the U.S for example. Seems to be a lot of whiteboard sessions and I would have a hard time passing that. I do think it's a good thing for some positions where you would do some heavy lifting algorithms, big data or algorithms. I don't think putting someone in a whiteboard session for making a GUI that communicates with a backend or just a basic backend developer having them figuring out an algorithm is a good idea. Generally I feel a lot of good people would not pass, even though they are fully qualified for the task they would be assigned.

Also I think you should take into consideration if you are hiring junior developers, they may not fully figure out the interview code project, but it's important to know what kind of person this is. Some can still become much better than other junior developers quickly. Will the person be a fast learner? does the person code outside of work? Is the person afraid of asking questions? Is this a goal oriented person? If they are I would accept them.

 

[Mythraus]

I've been interviewing candidates for some time now.

We auto-send a very basic coding challenge to create a set of classes/methods to implement basic program (Shopping Cart, Tweet Parser, etc) with specific styling/linting requirements which acts as a nice sieve.

Once a candidate passes through the challenge we will do a phone screen where we ask about their experience with a variety of things including:

• Version Control Systems and their benefits along with strategies you may employ when working across a project.
• IDE's and Editors and their benefits when developing software in addition to the candidates favourite one and why that is.
• Functional programming paradigms and why they can be beneficial.
• Outside hobbies, projects, interests to determine if they're likely to be a culture fit.

Following the screener we will do a one on one which will include some more technical questions surrounding Concurrency, API's, Security to grasp the candidates overall development knowledge as well as key things that we're looking for in the role. Additionally if a candidate had supplied a Github we would ask questions about one of their most active projects and the inspirations for it alongside any technical challenges they faced.

I find it works pretty well for getting the right people through as most of the content we require can be taught or picked up fairly easily depending on the developers experience and motivation. I've also been against interview with large stages or drawn out technicals since they enourage regurgitation of information rather than having a general understanding of the concepts.

 

[Weasel]

Back when I did the job interviews, the process was quite similar to what you are describing. The major difference is that in the job interview itself, we didn't really focus on tech stack-specific questions (like, which function would you use to solve X).

So at first, we start off like this:
1. The applicant is screened by the manager and 1/2 (senior) developers. We check if their CV matches up with our expectations and for which function (junior/career/senior) they are applying. As the cultural fit is also important, we do a little bit of research on the person too, and of course, check the motivational letter. The PO and SM are not included in the process.
2. If this seems alright, they are invited for a first interview. In here, we basically question non-technical things, see if it's a proper cultural fit, his expectations of the job, and things he'd like to do. We also expand a little bit more about what we do, so he's also properly informed.
3. If they passed this initial check, and also had a good feeling after the first interview, they are sent a coding challenge, which is based on the product we work on (basically, make a barebones version of a part of the application). Based on their job level, the requirements are either expanded on or not (for example, a Junior isn't asked to also create Unit Tests). They're basically given a lot of freedom on how they want to achieve this, from choosing whether to use frameworks or not, and even the language is basically up to them (as long as it's used in the stack, or if they show the willingness to learn another language). Usage of Git is for example always required.
4. If the result is satisfactory, they are invited over for the second and final interview, the technical interview.

Thanks to step 3, we already know a lot about the person's technical abilities. We can check how he handles himself with version control, to which standards the person upholds him/herself, etc. As languages can be learned, we mainly focus on how the person handles problem-solving. What is his way of thinking? Does he take security into account? All that kind of stuff.

So, onto the technical interview. As there's already a lot of information based on the previous steps, the technical inteview mainly focusses into why he made certain choices, instead of actual "technical" questions.
1) We ask about why the person made certain choices. For example, did the person use a framework? If so, why did he use it? What is the extra value of using it? There's often different answers to this. If someone for example answers "for security", we do a deeper dive into his knowledge about safe coding practicices, to make sure the person actually knows what he/she's doing.
2) Why did the person chose the language he/she used? Does the person have a deeper understanding of the languages he uses?
3) And of course, we discuss the assignment itself. How did he/she come to certain solutions?

So the "technical" interview is more a check if the person has a proper understanding of what they are doing, instead of checking how well they know a certain language. As said before, languages can be taught, the way a person thinks, is much harder. Of course when it's for a senior position, the questions are much harder.