Make take on the flattening arrays coding challenge

As someone who interviews candidates for programming positions, I find nice that some companies propose coding challenges that the candidate should complete before been interviewed. This allows the interviewer to have broad vision on the candidate programmings skills and adjust the interview based on candidate’s experience.

Today I’m going to complete the flatten array challenge and comment on what I’ll looking for if I were doing a code review for an applicant.

So, this challenge is for an experienced backend engineer position and goes something like this:

“Write some code, that will flatten an array of arbitrarily nested arrays of integers into a flat array of integers. e.g. [[1,2,[3]],4] -> [1,2,3,4].”
When writing this code, you can use any language you’re comfortable with. The code must be well tested and documented if necessary, and in general please treat the quality of the code as if it was ready to ship to production.
Try to avoid using language defined methods like Ruby’s Array#flatten

Since I “steal” the challenge from a ruby shop, I’ll use ruby to solve this challenge.

Because the code must be well tested and ready to ship, the first thing I’m going to do is to write a failing test for the very basic case and code my way up from there.

I like lightweight solutions, so I’m going to use “test/unit” library, because: a) it ships with ruby, and b) it’s really small and straightforward to use.

Here is the full listing of the code that I would write if I was applying for that position.

(At the bottom of this post I comment on what (in my opinion, of course) this code tells about candidate’s experience, or in other words, what would be my take if I were reviewing the code.)

The first thing I did was to write a test to verify the essential case, flatten the nested array that the challenge uses as an example on the spec.

nested_array = [[1,2,[3]],4]
flat_array = [1,2,3,4]
assert_equal(flat_array, flatten(nested_array))

So far so good. But what other cases are there? Let’s find out:

Instead of going over and analyze each test case separately, I’ll “dissect” the flatten method’s code. That’ll be sort, easy to follow, and focused on the production code.

Another nice thing about this code is that is implemented as a module, that is a piece of functionality that can be plugged in anywhere an used right off the bat.

So to sum up, this is what I would like to find on experienced candidates’ code:

  • Did they manage to implement a working solution?
  • Do they understand recursion?
  • Did they take into account corner cases?
  • Did they guard against invalid input?
  • Did they provide comprehensive messages when errors occur?
  • What about comments. Are they clear?
  • Did they write tests?
  • If they wrote tests, what’s the coverage of those tests?
  • Which tools did they use to implement the solution?

Since this challenge is language agnostic, I wouldn’t check on language features or platform specifics aspects.

It’s interesting how a little bit of code can tell so much about candidates experience, don’t you think that’s nice? I certainly do.

So that will be it for this coding challenge. I hope you enjoyed it, and see you next time!