He did end up passing, yes. This one is is pretty intensive coding position and he said the solution wasn’t quite up to what was expected.
It’s my bad. I have so little code I can show to people. All the clever algorithms, the elegant, fluent APIs, the gorgeous implementations of econometrics algorithms described in academic papers, pushing MATLAB as far as it can go, used in research projects generating papers I’m co-author on. The comprehensively documented libraries, the thorough error handling, the logging and type hinting. The elegant, sweated-over relational models, the NoSQL schemas, snowflakes and normal form. Data models so good that the algorithms write themselves. Nearly of all it covered by NDAs.
And because I’ve not published much open source code, through work or…
He did end up passing, yes. This one is is pretty intensive coding position and he said the solution wasn’t quite up to what was expected.
It’s my bad. I have so little code I can show to people. All the clever algorithms, the elegant, fluent APIs, the gorgeous implementations of econometrics algorithms described in academic papers, pushing MATLAB as far as it can go, used in research projects generating papers I’m co-author on. The comprehensively documented libraries, the thorough error handling, the logging and type hinting. The elegant, sweated-over relational models, the NoSQL schemas, snowflakes and normal form. Data models so good that the algorithms write themselves. Nearly of all it covered by NDAs.
And because I’ve not published much open source code, through work or in my time, understandably, all interviewers have to go on is me writing ten lines of code to sort a leaderboard, under pressure, on whatever day I’m having.
When I interview people, I don’t do this. Because I’ve been doing Test Driven Development (TDD) and pair programming (what Woody Zuill now calls “software teaming”) on and off since 2006, I grab a colleague and pair program with candidates, then swap round, them then pairing with my colleague, working on real, existing production code, rather than doing something from scratch. We listen for what they know and what they understand; what they notice and what they care about; what they ask and what they explain.
We do some Test Driven Development, too, writing production quality code right there and then, because if that’s what they’re used to, as I am, the other work is likely to be a disaster unless they’ve intentionally practiced for these interviews.
My approach is based on the very common experience I’ve had after interviews: I sit down and play around with the problem I was given and within ten minutes come up with a beautiful, elegant solution that seems worthy of some sort of gold star. Sometimes I share my solution with the interviewng team, for their amusement; it is also, perhaps, for my redemption.
But let’s keep it real. I’m also really rusty on this sort of coding in Python. It’s been a while. Mostly recently it’s just been plugging one ML or NLP tool into another. This is totally on me: I need to practice more involved coding. I also need to pull my Coding Interview books off the shelf so I can answer the basic questions my tech screener asked about OOP. Have those four pillars of Abstraction, Encapsulation, Inheritance, and Polymorphism ready to explain, along with the SOLID principles and a careful explanation of the Liskov Substitution Principle.
When I started at Phyn, Dr. Salil Banerjee, now Data and Analytics Strategy Lead for Google Research, told me I should never need to interview again. He had hired me without an interview because of our time working together at RECON Dynamics. Well, sure, but in reality, I do, and I did, and I have some work to do.