Re: Brainbench perl test?
On Tue, Sep 04, 2012 at 02:17:40PM +0100, Dave Cross wrote: And besides, I don't think I'd really want to work with a programmer who didn't know what the Fibonacci sequence is :-) I'd rather work with a good programmer who can't answer your question slickly in the heat of an interview, (whatever clever question you think up during your coffee break while chatting with a group of people about how to think up the best interview question), than a bad programmer who impresses you with a predictable memory trick during an interview, (aren't we so cool because we know the same things as each other?) -- Ciao Richard Foley http://www.rfi.net/books.html
Re: Brainbench perl test?
On Wed, 2012-09-05 at 09:01 +0200, Richard Foley wrote: And besides, I don't think I'd really want to work with a programmer who didn't know what the Fibonacci sequence is :-) I'd rather work with a good programmer who can't answer your question slickly in the heat of an interview, (whatever clever question you think up during your coffee break while chatting with a group of people about how to think up the best interview question), than a bad programmer who impresses you with a predictable memory trick during an interview, (aren't we so cool because we know the same things as each other?) That's fair generally however the question isn't particularly clever and doesn't require you to know any memory trick at all. It's just a very simple test to see if you can take a simple specification and turn it into some kind of code with the added bonus of seeing whether the candidate spots potentials issues with it. As for not knowing what the Fibonacci sequence is I agree that it's not a particularly good test but if it is specified as either of the two questions that were suggested then it's irrelevant whether you recognise and name the equation so long as you can do as asked surely. Jason
Re: Brainbench perl test?
David Hodgkinson writes: On 4 Sep 2012, at 16:07, Smylers smyl...@stripey.com wrote: Piers Cawley writes: Tower of Hanoi is always a better example for solving with recursion than the fibobloodynacci sequence. If nothing else, the recursive solution isn't quite so immediately obvious from the problem, the terminating condition is obvious and an iterative solution isn't quite so hogwhimperingly more efficient. Yes, that's much better. When was the last time you recursed in day to day web type code? The point I was trying to make in the part of my message you snipped is that different teams value different skills. If you don't feel that adeptness with recursion is what marks out the really useful people in your team, then ask about something else instead. That a particular question is only relevant to some teams doesn't make it a poor question in the abstract. Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect
Re: Brainbench perl test
One other point I wanted to make on this debate was: No matter how strongly each of us feels about what is or is not a legitimate or worthwhile interview question: part of the benefit of having this discussion is finding out what other people think is important in an interview. Even if we sway the opinions of people in this forum about what interview questions to ask, at the end of the day interviewing is a game and being able to give more complete answers to less worthwhile questions is part of the process. Hence these are the sorts of things we need to swot up on. My general aim in an interview is to present the interviewer with a number of things they didn't know. Hopefully of which a few are of broad practical use. I might argue that memo-ization is a minor, occasionally useful feature of perl, but knowing about memo-ization shows I have studied perl in more depth than the people who don't know about it. I also think it is good to be upfront in interviews about things you haven't done and somewhat humble in assessing your skill level. For the latter, the interviewer is unlikely to take your assessment at face value and over delivery in the interview is not a bad habit to get into. Perl is a huge subject and things like Moose start to challenge what the language is. Many modules are more like language extensions than perl per se. I start to doubt that anyone is a master of all areas of perl any more. At which point I could go off and have a little rant about a number of people who have written about DBI who are obviously somewhat clueless about a few things about databases (but I won't). Chris
Re: Brainbench perl test - girl friday?
I concur. Slightly OT: My daughter is looking for a job in London, but does NOT know anything about the Fibonacci sequence. Girl-friday/actress type of thing? -- Ciao Richard Foley http://www.rfi.net/books.html On Wed, Sep 05, 2012 at 09:11:06AM +0100, Jason Clifford wrote: On Wed, 2012-09-05 at 09:01 +0200, Richard Foley wrote: And besides, I don't think I'd really want to work with a programmer who didn't know what the Fibonacci sequence is :-) I'd rather work with a good programmer who can't answer your question slickly in the heat of an interview, (whatever clever question you think up during your coffee break while chatting with a group of people about how to think up the best interview question), than a bad programmer who impresses you with a predictable memory trick during an interview, (aren't we so cool because we know the same things as each other?) That's fair generally however the question isn't particularly clever and doesn't require you to know any memory trick at all. It's just a very simple test to see if you can take a simple specification and turn it into some kind of code with the added bonus of seeing whether the candidate spots potentials issues with it. As for not knowing what the Fibonacci sequence is I agree that it's not a particularly good test but if it is specified as either of the two questions that were suggested then it's irrelevant whether you recognise and name the equation so long as you can do as asked surely. Jason
Re: Brainbench perl test?
On Tue, Sep 04, 2012 at 12:25:57PM -0400, Uri Guttman wrote:
On 09/04/2012 08:03 AM, Mr I wrote:
I've literally had people who were Senior programmers (whatever that
means) who, when given the instructions Given that fib(n) is equal to
fib(n-1) + fib(n-2) write a fib function in any language didn't even
get to the
sub fib {
my $n = shift;
return fib($n-1)+fib($n-2);
}
IMHO this is a typical example of an awful question!
It requires additional knowledge of the problem domain NOT asked by the
interviewer.Your assumption is that the candidiate knows:
a) the fibonacci sequence
b) mathematically how to calculate (included recurrence)
why do they need to know it? they are given the formula!!
and they can do a linear version if they don't know recursion.
and knowing recursion is a good coding test to filter out the wannabes
from the serious coders.
No. Well, it filters out the wannabees. It doesn't recognize the serious
coder. If, given the Fibonacci sequence, or a similar recursive formula,
and your first instinct is to solve it with recursion or iteration, you
aren't serious.
Your first instinct should be Is there a generating function I can use?.
Abigail
Re: Brainbench perl test?
On Wed, Sep 5, 2012 at 9:35 AM, Abigail abig...@abigail.be wrote:
Your first instinct should be Is there a generating function I can use?.
Try not to blow your cache pipeline with all that silly branching,
sub fib {
my $n = shift;
int(0.5 + (0.5+0.5*sqrt 5) ** $n / sqrt 5);
}
High five! :-)
Paul
Re: Brainbench perl test?
On Wednesday, September 5, 2012, Paul Makepeace wrote:
On Wed, Sep 5, 2012 at 9:35 AM, Abigail abig...@abigail.be javascript:;
wrote:
Your first instinct should be Is there a generating function I can
use?.
Try not to blow your cache pipeline with all that silly branching,
sub fib {
my $n = shift;
int(0.5 + (0.5+0.5*sqrt 5) ** $n / sqrt 5);
}
High five! :-)
My favourite, especially given that:
Given that fib(n) is equal to fib(n-1) + fib(n-2)
... in its current form arguably simplifies to fib(n) = ⊥
Re: Brainbench perl test?
On Tue, Sep 4, 2012 at 12:31 PM, Paul Makepeace pa...@paulm.com wrote: The spec for fib() was given; the spec for ved() was not. That is the difference. No, neither were spec'd enough to code from. (As is true for every spec I've ever seen.) Either should lead to questions before a single character of coding. And the questions I'd ideally like to see from the fib problem aren't just what is the value of the element at position 0 and 1, (which assumes the sequence starts at 0, something not in the problem statement) but about what the expected range of input is, what to do with invalid input, even the relative importance of startup time cost vs per call cost (a lookup table may be a better choice than memoization) and the memory resources available. And if you are looking for how and what questions someone asks and how the resulting conversation goes, fib() provides a trap where someone familiar with the sequence may assume instead of asking, which IMO is a reasonable response given the name of the function. So ved() wins in my book.
Re: Brainbench perl test?
On Tue, Sep 04, 2012 at 01:03:22PM +0100, Mr I said: IMHO this is a typical example of an awful question! It requires additional knowledge of the problem domain NOT asked by the interviewer.Your assumption is that the candidiate knows: a) the fibonacci sequence b) mathematically how to calculate (included recurrence) Except for the part where I don't assume that and I tell them exactly how to do it. The fact that it happens to be the fibonacci sequence is almost incidental. What I'm looking for is - for them to spot that there's going to be base cases - that they notice they'll be doing duplicate work - how they think about how to prevent doing duplicate work - potential other solutions (i.e iteration) In my defense I'm not a monster in interviews, lounging archly in the corner and occasionally sneering Oh, you can't even do THAT? Where do you learn to program? Clown School? and then spraying them with water. I just want to see how people solve problems - if they get stuck I'll gently ask questions that point in the right direction. Just as an aside: one of my other favourite interview questions is I got to a web page in a browser, what happens? which is basically a Rorschach test.
Re: Brainbench perl test?
On 05/09/2012 17:35, Abigail wrote: No. Well, it filters out the wannabees. It doesn't recognize the serious coder. If, given the Fibonacci sequence, or a similar recursive formula, and your first instinct is to solve it with recursion or iteration, you aren't serious. Your first instinct should be Is there a generating function I can use?. Abigail I used to do a lot of interviews with brand new graduates, and quite often asked the CompSci ones to write me a factorial function (though Fibonacci would have done just as well). I don't recall any cases where knowledge of the maths was a problem; and the simple implementation was not intended as a filter, it just got them into the programming mindset. Of course, almost all of them would use recursion, and my real interest was in the follow-on discussion why did you do it that way?, and how long it took them to twig that while factorials are a good illustration of recursion, recursion isn't necessarily a good implementation of factorials. However, if interviewing, say, an engineer or physicist with self-taught practical knowledge of programming, you usually wouldn't get the same reflex response, and I'd probably not bother with that question... Gordon
Interview Questions (was: Brainbench)
Given that fib(n) is equal to fib(n-1) + fib(n-2) write a fib function in any language The fib(n) task as stated tests three things of the candidate: - Are you confident enough to consider that the interviewer might be presenting a problem as complete which in fact requires some more info? (And to risk asking?) - Can you spot the trick in the question? - Can you perform the fully specified programming tasks, once you've spotted the trick? While I wouldn't say those are invalid, the question for you, the interviewer, is do they tell you what you need to know?; the answer may depend a lot on whether you're after someone you are expecting to train up or someone you expect to be refactoring your legacy code in their first week. I'm going to assume something closer to the former. The confidence issue is a big question and I'd argue you need to mitigate it. It's going to depend on all sorts of factors including how stressed they are (if it's their ideal job, the answer is *very*), how many people you've interviewed (i.e. how impatient you seem), and whether it's before or after lunch. Whatever problem you set, you should do make it clear you expect people to ask questions (even dumb ones). Sure, hubris is a Programmers' Virtue and a good employee will be confidently asking tricky questions and poking holes in the spec, but compared to the interview room that's a very different social relationship. Confidence (natural, socialised, or situational) gives you an advantage in interviews anyway, and I think it's important to avoid increasing that advantage. Spot the trick can be a useful skill, in fact, you can argue it's similar to the skills we use for debugging, but it's impossible to gauge reliably based on one problem (especially when the problem is equivalent to a well-known one which people might know by chance rather than because they figured out you need the additional info). And because the problem is mathematical, people with academic mathematics-like backgrounds will see that quicker, and I suspect that's going to end up selecting for a less diverse range of experiences/ideas/approaches/demographics than you'd like (but hey, maybe you feel strongly linguists will mess up your Perl code, I dunno). If you want to do Spot the trick, avoid known sequences. But because you don't want people to focus on trying to guess if it's ok to question the question in an interview, I would simply recommend saying 'Here is a function to do X, it doesn't work: why not/what does it do instead?'. Performing defined programming tasks is something you might want to test, but you could do a selection of simple and clear tasks in a pre-interview question without the trick, It's a filtering question. If you're doing this, I would recommend something which people can picture rather than just numbers, e.g. triangle numbers, as this minimises the chances that you're explaining things less than clearly or in a way inaccessible to the candidate, or in a way which makes them pore over the wording looking for tricks. (I know I just said avoid defined sequences but that was if you were testing something else; I am suggesting you choose one or the other). Things it doesn't necessarily test for, but which you might be interested in: - Is the candidate able to grasp and apply the principles of recursion, even if they've not used it before in a language? - Can the candidate turn an iterative function into a recursive one? - Does the candidate know (or can they meaningfully discuss) when it is best to use recursion? I'm writing this not because I think it's heresy to use this task, but to use it as an example to think through why we do tasks in recruitment. We need to think hard about and talk a lot about these questions, because we are Perl devs and not HR experts. So I guess as a positive recommendation: rather than a simple is problem X good or bad?, the question we should be asking ourselves is I want someone who is capable of doing A/B/C, and I am also interested about what they know about X/Y/Z. How do I design and present my problems so that as far as possible they identify all those and only those who can do A/B/C and give them the opportunity to demonstrate their knowledge of X/Y/Z? Daniel
Re: Interview Questions (was: Brainbench)
On 5 September 2012 23:15, Daniel Perrett perret...@googlemail.com wrote: The fib(n) task as stated tests three things of the candidate You're missing a key point of interviewing. The task is used to test how the candidate thinks, how they ask questions, how they explore a problem space etc. It has to be discussed and interpreted - simply marking an emailed submission of code to solve fib(n) would be unhelpful. As an interviewer your job is to measure their abilities/deficits with regard to understanding and exploring new subjects, at least as they relate to the kind of work you'll be asking them to do. It's not even just about assuring yourself that they're capable of doing the job, you need to be sure it's a job that will satisfy and interest them. I've never set anybody the fib() test but I find it very enlightening to work through a programming task with a prospective candidate. Really I find interviews are less about individual questions or tasks, and more about where the conversation goes based on them, and the interviewer's abilities to steer the conversation and to assess the candidate based on those discussions. Which is one reason why pre-interview screening tests for developers only go so far. It is arguable of course that my methods may select for more articulate programmers but I do try to ensure that the interviews are relaxed and friendly. If a capable engineer can't communicate in those circumstances there's always a doubt about how much they will be able to offer in a team anyway. /joel
Re: Brainbench perl test?
On Wed, Sep 05, 2012 at 09:51:27PM +0100, Gordon Banner wrote: Of course, almost all of them would use recursion, and my real interest was in the follow-on discussion why did you do it that way?, and how long it took them to twig that while factorials are a good illustration of recursion, recursion isn't necessarily a good implementation of factorials. Nor's a naive iterative method though - it takes no time at all before you overflow your ints and then (assuming that you're aware of this and use bigints, instead of just doing a fandango on core^Wvariable) every single operation after that is on bigints, and so is like trying to suck molasses through a straw. I've been working on-and-off on a way to reduce the number of bigint operations, but I keep running into other expensive functions. The best I've come up with so far: * requires a function to return the nth prime * requires a function to return the number of primes less than n these are required to get a list of the factorial's factors. You could use a lookup table - but then, why not just have a table of factorials * is NP-complete if you want to really minimise bigint ops the knapsack problem, breaking that list into sub-lists whose products are all just under 2^32 (or 2^64, or ...). And being NP-complete is the least of my problems, because the previous two functions *don't exist yet* and very clever people have been failing to find them for, oh, at least 150 years. Oh, and it's wrong anyway, because it misses some repeated prime factors :-) But hey, it's something to keep me out of trouble. -- David Cantrell | Hero of the Information Age Do not be afraid of cooking, as your ingredients will know and misbehave -- Fergus Henderson
Re: Interview Questions (was: Brainbench)
ok now that the subject line has changed to reflect the interview process, here is what i think the ideal interview is (experienced this both as interviewee and as hiring manager.) it should be a very short internship, i.e. here is a masked part of a problem we are working on, lets discuss this for a bit, then i'll let you work on this 2 hours and we'll meet again to discuss. when I interviewed (for another company some time ago) the entire algo team showed up for the post work review, and this happened twice, it was a 7 hour day. (~3.5 hours per problem) when i interviewed , i started with a homework question and then discussed it in the interview. (and asked followups) nothing like seeing someone do actual work, while looking over his shoulder on an actual computer. here, this is the entry point, have a look. http://upstream.shalit.name/ -- vish On 5 September 2012 23:12, Joel Bernstein j...@fysh.org wrote: On 5 September 2012 23:15, Daniel Perrett perret...@googlemail.com wrote: The fib(n) task as stated tests three things of the candidate You're missing a key point of interviewing. The task is used to test how the candidate thinks, how they ask questions, how they explore a problem space etc. It has to be discussed and interpreted - simply marking an emailed submission of code to solve fib(n) would be unhelpful. As an interviewer your job is to measure their abilities/deficits with regard to understanding and exploring new subjects, at least as they relate to the kind of work you'll be asking them to do. It's not even just about assuring yourself that they're capable of doing the job, you need to be sure it's a job that will satisfy and interest them. I've never set anybody the fib() test but I find it very enlightening to work through a programming task with a prospective candidate. Really I find interviews are less about individual questions or tasks, and more about where the conversation goes based on them, and the interviewer's abilities to steer the conversation and to assess the candidate based on those discussions. Which is one reason why pre-interview screening tests for developers only go so far. It is arguable of course that my methods may select for more articulate programmers but I do try to ensure that the interviews are relaxed and friendly. If a capable engineer can't communicate in those circumstances there's always a doubt about how much they will be able to offer in a team anyway. /joel
Re: Interview Questions (was: Brainbench)
On Thu, Sep 06, 2012 at 12:12:16AM +0200, Joel Bernstein said: Really I find interviews are less about individual questions or tasks, and more about where the conversation goes based on them and the interviewer's abilities to steer the conversation and to assess the candidate based on those discussions Yes. Yes. Thrice yes.
Re: Interview Questions
On 09/05/2012 06:34 PM, Simon Wistow wrote: On Thu, Sep 06, 2012 at 12:12:16AM +0200, Joel Bernstein said: Really I find interviews are less about individual questions or tasks, and more about where the conversation goes based on them and the interviewer's abilities to steer the conversation and to assess the candidate based on those discussions Yes. Yes. Thrice yes. and i have said that here a few times already. it is also the core tip i give to my candidates when they are interviewing. it is not an interrogation but a conversation. you should ask questions and tell stories about your projects. this is closer to a real work situation where you are discussing how to solve a project. uri
