There are two things that baffle me most about candidates in coding interviews.
First, I’m surprised how many don’t think to ask questions.
I’m sure some interviews—and some interviewers—expect candidates to get no help. They want you to know some obscure trick or to spot the “gotcha.” That’s unfair in most situations.
During my time as a Google coding interviewer, that was never my expectation. Nor, as far as I saw, was it that of my peers. We judged good candidates in part by the quality of questions they asked to clarify assumptions and gather necessary details.
And even when candidates do ask questions, I’m disappointed by how terribly they devise good ones.
Don’t be like them.
If you’re preparing for technical coding interviews, focus on this crucial skill. In this article, I’ll share seven questions you can ask in almost any coding interview to become a more effective problem solver.
Why are questions so important?
Effective technical interview prep isn’t just knowing data structures and algorithms (DSA). It’s about knowing what questions to ask.
At its best, technical interviews are about how you solve problems with other people. You must use good communication skills and critical thinking. I’ve written about this in my now viral article about LeetCode interview prep.
Good problem solvers tend to be inquisitive. It is a quality that defines those who challenge the status quo. They tackle unsolvable problems. They find novel approaches that most people miss. These individuals are really hard to find.
Asking thoughtful questions is concrete evidence of good problem-solving behaviors. This is exactly what you want in your interview assessment so that the hiring committee forms the right impressions about you.
With that out of the way, here are seven questions you can apply to nearly any coding interview, whether you’re interviewing for Google, Meta, or a startup.
1. What language can I use for the interview?
For big tech companies, you are usually free to choose your language. But smaller companies or specific teams may want to know your skill in a specific language. It’s important that you ask what languages are acceptable for your interview.
You’ll usually work this out with your recruiter beforehand. However, your interviewer might need to test your knowledge of a specific language. The choice of language may also make a difference for the type of question they need to ask.
In my last coding interview some years ago, I had to learn a new language because that company used Ruby. I had never used it professionally or personally, yet I was willing to brush up on it over a couple of days to get acquainted. I could’ve insisted on going with a language I knew better. But I wanted to show my ability to pick things up quickly.
If I hadn’t asked about acceptable languages for the interview, I might’ve been just fine. I think I got the offer in part because I was willing to demonstrate flexibility in learning a new language in a short amount of time.
2. Can I use functions and libraries available in my language?
Candidates are often too eager to implement a data structure or algorithm from scratch. It is seldom ever necessary for you to do this. Rather, it’s more important to know how to use the existing tools of your language. Just ask for permission first.
There may be times when using an out-of-the-box library function would defeat the purpose of the interview problem. Maybe the function wouldn’t address the unique constraints of the problem. Either way, don’t dismiss built-in tools because you mistakenly assume you need to build it yourself, whether in an interview or on the job.
3. What is the type of the input data?
For a coding interview, you will need to transform some input into output data. You must understand what your input will be and its constraints. Among other things, that information will help you to author the correct function signature.
If you’re used to practicing on LeetCode or HackerRank alone, then you always get this spoon fed to you. You should not presume that a function signature will be given to you in a real interview situation. You’re going to have to work for it.
Now I wouldn’t recommend asking for the data types outright. That’s because your interviewer will likely provide hints in the problem statement about the nature of the input data. Form educated guesses about the input and validate them with your interviewer.
For instance, if given a list of phone numbers, they are likely either integers or strings. I might ask my interviewer if the phone numbers will be represented as an array of integers. Whether they respond by confirming my assumption or by correcting it, I will have more information I can use to solve the problem.
4. Will the input always be valid?
This is one question many candidates miss. Again, if you’re using LeetCode or HackerRank alone for coding interview prep, you’ll be used to the luxury of only valid input for most situations. But your interviewer may want to see that you know how to write code defensively to protect against bad user inputs.
Usually in interviews, I don’t trouble candidates with having to handle edge cases. However, I appreciate when they proactively identify potential issues with null, empty input, or illogical input. I mean, Murphy’s Law, amirite 😂?
Why not write guard code every time? The reason is that you only have 45 minutes to 1 hour for your interview. Writing guard code leaves you less time to work on the mainline logic. Avoid writing any code you don’t have to write.
5. Does the input fit in memory?
Most of the time, it’s correct to assume that the input will fit in memory starting out. So why should you still ask the question up front?
First, I appreciate when a candidate knows we don’t always have the luxury of working on a single machine. That’s especially true when you work at a big tech company. It demonstrates a certain maturity when a candidate confirms this assumption.
Second, asking this question takes some courage. The solution for a problem that can be solved on a single machine is quite different from one that can’t. This can be scary for some candidates, but not so much for those who are stronger and more experienced. Don’t worry about increasing the difficulty of the problem prematurely. Either your interviewer was going to go there anyway or they aren’t that interested in it. There’s only upside.
Besides, scaling up isn’t that hard when you learn a few patterns. Break the solution into smaller sub-solutions that run in parallel. Then, combine into a final answer. For instance, you can find the max of a large dataset by computing the max of smaller subsets and then computing the max of the maximums.
6. Is the input sorted?
I like this question a lot. With a simple “yes” or “no,” I can know whether to eliminate sorting algorithms as a tool I need to solve the problem. Not only that, but algorithms like binary search only work on sorted data. If I know that the input is sorted, then I should automatically think about how that tool could be useful.
If the data is mostly sorted, I could use insertion sort or bubble sort. Those work better for this situation and for some inputs.
7. How do we define “optimal?”
We all know that Big O is the usual way that we assess the performance of code in DSA coding interviews. But it’s not the only way. Sometimes, we just need the fastest solution we can build. Or the cheapest. Or the one with the least lines of code.
Many candidates agonize over getting to the Big O optimal solution when a naive solution is fine. It’s tragic, really. They end up losing time and not doing as well as they could have. They place undue pressure on themselves. Remember, it’s more important to get a working solution first than to get the fastest one.
Even when we are talking Big O, we may care more about space optimization than speed. Usually, you have to trade off between the two, and knowing which one is more important is a detail your interviewer will help you resolve.
Some questions for you
Although I’ve presented these 7 questions, there are probably a few more you should ask that I didn’t discuss here. Do you have any that you find useful? Is there a question that saved your neck in a coding interview? Are there questions you consistently forget to ask? Feel free to drop a comment and let’s discuss!
Anthony D. Mays is a former Google engineer, career coach, and founder of Morgan Latimer Consulting, lighting the way for the next generation of technologists. He’s on YouTube at youtube.com/@anthonydmays. Find more resources at anthonydmays.com/links.