I’m putting together a series on common questions candidates face in technical screens. My hope is to give folks a leg up on how they can prepare, and secondarily any screeners better understand what they’re asking and how to improve for a better signal.
No question (or answer) is perfect, but that shouldn’t stop us from exploring them. Feedback and constructive criticism are definitely welcome.
I wanted to kick off this series of blog posts with a bit of a modern classic for good reason, as you may see it frequently pop up and it’s a good context setting question for others to build off of. For those unfamiliar, the premise is simple:
“You sit down at a computer and open up your favorite browser, typing ‘google.com’ into the url bar. What happens?”
Being popular and intentionally with a narrow scope means you’ll see this question or variations of it often in the interview process. You may even give it as a question every now and then. Given that, it’s important to look under the hood a bit to get a better understanding from both sides of the interviewing table.
What are interviewers getting from the Question
The question itself has taken on a certain mythos, being used so widely, that many interviewers approach it as a question that is near “required” to ask. Of course, not every interview panel will, but it’s commonplace enough that folks feel like everyone else is also asking the question. As part of that, interviewers can feel some connection to standardization by offering it (even if there’s plenty of deviation in it).
It’s also sad to say a lot of interviewers can be lazy when it comes to interviewing, despite its importance. You’re hiring someone to work with you at your company but it can be hard to justify the context switching when in the moment, developing questions and collaborating with the rest of the panel on answers. Having this in your back pocket is an easy card to play, one that doesn’t require much thought to ask and, given that it is well known, affords an interviewer not to justify why they would ask it. It can feel like a constant – it’s supposed to be there. Ask the question, let the interviewee walk around some answers, and chew up time in the interview before getting back to work (interviewing is part of the job).
This all may be a bit cynical, so let’s switch gears for a moment. A question with as much openness to answers such as this can lend itself to exploration, which can in fact be a welcome surprise to an interested interviewer. A lot of what we do during the entire hiring process is look for people like the ones we already have. You can imagine how much systemic bias and homogeneity goes into that. When we come across ideas and knowledge entirely new to us, that’s the kind of “add” that grows a team. We don’t need to clone existing engineers – we need to find people who will bring something the team is missing or filling in gaps.
A good interviewer will do more with this question than let a candidate speak until they’re done and move on. They’re looking to see how far across the map you go and how deep on any given topic you can stretch. Those edges aren’t a means of “stumping” a candidate (which, unfortunately, too many panels treat their interviews as) but to apply this mapping of knowledge to services and technology that exist along with what they’re looking to build (or even be inspired by new approaches to solve problems). Good interviewers should come in with an understanding of said gaps and looking for answers that fill them in. Great interviewers will adapt during the interview itself to see the blindspots they miss and how a candidate is pointing them out. They can tailor questions as they go, honing in on gaining a signal to the candidate’s strengths.
So many interviewing questions are inherently broken because of their approach in searching for answers. Think about whiteboard interviews, for example. They’re regularly about writing code in an environment we’re not used to, without the tools to help us, under pressure that doesn’t exist in the same context. Here instead, a core conceit to this question is being able to explain a deep question and to see how a candidate approaches it within the trade off of being succinct vs. being thorough. You may have to share context to new hires, mentor folks across teams, or explain to non-technical folks how a service works. We’re looking at this question as a means of communicating ideas – underrated and very hard to get a strong signal on. You can’t directly ask someone if they’re a strong communicator (everyone will say yes, naturally). Instead, you have to allow them to communicate an idea, to see how well it meets your expectations for the role. “Typing google.com into a browser” is a means by which you can explain technical knowledge across a wide spectrum, a demonstration of strength in communication.
Strengths of the Question
- Breadth & Depth: The allowance to explore means a candidate can jump in to where they’re comfortable and to build confidence that they’re knowledgeable of one or many subjects.
- Anchoring to strengths: Interviewers can gain an understanding of where the person immediately gravitates towards, which is indicative of both their thinking and where their core understanding of tech lies. Having worked in or studied any part of a web request, a candidate should be able to focus on something they’re strong with. They can describe the language and how to build a webpage, the networking, infrastructure, distributed systems, security – the list is near endless.
- Flexible towards many roles: The question can be guided to areas that meet the needs of the role, which means an allowance for finding many small areas within that scope rather than asking an extremely pointed question without an understanding of surrounding knowledge.
- Easy to ask: We’re typically harsh on interviewers, but some folks are solid engineers but poor interviewers (or get nervous themselves). Having a back pocket question doesn’t have to be bad if conversational skills are tough.
- Customization: Pretty much every technical team can do something with this question with a level of success, depending upon how it’s approached.
- Open-ended answers: This isn’t a binary yes or no question, where yeses give little insight and noes can feel like a disqualification. Interviewers will get more signal out of a question that doesn’t have one right answer and candidates can shore up weaknesses in their response by working towards what the interviewer is looking for.
- Communication: This requires repetition because it’s so fundamental. Most of what we do as software engineers is communicate ideas. Questions in the interview process should lend themselves to demonstrating that skill.
Weaknesses of the Question
- Where to start: Being so broad, a candidate could begin in an area way off the mark from what the interviewer is looking for. You could explain in depth the functions of keyboard input which, while critical and demonstrating skill, is not knowledge needed for the role.
- Power tripping: Some interviewers are malicious, taking pride in tripping up candidates and putting them “off balance”. It’s easy to find esoteric questions and eventually find something they’re don’t know, to make a candidate feel small.
- Lack of grounding: Broadness means you don’t know if you’re answering the question the interviewer wants, especially for a non-communicative interviewer. You can ramble for 10 minutes without getting cues to look elsewhere.
- Feeling overwhelmed: This lack of grounding also can be uneasy for some folks uncomfortable without structure. “Tell me everything you know about a topic” can put folks in a bad footing. For example, some neurodivergent folks may be able to answer specific questions within this scope (“Explain how to scale the number of requests”) but get lost in the lack of bounds on what to answer.
- Laziness: The flip side to having a question you can ask without preparation is that interviewers will do less prep work, as much as that sounds like a tautology. With a simple question to remember, they may gloss over resumes or not be willing to dig into a candidate’s body of work to surface their strengths, relying on the question to do the heavy lifting.
- Bias: This can allow bias to creep in very easily with a question that allows so much flexibility in the interview. You can ask three people the same question and steer them in the direction you’d like while claiming fairness in having asked the same premise.
Ways to Improve the Question
Interviewers should come in knowing the background of the candidate from projects and resumes submitted to the hiring team. If they have several roles as a security engineer on their resume, having grown a company from 10 to 100 engineers, then a focus should be given to what challenges are faced when accessing a website as it grows presents to a team. In another scenario, if they were a frontend engineer having ported a large codebase over, you can ask about the challenges of presenting that frontend code in a browser while progressively transitioning. This is all to say that the breadth of the question does not mean the interviewer is free from focusing on areas of the candidate’s expertise. If they begin to flail (as even strong software engineers will) work back to areas of expertise to restore confident and branch to other paths that may uncover strengths.
When a candidate is showing signs of a deep level of knowledge in an area, you can do one of two things: dig deeper or move to an adjacent area. Digging deeper allows a candidate to feel empowered to showcase just how strong they are in an area or potentially hit a boundary in knowledge. You may know how DNS generally works, but TLS may be a bit more of a black box. This is ok, as it can allow you to ask how to reason through the unknown based on prior knowledge and experience (something software engineers do all the time), but be wary of pushing too deep for the sake of a “gotcha” question. Moving to an adjacent area means you’re getting info about more than one topic, potentially at a point where you know “enough” for the candidate to succeed in a role. Interviews being constrained by time, you’re likely going to need to jump around a bit. Encouraging the candidate by acknowledging said depth before moving on can help the transition much less jarring.
Lastly, it should be a focus on what your team needs. Knowing what a fleet of caches can do for response time can be core to some teams and useless for others. As the answers from this question can go in so many directions, the interviewer should know what gaps in their team make up they’re looking to fill and adapt to an awareness of new holes that are uncovered as a candidate shares their experience.
How to Approach as a Candidate
For companies where you can find out information about the hiring team, tailor the answers as much as you can to current and future projects the team publicly acknowledges. This may be trickier for smaller companies that aren’t sharing the roadmap publicly or are still in stealth, in which case asking the recruiter ahead of time can be helpful. Are they building a service for connecting external APIs? Think about how the request for a website brings forth that data, considering timeouts on requests and potential data processing required. Exploring that in depth will connect the interviewer in the moment to how you’ll work on day to day projects, giving encouraging feedback that you’re able to meet the needs of the org.
If your interviewer is jumping around to catch you off guard, know that the breadth of the question is intentional to see your areas of strengths and weaknesses. This can be particularly challenging, as you don’t want to change the subject back to your expertise (and thereby ignoring the question) but looking for adjacent areas of skill you possess can be useful. As a frontend engineer, you may not be strong in understanding First Meaningful Paint (FMP) but you do understand the challenges of trade offs between a page with lots of data vs. having the browser client waiting for all content before loading. Interviews can and should be a place of learning for you!
If they continually push for deeper answers in one particular area, know that they’re looking for said boundary to your knowledge. Everyone has blindspots, but learning how to reason about them can be critical for your work. As best you can, tie into previous experience or foundational knowledge you have. “Well, I don’t know DNS particularly well, but I can imagine trying to sync up all of the computers in the world would be challenging. There would have to be some levels of caching to avoid overloading requests from a single source, but that also means delays when records change. I can’t remember the differences between records, but I know that they have different use cases, which means that there’s more to a DNS record than a simple pointer.”
Unsure about where to go? Lacking any other information, answers in interviews should focus on 1) your strengths and 2) where you want to work. Don’t explain obscure database esoterica if you’re wanting to work in Machine Learning. It’s fine to demonstrate working knowledge, but remember your goal is to do more than just wow the panel, instead to install confidence that you can do the day to day. What answers are you giving that leads them to that conclusion?
My Feelings on the Question
I’m generally positive on asking this, while acknowledging its flaws and that some folks have strong feelings against. I like open ended questions because I do well as both candidate and interviewer with them – I like to talk! If I’m noticing as interviewer that the candidate is struggling, I want to alternate between areas they find confidence speaking about. I like that candidates have options, being able to talk about what they feel is of interest to them. I like the fluidity of an interviewer being wowed as the interviewer can’t possibly know everything about this either. If folks succeed more in more narrowly structured questions, then it’s up to the interviewer to bring that out in the interview.
I also don’t think this can or should be the only tech question in a panel. I can spend forever on the question if allowed, but I prefer in a 45 minute to hour long session that it takes up anywhere from 15 to 30 minutes, enough time to explore without feeling like it drags out. It should definitely not be the early screening phase (a recruiter or hiring manager giving a video call or phone screen with this, for example) as it’s better suited when a candidate showcases more than can they do the basics.
Candidates can still flop here. There’s no perfect system to guard against that. My hope with this question is that with any level of experience there’s something you can discuss. Variations on this might be to build a system with similar unrestricted bounds on how to accomplish a goal may be better suited for individual teams (such as “Build me a service that does X”). The question can be tailored for all skill levels, for many positions in a tech org, all while still producing meaningful results in the efficacy of a person as a potential hire.
Additional Resources
What happens when… (Alex Gaynor), an overview of technical approaches to this question.