Is It OK to Look Things Up During a Coding Interview? (2026)

Looking things up during a coding interview is broadly acceptable in 2026 if the lookup is for syntax, standard library signatures, or language documentation, and if the candidate narrates the lookup briefly. Looking up the solution to the problem itself, in any form, is a universal disqualifier and easy to detect on screen share platforms like CoderPad, HackerRank for Work, and CodeSignal. The line interviewers draw is whether the candidate is checking a tool they already know how to use, or outsourcing the actual thinking the interview was designed to measure.

Why the line exists where it does

Interviewers do not penalize forgetfulness about exact API shapes because that is not what they are measuring. They penalize substituting search for problem solving because the entire purpose of a coding interview is to observe how a candidate decomposes an unfamiliar problem, picks a data structure, and reasons about correctness and complexity. The signal collapses if a search engine or AI coding assistant supplies the algorithmic spine.

Real engineering work involves constant documentation lookups. A senior engineer who cannot recall the exact ordering of arguments to reduce is not a worse engineer than one who can; that recall has been replaced by tooling and habit. What the interview tries to preserve is the irreplaceable signal: can this person take an underspecified problem, ask the right clarifying questions, design a workable solution, and write code that actually runs? None of that is helped by Google, and all of it is destroyed by it.

The 2026 wrinkle is that AI assistants have changed which lookups are even possible. A candidate using an invisible AI tool for technical interviews is not technically looking anything up; the assistant is generating reasoning in parallel. Interviewers have responded by probing trade-offs more aggressively, which is covered in how AI interview assistants work. This article focuses on the older, narrower question of whether opening a browser tab during an interview is acceptable.

Variables that change the answer

The acceptability of looking something up depends on four variables: the company, the interview type, the resource being consulted, and how the candidate communicates the lookup. The same Stack Overflow tab can be a non-event or a fail depending on which combination of those four shows up. Treating "Is it OK to look things up" as a single yes-or-no question is why otherwise strong candidates get burned.

Company-by-company posture

Stripe is the outlier on the permissive end. The integration round, which most candidates encounter in the onsite loop, explicitly hands the candidate a private GitHub repo, the public Stripe API docs, and full internet access. Candidates are expected to read documentation, hit endpoints, and copy curl examples directly. The round is closer to a paid one-day contract than a traditional algorithm interview. The full breakdown lives in the Stripe technical interview process guide.

FAANG live coding rounds sit in the middle. Meta, Google, Amazon, Apple, and Netflix all tolerate brief syntax lookups in their live rounds, but interviewers will mentally downgrade the signal if the candidate is clearly searching for the approach. Google in particular is piloting a Gemini-allowed format for select junior US roles in 2026, which has scrambled the older norms; outside that pilot the expectation remains no internet for the algorithm itself. The shifts in question style are covered in how to pass a technical interview at FAANG.

Frontier AI labs and elite trading firms tend to be the strictest. The Anthropic technical interview process, the OpenAI technical interview process, and the Jane Street technical interview process all run rounds where any external resource access is treated as a serious breach. The implicit theory is that the candidate is being measured on raw, unaided technical thinking, not on tool use.

Interview type

Resource being consulted

Not all browser tabs are equal in interviewer eyes. Official language documentation (the Python docs, MDN, the Rust book) is the safest possible lookup; it signals exactly what an interviewer wants to see, which is a candidate verifying a detail rather than guessing. Stack Overflow is fine for a specific syntax question but starts to look suspicious if the candidate is reading an answer thread for a problem that resembles the interview question.

LeetCode discussion forums, NeetCode video walkthroughs, and any GitHub repo containing a curated set of solutions are red flags regardless of context. ChatGPT and Claude in a separate tab are policy-dependent; some companies have written rules now, most do not, and the trend covered in is using AI during a coding interview cheating is that the norms are still being negotiated.

Side-by-side: what passes and what fails

The same physical action (opening a tab, typing a query, reading a page) can pass or fail depending on what was searched. The table below uses real examples from candidate reports on Blind, interviewing.io, and Exponent through early 2026.

Question: does the interviewer literally watch the screen the whole time? Mostly yes on FAANG rounds. The platforms log tab switches, and human interviewers tend to glance over when typing pauses for more than ten seconds. The detection mechanics for the major platforms are covered in does HackerRank detect AI, does CodeSignal detect AI, and CoderPad cheating detection.

Question: what about Karat, the third-party interviewer service? Karat records everything and runs review passes. Their newer rounds explicitly probe for AI use, as covered in Karat invisible AI. The lookup tolerance is similar to FAANG: syntax is fine, solutions are not.

How to phrase a lookup without raising eyebrows

The pattern interviewers want to see is a brief verbal flag, a quick lookup, and a return to the problem with the missing piece supplied. The pattern they react badly to is a long silence followed by a fully formed solution. The script below is what strong candidates actually say, distilled from candidate reports across 2025 and 2026.

# Pseudocode for narrating a syntax lookup during a live coding interview.

def candidate_needs_to_check_something(thing_to_check, interviewer):
    # 1. Flag it before opening anything.
    say(f"Quick check, let me confirm the exact signature for {thing_to_check}, "
        f"one second.")

    # 2. Keep the lookup short and specific.
    open_tab("https://docs.python.org/3/library/itertools.html")
    read_for_at_most(seconds=15)

    # 3. Return verbally before returning to code.
    say("Right, it takes the iterable first and r as the second positional arg. "
        "Back to the problem.")

    # 4. Resume coding immediately. Do not let the silence stretch.
    return resume_solution()

# What NOT to do:
def antipattern(problem, interviewer):
    go_silent(seconds=120)
    open_tab("https://leetcode.com/problems/" + problem.slug)
    paste_solution_into_editor()
    say("Yeah I think I have it.")
    # The interviewer noticed. They always notice.

The first version reads as a working engineer doing what working engineers do. The second reads as a candidate trying to launder a search through silence. Interviewers calibrate fast on which one they are watching.

Edge cases worth knowing

A handful of situations sit outside the clean syntax-versus-solution split and trip up candidates who otherwise have the right instincts. These are worth thinking through before the interview starts so the candidate is not improvising under pressure.

The standard library function that is also the answer

Some problems are essentially "implement this standard library function." If the prompt is to implement a custom sort, and the candidate looks up the Timsort algorithm, that is searching for the solution even though Timsort is documented. The rule of thumb: if reading the doc would hand the candidate the algorithm, treat it like a solution lookup, not a syntax lookup.

The framework-specific question

A round that asks the candidate to debug a React hook or a Django ORM query is implicitly a framework round, and looking up the framework docs is part of the test. The interviewer wants to see how the candidate navigates official documentation under pressure. Failing to open the docs at all on these rounds is sometimes a downgrade, not an upgrade.

The follow-up extension

When the interviewer adds a follow-up like "Now make it work for streaming input," the temptation is to look up streaming algorithms. The lookup is a fail. The follow-up is specifically designed to test on-the-fly reasoning, and any external help defeats the purpose. The deeper reasoning probes that 2026 interviewers add are part of why coding interviews are getting harder at the senior end.

The take-home with a video review

Take-homes increasingly come with a 30-minute follow-up where the candidate walks through their code. Anything looked up during the take-home needs to be something the candidate can defend live. Pasting a Stack Overflow snippet that the candidate cannot explain is a worse signal than writing slightly worse code from first principles.

The proctored remote assessment

Proctored platforms (some HireVue formats, certain CodeSignal certified assessments) block tab switching at the OS level or flag it as suspicious. The lookup question is moot because the lookup is technically impossible. Detection details are in HireVue AI detection.

Recommended action by interview type

For most candidates in 2026, the working playbook is: assume syntax lookups are fine, narrate them briefly, and never search for the approach. The table below collapses that into per-interview recommendations.

Companies in adjacent categories (Coinbase, Databricks, Snowflake, Figma, Pinterest, Notion, Linear, Cloudflare, Shopify, Palantir, Airbnb) tend to align with FAANG norms in their live coding rounds. The specific shapes are covered in the Coinbase technical interview process, Databricks technical interview process, Snowflake technical interview process, Figma technical interview process, Pinterest technical interview process, Notion technical interview process, Linear technical interview process, Cloudflare technical interview process, Shopify technical interview process, Palantir technical interview process, and Airbnb technical interview process guides.

Common Mistakes

Even candidates who understand the syntax-versus-solution rule manage to torpedo themselves in predictable ways. The patterns below show up repeatedly in 2026 candidate debriefs.

• Lookups without narration. A silent tab switch followed by a working line of code reads as suspicious even when it was a legitimate syntax check. The cost of saying one sentence before looking is zero; the cost of not saying it can be the round.
• Looking up things the candidate should know cold. Searching for how to write a for loop in Python, or how to declare a HashMap in Java, is a downgrade signal regardless of accuracy. Core language fluency is table stakes; lookups are for the long tail of standard library APIs.
• Pretending the lookup did not happen. When the interviewer can see the screen share, denial reads worse than the original lookup would have. Saying "I had to double check itertools" after the fact is recoverable; pretending the tab never opened is not.
• Browser tab titles that leak the problem. A tab titled "Two Sum - LeetCode" sitting in the screen share next to the active editor is the most common self-inflicted disqualifier reported in 2025-2026 debriefs. Close all such tabs before screen sharing starts.
• Searching the exact problem phrasing. Interviewers often use slightly nonstandard wordings precisely so that a verbatim search will leave traces. A candidate who types the phrase into Google is creating their own evidence.
• Looking up the approach for follow-up extensions. The follow-up is the test. The original problem was the warm-up. Outsourcing the follow-up wastes the only round that produces high-confidence signal.

FAQ-style mini Q&A inline

Question: if a take-home explicitly allows AI, should the candidate use it? Probably yes, but the candidate needs to be able to defend every architectural decision in the follow-up review. Code that the candidate cannot explain produces a worse signal than simpler code that they own end to end.

Question: does asking the interviewer "can I look this up" count against the candidate? No. Almost every interviewer welcomes the explicit ask; it shows the candidate understands the norms and respects the format. The downgrade comes from doing it without asking, not from asking.

Question: what if the candidate is using an invisible AI tool and the interviewer asks point-blank whether the candidate is using AI? This article does not take a prescriptive position on AI assistant use; the is using AI during coding interview cheating and how to use AI coding interview without getting caught articles cover that question directly. The narrower lookup question is independent: searching the open web during the round still follows the rules above regardless of any other tooling in play.

Question: are video-based screens (Zoom, Google Meet) any different from coding platforms? The detection surface is different but the norms are the same. Detection specifics live in Google Meet vs Zoom detect AI and is ChatGPT in Zoom interview detectable.

Question: how should new grads handle this? More leniently. Recruiters expect new grads to have shakier API recall, and brief documentation checks are well tolerated. The broader new-grad picture is in the new grad software engineer interview guide.

Question: what about machine learning interviews specifically? ML coding rounds often involve more library lookups (NumPy axes, PyTorch tensor shapes, scikit-learn API), and the tolerance is correspondingly higher. The machine learning engineer interview guide goes into the per-company specifics.

What the interviewer is actually scoring

It helps to remember why this rule exists at all. The interviewer is filling out a rubric with a handful of axes: problem solving, technical competence, code quality, and communication. None of those rubric axes reward perfect API recall. All of them reward clear narration, sound judgment, and visible reasoning. A 30-second documentation check that produces a correct line of code costs the candidate almost nothing on any rubric axis. A two-minute silent search that produces a working solution costs the candidate everything on the problem-solving axis, which is usually the highest-weighted item on the form.

The other framing that helps is to treat the interview as a paired programming session with someone who has not yet decided to hire the candidate. Real paired programming involves constant lookups, narrated decisions, and back-and-forth on trade-offs. The candidate who behaves that way reads as someone who would be productive on the team. The candidate who treats the interview as a closed-book exam and either over-fakes recall or silently outsources the thinking reads as someone the interviewer cannot calibrate. Calibration uncertainty is a no-hire signal at most FAANGs, even when the code on screen looks fine.

Bottom line

In 2026, the candidate who briefly looks up heapq argument order, says so out loud, and gets back to the problem is doing exactly what the interviewer wants. The candidate who silently searches for the algorithm and pastes a half-understood solution is failing the round even if the code compiles. The rule has not changed in a decade; what has changed is that the platforms make detection nearly automatic, and the reasons qualified candidates fail technical interviews increasingly trace back to misjudging this line. Narrate, lookup syntax not solutions, and close the LeetCode tabs before screen share starts.