On 4 Sep 2012, at 13:26, Mr I wrote: > On Tue, Sep 4, 2012 at 1:13 PM, Roger Burton West <ro...@firedrake.org>wrote: > > >> >>> It's equivalent to asking you to write a function ved(n, m) that >> implements >>> the 16 sutras* and uses them to return the result. A task that maybe >> easily >>> done by many an Indian programmer yet many in this group would struggle >>> with. >> >> Similarly, I'd expect the candidate to ask for more information. >> > > However under your above reasoning such questions may result in the > candidate only being considered for 'maintenance programming' simply > because the candidate does not know vedic mathematics. > > That's foolishness. >
Well in interviews you have the luxury of asking a range of questions, so even when the candidate is not strong on maths for example, it's interesting to see how they tackle the question and it's challenge. I've always appreciated it when the candidate will have a go on the whiteboard with something that maybe isn't their strong point. And when i've conducted interviews and also done training it can be rewarding to work together on a solution helping the candidate or trainee with the gaps in their knowledge and seeing how they use the clues. It's about seeing how people think, so if for example it wasn't fib but factorial (fac). Asking someone how their program would work for fac(-4). And then how would both_fact(n) = (fac(n) + fac(n*-1)) would behave for 1..m, etc. etc. While it's a bit computer science-ey, something like big O for bogosort is also interesting. The most important things are, 1) know what sort of skills you want to hire for the role, especially for the role as it stands in the next 6 or 12 months. 2) have a range of questions in different degree's of difficult for the skills required (Perl, UNIX, version control, SQL, etc). 3) treat it as a conversation where you are trying to help and work with them. G.
