They ask: "How do you test deep links on both platforms, and what do you actually configure in Xcode's Signing tab?"
Deep links and signing are where React Native engineers get exposed as web developers in disguise — both live entirely in native tooling, and a broken link or a signing mismatch ships a broken release. For deep-link testing you never need to build a special harness: on iOS, xcrun simctl openurl booted "myapp://profile/42" fires the URL at the booted simulator; on Android, adb shell am start -W -a android.intent.action.VIEW -d "myapp://profile/42" com.example.app sends an explicit VIEW intent and -W waits so you see which activity resolved it. In Android Studio, the App Links Assistant validates your intent filters against AndroidManifest.xml and generates the assetlinks.json for verified App Links; Logcat shows the intent resolution when a link routes to the wrong activity. On the iOS side, Xcode's Signing & Capabilities tab is the contract with Apple: bundle identifier, team, provisioning profile, and entitlements (Associated Domains is what makes universal links work at all). Automatic signing lets Xcode manage certificates and profiles — right for development; manual signing pins explicit distribution profiles — what CI and enterprise pipelines use, because "automatic" on a build server means non-deterministic.
Say it: "I test deep links from the terminal — simctl openurl and adb shell am start — because that exercises the same intent/URL resolution production traffic hits, before any UI test does."
Red flag: Saying you test deep links by tapping links in Notes or Messages — that only proves the happy path on one OS state; the CLI commands test cold-start, warm-start, and wrong-activity resolution deterministically.