As part of the interview process that I've run here in the past few years, I've given my applicants a technical test. This has taken the form of a series of questions on VB, SQL Server and ASP (I haven't recruited .NET employees yet). These were then marked and scored and used as a reference for the interview. I didn't go through the results with the candidates, unless they specifically asked about it.At my interview last Friday I was given 3 pages of questions, one on SQL Server, one on C# and one on ASP.NET. I completed the questions, and then we discussed my answers giving me an opportunity to explain verbally some of the concepts I was having problems writing answers to. This worked reasonably well, but I think it can be improved upon.Obviously one needs to consider technical ability when doing the selection process, but I'm not convinced that the written test is the best way forward. Over recent months, I've been thinking of a better way to do tests, and so I think that next time I need to do technical interviews, I'm going to supply the candidate with a laptop, internet access and a problem in the appropriate programming environment. It needs to be a pretty simple challenge so as not to exceed the 30 - 40 minute period that the tests currently take. I figure I'd give the developer a working system, and ask them to make a few enhancements, maybe one to the database, one to the code. Once the time is up I'll sit with them and work through the code together to see how far they've got, and they can then explain to me what there thought processes were etc. This feels like a much fairer and more realistic way to determine the technical ability of a potential employee.
comments powered by Disqus