4 ms·

At my company, we do 2 phone interviews, then we do a 4 hour on site paid coding interview where we ask the candidate to code real world problems on a real comp

by dsp1234 10y ago

At my company, we do 2 phone interviews, then we do a 4 hour on site paid coding interview where we ask the candidate to code real world problems on a real computer, with an OS/toolset list that we ask them to provide for us. We let them know explicitly what we're looking for (getting it working, getting it right or getting it fast, etc). This is about as 'real world' as we can make it, and it's generally worked out well. It's still problematic since it requires a physical block of time, and that eliminates some candidates who are currently working, but it's the best we've found so far.

mindcrime 10y ago
What we do is a "take home test" that's pretty open ended (depending on which role we're hiring for). We basically give the candidate the requirements and they have 48 hours to send us something. Currently for our data science roles, we give them some instructions regarding where to find a specific dataset, and basically say "use data science tools, visualization, etc., to tell a meaningful story about something in this data." We don't dictate language, libraries, or anything. So you can use R, Python, Scala, Octave, Fortran, or whatever floats your boat. Then what we look for are things like: 1. Is it documented well enough that we can deploy and run the code ourselves? 2. Is the code clean, well structured, documented, etc.? 3. Does it run with no errors? 4. Does the output do a reasonable job of satisfying the requirements? It's pretty open ended, which is itself a mixed blessing. Some people will look at it as an opportunity to really show off and show what they can do, and "flex their muscles" so to speak. Others may be intimidated by the lack of more detailed requirements. It's not a perfect test, but it works pretty well for us. The one other risk is that the candidate will use a language that nobody here is qualified to evaluate (like FORTRAN), but in practice that hasn't been an issue.

by dsp1234 10y ago

mindcrime 10y ago

What we do is a "take home test" that's pretty open ended (depending on which role we're hiring for). We basically give the candidate the requirements and they have 48 hours to send us something. Currently for our data science roles, we give them some instructions regarding where to find a specific dataset, and basically say "use data science tools, visualization, etc., to tell a meaningful story about something in this data." We don't dictate language, libraries, or anything. So you can use R, Python, Scala, Octave, Fortran, or whatever floats your boat. Then what we look for are things like: 1. Is it documented well enough that we can deploy and run the code ourselves? 2. Is the code clean, well structured, documented, etc.? 3. Does it run with no errors? 4. Does the output do a reasonable job of satisfying the requirements? It's pretty open ended, which is itself a mixed blessing. Some people will look at it as an opportunity to really show off and show what they can do, and "flex their muscles" so to speak. Others may be intimidated by the lack of more detailed requirements. It's not a perfect test, but it works pretty well for us. The one other risk is that the candidate will use a language that nobody here is qualified to evaluate (like FORTRAN), but in practice that hasn't been an issue.