Question 1

How do you approach a "build this screen" task?

Accepted Answer

Five steps: (1) clarify — where the data comes from, how large the list is, whether offline matters; thirty seconds here changes the direction of everything. (2) state the structure aloud before writing it, so a wrong direction gets corrected early. (3) narrate while writing — I voice the reason for each decision, because silence is the worst signal: my thinking becomes invisible. (4) cover the states — loading, empty, error; I name them even when there is no time to write them. (5) wrap up by saying what I simplified and what I would do next. That last step matters most when the clock beats you.

Question 2

What do you do if you get stuck during live coding?

Accepted Answer

I do not go silent — that is the worst option. I say out loud where I am stuck and what I am thinking: "I need a LayoutBuilder here but I do not recall the exact signature; the logic is to return two different arrangements based on the constraints." That does two things: the interviewer can help, and my reasoning stays visible. My second tactic is to write the simple working solution and then talk about the optimisation — a working simple answer always beats an unfinished clever one. And when a hint is offered I take it; refusing one reads as stubbornness, while collaborating is what gets credited.

Question 3

How deep should you go in an architecture question?

Accepted Answer

Go for depth, not breadth. The most common mistake is touching ten topics with one sentence each and developing none — it sounds like a memorised list. My approach: ask about scale and constraints first, sketch the layers briefly, then pick one or two critical decisions and open them up with their trade-offs — stream versus polling for live updates, say, or the caching strategy. At the end I name what I deliberately left out ("I have kept push notifications and deep links outside this discussion"), which shows they were considered rather than missed and lets the interviewer steer where they want to go next.

Question 4

How do you react if the interviewer criticises your solution?

Accepted Answer

First I try to understand it: "So the concern is that this approach fills memory as the list grows?" — restating buys a moment and confirms I understood correctly. Then there are two cases. If they are right, I accept it openly and propose the fix — that reads as collaboration, not weakness. If I still think my choice was sound, I justify it, but without absolutes: "I chose X in this context because...; though in the scenario you describe, Y would genuinely fit better." Often this is a stress test, and what is being assessed is not the technical answer but how you conduct a disagreement.

Step	What to do	Why it matters
1. Clarify	Where the data comes from, how large the list is, whether offline is needed	A solution built on a wrong assumption cannot be salvaged
2. State the structure	Describe the widget tree aloud, then write it	It lets the interviewer redirect you early
3. Write and narrate	Voice each decision: "Expanded here, because..."	Silence is the worst signal — your thinking is invisible
4. Cover the states	Loading, empty, error — name them even if you do not write them	It is the most visible junior-to-middle difference
5. Wrap up	Say what you simplified and what you would do next	Even out of time, it shows you saw the whole picture

Live coding and architecture discussion

📚 Sources and documentation