How many questions should you ask in a CS interview?
Technical interview questions vary enormously depending on the role, the seniority level, and what a company is actually trying to measure. This guide covers the questions that come up most often across software engineering, Python-specific roles, and machine learning engineering, plus the strategy question hiring managers ask more than almost any other: how many questions should you actually ask.
Most hour-long technical interviews work best with three to five substantive questions or problems, not ten or fifteen quick ones. Depth beats breadth here. A candidate who spends 20 minutes working through one meaty problem, explaining their reasoning, handling a follow-up twist, and discussing tradeoffs gives an interviewer far more signal than a candidate who rushes through eight shallow ones.
A reasonable split for a 45-60 minute technical interview looks like this: one warm-up question to settle nerves and confirm basic fluency, one or two core problems that carry most of the evaluation weight, and one open-ended follow-up or system-design-style extension that tests how the candidate thinks beyond the immediate problem. Leave the last 5-10 minutes for the candidate’s own questions.
The number matters less than consistency. Whatever count you land on, ask every candidate for a given role roughly the same set of questions, so their answers stay comparable. A panel that improvises a different question count and mix for each candidate loses the ability to compare results fairly. This lines up with Google’s own structured interviewing research, which found that consistent questions and scoring criteria across candidates predict job performance far better than freeform, improvised interviews.
Seniority changes the mix more than the count. A junior interview usually spends more time on the warm-up and core questions, checking that fundamentals are solid, while a senior interview spends less time proving basic competence and more time on the open-ended extension, since that’s where seniority actually shows up — in how someone handles ambiguity, tradeoffs, and scale, not in whether they can solve the base problem.
Python interview questions
Python interviews at most companies test a mix of language fundamentals and problem-solving ability, rather than obscure trivia. Common areas include data structures and their tradeoffs, since a strong candidate explains the time complexity difference between reaching for a list versus a set versus a dictionary, not just which one “works.” Common built-in behavior that trips people up also comes up often — mutable default arguments, how Python passes objects to functions, and the difference between shallow and deep copies — since these questions test whether someone has actually hit these issues in real code, not just read about them. Practical problem-solving matters too: string manipulation, list processing, or a small algorithmic problem the candidate solves in Python specifically, since idiomatic Python (list comprehensions, generators, built-in functions) is itself a signal of experience level. Object-oriented and functional patterns round this out — how a candidate structures a small program, when they’d reach for a class versus a plain function, and whether they understand decorators or context managers well enough to use them correctly.
A strong Python interview question doesn’t need to be obscure. Asking a candidate to write a function that groups a list of dictionaries by a key, then discussing how they’d handle a much larger dataset, reveals more about real ability than a puzzle question ever will. Other questions that work well in practice: explain what happens when you use a mutable object as a default argument, and why that surprises most people the first time they hit it; given a list of numbers, write a function that returns the running average without loading the whole list into memory twice; and explain the difference between == and is in Python, with an example of where confusing the two causes a real bug. For a deeper set of practice problems at every difficulty level, see our Python coding challenges guide.
Python debugging interview questions
Debugging questions test a different skill than “write this function from scratch” questions: how a candidate investigates a problem they didn’t create. This matters because most real engineering work is debugging and modifying existing code, not writing greenfield code.
A good debugging interview question gives the candidate a working-looking piece of Python code with a subtle, realistic bug — an off-by-one error in a loop, a mutable default argument causing state to leak between calls, or a comparison that silently fails on edge cases like empty lists or None values. For example: a function that appends results to a list passed in as a default argument will keep accumulating results across unrelated calls, producing results that look correct the first time and wrong on every call after — a bug real engineers hit in production, not an artificial puzzle. The goal isn’t to trick the candidate; it’s to watch their process.
What to look for: does the candidate read the code and form a hypothesis before changing anything, or start randomly editing? Do they add print statements or use a debugger methodically, narrowing down where the problem actually lives? Do they explain their reasoning out loud as they go? A candidate who finds the bug quickly by guessing is a weaker signal than one who takes a bit longer but demonstrates a repeatable, systematic process — because that process is what will actually scale to a much harder bug in production.
Machine learning engineer interview questions
ML engineer interviews need to cover more ground than a typical software engineering interview, because the role spans data work, modeling, and production engineering. Strong ML interview questions usually fall into a few categories. Data and feature questions cover how a candidate would handle missing data, detect a data leak between training and test sets, or decide which features actually help a model versus adding noise. Model evaluation questions cover how to choose the right metric for a given problem, such as why accuracy is a poor choice for an imbalanced classification problem, and how to interpret a confusion matrix or a precision-recall tradeoff in a real business context. Production and deployment questions cover how a candidate would detect model drift after deployment, what monitoring they’d put in place, and how they’d debug a model that performs well in training but poorly in production, which is one of the most revealing questions in ML hiring because it tests systematic thinking rather than memorized theory. System design for ML rounds this out — how a candidate would design a recommendation system or a fraud detection pipeline end to end, including how data flows in, how the team retrains the model, and how the system handles scale.
These same questions work whether you call the role a “machine learning engineer” or an “ML engineer” — the title varies by company, but the actual skills the interview tests don’t change.
OpenAI and AI company interview questions
OpenAI interview questions, and interview questions at any company building generative AI products, typically add a layer on top of standard ML and software engineering questions. Expect questions that test applied LLM knowledge — how a candidate would design a retrieval-augmented generation system, handle prompt injection risks, or reduce hallucination in a production application, rather than just explaining how transformers work in the abstract. Evaluation of generative systems comes up too, since a generative model doesn’t have a single “correct” output, and interviewers often ask how a candidate would build an evaluation framework for something inherently subjective, like response quality or safety. Scale and cost tradeoffs matter as well — how a candidate would think about latency, inference cost, and model size tradeoffs when deploying an LLM-based feature to millions of users, which is a very different constraint set than training a model in a research setting. Safety and alignment awareness rounds this out: even in a straightforward engineering interview, companies building frontier AI systems increasingly expect candidates to have thought about failure modes and misuse, not just capability.
The bar at these companies tends to be less about memorized facts and more about whether a candidate has actually built with these systems and hit their real limitations firsthand.
Turning good questions into a fair interview
Having strong questions is only half the job. The other half is scoring answers consistently across candidates, which is where a lot of technical interviews quietly fall apart — two interviewers asking the same question can walk away with very different impressions of the same answer if they don’t agree in advance on what a strong response looks like.
Build a simple rubric for each question before the interview: what does a weak, adequate, and strong answer actually look like. Our guide on how to conduct a panel interview covers this in more depth, including a worked example of scoring a system-design answer on a 1-to-5 scale.
Where CodeAid fits in
Writing and scoring strong technical interview questions consistently across dozens of candidates is exactly what Codeaid’s AI Interviewer automates. It generates domain-specific assessments covering software engineering, Python, and machine learning, including the kinds of debugging and system-design questions this guide covers, then scores every submission against the same criteria automatically. Hiring teams get the benefit of well-designed questions without writing and re-grading them by hand for every candidate.
FAQs
What should I ask candidates during a coding interview?
Ask a small number of substantive questions rather than many shallow ones — three to five for a typical hour-long interview. Cover core language fundamentals or algorithmic thinking with one or two questions, include at least one debugging or “read existing code” question since that reflects real engineering work, and reserve time for a follow-up or extension question that reveals how the candidate thinks beyond the immediate problem.
What are common interview questions for technical roles?
They vary by role, but most technical interviews draw from four buckets: language and data structure fundamentals, debugging or code-reading exercises, system design or architecture discussion, and role-specific questions — model evaluation and data pipeline design for ML roles, for example, or applied LLM questions for generative AI roles.
What’s the best way to prepare for a machine learning engineer interview?
Focus on the categories interviewers actually test: data handling and feature engineering, model evaluation and metric selection, production concerns like monitoring and drift detection, and end-to-end system design. Practicing with real datasets and real production-style problems, rather than isolated algorithm puzzles, tends to prepare candidates better for what ML engineer interviews actually ask.