I've recently been in an argument with a colleague about technical questions in interviews. As a graduate, I went round lots of companies and noticed they used the same questions. An example is Can you write a function that determines if a number is prime or not?, 4 years later, I find that particular question is quite common even for a junior developer. I might not be looking at this the correct way, but shouldn't software houses be intelligent enough to think up their own interview questions? I've been to about 16 interviews as a graduate and the same questions came up in about 75% of them. This leads me to believe that many companies are lazy and simply Google: 'Template questions for interviewing software developers' and I feel there are doing themselves a disservice in taking this approach.Question: Is it better to use a set of questions off some template or should software houses strive to be more original and come up with their own interview material?From my point of view, if I failed an interview and went off and looked for good answers to the questions I messed up on, I could fly through the next interview if the questions are the same.
Using template questions in a technical interview
interview
A lot of those sorts of questions stick around precisely because it is hard to come up with questions that are clear, require as little domain knowledge as possible, require an ability to come up with an algorithm without being a trick question that someone will either get or not get, and that people have a historical background of answers to compare the candidate against.  And the best questions have multiple levels of correct answers that allow the interviewer to gauge the candidate's problem solving skills.  If someone suggests a trivial prime-finding algorithm, for example, we can then talk about how you might optimize the implementation or the interviewer to lead the candidate toward one of the more sophisticated algorithms.I've been in groups where a number of different developers rated how difficult a particular problem would be for a set of interviewees and the estimates were all over the map.  Lots of people look at FizzBuzz initially and dismiss it as patently too easy.  If you go into the interview without a good understanding of how difficult the questions are, the fifth person you interview has a massive advantage over the first person because you've learned that people struggle with FizzBuzz while you formed a negative impression of the first person you interviewed because they had identical struggles.If developers are coming up with fresh questions, they also tend to have unintended cultural or domain knowledge embedded in them.  They'll ask questions about a sport, for example, that tends to give an advantage to people that know the rules of that sport who can either quickly spot an ambiguity or make an obvious assumption.  Someone that is utterly unfamiliar with the sport has to figure out the rules of the game on the fly and is much more likely to make a mistake or to come up with a less sophisticated answer.  Or they'll ask a question that unintentionally assumes that candidates will know/ remember some relatively minor tidbit.  Someone that has been working on accounting systems for years, for example, may assume that everyone knows what a double-entry accounting system is or that a question that assumed a simple double-entry accounting system schema definition would be clear to a competent developer.  But it could easily throw a good developer that has to get their head around the idea of a debit to cash increasing the cash balance and a credit decreasing the cash balance.  Someone that has taken Accounting 101, however, would quickly catch on.  If your intention was to test the candidate's familiarity with accounting, this might be a perfectly reasonable question.  But if you're not looking for a subject matter expert, it would be problematic.While I suppose it's possible that someone would could memorize the answers to the few hundred common template questions that people use, that doesn't bother me much as an interviewer.  In the first place, it would be somewhat impressive if they did so and would reflect quite a bit of industriousness and problem-solving.  In the second place, it would generally be pretty good training-- if the developer knows how to reverse a string, knows some algorithms for finding primes, knows how to write loops and implement control constructs for FizzBuzz, knows the various graph algorithms that come up regularly, etc.-- they're likely a pretty well-rounded developer.  If the developer managed to memorize the answers without learning anything, they'd be caught out when the interviewer wanted to drill down a bit or they'd be disqualified when the interview moved on to more open ended questions about their previous projects or delving into details about the role.