How do you perform technical interviews for developers?


fight teh power
Staff member
May 3, 2010
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).


DevBest CEO
May 28, 2011
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


May 18, 2016
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.


May 25, 2018
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.

  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.

Users who are viewing this thread