Technical Interviewing Portal

Interview format

Hands-on Coding

Overview

At Perplexity, we use hands-on coding rounds to evaluate candidates’ ability to solve problems through sound abstractions and precise, working code.

Logistics

Hands-on coding rounds are typically conducted as live interviews with either one or two interviewers. Most rounds are scheduled for between 30 and 60 minutes, with around 5-10 minutes reserved for introductions and wrap-up, and the remainder of the time allocated for the technical exercise itself.

Most of our hands-on coding rounds are conducted in a shared CoderPad session which allows you to write, run, and debug code in a lightweight IDE-like environment.

Note that we administer hands-on coding rounds in both in-person and virtual formats, depending on the role and geography.

Question format

We aspire for our interview process to be a window into the work we do here. Most of our hands-on coding exercises focus on building practical components and abstractions for the types of systems that power Perplexity.

Each exercise is self-contained and structured in multiple parts:

It’s common to reach the end of the interview time without having finished all parts of the exercise. Your interviewer is trained to pace the exercise such that you can effectively demonstrate your technical abilities.

Content & topics covered

Our hands-on coding exercises are designed for strong candidates to succeed without extensive preparation. We expect knowledge of programming fundamentals in your chosen language, along with taste in abstractions and code quality.

For experienced candidates, we also expect a strong command of engineering principles relevant to your recent work. For instance, a candidate whose current role focuses on infrastructure would be expected to be proficient in networking and concurrency, among other topics.

We don’t use question banks from LeetCode, HackerRank, or similar platforms. Our exercises are authored in-house by our Members of Technical Staff to reflect the types of problems we solve at Perplexity.

We also disfavor testing your knowledge of obscure data structures and algorithms. We’re proud to have numerous IOI and ICPC medalists among our team members, but we believe that success at Perplexity requires much more than an encyclopedic knowledge of competitive programming recipes. Although many of our exercises involve data structures and algorithmic concepts, those concepts will typically be ones involved in real-world technical work.

Examples of expected knowledge:
  • Data container types such as arrays, strings, dictionaries, sets, and priority queues.
  • Techniques for representing common types of relationships.
  • Common algorithms such as sorting, searching, and iterating over sets and graphs.
  • Classes, methods, and object-oriented design principles.
Examples of knowledge that is not expected:
  • Dynamic programming recipes (e.g., longest common subsequence, edit distance, football score counting).
  • Esoteric data structures (e.g., Fibonacci heaps, binary-indexed trees, suffix trees).
  • Advanced graph algorithms (e.g., Dijkstra’s algorithm, minimum spanning trees, maximum flow).
A note on specialized roles

Note that certain specialized roles may have hands-on coding rounds that focus on a specific domain (e.g., model training, inference, frontend engineering, etc.). To the greatest extent possible, these questions follow the spirit of this guidance; however, the precise details and format may differ from our general hands-on coding rounds.

To be clear, our hands-on coding exercises are challenging. However, we’ve designed them to be challenging in the dimensions that matter (such as problem solving and analysis, abstraction design, and execution ability) rather than the dimensions that don’t (such as rote memorization of LeetCode recipes).

Example problems

Below are some example problems that illustrate the format and style of our hands-on coding exercises. We’re offering them to help illustrate what you might encounter in a hands-on coding round (however, you should not overindex on these precise questions or the topics covered).

If you’d like to try these exercises out in a real CoderPad environment, feel free to request a practice session link from your recruiter.

Outside assistance & interview integrity

We expect candidates to complete our hands-on coding exercises independently. We do not allow the use of AI or other outside assistance (such as the internet or other humans) during hands-on coding interviews.

There are two exceptions to this rule:

Exception 1: you may refer to online language documentation.

Exception 2: you may use Perplexity, a search engine, or another AI tool to ask questions about your language’s libraries (including to see example usage). However, you should not ask the tool to produce any significant part of your answer. If needed, your interviewer can provide further guidance about what is and is not permissible

Breaching this policy is treated as an integrity violation, with the consequent pre-employment, post-employment, and/or legal ramifications described in our note on interview integrity.

We understand that you’re very likely using AI coding agents for most or all of your coding work. This is true of our Members of Technical Staff as well. We rigorously calibrate our exercises to ensure that strong candidates can succeed independently on our hands-on coding interviews.

Evaluation criteria

The primary signal we’re interested in is your ability to produce high-quality work that precisely and correctly addresses the given requirements. Below are some more specific dimensions that feed into our evaluation.

We highly value a methodical approach to problem solving and debugging. It’s often tempting to jump right into the problem without a particular direction in mind, then fix bugs in an ad-hoc manner. We’d like to see you plan and sequence your work effectively, and address issues in a systematic manner.

We’re also interested in your technical judgment. We want to see that you can design sound abstractions and write clean, maintainable code. In addition, we’re interested in your ability to reason about tradeoffs (there’s rarely a single, obviously optimal solution to our technical exercises).

Finally, we want to see you execute precisely, efficiently, and correctly toward a solution. Many candidates can describe a potential solution in vague, handwavy terms. Our work requires us to execute on our ideas with precision and speed, and we’d like to see you do the same.

Note that solving all parts of a problem is not required for a positive evaluation. You should make as much progress as you can, but not at the cost of becoming sloppy or careless.

How we calibrate hands-on coding interviews:

To ensure fairness and consistency, we calibrate each exercise by having Perplexity’s own team members attempt the exercise under interview conditions. We use the results of these calibration sessions to ensure that the exercise is productively challenging and define expectations for what strong performance looks like.

Our calibration panel includes a mix of Members of Technical Staff across teams, technical managers (up to and including our cofounders), and even certain nontechnical personnel. No members of our calibration panel still code by hand in their day jobs, and we ask them not to practice hands-on coding before the calibration session. This ensures that our exercises are appropriate for strong candidates from a variety of backgrounds, and that strong candidates can succeed without dedicated practice.

Tips

Read carefully. Building performant and delightful AI products requires exceptional attention to detail. Therefore, our exercises often require you to internalize significant amounts of context (both written and code) before you can begin to design a solution. Carefully reading and understanding all relevant context is highly correlated with success.

Don’t get bogged down in the weeds. When writing production systems, there are often a dozen or more considerations to juggle at once. For hands-on coding exercises, your focus should be on the essence of the problem. For instance, don’t spend time on thread-safety unless the problem’s specific focus is on concurrency. Avoid the temptation to build wishlist features that have nothing to do with the exercise part you’re working on (even if you think they’d be useful).

Remember your interviewer’s perspective. Your interviewer is there because they want to welcome new team members to Perplexity. They’re rooting for you to succeed, and they want to award as much credit as possible for your work. Clean code and clear communication make it easier for your interviewer to help convey your abilities at their best.

Language choices

We offer a number of programming languages for candidates to choose from. You and your recruiter will confirm your preferred language prior to the interview.

In most instances, the available languages include:

Note that certain domain-specific practical assessments may only be offered in a single language.

We strongly recommend Python for almost all candidates. We hear overwhelmingly consistent feedback from candidates that Python is the most expressive and productive language for hands-on coding rounds, and we often hear regrets from unsuccessful candidates who chose a different language that ended up being much harder to work in.

If you strongly prefer a different supported language, you’re welcome to indicate that choice to your recruiter. However, we recommend doing so only if you have an exceptional command of that language.

A cautionary note on Java:

We strongly discourage Java for almost all candidates. Our interviews focus on problem solving and abstraction design, while Java often forces candidates to spend time on boilerplate and working around various clunky aspects of the language. Our data indicates that candidates who choose Java are much less likely to succeed on hands-on coding rounds. We offer Java because we believe in candidate choice, but we urge you to avoid using Java unless you’re exceptionally proficient in it.