Technical interviews, and the big ‘big-O’
I often have one of those “it’s amazing how different people’s views on programming can be” moment. Last one happened during a phone interview for a full-stack engineer type of gig, the third one in a row for that position. This was supposed to be the ‘technical’ one…
Given a list of letters, and a list of words, please find the longest word in the list that can be created using the letters.
When I hear something like that, my first thought (in a Python context), is to head for the ‘itertools’ module, part of the standard library. Basically my solution to the above problems involved using ‘itertools.permutations’ to get a sequence of all possible permutations of letters, and use that as a basis for further step-by-step filtering and sorting.
However, pretty much as soon as I started typing “import itertools”, the interviewer interrupted me and started: “but Monsieur, this would not be big-O efficient’.
Oh boy, here we go again…
Perhaps I should have known better, cause a year ago I had exactly the same experience(that time involved a list of integers, and the need to find all pairs that would add up to 10).
Actually, I do this stuff somewhat on purpose, cause there is an idea behind all this: I want to find out “what engineering culture is that company trying to build?”.
Here is my point of view: when you use itertools, it might not be big-O efficient, however it gets the job done, and most importantly it’s easy for anyone to know what your code is doing.
Basically, I work with the people reading my code my mind, not the computer executing it. Also, I try to use ‘what you want done’ type of tools over ‘how you want it done’ ones, unless I have a really good reason for not doing so(hint: a coding interview is not a good reason).
If you love algorithms
I’m not saying bare-metal algorithmic logic is not an art in itself, as a matter of fact, I have huge respect for the people implementing the libraries and data-structures that I use on a daily basis.
Having said that, in the day to day practice of web application programming, you don’t deal with big-O type of problems. So why focus on this particular type of problem in interviews?
Are we simply fooled by things that are labeled as ‘knowledge’, and happen to be easily standardised and testable? The stuff you pick up through experience is much harder to describe, let alone ‘test’ in a standardised way.
Some people asked me: ‘why don’t you make an effort and learn those basic algorithms skills?’. It’s a good point, and my answer is: I love to learn new things, and I’ll let my daily needs as a programmer guide me, not somebody else’s ideas of how to interview someone.
Most importantly, I want to work with people who keep things simple, reach for the appropriate tools when they can, and worry about efficiency only when it becomes a problem.
“Premature optimization” is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.