I take many programming interviews at my current organisation. These days one of my favourite interview question is to flatten a nested list structure. I give user an input
[1,[2,3], [4, [5,6]]] and ask them to write a program that will give output
[1,2,3,4,5,6]. So, far I have asked this question to at least 20 candidates and 18 out of them have failed to write this program. I find this question better than canonical FizzBuzz problem as flattening a list is comparatively more involved problem.
This is how interview goes:
- I ask candidate to write a program that takes
[1,[2,3], [4, [5,6]]]as input and return
[1,2,3,4,5,6]as output. I specifically say you have to flatten a list.
- They can choose any programming language they like. Usually they are Java programmers so they end up choosing that.
- I ask them to write test case as well.
The common patterns I have noticed in most interviews:
- Candidate fail to write proper method signature. They get confused about what type of list they should use. Some start with List of integers
List<Integer> ints. They fail to see how they will store a
public List<Integer> flatten(List<Integer> numbers)
- Some candidates start with a primitive array. Very quickly they realize array is fixed size data structure so they should use a List.
- They give method bad name like getList or processList etc. While explaining the problem, I explicitly mention that they have to flatten a list still they don’t use
flattenas name of the method.
- Most programmers fail to get that they can recursion to solve the problem. Candidates who solved this problem get that they have to use recursion in a few seconds.
- Some programmers have hard time storing result in a List using the recursion approach. They use recursion but forget to store result. Most don’t know difference between recursion and tail recursion.
- Some programmers have hard time thinking how they should check instance is of some type.
- Most of them make flatten instance method. Programmers don’t think whether they should make method static. Programmers for some reason think static is bad.
- No one starts with a test. Most jump straight away to code. You have to pause them and ask can you please write down in plain English what you are trying to achieve.
- I tend to give a lot of help and pointers to the candidate. I want to make sure that they solve this problem. Candidates end up taking close to 45-60 mins to finish the solution. Some fail to get it working even after an hour.
- No one thinks about generic program so that solution will work across all types.
- No one used Java 8. Candidates tell they have heard some features of Java 8 but they don’t use it. I doubt adoption of Java 8 has reached a critical mass.
I am not sure what makes this problem tough for candidates. May be pair programming with interviewer just does not work. What are your thoughts?