skip to content

Orientation & Screen Sizes

15 roadmaps3 questions

Layout as a test target: rotation mid-flow and what must survive it, small and large form factors, split-screen and multi-window, display scaling and large text, and assertions that survive reflow.

on this pageshow

explore

questions

3

A sign-up form is half filled in when the device is rotated mid-flow. What must the case assert after rotation?

level: middleimportance: must knowfreq 58%

answer

  1. A rebuild, not a repaint
  2. Rotate in the middle of the flow
  3. Unsaved input, selection, scroll, open dialog
  4. Old element handles may be stale
  5. Rotate back and assert again

basics

~20 s

Assert the in-progress input survives: values already typed, the selection, the scroll region, any open dialog, and the step of the flow. Rotation rebuilds the screen, so a case that only checks it still renders proves nothing.

solid answer

~50 s

Rotation is not a repaint. On handheld platforms a change of orientation usually tears the screen down and builds a new one for the new geometry, so anything the app held only in that screen disappears unless it was deliberately preserved. The case must therefore rotate **in the middle** of the flow — not before it starts, not after it ends — and then assert on the product state a user expects to keep: text already entered, the chosen option, the scroll region, the current step, and any dialog that was open. Find every element again rather than reusing handles captured before the rotation, because the rebuilt screen may hand back new instances or a different arrangement. Finally rotate back and assert a second time; a defect that survives one turn often appears on the return trip.

code

pseudocode · 22 lines
pseudocode
open screen "signup"
type into field "email" the value "[email protected]"
type into field "displayName" the value "Ada"
select option "monthly" in group "plan"
scroll list "plans" to item 7
open dialog "planHelp"

rotate device to landscape
wait until screen "signup" reports ready

# handles taken before the rotation may point at a screen that is gone
assert value of field "email" == "[email protected]"
assert value of field "displayName" == "Ada"
assert selected option in group "plan" == "monthly"
assert visible range of list "plans" contains item 7
assert dialog "planHelp" is open
assert calls_received_by(profile_service) == 1

rotate device to portrait
wait until screen "signup" reports ready
assert value of field "email" == "[email protected]"
assert calls_received_by(profile_service) == 1

go deeper

for a junior

Be ready to say what rotation does to a screen: it usually rebuilds it rather than repainting it, so anything held only in memory is lost unless the app saved it. Name the things a user expects to keep — typed text, the chosen option, where they were in the flow.

for a middle

Explain the mechanics. Say where in the flow the rotation belongs and why, why element handles taken beforehand can go stale, and why the assertions are about values, selection and step rather than about positions on the screen.

for a senior

Show production judgment: which flows earn the rotation axis at all, how you keep the case stable without leaning on fixed pauses, and how you read a failure that only appears on the return trip or as a duplicated request on rebuild.

for a principal

Own the tradeoff. Rotation is an axis multiplied across a suite, so argue for where it pays — unsaved work, multi-step flows, arrangements that genuinely differ by geometry — and set the rule that stops a team applying it to everything by reflex.

## What a rotation does to the screen Rotating a handheld is not a repaint of the screen that was already there. On the platforms a mobile suite targets, orientation is part of the environment a screen was built for, and the usual response to that environment changing is to **discard the current screen and build a new one for the new geometry**. Everything the application was holding only in the discarded screen's own fields goes with it. Values that were written somewhere that outlives the screen — a form model the app keeps, a saved draft, the server — come back. That teardown-and-rebuild is the whole reason orientation is a case axis rather than a cosmetic check. Rotation is the cheapest user-triggered way to force the application down a restore path that otherwise runs only under memory pressure, hours later, on someone else's handheld. A flow that loses the user's work when the screen turns is not really a rotation bug; it is a state-preservation bug that rotation made visible in two seconds. ## Where in the flow the rotation belongs The most common defect in an orientation case is not the assertion — it is the placement. There are three placements, and only one of them is useful: - **Before the flow starts.** Proves that a screen can be built in the other geometry. Nothing was in flight, so nothing could be lost. - **After the flow finishes.** Proves that the result screen renders. By then the entered data lives on the server, and the restore path is bypassed entirely. - **Mid-flow, with unsaved work on screen.** The only placement that exercises what a rotation can actually destroy. So the case drives the flow to a partially complete state first, and rotates from there. ## What the case asserts | On screen when you rotate | What must survive | Typical failure | |---|---|---| | Text typed into fields | Every entered value, character for character | Fields cleared or reset to a default | | A selected option or row | The same selection | Selection snaps back to the first item | | Scroll position in a long list | Roughly the same region | The list jumps back to the top | | A step in a multi-step flow | The same step | The flow restarts at step one | | An open dialog or sheet | Still open, with its own contents | Dismissed silently on rebuild | | A running countdown | Continues from where it was | Restarts from the beginning | | An in-flight request | One request, not two | The call is issued again on rebuild | The last row deserves its own attention. A screen rebuilt on rotation may re-run whatever the original screen ran when it was first created, and a case that asserts only on what is visible will never see a second call go out. Where a flow issues a request on entry, assert on the number of calls a programmable stand-in received, not only on the screen that came back. ## The shape of a rotation case 1. Drive the flow to a state that has **unsaved work** on screen. 2. Record the expected values inside the case. Reading them back off the screen after the rotation and comparing them to themselves proves nothing. 3. Rotate. 4. Wait for a readiness signal from the rebuilt screen rather than for a fixed number of seconds. 5. **Find every element again.** A handle taken before the rotation may point at a screen that no longer exists. 6. Assert values, selection, step, scroll region and open dialogs. 7. Rotate back and assert the same set a second time. 8. Complete the flow and confirm it submits what the user actually entered. Step 7 earns its place. The return trip restores from a state that was itself restored, and that is where a second class of defect lives: a listener attached once per rebuild so a submit fires twice, a value restored into the neighbouring field, a counter that climbs with every turn. ## Assertions that break for the wrong reason Geometry is precisely what a rotation changes, so assertions made out of geometry fail whether or not the product is broken: - **Pixel positions and coordinates.** The layout is different by design; that is the point of rotating. - **Whole-screen image comparison.** It flags every intentional rearrangement, and it buries the one value that was lost inside a diff nobody reads. - **Fixed line breaks or truncation points.** A wider window wraps text differently. - **Position in a flat list of everything on screen.** A one-column arrangement may legitimately become two columns. What survives a rotation is identity and content: the element with a stable identifier is present, holds the expected value, and can still be acted on. Where geometry genuinely is the behaviour — a primary control must stay reachable in the shorter window — assert the property, not the number. ## What a good orientation case actually finds Real, user-visible defects rather than cosmetics: work in progress silently discarded, a duplicated request on rebuild, a dialog that disappears and takes an error message with it, a media surface that restarts from zero, a second column that becomes unreachable when the layout collapses. All of them sit on a path that ordinary users take by accident several times a day.

  • The team says rotation is covered because the app is locked to one orientation. What would you still check?
    That the lock is real and complete. It is normally declared per screen, so one screen opting out is the usual miss, and larger form factors may ignore it entirely. Beyond that, a lock removes the trigger but not the path: a change to a system-wide display setting rebuilds the screen the same way, so the state-preservation check still has to happen, reached through a different door.
  • What does rotating back to the original orientation add that a single rotation does not?
    It runs the restore path a second time, starting from a state that was itself restored rather than freshly built. That is where a distinct class of defect appears: a value restored into the neighbouring field, a listener attached once per rebuild so a submit fires twice, a counter that climbs with every turn. A one-way case never reaches any of them.
  • How do you stop a rotation axis from doubling the whole suite?
    Apply it deliberately rather than everywhere. The flows that earn it hold unsaved work: forms, multi-step wizards, anything with an open dialog or a live media surface, and any screen whose wider layout is genuinely a different arrangement. Elsewhere one rotation per screen family is enough. Applied by reflex, the axis pays full runtime for almost no extra defects.

It is like being interrupted mid-sentence and handed a fresh sheet of paper: what you had already written down survives, what you were only holding in your head does not.

saying these in an interview costs you the question

  • Rotates before the flow starts and calls it covered
  • Asserts only that the screen still renders afterwards
  • Reuses element handles captured before the rotation
  • Compares whole-screen images instead of asserting values
  • Treats losing typed input on rotation as expected
  • Adds a fixed pause after rotating instead of a readiness signal
open as a page

A case asserts an element sits at fixed screen coordinates. Why does a raised system text-size setting break it, and what should it assert instead?

level: juniorimportance: should knowfreq 42%

basics

~20 s

Larger text reflows the layout: everything moves, wraps and grows, so a coordinate no longer identifies the element. Assert on identity and content instead — the element is present, reachable, holds the expected text, and is not drawn cut off.

open as a page

When a product runs in split-screen beside another app, which single-window assumptions break, and how would you test them?

level: seniorimportance: nice to knowfreq 22%

basics

~20 s

Split-screen halves the available width and can resize the app while it runs, so layouts assuming a fixed full-screen size, permanent focus, or exclusive use of hardware break. Test at the narrow size and while the divider is dragged.

open as a page