3 Interview Questions for Software Developers I love, and Why
When recruiting talent I like to keep the process simple. Getting a job is, after all, a full time job and I want to be respectful of people’s time and make decisions quickly. Over the years I’ve found it’s useful to ask a few questions that can’t be Googled, copy/pasted or involve writing code.
These questions are a good barometer of a candidate, whether they’ll fit into our organization and can be phrased or designed as so-called “knock-out” questions (meaning if the right answer isn’t obtained, the candidate is auto-rejected). This is particularly helpful when posting to job boards that are free and make it easy to apply to open positions in bulk.
Question 1: Readability or Correctness
If you had to choose between readability and correctness of code, which would you pick an why?
This question is great because the answers can be ranked and most candidates self-select into the worst response, making it a good knock out question:
- Worst response: candidate doesn’t pick, instead saying “you need both”
- Decent response, if defended: Correctness
- Best response: Readability
Worst response: no answer
In my experience roughly 80% of candidates don’t answer this question. And by that I mean they say “both are important”. Yes, both are important. But I operate in the realworld of building a growing business and you often need to make tough choices.
It’s ok to be wrong- after all, if you’re never wrong, you’re not learning. But it’s really not ok to harbor an attitude of, “we need to live in a perfect world before we can do anything”. Those are bad hires.
Decent answer: correctness
Correct code is good in that it keeps your system functioning and lights on. It pays the bills. However the question is constrained: either the code works but can’t be read, or it has a bug but you can read it.
If you pick code correctness, then you can’t read it. You literally can’t make sense of it, which means you can’t change it, and that means you just inherited technical debt, which you need to manage.
Junior developers tend to pick this option. After all, what good is code that doesn’t work? Why and how did it get into production in the first place? And isn’t that bad for the business?
All fair points, but more experienced software developers have probably felt the real pain of so-called spaghetti code. And they recognize that not only is that code difficult to work with, but managing the technical debt puts downward pressure on the organization across many dimensions that prevents innovation. Too much leads to a downward culture spiral since the best software developers don’t want to spend their time managing technical debt.
Embedded in the question is an opportunity to pick whether to have technical debt or not — so for goodness sake, don’t pick the debt.
Best answer: readability
If the code is readable but incorrect then it’s broken. Now, that’s unfortunate, and I don’t wish bugs on anyone or anything. But as long as it’s readable, it’s debuggable and the problem can be fixed.
Moreover code that’s readable tends to be written by senior software developers who know the value of commenting, linting and how to bring peers into pull request reviews. Those same people tend to build logging and metrics into their software to make it observable. They build out automated delivery pipelines to ship new releases. All these add up to broken code having limited impact, low blast radius, optionality to rollback to a previously working version, (hopefully) quick fixes and easy follow up communication to customers.
Question 2: Difficult Code and Situations?
We ask this a couple of different ways — “what’s difficult about achieving code maintainability” or “what’s the biggest anti-pattern you’ve seen among your colleagues or peers?”
The point of this question is simple: we all have horror stories we’ve been through. But did you learn anything? Did you blame people around you? What’s your overall attitude, and how well did you handle the situation, however much pressure there was?
This is a good get-to-know-you question and to get the candidate talking about soft skills and lessons learned, not just what knowledgeability and technical skills are being brought to the table.
Question 3: What’s the limitation of the GIL in Python?
This question both is and is not specific to Python. Taken literally, yes, it’s asking about the GIL (Global Interpreter Lock). But the underlying issue is about concurrency vs. parallelism. And a Pythonista would recognize that immediately.
We’re looking for candidates to be able to identify that a correct system design is one that is enabled for concurrent execution. If, as a byproduct, you achieve parallelism because threads can be spread over multiple cores, then that’s great.
The reason we ask this question in the lens of Python is company-specific. BridgeFT started in 2016 using Python and we’ve since migrated to Go. We love Python, but only for data science and exploratory work. We had too much trouble productionizing it: packaging was a nightmare (yes, even with pipenv), the Docker builds were extremely large, and put a lot of work into making sure data wouldn’t “leak out” of C-compiled backends like Pandas, Numpy and Cythonized code.
As a team, we’re very open to hearing about other people’s pain points around Python. And while it’s easy to throw Python under the bus for all kinds of problems, I personally don’t think the GIL is a fair criticism. It sounds bad, but it’s less worse than you think. And someone being too critical of the GIL isn’t properly building for concurrency. And people that are critical for the sake of criticism without thoughtfulness tend to be bad hires: they blame problems on everything and everyone instead of focusing on the solutions.
BridgeFT is recruiting for three roles to join the ranks of a quickly expanding company:
- Full Stack Engineer to join our platform team in building out both frontend product and backend systems.
- Infrastructure Engineer to work on a combination of DevOps tooling, SRE monitoring and migrating us over to Kubernetes so we can better leverage open source projects.
- Data Engineer to ingest and aggregate our data sources in a scalable, streaming ETL pipeline to deliver data and enable analytics.
Let me know if you’re interested! Please apply or reach out to me on LinkedIn if you’d like to chat.
