In Part 1 I covered defining the role, writing a job post, screening CVs, and the short phone interview. Now, let’s move to the next stages – face-to-face interviews, home exercises, and closing the process.

Home Exercise or Face-to-Face Interview  –  What Comes First?

There’s plenty of debate online about whether candidates should receive a home exercise, and if so, whether it should be given before or after the interview.

Some argue that home exercises scare candidates off or are too time-consuming. While I understand this perspective, I strongly recommend including a home exercise as part of your process. It’s your best tool to assess crucial qualities that are hard to uncover in an interview alone.

That said, the home exercise can indeed scare away candidates – so it should come only after the face-to-face interview, and should be designed to respect the candidate’s time (since they’re likely getting exercises from other companies as well). Time it properly within your process, and you’ll mitigate most concerns.

With that in mind, let’s drill down into the interview itself.

The Face-to-Face Interview

The main interview should be face-to-face, ideally in the office. However, if logistics make that difficult, a Zoom interview is acceptable. Just make sure the video is on – otherwise it’s too detached.

By now, you have a candidate who’s passed resume screening and the short phone interview. You’re already familiar with their background and motivations, and they know something about your company and the specific role.

Interview Goals:

The overall goal is clear: assess whether the candidate is a potential match. But let’s get more specific. Your goals are:

1. Understand the candidate’s approach to product management
2. Assess their communication skills and ability to express themselves (a huge part of the PM role)
3. Get to know them as a person – and whether you’d actually want to work with them
4. Market your company and the specific role
5. Fluency in English and the ability to express oneself verbally and in writing usually won’t change on the job – no matter how much you mentor someone. So it’s crucial to test these skills during the process.

During the interview, focus on verifying their ability to express themselves verbally. As for written communication, leave that for the home exercise.

Preparing for the Interview:

I strongly recommend inviting someone from the engineering team – someone with good people intuition – to join the interview.

Set the interview for one hour. I suggest dividing the time: you (the hiring manager) get about 60% of the time to ask your questions, your engineering partner gets 20 – 25%, and the rest is for the candidate to ask their own questions.

Plan your questions in advance, and focus on these three areas:

1. Business orientation and KPIs
2. The “why” and the “what” (test case that verifies the candidate knows how to approach features/priorities and find the value)
3. Data & AI

Tailor your questions based on whether you’re interviewing a junior or senior PM.

Questions to Ask

First:

Ask the candidate to describe their thought process as they answer questions. Many times, the thought process is more important than the answer itself.

Second:

Guide your engineering partner to focus their questions on day-to-day interactions with engineering (for example, conflicts of priorities and how the candidate would resolve them). Their goal: figure out if they want to work with this person.

Third:

I usually leave five minutes of my time to ask some personal questions, just to see the person behind the professional mask.

Based on the above, here are the types of questions I ask:

1. Business Orientation and KPIs:

Describe a business (could be your company or another business) and ask the candidate how they’d design a dashboard for the CEO to track the “health” of the business.

This question forces the candidate to demonstrate both business orientation and a data-driven mindset.

For senior PMs, expect them to identify key metrics and ask clarification questions, then translate that into relevant business KPIs.

For junior candidates, this might be a bit tough – so they may need guidance. What’s important is their thought process and potential to grow.

It might surprise you, but many non-junior candidates fail this question by focusing on only one aspect of the business and missing the big picture.

2. The “Why” and the “What”:

Pick a product from the candidate’s past jobs and ask about it – ideally, something they had full ownership over. If they don’t have such experience, or are too junior, come prepared with an imaginary product facing an important decision: which of three requested features to promote.

You want to see how they evaluate each feature and how much they dig to find the actual “pains” behind them (who requested them, and why? Is there a better solution that covers all three?).

A “medium” answer: the customer asked for it, they discussed with R&D and prioritized based on requests.

A “good” answer: they asked why the customer needed it, understood the pain, and built a solution around that.

A “great” answer: they ran a full discovery, gathered pain points from multiple customers, and designed a solution that catered to all of them – even if the customers each had a different solution in mind.

3. Data & AI:

Traditionally, this is where you’d test analytical skills. Today, in the age of AI, the bar is higher. Now, I ask several smaller questions and expect immediate answers. I ask questions in this spirit:

• Do you leverage AI for your day-to-day routines? Which tools, and how?
• Which routines have changed for you as AI evolved?
• What’s the biggest gain you get from AI?
• What key raw data points drive your product?
• Does your product or its infrastructure enrich raw data? If so – how?
• What main data aggregations do you use (for users/customers or internal stakeholders)?

After a round of these, you’ll know if the candidate truly “gets” data – or if they just use AI for basic research.

Personal Questions

Emphasize that there are no “right” or “wrong” answers here – you just want to know them better. I like to ask questions they’ve probably never been asked in other interviews, to break through automatic responses.

Examples:

• Are you a morning person or a night person? What time do you wake up if you don’t set an alarm?
• What’s your favorite movie?
• If you could travel anywhere, where would you go?
• What’s the best present you’ve ever received?

You get the idea.

The Interview Timeline

Here’s how a one-hour interview might look:

First 5 minutes: Getting acquainted.

Tell a bit about yourself, and ask the candidate to introduce themselves in two minutes.

Minutes 5 – 15: Business KPIs

Minutes 15 – 25: The “why” and the “what”

Minutes 25 – 35: Engineering partner’s questions

Minutes 35 – 45: Data & AI

Minutes 45 – 50: Personal questions

Minutes 50 – 60: The candidate’s questions (your opportunity to market the role, if you liked them)

The Home Exercise

The home exercise shouldn’t take more than four hours for an experienced PM and up to 8 – 10 hours for a junior.

Personally, I always ask for a PRD (Product Requirements Document) for a small feature – either one I worked on, or a feature recently released by a known company/app.

Regarding screen design and UX/UI: this is a constant debate among PMs. My view is that a product designer – not a PM – should handle screens and suggest sensible UX. So, until recently, I only asked for high-level wireframes.

However, with the rise of AI, we can (and should) raise the bar here. I now ask candidates to show specific screens, and while I don’t require a functional prototype, I expect good candidates to provide one (it’s easy to do with modern tools).

I make it clear in the exercise that I don’t care about pixel-perfect UI – just the UX. What I’m evaluating is how comfortable the candidate is with AI, and how far they can take it in a limited time.

Candidates must also explain:

• Their choice of PRD template (they’re free to choose, but must explain why)
• The product decisions made in the spec

To avoid lengthy submissions, I emphasize that over-comprehensive specs won’t get extra points. On the contrary.

I also let them know what happens if they pass: they’ll present a spec review in front of people from R&D (and maybe other stakeholders), and they’ll need to do it in English (if that’s not the native language).

What are you looking for here?

• Can they provide a good solution to the pain described?
• Can they express themselves in English, clearly and concisely?
• Do they understand what’s important, and what’s not?
• Do they “think” agile (how do they break down features into user stories)?
• Do they leverage AI to expedite their work?
• Do they consider data & analytics (e.g., including user stories about tracking/analytics)?

The Spec Review

The candidate presents their spec to a live audience: engineers, PMs, and any other internal stakeholders who might work with them.

You should pay attention to how the candidate:

• Runs the meeting and maintains control
• Keeps calm and cool, even when challenged
• Manages time and handle interruptions
• Demonstrates she/he came prepared, can defend their decisions, and acknowledge good feedback
• Proves they can express themselves well enough in English to be customer-facing

The review doesn’t have to be perfect, just good enough to give you confidence that, with some mentoring, this candidate could become great.

The Rest of the Process

If the candidate passed the spec review, there’s a good chance you’ve found the one – unless you still have unresolved concerns or (even better) you have more than one strong candidate at this stage.

Before you’re done, they’ll need to meet HR (for personality evaluation and salary negotiation) and possibly a C-level or executive (depending on company policy). As always, protect the candidate’s time – don’t make them meet unnecessary people.

If you still have concerns, ask HR or someone you trust to give a second opinion or dig deeper. Sometimes they’ll reassure you, sometimes they’ll flag a real issue.

References

This is one phase you must not skip. I expect candidates to provide at least two references – people who worked closely with them, ideally including a manager.

If a senior candidate can’t provide a manager as a reference, understand why – sometimes it’s reasonable, sometimes it’s a red flag. Candidates who take too long to produce references are also a red flag.

Call all references (unless you get more than three, which is always a good sign). Ask:

• How long did you work together?
• What was your relationship (manager, peer, etc.)?
• What was it like working with the candidate?
• Examples of when the candidate struggled – how did they handle it?
• What was their forte? Where did they have more trouble?
• How are they as a person? Did they work well with the team?
• Any team conflicts? Why?
• Would you re-hire them?

You’ll hear it in their voice if the reference genuinely likes the candidate or is just being polite.

If you still have concerns after references, don’t hire.

Summary

Hiring a product manager is a complex, multi-step process – but with the right structure and clarity, you can consistently find and hire the right person for your team. Focus on communication, value orientation, data skills, and the ability to leverage AI. Use a clear, rigorous process, and don’t skip the steps that let you see how candidates think and interact in real-life scenarios. Trust your process, and don’t ignore lingering concerns at the end. If you do it right, you won’t just fill a role – you’ll set your team up for long-term success.

If you found this post useful, don’t forget to ‘like’ it. Also feel free to share it with your friends/peers using the social icons below.