9 Comments

  • In the interviews that I've given in the last 6 months, we tortured our applicants by giving them VB6, a single table MS Access database and told them to write a class that reads / writes a single record in the database... all with 4 team members sitting there watching. 8) talk about sadism.



    of the 10 people that we interviewed... for a VB6 position, who were supposed to have at least 4 years of VB6 experience... only 1 guy actually knew what a class was and wrote a working program. we hired him.



    for the interviews that i've done recently - 2 BrainBench.com tests, and a "walk me through these 500 lines of code / stored procedures" got me a new job. i prefer the method that i went through.

  • We did a 20 questions pen-and-paper test asking some more esoteric points about C# / ASP.NET. We then gave a fairly simple piece of code riddled with bugs; logic, syntax and basic implementation (intentionally :)) and asked candidates to fix it (using full Visual Studio)- then we asked them to take us through what the code did - this was important as the job was client-facing . This didn't take long but let us whittle down candidates based on technical prowess fairly quickly - this was for a fairly senior job and around 5% of the candidates even came close to passing our little test.

  • I know that in Microsoft they usually test you on the white board. Besides the way the person handles the environment can tell nothing abot him from the professional point of view :)

  • asking candidates to code on notepad is truly a problem.

    the point is most interviwers themselves would google some piece of code and use Vstudio or any special tool to write code.

    Instead I would love to have an interview where in incorrect code is given and candidate is asked to fix it or atleast identify errors

  • Why would you judge someone based on how they handle VS.NET or any other specific tool?



    There are plenty of other development tools for .NET and you may lose a perfectly fine developer just because he or she chose to go with another development environment (one that probably hogs much less HD space, CPU and memory).

  • yn: I was merely stating something that I would check if I knew that developer has working experience with vs.net. If they don't, and my company works with that tool as the standard, I also want to know this, since "learning curve" is also something one should consider for a candidate.

    But I agree it is not the *only* element I would check. But it's definitely a "red flag" for a lot of candidates (999% of devs I know work on vs.net so that test would be valid for them).

  • Once again... RoyO says what we've all been thinking... ;)

  • As a candidate, I simply despise paper tests and think it's an outdated process...are paper tests testing one's programming skills or compiling ability?



    Watching a candidate at work, either on paper or on a compiler, is very pressuring and definitely unrealistic...a manager/team leader doesn't look at the programmer while he/she is coding in real life work, so why do it in an interview?



    The pin-point questions are a valid method IMO, but I think that asking a candidate about little nuances that only 5% of the coding population know of is a little harsh..



    One of the most underrated things in programming interviews is personality tests and personal questions, out of the coding scope. Programmers are real people, not robots - get it through your head recruiters!! We too have a life and don't find coding the only passion...so check out how your candidate is as a person as well...



  • If I were in the "hiring position", what I would do is put the interviewee in a small room with a computer loaded with VS.NET, MSDN Library, and a web browser. Then give them a small utility/app to create. The GUI would already be done, since often times, this is the piece that causes people to spend a lot of time (some of us wind up trying to create the perfect UI... usually without much luck).



    Give them about 30 minutes, and watch them through a window in the door periodically. This allows them all of the tools that they can realistically expect to use in a day-to-day environment. If they were using "chat" to get answers from someone else, then they would score less (if at all), however, if they are using MSDN library, Google, and forums to find code snippets, and then successfully integrating them into the app, I would score them higher, because this is the way the real world works.



    Later,



    Eric

Comments have been disabled for this content.