Many hiring managers like to use a pair-programming exercise to assess a candidate’s skills. In theory, these exercises provide a more realistic testing environment than whiteboard exams, brainteasers, or technical interviews. In these pairing exams, the test taker and evaluator typically work together in pairs on a coding problem. Even if you have considerable pair-programming experience, you stand a better chance of passing the test if you follow a few best practices. Here’s some advice from two veteran evaluators that can help you nail your next exam:

Ask About the Test Structure and Setup

Since the purpose of the test is to create a comfortable and familiar atmosphere so tech pros can focus on coding, you may be able to tailor the setup and testing environment to match your comfort level and preferences. According to software engineer Ed Ruder, applicants at Square Inc., a financial-tech company, are allowed to select their testing language and code editor. And many companies will let you choose between Windows, Linux and Mac machines. Applicants should ask how long the test should last (if you’re not provided with that information beforehand). Agile developer Will Read said that, at Pivotal Labs, applicants work on real projects, alternating between driver and navigator, for about six hours during their onsite interviews. Over at Square, meanwhile, candidates need to move quickly, because they only have about an hour to create working code that will impress an interviewer. Though you’ll probably be able to look up syntax, documentation and APIs during the test, it’s a good idea to ask permission first. In addition, make sure to query about preferred testing methodology. If there’s time, set up your test first so you can run, test and debug the code to make sure everything works as it should. “It may not be necessary to test the code given the time constraints, or you may need to use ad hoc testing,” Ruder said. “But if you can set up a test up quickly, it’s always a good idea to test as you go.”

Focus on Solving the Problem

The interviewer is primarily looking for two things: 1) your ability to solve the problem, and 2) your ability to collaborate, communicate and work with a partner in a pairing environment. Always walk your partner through your decision-making process and likely approach before you tackle a problem. If you know a novel way to solve a problem, suggest it. But keep in mind that results trump flash in a testing situation, so it’s in your best interest to stick with the straightforward, slam-dunk solution. “Most interviewers will either agree with your approach or let you know if you’re going down the wrong path,” Ruder said. “Use your partner as a sounding board and pay attention to their cues.” Break down bigger problems into small, manageable chunks so you can test and change your code (if necessary) as you go. Don’t waste time creating documentation unless it helps you solve the problem, but feel free to outline your solution first or make comments as you code. Think about edge cases. Search for edge-case bugs by running your code against a variety of inputs. Explain any shortcuts you took due to time constraints, along with what you would normally do under similar circumstances. “For example, if you would normally consult the PM or a teammate before moving forward, suggest it,” Read said. “The key is to relax and act like you would on a typical workday.” Last but certainly not least, remember to build rapport with your partner during the exercise to demonstrate empathy and mastery of pair-programming concepts and mechanics. Interact and bounce ideas off of them. “If you’re working on real problems, the interviewer may not know the answer either,” Read noted. “If you work through it together, you are more likely to come up with the best solution.”