This post is about my weak side. I am terrible in going through interviews. Even when I get hired, my managers would almost always later tell me that they were uncomfortable making that decision. Just today I have been reminded how bad I am at this.
A recruiter from a big and famous company reached out to me on his own. I was surprised as I applied there just a few months earlier and never heard back. The recruiter said that there is no record of me in their system. Ok. That is not the worst part. The worst part surfaced later, when I started to look at two year old emails - from the time I have applied there the previous time. I found a piece of code that I send to that company. That was the worst part.
They asked me to write a code that searches a sorted (!) array for a nearest match. There could be various matching conditions and various directions of search.
Looking at the task now it is apparent for me that they expected a modified binary search function. That is not what I wrote and send them back.
My code had an enum for search criterias, I used its body as an interface and its instances as concrete implementations. It is a sealed trait in Java. Then I wrote a reverse iterator to traverse the array in an opposite direction. Finally, I have put the two together in a function that - oh my god - traversed the entire array to find the match.
I was looking at this today, thinking "Why would I ever write it this way?" And then I looked at the task I had been given. It did not state that the resulting function had to be efficient, there were no conditions on computation complexity. It was simply "write a function that does this". So I did. I wrote a well documented and very readable code, that would have been obvious how to extend (to add other search criterias, for example) and to reuse (to delete all by criteria, for example). It did not rest on any minute assumptions, such as that criteria-defined distance is monotonic (it would've worked if an integer was the char, with both 'a' and 'A' being equally close to 'b'). It was even bright in its use of a sealed trait. But it was not the best performing code.
Even though I was not tasked to write the best performing code, it was implied by the fact that it was during an interview.
Of course the next letter I received was a rejection one. I would've rejected an engineer who wrote this code probably. And yet something does not feel right.
I was in my "production coding" state. The mode in which one thinks about people who are to support one's code. The mode in which locking extra expectation in your code is bad. The mode in which premature optimization is evil.
The code I wrote was good, but I did not get the job. Because I used the wrong skill. The code was good for real application, not for an interview.