## My role, contribution

* What exactly did you do

Some projects are so complex that it is hard to understand your individual contribution to the project's success. You want to make sure that it is clear what you have contributed so that a listener can understand that.

We’ve seen designers struggle to highlight their contributions. Mind you, a listener doesn't know everything, and things that are obvious to you might not be obvious to them.

If you struggle to list specific things you did, try answering this question: what would happen with a project if you haven't participated? If the answer is relevant to the job you are applying for, don't forget to mention that.

## XFN examples

Reflect on your ability to work closely with cross-functional (XFN) partners (i.e., engineering, product management, content research, etc.).

Think of examples where you collaborated with people from your team.

The keyword is a**n example**.

List these examples and think about how you would incorporate them into your storytelling.

How to talk about my role, contribution, XFN (cross-functional)

Even seasoned designers struggle to pick the right projects. Our process guides you to build a presentation based on the hiring manager's expectations.

### Do you have high-definition layouts you can use in a presentation?

You'll need large, high-fidelity layouts to use in your presentation. Say yes if you have layouts you can demonstrate, and they are of good quality.

- You can fine-tune your existing layouts if it helps explain the story better.
- If you are interviewing in English, but your layouts are in a different language, consider translating them.

### Was this project released to users with your participation?

Such experience helps you answer the question about what you would have done differently next time (reflection), which demonstrates that you care and are able to learn from each launch, especially if your designs affected metrics and/or user behavior. It can potentially be a good example of cross-functional collaboration.

### Do you have user research or data analysis to support your design decisions?

Qualitative or quantitative research results can be a good way of explaining your design decisions, why it was the problem in the first place, and presenting the results.

### Have you tested different hypotheses?

A hypothesis helps you to prove or disprove the assumption. They are either proven or disproven using research and experiments. Usually, it helps find the fittest solution and explains your thought process during the interview.

### Can you state a user problem in one sentence?

Designers often fail to communicate the problem statement of the user or business clearly. If you can reduce the statement to one simple sentence without extra complications or explanations, then you've got it. If you have a lot of explaining to do, you probably lack a simple problem statement.

### Have your designs improved relevant product metrics?

E.g., you intended to boost the metrics, and your design was the driving force of the team’s success. If you performed A/B testing, let that data support your story. Presenting this data will help you answer the question, "How did we know if we solved the problem?"

### Were there any measurable improvements in the user experience?

If you measured user satisfaction: the usability index, error rates, the speed of solving the problem (from the user’s perspective), or even the net promoter score or lifetime value. Usually, they are measured before and after the implementation. Knowing these measures will help you to answer the question, “How did we know if the problem was solved?”

### Can you clearly explain your individual contribution?

Since you are filling in this questionnaire honestly, tick this box if you are 100% confident that the team wouldn’t have done this project without you.

It is essential to highlight your input because much success comes from teamwork, and some candidates hide behind other people’s achievements.

### Do you have an example of cross-functional collaboration on this project?

Also known as XFN.

How you solved problems and came up with solutions with teammates or people from other departments (e.g., the development team, marketing, research, data scientists, support).

### Extra points if you have designed for multiple platforms:

* Your designs were made for native mobile platforms (iOS, Android, etc.). It can be mobile-only or a cross-platform solution, including wearables (mostly watches).
* You designed a desktop app with GUI—macOS, Windows, and Linux. E.g. browser, media player, etc.
* You designed a web app (something users can interact with inside a browser). Usually, exclude landing pages and static websites.
* You have examples of VR or AR for mobile apps, glasses, etc.

### Do you have a prototype that you can use during the presentation?

Having a prototype in your possession, preferably one you can share on your website, might help you build a portfolio or explain your design process or problem solution during the portfolio presentation.

### Do you have a reason to be proud of your work on this project?

Answer "yes" if you are really proud of your input for some professional reason: significant improvements, implementation speed, craftsmanship, XFN, 3D, visualizations, or awards.

### Have you participated in quality assurance testing of the final product?

Some designers find it essential to participate in development processes and QA to make sure their designs were delivered correctly or if there were improvements they could help deliver ASAP. This can be a good example of XFN and might help answer the question about what you would have done differently if you were about to work on this project again.

### Did you help with the launch?

Some designers participate in the product launch by working on marketing materials, from communication strategy and visualizations to media planning and polishing loads of banners or videos. This can be another example of XFN collaboration to mention.

How to pick projects for portfolio presentation

We’ve listed the most important questions that hiring managers want to be answered in your portfolio or past work presentation. Use them or the STAR method to prepare your slides.

We highly recommend answering the most questions we provided here to build a story about your project. We have also found that for some designers, it feels intimidating to answer some of them for whatever reasons. If that’s the case, try using the STAR approach.

We would not go deep into STAR because there is a lot of information about it on the internet, and it is more of a generic approach (which still could be a great starting point).

Instead, we will list questions and subjects that product designers are usually pretty fluent.

## Tell a story while showing your work.

We noticed that some designers tend to answer questions and publish them on a website as sections. That might be cool and all, but when people listen to a presentation, they remember stories better. Also, people love reading stories. So, you might want to end up with is a story about a project.

Usually, a story has a beginning and end, some plot, actors, and so on. People that would listen to your presentation want to know the context — what was the problem or task you had to deal with, then they want to know how you solved it, then they want to know how you know that that was a good solution. The characters in your story would be your colleagues, clients, and you. The story arc is that clients had such and such problems, and your team and you had such and such adventures while you were solving the problem, and the happy end is the result — how your designs helped.

We recommend that you will write down the answers to the following questions. Think of them as of your storytelling bullet points — that is what you want to tell when showing your awesome designs.

The overall structure can be boiled down to three sections:

* People or business problem — what was the problem you were trying to solve and how you found out about that problem.
* Solution and key design elements — start with what final screens/layouts you have delivered and explain why and how they solved the aforementioned problem.
* The role, individual contribution, and XFN examples. The hiring party wants to know what it would be like working with you. Specific examples of your collaboration would paint the picture.

How to structure your case study

What is important when talking about the context of your projects?

## People or business problem

You've got it if you can reduce the statement to one sentence without extra complications or explanations.

If you have a lot of explaining to do, you probably lack a simple problem statement (if true, consider dividing the feature into smaller chunks or user stories).

Remember, this problem statement should correspond with the described solution and results.

It is important to explain the problem because your presentation with problem-solving skills heavily depends on understanding a problem. If your listener doesn’t understand the problem, they will have no means to evaluate your solution and draw conclusions from your presentation.

People struggle with this question most often. Here’s a quick way to make sure you can boil down a complicated problem into one sentence: try answering a question — what would have happened to users if you hadn't implemented that thing? Transform the answer into the problem statement.

We have also witnessed a situation when a candidate wastes too much time explaining the problem. Usually, it is a bad sign because a complex explanation requires a lot of attention from a listener, and they can easily misinterpret a lengthy explanation. Even if a problem is complex by its nature, you want to make its statement as simple as possible.

### What would have happened to users if you hadn't implemented that thing?

> We had the following dialogue with one of our users:
>
> — I can't explain the user problem because it was such a complex project.
>
> — What were you doing there?
>
> — We worked on how to link a banking card to the account and all sorts of that kind of things.
>
> — What would have happened to users if you wouldn't implement these features?
>
> — They would not be able to transfer money between countries.
>
> — Can I suggest that the user's problem was that they needed a way to send money internationally?
>
> — Yes! That's it!


## Target user/addressable audience

Describe your user so that the problem you were solving would be more relatable.

Also, elaborate on why this audience was picked in the first place, how many users were there, and why you decided to focus on them.

The information about the audience would provide context to a listener.

## Problem verification

People usually don’t like working on problems that are not worth solving. If you can explain the origin of a problem and why you have picked this problem to solve, that might also provide more context to a listener, and they will understand your story better.

Try answering these questions:

* Why was it a problem to begin with?
* How do we know this is a real problem?


## Goals/success metrics

When you have a problem to solve, you sure have thought of the desired outcome before you start solving the problem. Usually, you want to improve a metric, or change the user behavior in a specific way, or reduce friction (which also could be measured and turned into a metric).

Consider thinking about these questions:

* How would you know the problem was solved?
* If there was only one metric (relevant to this project), what would it be and why?

Remember, you've described the problem above. Your desired outcomes should correspond to the defined problem. This would help a listener to understand your thought process and the solution.

***

## Make it shorter

The best strategy here is to think about answers to these questions, write them down and then turn them into one short paragraph.

It is okay if you can't provide examples of all the items above, but you should be able to rationalize them and show that you understand what you are talking about and sound assertive.

 The context was needed so that a listener would understand your work. Now that we've covered the context of your project let's move to the best part: show your work. Your work should be the most exciting and informative part of your story.

How to talk about the problem statement and research

This is where you show your work and explain why.

Start with large images of the resulting layouts.

If you have explained the problem well, we hope your solution will become understandable for a listener, and they will focus on your work instead of trying to figure out what they are looking at.

## Key achievements and/or improvements

No matter what the results were–if you decided to talk about a failed experiment or an astonishing achievement, consider talking about what your work has achieved.

If you have followed the previous article and described what was the expected outcome, here is the place to tell how it worked out after release or user testing (or any other result relevant to your project).

When showing your work, consider pointing out what were the design decisions that helped achieve the results and what the results were.

## How did you know if the design or solution was any good?

Have you achieved the goals you planned to achieve? If you have listed them before, comparing your expectations and actual results could be great storytelling.

Talk about how you knew that that problem was solved. Usually, a relevant product metric was affected by your work, or there was some measurable change in user experience.

## Key design solutions

If you are writing notes for your presentation, make a list of layouts that you can share that would illustrate your story and results in the most convenient way for a listener.

Since we are talking about a product designer job interview, your listeners would be most interested in your design skills. Please make sure to provide high-definition images.

If you have to adjust existing layouts for your presentation slightly–do it if it helps you explain your work better.

Think of these questions:

* What were the key design solutions you provided?
* How did you know if they have solved the problem?
* Highlight experience with working across cross-platform (web/mobile/desktop) products.

## Constraints and tradeoffs

* Were there any constraints that affected your design decisions?
* Tradeoffs you and your team had to make or explorations you decided against.
* What would you have done differently if you had to start from the beginning knowing what you already know now?

Sometimes when we show our work, the decisions are not obvious and could be explained by limitations or constraints. E.g., you were limited by the time, or there was not enough audience to run a proper a/b test or some technical restrictions. Mention them if they are relevant and help you explain your work better.

It is always great when you can show and explain what you would have done differently if there were no constraints and what would have been the best design you think you could have delivered. If possible, show that. The least you can do is explain what you've learned from this work.

## Measuring progress/success

Consider mentioning datapoints that back up your design decisions:

* How you were involved in the research phase.
* How you made decisions based on data throughout.
* A/B testing, UX research, and any other relevant data that supports your story.

It is always nice to explain how you got the data you used to guide you for your design decisions and how you have measured your project's success.

Explain how you've learned about the user problem. It all matters if you participated in user research, data analysis, or tested hypotheses by building prototypes. It helps a listener understand your decisions.

Basically, there are two things to think about:

* Research phase, where you learn about a problem and get a better understanding of it.
* Verification: after you come up with a solution, have you tested it against reality to ensure it would achieve the desired outcome?

How to talk about solution and key design elements

Writing helps some of us to prepare better. You'll have to fit three projects into 1800 words max.

Avoid writing a lot of text: you have a time limit for a live presentation, and hiring people rarely (if ever) read this stuff in your portfolio.

Consider time limitations if you want to write down your presentation outline before assembling it into a slide deck. Here we’ll explore how many words you might want to use to ensure you will fit the given time, what structure to follow and why the 42 words/slide is the average you might want to aim at.

Given: the portfolio presentation at the interview should fit into 30 minutes.

You have to fit 2-3 projects into a presentation.

Depending on the strategy, 20, 10, or 5 minutes can be allocated to a project.

For simplicity's sake, let's consider 10 minutes per project.

There is a vast difference between reading and pronouncing speed. If you google for “English pronunciation speed average words per minute,” here’s the snippet for you: “Most words are two to three syllables long, giving you the answer that the average person speaks approximately 100 – 130 words per minute. A professional voice-over artist usually uses 150 to 160 words per minute.”

It will be a mistake to speak quickly - you want your peer to hear everything clearly, so let's take 100 words per minute as an average pronunciation speed.

One or two minutes will be spent on a clarifying question/joke/interviewer's comment. You want the presentation to be like a dialogue and to be understood, which is the whole point of an interview.

Now we have 8 minutes/case left.

That's 800 words if everything goes smoothly and without hiccups. But they happen, so let's remove 20% from here.

Now we have 640 words left.

640 words for context, user problem statement, and comments to the slides (your process and results).

What you need to reveal in 640 words:

1. About the company or product.
2. The user problem statement.
3. Justification of that problem.
4. The audience or target user.
5. Expected result.
6. Problem-solving: your solution, the core of the presentation.

Depending on your story, consider these questions, too:

1. How did you know that the solution was good?
2. Sacrifices and restrictions, if any.
3. Your individual contribution to the results (that's why they might want to hire you, by the way).
4. An example of working with a team and other departments (XFN), if applicable.
5. What have you learned at the launch/what would you have done differently?
6. If there is a professional reason to be proud, tell about it.

Each slide with pictures will take a minute or two to explain or comment on.

There will be approximately 15 slides per case.

640/15 = 42 words per slide.

Obviously, you will have to adjust your story to the timing and slides to the story, and depending on your cases, these averages would be different. You still would want to keep the pace and avoid long talks over one slide while quickly skipping other slides.

This text has ~500 words. It would take me approximately 5 minutes of reading out loud, which is ~15% of the presentation time.

How to write for portfolio presentation and case study

Make sure the information on each slide is useful, adds to the story, and helps the listener understand it.

Consider devices and your interviewer's environment:

* People will be watching your presentation on all forms of devices.
* Hopefully, not on the phone. But it happens quite often.
* When sharing a screen, there is a probability that the UI of a browser or connectivity app (e.g., Zoom, Hangouts, Bluejeans) would occupy a big part of a viewer's screen (1/3) so your presentation would take a part of the screen, and everything will be perceived smaller.

## Use large images

Rule of thumb: use one image per slide.

Designers tend to place three mobile screens in a row. Almost every time a viewer watches it, they think it is some sort of development of the first screen. If that is the case, and that was your intent, then it is okay.

But more often than not, designers just place these screens on one slide for no reason. Your audience will think of your pictures instead of listening to you, and most of the time they will feel confused.

If you have to show a few screens on the same slide, consider revealing them one after another so that a viewer’s focus will remain on an image you are talking about at the moment.

## Avoid walls of text on slides. Use short headlines only

If you are like lots of designers who want to start by writing down a story they'd like to tell, you probably would like to put some of these texts on your slides. That would be a mistake! The answers you are writing are to support your story, not for publishing on slides.

* People read faster than you can pronounce
* If you read from slides, they will fall asleep
* Show and tell, don't write
* If you have to share slides, add accompanying text if necessary

It is cool to use your texts later on a website as a commentary on your slides.

How to design a portfolio presentation

How to write project case studies for your portfolio

Presentation and slides are almost a requirement. It helps the candidate to manage time and focus on what is important.

You can't skip the presentation. Accept it and cope with it.

Presentation is the only part of the interview that you control 100%. This is your best chance to make the right impression and set the right tone for the rest interviews.

Make sure you show your best. Interviewers probably have never seen you before; they don't know you and have no idea about your life. All they know and see is how well you can prepare.
Also, note that they have been through the presentation before you. They came prepared, and they expect the same from their potential coworker.

The best strategy is to practice your presentation before building a portfolio website and before applying:

* You will learn what projects work best for you
* You will feel confident talking about these projects
* Once you get feedback on your presentation from real people, you will put a better story on your portfolio website and increase the chances of an invite for an interview.

In the following articles, we will cover:

* Presentation structure
* How to design presentation slides
* How to talk about your projects

> We highly recommend you watch this lecture on presentations. Even though it is not focused on design and portfolios, it gives a fantastic insight on how to build any presentation and how people perceive stories:
>
> [How to speak](https://youtu.be/Unzc731iCUY) by MIT professor Patrick Winston.

Why bother with a portfolio presentation?

Knowing what mistakes to avoid before you start building a presentation is cool (feat. considerations and recommendations from Google recruiters).

## Considerations

1. Make sure your presentation works all the time. Avoid relying on third-party online services that might be offline or change their UI (including Figma).
2. You want to make sure your story has a linear narrative. It should be a story or a set of stories.
3. Make sure you can quickly and easily access any presentation parts without wasting too much time (get back to a certain slide to discuss or explain something).

If you glance through the following misconceptions, you will realize that most of them do not comply with the considerations as mentioned earlier.
Things to avoid (common misconceptions)

### 1. Avoid live product walkthroughs.

It might sound like a good idea, but in reality, it doesn't work because:

* Products change over time (usually, you can't control that).
* It is hard to jump back and forth if necessary.
* It is finicky to share a screen of a mobile app and prone to mistakes.
* You usually don't control the content, which might distract from the point you are conveying.

### 2. Avoid sharing layouts in Figma and jerking them across the screen (it nauseates other people).

When you both look at the screen and control it, your brain understands what's going on on the screen because your brain first thinks of action and then anticipates the change. People that follow your story process the same in reverse: they have to see the change on the screen first and then process it.

Some candidates are nervous and jerk and twitch layouts so that layouts are dancing on the screen. This might literally cause nausea. You want to avoid interviewers literally experiencing nausea because of your presentation.

We have also noticed that people that rely on layouts tend to forget what they are talking about and why and focus on details that don't matter.

### 3. Never put walls of text on your slides — you should show and tell, not read together from the slide.

* Avoid more than one headline on the screen.
* Avoid paragraphs of text on slides.
* Never read out loud what is written on a slide. A listener will read faster than you will pronounce these words, and your voice will distract them from reading or bore them into sleep.

### 4. Avoid browsing your portfolio website together with an interviewer

* Same as with jerking layouts across the screen and reading out loud, but combined.
* Shows you aren't prepared for an interview.

## Export to PDF, don’t rely on cloud software.

It might sound strange, but PDF is the most reliable format that works both for you and for the hiring party:

* PDF works all the time and it is cross-platform.
* PDF is less finicky.
* PDF works everywhere.
* PDF is linear, which is important for a narrative and linear storytelling (which is your presentation)
* You can share it if necessary.

Some people used Figma prototypes instead of PDF. This also worked as well for linear storytelling, but we have also noticed that Figma might change the UI, might be offline, etc. Seriously consider if you want to risk your presentation and rely on this kind of dependency.

***

## Recommendations from Google recruiters

Let’s quote people who work with candidates the most (note that their recommendations are based on loads of experience):

> A few guidelines for a successful presentation:
>
> * You will be presenting through Google Hangouts. NOTE: Don't include any animations or media as part of the presentation -- they are clunky at best over Hangouts, and I don't want you to feel frustrated or have that impact on your presentation.
> * Show us your work along with your process--we want to see both! Use specific examples to walk us through from the beginning to the end of your involvement. Discuss the challenges you had to overcome, alternate solutions considered, and the final results.
> * If you were working as part of a team, clearly identify your contributions to the process and the final product.
> * We would rather you go into 2 projects very deeply than many projects shallowly.
> * Please don't show any work that is confidential. Usually, projects you have worked on in the past that have launched are acceptable to show.
> * The presentation can be as formal or as informal as you would like it to be.
> * Please make a backup version of your portfolio and send it to me as a PDF to share with any panelists who may not be able to make it, or who lose connectivity as happens during these crazy work-from-home days (smile).

We will explore presentation structure and slide design in the next articles.

What makes a good portfolio presentaion for a job interview?

Intro, context, case studies. Make sure interviewers will understand the scope of your work and your background.

## Presentation structure outline

We decided to describe this structure because we noticed that people often forget to provide the context and listeners have to waste a lot of time trying to understand what’s going on and why a person talks about these projects.


#### 1 — 2-3 minutes to introduce yourself and set the stage for the following story

* It is worth mentioning why and how your experience is relevant to the job you are applying to and
* how your experience highlights are relevant to the job

#### 2 — Context and frame of reference:

* When talking about past work, don’t forget to mention a company name, size, goals, business model. You don’t have to go deep into details, just enough information to set up the scene for your stories about projects.
* Audience: what and why they became clients or users of that company’s products. Sometimes it is worth mentioning so that your listener would understand the motivation to use products and services you would be talking about.

#### 3 — Projects:

- Project # 1
- Project # 2
- Project # 3

We have a comprehensive guide on how to talk about projects.

Pick a strategy (described below) to make sure you cover stories that are relevant to your desired job

#### 4 — Summary (optional)

* Recap what you’ve just told so that they will remember better (the very short recap for 2-3 minutes maximum)

***

If all projects were done at the same company, you would save some time explaining the overall context: you would only talk about it once. A bit harder to allocate time if projects are for different companies. Think about allocating more time to explain the context for each company you are talking about.

Also note that you might want to turn your presentation into a story, not just a bunch of slides with comments on them. Telling a story is an important part of the presentation if not the whole presentation.

## Strategies: 15/10/5 and 10/10/10/

Think about how you will distribute your time among the projects. If you will talk about three projects, you don’t have to dive into all the details for each project, but consider these two strategies:

### 15-10-5 minutes:

Start with the most challenging and interesting project for 15 minutes (a job position with a focus on product thinking), followed by something that can be compromised or something with little graphics and finish with a short story that has a remarkable outcome (literally 3 minutes to tell a story). The reasoning here is that your listener will understand that you can handle complex projects, but the last story will be uplifting and will leave a good impression.

### 5-15-10 minutes:

Start with the most visually striking project, followed by the challenging ones (if the job position emphasizes interfaces). The logic is that the candidate first demonstrates powerful visual skills, then strengthens the story with complex projects. If visualization skills are crucial for the job, you can show the interviewer from the very start that the basic requirements are met and lead the presentation to more complex topics.

***

Obviously, you can mix and match the timing strategies depending on the role you are applying for and the projects you are about to talk.

The idea is that you don’t have to distribute timing among the projects evenly. Your only goal is to deliver a message that will explain how good you are as a professional.

Presentation structure

Even though interviews are scheduled for 45 minutes to an hour, make sure you can deliver your story in 30 minutes.

Professional interviewers note your time management skills.

Even if an hour is allocated for the interview, it doesn't mean you can use all that time for your presentation. Take a look at what adds up for that hour:

* Meetings usually start 2-5 minutes later than, the scheduled time (but you always should show up on time!)
* Introductions, 5-7 minutes
* Brief overview of the company, product, and team, 5-7 minutes
* Candidate's self-introduction (present yourself and talk about yourself)
* 30 minutes for portfolio presentation
* 10 minutes for presentation questions (by the way, they can come during the presentation)
* Time for candidate's questions (time is usually allocated for this because it's important for the interviewer to understand how you ask questions about the company)

Here is that hour (60 minutes). It would be naive to assume you'll have an hour to show your work. In reality, you'll have a 45-minute meeting - less than an hour! So, aim for 30 minutes for your presentation.

## Interviews always end on time (even if they started late)

It is your job as a presenter to keep track of time.

When you talk to friends, they listen until the end. But in a real interview, the interviewer will simply have another meeting start, and you will say goodbye on time. It's especially awkward when the time is up, but you're only halfway there, or you finish too quickly, and important details are left uncovered.

Why aim at 30 minutes for a presentation

Portfolio presentation structure

Use real-life job interviews as opportunities to collect offers and make the most of your job search.

To prepare for job interviews, it's essential to spend at least two to three weeks practicing and eliminating basic mistakes. This will help you feel confident and increase your chances of success. If you are rejected, the company may not consider your application again for six to twelve months, so it's important to put your best foot forward.

## Top reasons why candidates are failing

* They come unprepared!
* Too nervous, anxious, forgetting words (hard to communicate).
* Irrelevant experience.

People that are interviewing you have been through the same interviews, and they came prepared. They expect candidates to come prepared, too.

Preparing is easy but requires some time. We’d say about a month if you spend at least five-seven hours per week.
Coming prepared is awesome for both parties. You both know what you are looking for and respect each other. Also saves time for both parties as well.

## Most of preparing should be active practice with peers

One way to prepare is to practice with peers who can provide feedback and help you feel more comfortable talking to strangers about your work.

Real-life job interviews all have an interviewer — a person that will listen to you and ask you questions. A person you probably have never met before. You might either feel anxious while anticipating such an event, or you can practice with other random people until you feel comfortable talking to strangers about your work. In any case, there would be another human being interviewing you.

We have observed hundreds of candidates, and this stands true: one can learn how to talk with real people only by talking to real people.

There is no other way to learn the skill but to practice it.

Reading helps you learn what to expect and what exactly to prepare for an interview, but you should fast forward to practicing with other peers as soon as possible.
Practicing with random folks eliminates anxiety, and you will come prepared for an interview.

Our practice sessions are built in a way where you have to listen to others. After the second listening session, you will realize what is relevant and what is not. This will help you detect bullshit and avoid having it in your presentation!

## Treat real-life job applications as opportunities, not practice

Some people recommend applying first and preparing later. Some suggest “practicing” on companies you don’t want to work at, then applying to companies you like.

We think you should treat each application and each interview as an opportunity to get an offer.

You don’t want to optimize your efforts toward getting better at receiving feedback or handling rejections.

You want to optimize for job offers. So treat every interview as an opportunity to get an offer.

The goal of our platform is to help you prepare for interviews so that you get as many offers as you can.

Your goal is to get a job. If you have a bunch of offers on hand, you will choose which one you like or want and get a job. Not feedback or rejection, but a job. So try getting as many offers as possible.

The number of offers should be your metric, not the number of interviews. Even if you are not necessarily planning to work there.

> There are psychological and ethical sides to applying to companies "you don't plan to work at."
>
> First, psychological: some folks prefer treating rejections like "I never wanted to get there anyways" as a kind of coping mechanism. If it happens to you, consider if you are being honest with yourself.
>
> Second, ethical: is that okay to apply to a company you are probably not passionate about? Well, consider this: if you haven't discovered anything particularly bad about them, people are nice, the product is fine, and you can be helpful–we think it is okay to know them better during an interview. Some jobs are not what they seem, and sometimes you might benefit more from going to companies you didn't think about before. Do your research. If the only reason you apply is to practice before applying to a company you think you want to work at, then it is probably a waste of time unless you secure an offer.

## Having offers on hand helps you negotiate and feel confident.

Getting offers takes some time, but once you have one or two and you have a few more interviews coming up, you feel safer and more confident because you have already secured a job.

Also, once recruiters realize you already have offers on hand, they might speed up their internal processes at least to start with the first round of interviews sooner.

Also, if you have an offer already, you will have a solid position to negotiate a salary.

***

Preparing for interviews pays off because it increases the chances of getting an offer.

We'll explore tactics in the following article as a step-by-step guide. The whole course is built around how to make this strategy work.

In the end, the number of job offers you receive should be your metric for success, not the number of interviews you attend. So focus on preparing and optimizing for offers.

Strategy and tactics

Hiring managers can afford to be picky because of the large amounts of applications. Learn how to stand out in the application process.

Recruiters and hiring managers at FAANG companies have to look at dozens, if not hundreds, of applications daily. It is a tiresome and mundane task. They have an opportunity to pick candidates that seem to be most suitable for a role in their team; thus, they are all looking for something that matters to them at the moment (and this moment has nothing to do with your application, it is all about them).

Given the time constraints and the power to be picky, and also knowing what they are looking for, they are most likely to omit applicants without portfolio and usually evaluate portfolios in less than a minute (55 seconds on average).

This statement is based on research: we invited 16 hiring managers from different companies to evaluate 243 applications.

We asked design managers to say yes or no to a question: would they invite the candidate for an interview after reading an application and viewing a portfolio (if a candidate decided to provide it.)

On average, it took them 55 seconds to make a decision if they wanted to interview a candidate.
55 seconds included reading a cover letter and viewing a portfolio website.

> More stats if you are curious:
>
> About 3% of applications have got a unanimous 'yes' (meaning all hiring managers would have invited these candidates for an interview).
> About 8% of applications got 80% of approval (meaning that most of the hiring managers would have invited these candidates for an interview)
> More than 60% of applications were considered irrelevant, and most of hiring managers would not invite these candidates for an interview.

Having a portfolio does not guarantee you an invitation for an interview.

However, a lack of a portfolio or at least a personal website or professional profile most likely guarantees a rejection.

The portfolio is a must. Nuff said.

The research emulated a real-life situation, where applications appeared as candidates were posting them during the month period.

The number of applications is declining after a week since the job was posted. By that time, both recruiters and hiring managers have booked at least a dozen of interviews and tend to spend less time reviewing new applications.

By the way, you don't have to be a hiring manager to start recognizing irrelevant applications. Another research showed that former candidates start recognizing irrelevant (bad) applications after they rated 20-30 applications themselves. Such an exercise is useful when writing your own application: once you start recognizing basic mistakes, you will avoid them as you apply yourself.

An irrelevant (or bad) application or portfolio does not necessarily mean that a candidate is good or bad. The point is that if an application or portfolio is all the information a hiring manager has, they will make a decision based on this information only. And they will make a decision quickly.

How they evaluate your portfolio and resume

Here's why hiring processes are so complicated and take a long time.

Imagine you are working on a scientific project, and you have to deliver results in a few months. If you are successful, you are getting paid, your work is published, and your career prospers. If you fail, you will have to start over again, but with losing precious time. In order to make it, you have a budget to spend on specialized equipment. Say you have to buy a computer to do all the calculations. It seems easy in the beginning: there are a lot of computers on the market. But some of them are not compatible with the software you intend to use, and some o them are overpriced, some of them are not powerful enough, and you will have to be very specific in your experiments because the underpriced computer might be slow.

The same works with hiring managers when they choose who to hire.

A hiring manager has to improve their team. A hiring manager has to achieve goals (or KPIs). The teams they are hiring have to achieve their goals. A candidate should be compatible with not only one team but with the whole company because they may end up in another team in a year or so (within the company: products evolve, teams being disassembled and rearranged, etc.).

A hiring manager has to consider all these factors before making a decision.

To check all that, there are (costly) procedures aimed to weed out candidates that most likely miss most of the criteria. Also, these procedures involve a lot of high-paid employees to form the most objective conclusion on a candidate (as humanly possible.)

So, hiring a candidate is not only a lengthy process but also very expensive.

* It takes 3 to 6 months for any candidate to start performing at their peak abilities in any new company. So, add these months of investing in a candidate to the costs.
* Now imagine there was a mistake in hiring a candidate, and a fresh employee leaves a company in 3 to 6 months. Add
* the average 3 months of interviewing wasted on hiring that candidate AND add another half a year on interviewing and hiring another, and you will end up with an astonishing amount of money a company already spent.

Companies probably have that covered, but remember — a hiring manager has to deliver products with their teams, and if they cannot achieve that, they can't meet their goals, their personal careers stagnate, and they start losing their own personal money/gains.

It is worth mentioning that all the people that will interview you — engineers, designers, managers — have their own job. Not only do they spend paid hours interviewing candidates, but they are also doing it instead of what they were hired to do in the first place (engineering, designing, managing).

From a company's perspective, hiring a person consists of these steps:

* Interviewing (paying recruiters and all the interviewers)
* Team compatibility check (extra set of interviews with teams that follows the initial set of interviews)
* Training new employees (usually up to 3 months)
* A few months before a new employee learns the ropes, understands the processes, and starts delivering
* Firing
* Interviewing again

Mature companies can keep track record of how successful each hiring manager was in improving the team. Given the time, it is easy to see if their hires performed well and long enough. Any personal success might affect the salary or bonuses of each manager. So, it is also in their best interest to ensure the company they are rehiring for prospers. On so many levels.

As you can see, it is easier for them to reject a candidate if doubtful, even the slightest.

But their goal is to hire as many best candidates as possible.

They have to balance both.

The cost of a hiring mistake

In mature companies, a team will interview candidates on the final day and submit their feedback to a hiring manager. Here's why it matters.

The product designer plays an integral role in everything: learn from managers on business goals, be a protector of users' interests, collaborate with developers and UX researchers, deliver a polished end result and feel the chill of running A/B tests. Yes, we have put it on ourselves and have to bear all that. It comes with the role.

That is one of the reasons you will be interviewed not only by other designers but by all sorts of researchers, managers, engineers, architects, and so on.


On the final day of the interviews, 4 to 10 people of different roles will interview you.

The only thing they want to know is if they will be comfortable working with you.

* Can they understand what you are talking about?
* How would you behave in such and such situation (that probably scarred them in the past)?
* Can they learn from you?
* Are you an okay person?
* Do they trust you?
* Do you speak the same language? (And I don't mean English or whatever, I mean — the same language.)


You will do your presentation and then start interviewing with them one by one. Each of them will ask you questions that are relevant to working with them. This is why it is so hard or nearly impossible to cheat your way in: if you are honest and open-minded and have had the experience you talked about in your resume and during your presentation, it will show up.

It is also useful to keep in mind that non-design people should be able to understand what you are talking about during your presentation and the value of your individual contribution. Some of the designers think that they should practice with other designers, while in reality, most of the product work happens with the team.

They want to see if they can collaborate with you. That is one of the reasons why most recommendations suggest you emphasize not only your individual contribution but also share your XFN examples.

Hiring party team's perspective

Here's what happens behind the scenes after you manage to navigate through all stages of interviews.

This is uncharted territory, and every company has different views on this process, so we must extrapolate and generalize here heavily. Take this with a grain of salt.

## Interviewers are writing feedback

After you have finished with interviews, each interviewer will submit their feedback to some form of applicant tracking system (usually, it is specialized software, however, in some companies, they will just email their thoughts to a hiring manager or an HR person that is responsible for a candidate).

Since it is done by busy humans that have their own stuff to take care of, it is only natural to expect that it will take some time for them to write down the answers and thoughts about a candidate. It would be awesome if they had done it the same day, but it may not be the case: it might take more time.

After all, they have to be as objective as possible (which is hard), and they do realize that whatever they submit will affect the final decision about another person's career. And most of them have been there before as a candidate, and they know and still feel what it was like to be on the other side.

Side note. If you want to understand how it works, we highly recommend listening to a bunch of candidates talking for 30-45 minutes and writing your feedback to them. You will see how hard it is to do so in a timely manner, but the most important perk you can get from it is that you will see the mistakes candidates do when talking about their past experiences. If you will learn how to spot them, you will see your own mistakes clearly and will communicate much better in your interview.

## Subjective objectivity

Depending on a company's strategy and culture, the questions the interviewers will answer will try to reflect what traits a candidate shows (and how) that are relevant to a company's culture and/or situation.

For some companies, it is important that an employee would be ruthless and dynamic. Others will emphasize cooperation, some will lean towards tech prowess, and so on. There are no companies alike. More so, they change these requirements over time to adapt to changes both internal and external.

Now imagine you have, say, seven answers from different people on the same question about a candidate. You know these were seven different interviews, and you can examine the same trait from seven different angles/points of view.

Sure, all of them try to be objective, but they are subjective. But having read them all, you start seeing the more objective story.

## The (almost) final boss

It is not true for every company, but in some cases, there would be a senior manager that will read all the feedback after interviews, and that person will make a final decision whether to proceed with a candidate or reject them.

That person most likely has no stake in hiring and has never seen or interacted with the candidate in question. That helps to eliminate prejudices and biases.

This might seem unfair, but so far, it is one of the best solutions there is: that person knows they can trust their colleagues, and being unbiased, they care about a company as a whole, and being unbiased they can make a judgment in everyone's best interests (including the candidate).

## The true finals

In some cases, there are so-called hiring committees, bar raisers, and team matching interviews that might delay the first day of work for a few weeks or even months. But if the interviews were successful, here's where a candidate's major efforts are finished.
The time to actually accept the offer and start to work (and get paid) may be delayed by up to a month.

How to talk about my role, contribution, XFN (cross-functional)

My role, contribution

XFN examples

Presentum helps designers practice portfolio presentations with peers and connects them with hiring managers.

Prepare.

Practice with peers.

Get hired.