How & Why to Ask Clarifying Questions at a Whiteboard Interview (for Junior Devs)

7 min readApr 22, 2018

Many junior devs are told to ask clarifying questions during the data structure/algorithm (or “whiteboarding”) part of technical interviews, but a quick web search didn’t bring up any resources on

how to ask clarifying questions?
why they are so important to ask?

This post will attempt to answer both of these questions.

Why Junior Devs Should Ask Clarifying Questions During an Interview

To understand what the interviewer wants to see from your answer (e.g., what limits are in place for you while you answer the question?)
To give the interviewer a chance to help you or give you hints (especially if you’re going down a path that is incorrect or not what the interviewer is interested in today)
To show that you know planning before coding makes you a better dev
To give yourself time to organize your thoughts and clear your head
To show off your communication skills
To show off an area of knowledge or expertise (e.g., space and time considerations using Big-O notation, Unicode expertise, etc.)

How to Ask Clarifying Questions When Whiteboarding

As a junior dev in a whiteboarding technical interview, you are being asked to show that you have a good foundation in computer science concepts. Those concepts fall under three broad categories: algorithms (especially sorting algorithms), data structures (including space and time considerations), and systems architecture design.

In this post, I’ll be covering how to ask questions about sorting algorithms and data structures.

For data structures, I’ve divided the questions into two broad categories:

Questions about the input/output of the function (the function signature)
Questions about allowable/preferred solving methods (used in the body of the function)

Third, I’ll cover special considerations for sorting algorithms.

Your First Clarifications: Input & Output

So, you’re in the whiteboarding room and the interviewer has just asked you the first question they want you to solve. What’s the first thing you do?

I re-state the question in my own words back to the interviewer. This gives them a chance to correct me if I misheard the question and also gives me time to start thinking about the question in its most basic terms.

For example, if the question involves scalene triangles, I would clarify what was meant by scalene even if I was 99% sure I remembered the definition correctly. This gives the interviewer a chance to correct me before I write an entire function based on a misunderstood basic (in the sense of that the function would be based on this idea) mathematical concept.

Next, I clarify the input and output of the function I’m going to write for the interviewer. Often I’ll literally write this out on the top of the board. For example, if I was asked to write a function that returns whether a word has any duplicate letters, I would write out String -> Bool while saying, “So my input will be a string and I want to return a Bool.” This gives the interviewer a chance to confirm. Now you have a building block to start writing your function signature.

This may sound simple, but imagine a more complex problem where you’re working with arrays of dictionaries as input, or need to return a tuple, set, or string. It would be important to clarify if, for example, you could return a string as an array of characters: [“a”, “ “, “s”, “t”, “r”, “i”, “n”, “g”] or as a string literal with standard sentence capitalization and punctuation: “A string.”

These steps allow you to show the interviewer that given a more complex problem on the job, you would take the time to make sure you understood it before you started coding (thus saving time and money in the long run) and that you would know what questions to ask a coworker in order to perform your task.

A Note About Special Cases

Most clarifying questions have to do with special cases of the type of input or output of your function. Questions about special cases (also called edge, corner, and boundary cases in computer science) could take up almost all of your interview. Don’t believe me? Look at this page of special cases having to do with time shown as a list of falsehoods programmers believe about what seems like a “simple” concept.

So, complex interview questions may require more clarifying questions than something simpler like FizzBuzz. Most likely you don’t need to be afraid of asking too many questions as my understanding is that most juniors actually don’t ask enough.

If you’re hired as a junior dev much of your day will be spent asking questions of yourself, of the Internet, and then of your peers, so showing that you know how to phrase questions and ask them politely is a good skill to demonstrate in your interview.

A Note About Trees & Graphs

I don’t understand enough about them to write comfortably about trees and graphs, though they are important data structures to know and you will likely be asked about them on some interview, possibly even for junior dev roles. Every interviewee goes into their interview with some gaps in their knowledge, and trees and graphs are my gap.

If you are knowledgeable about trees & graphs and can write about common clarifying questions to ask about them, please do and let me know! I’d love to link to your work.

Data Structure Clarifying Questions

Input & Output Validation Questions (Function Signature)

With these data structure clarifying questions we are trying to validate either the input for the function we are to write or the output (think: return type). For each element in the outline below, you will probably want to ask:

Is this element present in my input?
If so, how do I deal with it? (i.e., preserve, eliminate, or modify)
Does this element need to be present in my output?

Primitive Types

Numbers

Zero (0)
NULL or nil
Negative Numbers
Floats or Doubles (clarifies if Ints only?)
Min/Max Int

Strings

Empty string
NULL or nil (and Optionals, depending on language)
Spaces (multiple words or sentences, or single/multiple whitespaces alone)
Punctuation
Upper, lowercase, or mixed (e.g., “stRiNg”)
Strings of numbers (e.g., “12”) Should these be changed to Int, Float, or Double?
Different Languages (Diacritics? Unicode compliant? ASCII?)
Emoji 👍 (especially if question is presented as a text field input by a user)
Long String

Data Structure (Collection) Types

Tuples

Named elements

Arrays

Empty array
Nested or not nested

Dictionaries (Hashmaps)

Collisions

Linked Lists (Stacks, Queues, Deques)

Circular
Loops (present or not?)
Doubly-Linked List

Legitimate Methodology Questions (Function Body)

The following questions are you asking the interviewer if certain methods are allowed in the function body you are going to write.

Built-in functions of language allowed (e.g., .reverse)
Higher order functions allowed (e.g., map, filter, reduce)
Recursion: Usually in an interview you begin with an iterative/brute-force approach and then optimize it, but if you’re comfortable with recursion and think it’s called for, go ahead and ask if the interviewer wants a recursive solution

Sorting Algorithm Clarifying Questions

When doing a sorting algorithm, all of the above questions for data structures apply (depending on the type of input you have and the output desired). However, there are special considerations when doing a sorting algorithm:

Is the input already sorted?
Is the input reverse sorted?
Is the input only one element? If so, is that considered “sorted” (if returning a bool)?
Is the input such that all the of elements are of equal value?
Is an “empty” version of the input (NULL, nil, or whitespace) considered sorted or not (especially important if you’re returning a bool)?
Is the input of different types (e.g., numbers and strings) that would be difficult to sort against each other? If so and you’re only sorting one of the types, should the other types be eliminated or saved? If saved, how should they be placed (before or after the sorted type) and should the other types be sorted against themselves?
If you plan on doing a split when doing the sorting algorithm (a common technique) is the input even or odd?

Conclusion

Hopefully you now feel comfortable about the first few minutes of your technical interview and have a better idea of the type of clarifying questions to ask. To conclude, here is a possible script for an interview:

Interviewer: Write a function that can determine whether or not a string contains all unique characters.

You: OK, so I’m taking a string as input and returning a bool (write: “String -> Bool” on board).

I: That’s correct.

Y: Is it possible to receive an empty string, nil or NULL, or just whitespaces as input?

I: Yes.

Y: (Writes “Optional” in front of the input/output so it now reads “Optional String -> Bool”) How would you like me to handle those cases?

I: How do you think they should be handled and why?

Y: I would return False for an empty string and nil or NULL, and True if there’s just one whitespace or only multiple whitespaces.

I: That’s fine.

Y: And will punctuation be present? For example, if there are two apostrophes or ampersands present in the input, should I return False?

I: No, you may ignore punctuation for this problem.

Y: Would input containing an uppercase “A” and a lowercase “a” count as a duplicate in this case?

I: No.

Y: And lastly, should I worry about diacritical marks and/or language input that’s other than English?