What are good interview questions or how to get the big picture?

Here we go again, need to employ a new guy that is hopefully very smart, intelligent, friendly, enthusiathic, creative, assertive, service-based… and yes, he should be capable of programming ;-).

In the last months we did a couple of interviews, and I still adjust the questions and points of interests to check out if the guy at the other end of the line is the right for us.

Certainly I have to do my homework. When I got a CV from a new candidate I am going to check what I can do in front. The last one had a couple of web sites created, which where publicly available. So I had a look.

• what did he use? Asp.net? MVC? WebApi? SignalR?
• Is it SPA? If not, why?
• How does the javascript code looks like?
• How does css? Was is compiled by SASS or the like?
• Are Css and Javascript compressed?
• Is Javascript obfuscated?
• What is the performance of the site?
• Is the site responsive, mobile first?
• Does he use some kind of framework (twitter bootstrap or the like)?
• What kind of frameworks are used?

All of these points – don’t consider that list to be complete – give me an impression how this guy works. Today it is quite often the case that people use public github profiles or they even do work for open source projects in their spare time. Perfect thingy to be able to see

• How does one commit?
  • Small commits?
  • Sensible commit messages?
  • Are the commit messages always in same format?
• What does the code look like?
  • Does he always use the same rules? (think of Resharper, StyleCop)
  • When he is in multiple projects, does he apply to the rules of the project or does he do his “own” style?

Actually I personally like the fact that people engage themselves into projects to improve, drive, put pressure. That shows interest, and in best case some passion. Unpayable.

Back to the code. Certainly that’s not all. Our coding guidelines include SOLID, therefore dependency injection beside a couple of other rules. None of them have been made up by us. It is just a sensible collection of proven rules that are easily understandable. And they lead us to where we want to be: Having maintainable, extensible, understandable code.

So there are always questions about

• design patterns (obviously)
• dependency injection
• automatic testing

Funnily design patterns are (still) not used by everybody. Most people “heard about it”, or “sometimes use them”. What is the actual benefit? It is not being the fancy guy who could be woken up in the middle of the night, telling all the patterns and how they could be implemented like done on DoFactory.com. Mostly it is about two things:

1. Having the same terms, thus the same understanding of a certain thing to be implemented. When somebody talks about “chainable actions”, using a “proxy”, having a “factory” in place, an experienced guy knows exactly what he means. Thus they are faster bringing a technical discussion to an successful end.
2. When introducing new people to code (or when a developer didn’t see the code for a long time), recognizing patterns increases understandablilty immediatly.

The last two interviews I asked the following questions which lead to a pretty good “big picture” of how the candidate thinks, does analysis esp. when it is an area where he is not comfortable with.

Nr. 1: Imagine you have to automate Excel. The real Excel application. Funnily there are a lot of guys that are scared by that idea, and I can tell you, they are right :-D.

We need to

• open the Excel application
• open a workbook
• iterate through all the sheets
• set some range values
• create a chart
• take a picture from the print area
• close the workbook
• close the application

How would the candidate implement that? The answers are always pretty interesting as there are many aspects that come into play.

Nr. 2: Imagine we need to have communication over machine borders. How would you garantuee that a certain information is sent from one machine to the other and gets processed on the other machine?

The latter is a tricky question. What kind of architecture will you choose to communicate? How do you garantuee that in case of failure the information will be delivered anyway?

There are a couple of things that are just not prepareable in front of an interview. Mostly these kind of questions enables me to get the big picture thus being able to decide is a person does fit our needs.

Do you have any other questions that do the job even better? Let me know.