What Junior UI UX Designers Get Wrong About Talking to Interviewers

Interview Insights · UI UX Designer

What Junior UI UX Designers Get Wrong About Talking to Interviewers

SECTION 01Mistake one: talking in jargon to everyone in the room

Junior designers often believe that design vocabulary proves expertise. So they say 'I leveraged a mental-model-driven IA with progressive disclosure to reduce cognitive load' to an HR recruiter who just wanted to know what the project was. Vocabulary is useful, but only when the listener shares it, and only when you can also say it simply.

In a panel, you may meet a designer, a product manager, a developer and a recruiter in one day. Each one cares about something different. A good designer adjusts the explanation to the listener, and the interview is the perfect place to show you can do that.

Recruiter: Tell me about this project.

Candidate: So I did a heuristic evaluation, then
an affinity map, which informed the IA. I applied
progressive disclosure and Gestalt proximity to
reduce cognitive load and improve the
affordances of the CTA hierarchy.

Recruiter: ...Okay. And what was the app for?

TO HR:
'It was a hostel complaint app. Students could not
see if anyone was fixing their complaint. I made
the status visible, and in my test every student
found it quickly.'

TO A PM:
'The goal was fewer repeat complaints. Students
filed duplicates because they saw no progress, so
I added a status tracker with clear stages.'

TO A DEVELOPER:
'The tracker is one component with four status
variants. Each status maps to a field the backend
already had, so no new API was needed.'

The project is the same in all three versions. Only the focus changes: what it was for, what it changed and how it gets built. Prepare all three before the interview.

SECTION 02Mistake two: a screen share that loses the interviewer

Online interviews have made screen sharing a core skill, and juniors often underestimate it. Common problems: sharing the whole Figma canvas so every frame is tiny, scrolling fast while talking, waving the cursor in circles, saying 'this one here' without saying what it is, and opening the wrong page while everyone waits.

The interviewer cannot lean over and point. Everything they understand comes through your narration and what is visible on the shared screen. A clean, slow and labelled screen share makes average work look organised. A chaotic one makes good work look confused.

SCREEN-SHARE SETUP (10 minutes before)

[ ] Close chat apps and notifications
[ ] Browser tabs in order:
      1. Portfolio home
      2. Case study 1
      3. Figma prototype (presentation view)
[ ] Figma: one page called 'Interview'
    with only the frames you will show
[ ] Zoom set so text is readable at 100%
[ ] Before/after frames placed side by side
[ ] Share a single window, not the whole desktop

NARRATION PATTERN FOR EACH SCREEN

1. Orient : 'This is the complaint status screen.'
2. Point  : 'At the top is the status tracker.'
3. Problem: 'Before, students saw only a date.'
4. Change : 'Now there are four labelled stages.'
5. Reason : 'They told me they wanted to know
            who was handling it.'
6. Pause  : 'Any questions before I move on?'

Move to the next screen only after step 6.

The pause at step six feels slow to you and perfectly natural to the interviewer. It gives them a moment to ask questions, which is where the real conversation happens.

SECTION 03Mistakes three and four: hiding your role and ending flat

Two smaller habits do a lot of damage. The first is ownership language. Juniors who worked in a group or internship often say 'we' for everything, so I cannot tell what they did. Others say 'I' for everything, which becomes a problem when the follow-up questions show the work was shared. Both lose trust.

The second is the ending. When I ask 'Do you have any questions for us?', many juniors say 'No, everything is clear.' That ends the conversation on a flat note. Good questions show what you care about, and for a designer, they should show curiosity about users, process and how design works in the team.

OWNERSHIP STATEMENT (use at the start of each project)

'This was a [team / solo] project.
The team was [who].
My part was [specific tasks].
[Name/role] owned [their part].
The decision I'm proudest of was [X],
and I'll explain why I made it.'

Example:
'This was a 3-person college project.
I ran the user interviews and designed the
checkout flow. A teammate designed the menu.
The decision I'm proudest of was guest checkout.'

QUESTIONS THAT SHOW DESIGN CURIOSITY

About users:
- Who are your main users, and what do they
  struggle with most right now?

About process:
- How do designers get research input here?
- How do design reviews work on this team?

About collaboration:
- At what stage do developers see designs?

About growth:
- What would success look like for a junior
  designer in the first few months?

Avoid: questions answered on their website.

Choose two questions that fit the conversation you just had. A question that builds on something the interviewer mentioned earlier is the strongest of all, because it shows you were listening.

SECTION 04Conversation rehearsal kit for junior UI UX designers

These three sheets let you practise talking about your work the way real teams will hear it. Do them out loud, not just on paper.

THREE-AUDIENCE DRILL (main project)

For HR (30 seconds):
  What it was, who it helped, one result.

For a PM (45 seconds):
  The goal, the problem, what changed.

For a developer (45 seconds):
  Components, states, data, constraints.

Record all three. Check:
  [ ] Each one sounds different
  [ ] No unexplained jargon in the HR version
  [ ] The dev version mentions states and edge cases

JARGON TRANSLATOR (fill for your terms)

Term I use          Plain meaning
_________________   _______________________
_________________   _______________________
_________________   _______________________
_________________   _______________________

Rule: if the plain meaning takes more than
one sentence, practise it until it doesn't.

Test: explain each to someone outside design.

MOCK CALL CHECKLIST (with a friend)

During the call, friend notes:
[ ] Moments they got lost on screen
[ ] Jargon they didn't understand
[ ] Places 'we' hid my contribution
[ ] Whether I paused for questions
[ ] Questions I asked at the end

After the call:
Top thing to fix: ______________________
Second thing:    ______________________

SECTION 05Talking habits that make your design sound senior

Senior designers are not always better at drawing. They are almost always better at explaining. Borrow these habits early.

• Start with why it mattered — Begin each explanation with the user problem before describing any visual detail.
• Name what you point at — On a screen share, always say the element's name and position so the listener never has to guess.
• Use 'I' precisely — Say 'I' for what you did and 'we' for shared work, and name who owned the rest.
• Check understanding — After a key screen, ask whether it makes sense before moving on, just as you would in a stakeholder review.
• Ask one curious question — Prepare at least two questions about users and process, and ask the one that fits the conversation.

SECTION 06Interview Q&A — Junior UI UX talk

SECTION 07Test yourself — Junior UI UX talk quiz

SECTION 08Frequently asked questions

SECTION 09Related reads