-) https://news.ycombinator.com/threads?id=basecase_com (scroll down a bit)
Unfortunately, I was only made aware of this after the thread had closed for commenting. For that reason, I thought it best to reply here to the issues raised.
Firstly, I'd like to say that recruitment is hard, and reasonable people can disagree on what constitutes the 'best' strategy.
With that in mind, I think the main issues raised in the thread were:
1. Rejection email not sent
2. 9hr coding test is too long
3. Coding test is 'pointless OO', not suitable for a senior position
I'll address them one-by-one.
1. Rejection email not sent
One of the posters (wayn3) mentioned they didn't receive a rejection email. I've checked our logs, and he's right that when he wrote his comment we hadn't sent the rejection email, but we subsequently did. So - wayn3: apologies for taking so long to send a rejection notice (3 weeks / May 10). It doesn't usually take me so long to review a solution, but sometimes it does happen due to other commitments.
But I would like to say that to the best of my knowledge, we never "drop" conversations, we make it clear if / when we reject a candidate.
2. 9hr coding test is too long
9hr is the time limit, not the expected duration. The amount of time required is usually 3.5hrs - 7hrs, with an average of about 6hrs for a good solution.
3. Coding test is 'pointless OO', not suitable for a senior position
I'm not looking for OO code specifically. Candidates can submit any kind of solution and I'll review it.
But to some extent the criticism is accurate - the test isn't technically very challenging, and it doesn't have any 'tricky' questions. This is however intentional: the day-to-day of software engineering is writing high quality, easy to maintain code for (mostly!) straight-forward problems. Logic tricks / fancy math are only rarely required for the work we do at BaseCase.
Put another way, the programming test tries to be a 'work sample' tests, simulating something more like the code you would actually write at BaseCase (without requiring you to learn all about our architecture).
This isn't to say that work at BaseCase is boring or humdrum, it's just that the challenges are related to designing high quality, easy to maintain software. To evaluate someone's ability to do this, I need to review a couple of hundred of lines of code they've written to solve a straight-forward problem.
If anyone has any questions please add them in here and I'll try to answer them.
Diarmuid Glynn / CTO