In the May 2016 thread, a number of questions / criticisms were raised about our recruitment process at BaseCase:

-) 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

From the document I received:

BaseCase Programming Test You have 9 hours to implement the following game. In order of importance, we are interested in: 1. The full, bug-free implementation of the spec 2. The elegance of the code 3. The time needed to completion

These were the only criteria that were asked and I can assure you that my code was a full, bug-free implementation and very much on time. Elegance lies in the eye of the beholder, but I thought it alright.

Followed by some test that I'm not going to specify further at OPs request. (they seem to have a couple of these tests and you get assigned one randomly and they probably appreciate not having to delete from their test base)

While you claim that this is not specifically OO, the problem itself was very clearly one that lends itself heavily towards OO. If you want me to solve it in Erlang, we can do that as well, but please.

If you want the test to be a "work sample" test, say so. Seriously. You hand me a test that screams "please, for the love of god, just demonstrate that you're capable of writing some classes" and then you use that to find evidence of production level software development. That's not how it works. Include one line in that 3 page document that says "demonstrate your ability to produce maintainable code" and the solution would have looked vastly different. This was a silly challenge and you got a silly solution to a silly challenge. Because thats all it is. If google invites me to a technical interview and says "write fizzbuzz", I'm not writing a unit test first to demonstrate my Test Driven Development fundamentals. I just write some code to demonstrate that I'm not a potato.

Why would I assume that this is just another algorithm test? Because you told me clearly that there would be another 2 rounds of technical interviews.

If you want to look at a work sample, here's how you go about it: Ask for a work sample. Really simple.

FYI, if this test is indicative of the "challenges" faced at basecase, then working at basecase IS boring (to me). If it's not, then your interview process is flawed. Writing "test driven, maintainable code only" is an accountants job. Not something I'd be interested in. So in a roundabout way, I guess your test succeeded.

Take care!

Thanks for the frank feedback.

You raise a valid point: I should make more explicit what I am evaluating in the solution. I will update the relevant document so that future applicants have a clearer idea of what they're being 'graded' on.

Regarding the other points you raised, I disagree with many of them, but I think I'd chalk it up to 'reasonable people can disagree on these things'. If you would like me to respond to a specific item, let me know and I'll do my best.

Best of luck,

Diarmuid

Well, since you seem to know who I am, you probably know which challenge I was given. Do you really think its not an OO problem?

Otherwise, you can probably have some of your other engineers review these tests if you are too busy to do it yourself. Not like this is rocket science. They can at least weed out clear failures like me :D

  > Well, since you seem to know who I am, you
  > probably know which challenge I was given.
  > Do you really think its not an OO problem?

OO is indeed the most common strategy for solving the problem you received. However I'm sure you appreciate that you could use many different techniques.

I think that after OO, ~functional solutions (ie: 90% pure functions, 10% non-pure) would be the next most popular. Such solutions can be quite elegant.

  > Otherwise, you can probably have some of
  > your other engineers review these tests if
  > you are too busy to do it yourself. Not
  > like this is rocket science. They can at
  > least weed out clear failures like me :D

I know you're joking but I certainly realize that I reject many candidates who would actually have been great hires. It isn't possible for me to evaluate people 100% accurately, so I have to settle for conclusions drawn from an admittedly imperfect process.

As for getting other engineers to help with the review process: I've been reluctant to do so in the past for a variety of reasons, but after 8 years (!) I'm actually considering it.

Cheers,

Diarmuid

"If the hiring/interview process is needlessly complicated, run."

It's great to see so clear response here, thanks.

Cheers. It's important to me to convey that we're utilizing the HN "Who is Hiring" threads in a fair and reasonable manner.

I'll do my best to answer any other questions people may have.

Diarmuid