Question 1
Difficulty: medium
Can you walk me through how you would design a basic augmented reality app from concept to launch?
Sample answer
I’d start by clarifying the user goal first, because AR only works well when it solves a real interaction problem. For example, if the app is meant to visualize furniture, I’d confirm the target devices, environment constraints, and the level of realism expected. From there, I’d choose the right AR stack, set up plane detection, anchors, and tracking, and build a simple prototype as early as possible to validate usability. I’d test whether the user can place, move, and interact with objects without confusion. After that, I’d focus on performance tuning, asset optimization, and making sure the experience feels stable across different lighting conditions and device capabilities. Before launch, I’d run device testing, gather feedback from a small group, and refine the interaction flow. My goal is always to make the AR feature feel useful, lightweight, and reliable rather than flashy for its own sake.
Question 2
Difficulty: medium
What steps do you take to keep AR experiences stable and performant across different devices?
Sample answer
Performance is a big part of AR quality, because even a visually impressive app can feel broken if tracking stutters or frame rate drops. I usually start by keeping the scene lightweight and limiting unnecessary real-time calculations. I pay close attention to polygon count, texture size, and the number of active light sources, since those can quickly affect mobile performance. I also try to avoid expensive updates in every frame unless they are truly needed. On the tracking side, I make sure the app handles temporary loss of tracking gracefully instead of behaving unpredictably. I’ll test on both high-end and mid-range devices, because the differences are often significant. If I see lag, I profile the bottlenecks before changing code blindly. I also think about user perception: sometimes a small loading delay or simplified animation is better than a device struggling to render a more complex scene. Stability builds trust in AR.
Question 3
Difficulty: hard
Describe a time when you had to debug a tricky tracking issue in an AR project. How did you approach it?
Sample answer
In one project, users reported that virtual objects were drifting after placement, especially in rooms with uneven lighting. My first step was to reproduce the issue under the same conditions rather than assuming it was a code bug. Once I could trigger it reliably, I checked whether the problem came from poor plane detection, weak feature points, or unstable anchor placement. I also reviewed device logs and compared behavior across a few phones to see whether it was hardware-specific. The issue turned out to be a combination of low-texture surfaces and an interaction flow that let users place objects before tracking had fully stabilized. I fixed it by adding better placement guidance, delaying placement until tracking quality improved, and giving users clear feedback when the environment was not ideal. That experience reinforced for me that AR debugging is part technical analysis and part understanding how the environment affects user behavior.
Question 4
Difficulty: medium
How do you decide between using marker-based AR and markerless AR?
Sample answer
I decide based on the use case, environment, and user expectations. Marker-based AR is a good fit when you need reliable positioning, controlled interactions, or repeatable alignment, such as product packaging experiences, print media activation, or educational content tied to a specific image. It can be easier to manage and more predictable in constrained settings. Markerless AR is better when the experience needs to feel natural in a physical space, like placing furniture, gaming, or spatial visualization. It gives users more freedom, but it also introduces more complexity around tracking, lighting, and surface detection. I usually ask which approach creates the least friction for the user. If the experience depends on exact alignment, I lean marker-based. If the goal is immersion and spatial interaction, markerless is usually stronger. I also consider device support and implementation effort, because the best technical choice still has to fit the project timeline and audience.
Question 5
Difficulty: hard
How would you handle building an AR feature for both iOS and Android without creating two completely separate codebases?
Sample answer
My first preference is to choose a cross-platform strategy that still gives me enough control over AR-specific behavior. I’d look at the core requirements, such as whether the feature depends on native ARKit and ARCore capabilities or whether a shared framework can cover most of the logic. If possible, I’d separate the experience into layers: shared business logic, shared interaction design, and platform-specific AR implementation where needed. That way, I can avoid duplicating everything while still respecting each platform’s strengths. I’d also standardize asset formats, coordinate systems, and interaction patterns early, because those are common sources of cross-platform issues. Testing is especially important here, since AR behavior can differ significantly between devices even when the app code is shared. I’d build a thin abstraction around tracking, anchors, and session management so the app remains maintainable. The key is reducing duplication without forcing both platforms into an identical workflow where they don’t naturally fit.
Question 6
Difficulty: medium
Tell me about a time you had to explain a technical AR limitation to a non-technical stakeholder.
Sample answer
I had to explain why a proposed AR feature could not support unlimited object placement in a small mobile app without affecting quality. The stakeholder expected users to fill a room with many detailed 3D objects in real time, but the device limits made that unrealistic for our target audience. Instead of saying no directly, I explained the tradeoff in terms that mattered to them: if we pushed for too much visual complexity, the app would become slow, unstable, and frustrating for users. I showed a simple comparison between a heavy scene and an optimized one so they could see the difference in frame rate and interaction smoothness. Then I offered an alternative approach that preserved the user value while staying within device limits. That conversation worked because I focused on outcomes rather than technical jargon. In AR, I think communication is just as important as coding, because expectations can easily outrun what the hardware can support.
Question 7
Difficulty: medium
What AR SDKs, frameworks, or tools have you worked with, and how do you choose the right one for a project?
Sample answer
I usually evaluate tools based on the target platform, the complexity of the interaction, and the team’s ability to support the stack long term. For example, if the project is centered on mobile AR, I’d look closely at ARKit and ARCore capabilities first, because they offer solid native support and strong device integration. If I need a broader development workflow, I’d consider a game engine or cross-platform framework that can speed up iteration and asset handling. I also pay attention to features like plane detection, image tracking, occlusion, lighting estimation, and cloud or shared anchors if collaboration is part of the experience. Beyond capabilities, I care about documentation quality, community support, and how mature the debugging tools are. A framework is only useful if the team can ship and maintain the product confidently. My process is to match the tool to the product, not the other way around, because overengineering the stack usually creates more problems later.
Question 8
Difficulty: easy
How do you ensure 3D assets are optimized for use in an AR application?
Sample answer
I optimize AR assets with both visual quality and runtime cost in mind. First I review polygon counts, texture resolution, and material complexity, because high-detail models that look great in desktop tools can be too heavy for mobile AR. I try to use efficient geometry and reduce unnecessary hidden surfaces, especially for objects that will be seen from a few angles in real space. I also look at texture compression and reuse materials where possible, since that helps memory usage and load times. If the experience involves multiple objects, I think about level of detail and whether I can simplify models for smaller screens or slower devices. I also test the asset in context, because a model that seems fine in isolation may look too dense once it is placed in a live camera feed. Good optimization is not just about making the app faster; it also helps the AR object blend naturally into the environment without overwhelming the scene.
Question 9
Difficulty: hard
How would you handle a situation where an AR feature works well in the lab but poorly in real user environments?
Sample answer
That happens a lot in AR, because controlled testing environments rarely reflect real-world conditions. I would first gather as much detail as possible about where the failures happen: lighting levels, room size, surface types, device models, and user behavior. Then I’d try to reproduce those conditions outside the lab. Once I understand the pattern, I’d identify whether the issue is tracking, interaction design, content complexity, or user guidance. Sometimes the problem is technical, but sometimes the app assumes too much about the environment and the user gets no support. I’d likely add clearer instructions, better fallback states, and more resilient tracking logic. If needed, I’d simplify the feature so it works reliably in more situations instead of only looking great in ideal conditions. For AR, shipping something slightly simpler but dependable is usually better than shipping something ambitious that breaks in normal use. Real-world testing is essential, not optional.
Question 10
Difficulty: hard
What would you do if product requirements changed late in development and the AR experience needed a major redesign?
Sample answer
I’d treat it as a scope and architecture problem first, not just a coding problem. I’d quickly review what parts of the current implementation can be reused and what parts are tightly coupled to the old design. In AR, late changes can affect tracking assumptions, asset pipelines, and interaction logic, so I’d want to understand the impact before making promises. Then I’d talk with product and design to clarify the new priority: is the goal speed, visual quality, technical feasibility, or user engagement? Once that is clear, I’d propose a phased approach if the deadline is tight. For example, I might keep the stable core interaction and simplify the visual layer for the first release, then plan enhancements after launch. I’ve found that transparent tradeoff discussions work better than trying to preserve every original idea. A strong AR developer has to adapt quickly while still protecting stability and user experience.
