As many of you know, I’ve done a lot of mentoring — probably with north of eighty people at this point. Though I am no longer mentoring, something I’ve noticed is that almost all of the things I tell my mentees are a serious surprise to them.
By this, I mean that, without fail, they all remark that they’ve never heard my advice before. Real quotes abound, like: “no one has ever told me the truth about my work, not even the other mentors I’ve talked to,” “I’ve never heard this about the industry before,” “I now have a better understanding of how design works at companies, my mentors didn’t talk about this,” “I didn’t know that interviewing worked like that, my bootcamp mentors haven’t mentioned this,” “all the other mentors said my work was fine,” and so on.
Because my advice comes as such a surprise, the majority of those I’ve mentored choose to dispute what I say right on the call — they try to argue with me, prove me wrong, and get me to change my mind. I wouldn’t recommend this approach with your mentor — if you want them to keep doing you this favor (a previous article I wrote explaining how to be respectful of your mentor), I would recommend practicing gratitude and emotional restraint when you feel like being combative. Personally, when this kind of behavior reveals itself, I no longer maintain these relationships. I’m certain many mentors can relate.
Putting respect for the person doing you a solid to one side, I’m not alone in hearing complete surprise from mentees. Chatting with other experienced designers who do — or have done — mentoring, I notice a few things: the nature of our feedback is nearly identical, mentees are always blindsided by said feedback, and most of them become argumentative (see above).
What is of particular interest to me, however, is that mentees are surprised at all — frankly, I’m surprised that they’re surprised. This tells me that there are a dearth of mentors not saying things that need to be said — even when they professionally advise as part of design programs (e.g., bootcamps, universities, etc.). This is likely part of what explains another common thing I hear from pre-/early career designers: “there’s so much conflicting information out there.” Many mentees feel confused and frustrated by the amount of confusing information out there — by the amount of “your work is great”s they receive from mentors, compared against the little interest they receive from prospective customers.
There could be many reasons why this occurs, however. For instance, it could be that mentors know most mentees easily become irate, argumentative, and ungrateful, and so mentors simply don’t feel comfortable telling the truth, as a result. Alternatively, it could be that many people attracted to becoming mentors just aren’t very experienced, themselves, and so they don’t have much actionable feedback or useful information to give. Perhaps there are other explanations — it’s hard to speculate.
Nonetheless, it is very concerning to me that there are so many mentees walking out of sessions with misconceptions and distortions about their work — and their chances on the market. In this opinion, I wanted to help discerning mentees figure out how to evaluate their mentors before committing to sessions (or subsequent ones).
This opinion also assumes that the reader is a designer that already knows what they want: to work at tech companies (e.g., Medium, Substack, Notion, Twitter, TikTok, Instagram, Webflow, etc.). If this is you, consider the traits below that will work for you.
1. Your mentor works in tech
If you want to work in tech, ensuring that your mentor does, too, is your first order of business, and is absolutely mission critical. You need someone who competes on the same market you are targeting — if they don’t, they will not be able to advise you. This is why your bootcamp mentors and university professors can’t help you, and you’re surprised when people who work in tech disabuse you of the misconceptions these individuals proliferate — the majority of them are not competing for the jobs you’re competing for.
The advisors in your design program, generally speaking, compete for jobs in education — you are competing for jobs in tech. These individuals don’t know how to compete on the market you’re targeting, and it’s because they don’t have to know. As a result, it is very easy for them to believe they know what it takes to compete on this market — but those beliefs will never be checked against reality, because they’ll never experience it, themselves.
Equally, there are many mentors who believe they work in tech, but actually just work at companies that sell technology services in some other capacity. There are many ways to work on software, but still not work in tech (a previous article wherein I explain the difference between working on software, and working in tech, specifically). Here are some examples of companies (and organizations more generally) that could have you working on software services, but that are, nonetheless, not tech companies:
- Agencies (e.g., you might work on websites advertising services for companies, or simple checkout experiences for e-commerce companies, etc.),
- Government (e.g., a local government where you might be working on informational websites about resident benefits, often with simple account management, etc.),
- IT companies (e.g., simple ticketing software for enterprise customers, making simple package managers with skins for a company’s employees, etc.),
- Brick-and-mortar turned digital (e.g., banks, insurance companies, airline companies, rental companies, moving companies, old payment processing companies, hardware companies like IBM and Intel, etc.),
- E-commerce companies (e.g., retail of physical products that are sold online on a simple e-commerce platform they maintain for their brand, etc.),
- Educational institutions (e.g., bootcamps or universities, etc.).
Again, there’s nothing wrong with these companies or organizations, but the listed examples above will not have designers working on products. As I’ve mentioned in previous articles, for example, websites are not products. They are online brochures. You don’t want to compete for jobs where you make online brochures — you most likely want to work at companies like Twitter, Notion, Medium, Instagram, Instacart, Slack, Google, Apple, Uber, Lyft, Snap, Spotify, Discord, etc. These designers do not touch their company’s marketing material, and they don’t make simple checkout experiences. They make chat products, text editors, music streaming services, ridesharing products, image sharing apps, etc. These are complicated experiences that take in a ton of user inputs.
By contrast, websites don’t do any of this. Websites exist to allow people to consume information and either take a simple action (purchase, download, subscribe, etc., to something), or nothing at all. They mostly display what developers call static content, where products leverage user data to render dynamic content. In other words, websites are brochures that generate leads for businesses and/or provide information — this is all to incentivize some top of funnel action on the part of the user, to get them into the product, itself (usually). This is not product work.
What’s more, if you want to successfully get jobs at tech companies, you need to know how they interview candidates, what their expectations are, and what your competition is. People who work at the companies and organizations above will not usually know how to interview at tech companies, nor how to attract tech companies as customers, as those more traditional organizations listed above tend to have their own beliefs about what designers are (and what they do) — and those beliefs are not consistent with the ones that tech companies have.
For example, many people who work with more dated and/or simple software companies are accustomed to more dated work styles, such as having “pure UX” designers that pass gray box schematics off to “pure UI” designers. This is not going to be easy to do when working on a complex product, because the interactions on software like FigJam, Instagram Stories, Instagram Reels editor, TikTok, etc., are just too hard to enable this kind of ping pong between “UX designers” and “UI designers.” Product design is interesting in that, the more complicated it gets, the more it becomes inefficient to break roles up.
Tech companies don’t hire “UI designers.” They hire people who build good products, and know how to execute on them to a professional level in terms of craft, and then they hire people who work on the brand team (they usually refer to these as “visual designers,” etc.). Mentors accustomed to work styles where there are “UX designers” and “UI designers,” therefore, will unintentionally misinform prospective designers about the (lack of) importance of visual excellence in their work, for example. This will result in mentees applying to tech companies and getting no results, without realizing they are putting out work that is being crushed by the superior competition.
Another example is the nature of one’s case studies. People who work in more traditional workplaces listed above are not usually working on complex software, so they couldn’t advise on the kind of work mentees need in their portfolios (i.e., real software within products). They are likely to advise website redesigns (common in bootcamps and universities for this reason), or redesigning of successful apps, and other things that tech companies don’t care to see.
They will tend to advise you have stereotypical things like: personas, double diamond graphics, Google Forms research, site maps, walls of stickies and “maps,” and other “process” work, etc. These are things that recruiters at tech companies specifically ask candidates not to show (a previous article written about what your case study content, specifically, should include, and quotes from recruiters at companies like Meta and Apple requesting specifically to not to see “process”), as this is not interesting to interview panelists, does not help us evaluate you, and we don’t have this “process” internally.
Adding to this is that tech companies are results-based and, as such, are highly merit driven. It is extremely difficult (read: impossible) to “talk” one’s way into these jobs, and so mentors from traditional organizations may often mislead mentees into believing they need to over index into “networking” and begging for referrals (a previous article wherein I explain my thoughts on the efficacy of networking) when, in reality, they should be advising mentees to redo their portfolios, and focus on building software and visual excellence — with this being unequivocally the most optimal use of their time.
Lastly, tech companies also tend to have certain values, expectations, and styles of working that create culture shock in people who have never worked at them before. Tech companies do not work like how any of the bootcamps or universities claim — these programs do not prepare one to work at tech companies, but rather at more dated organizations. Mentees may onboard on to tech companies and be surprised at how little marketing bingo there is at tech companies, and that “process” work cannot be relied on as a crutch to appear to be getting results — people at tech companies make software, and it’s hard to fudge that. It’s hard work, and you will not be prepared in any way if you follow advice from those in traditional organizations. Expectations are frequently very, very high at tech companies — and for good reason (see: tech compensation).
However, if you are not looking to work at tech companies, and you want to be a web designer (i.e., mainly work on websites, etc.), product designers are not good matches for you. Ultimately, you have to decide what you want to do, — work on websites or products — and make your decisions from there.
2. Your mentor builds products, not websites
As mentioned above, the reader is probably looking to work at tech companies, — working on digital products — rather than at companies that build websites for other businesses. As a result, it’s best to consider mentors that work on digital products, particularly at tech companies.
When people mostly work on simple software like websites, they don’t know what it takes to work on complex software, like webapps or native apps. They are very unlikely to know how to prepare case studies that persuasively argue based on past work that tech companies (companies that build digital products) should hire them. Building websites (and other simple software) tends to result in work styles that are also very different to building products, so they wouldn’t know what it’s actually like working at a digital product company, or how to become more appealing to them.
These work styles tend to be dated and very different to the kinds seen within tech companies, which makes it hard for one to understand the expectations that tech companies have, and so it’s not a great idea to take the advice of individuals who have only worked at places that have had them working on websites (see list above).
3. Your mentor interviews — a lot
Whether you’re a pre-career designer looking to get into the industry, or one that’s early in your career and looking to get subsequent jobs, you need someone who interviews a lot. Ideally, someone who interviews multiple times a year at tech companies.
Tech companies interview in particular, but fairly consistent ways. If your mentor doesn’t interview often, or doesn’t work at tech companies, then they won’t be able to advise you well.
Your mentor should be very comfortable with whiteboarding and app critiques. They should frequently do well on these. They should be able to provide actionable tips on how to do these well, how to manage time, and the conversation. They should be able to help you practice an app critique or whiteboarding session with you on a call. They should be able to cite specific whiteboarding challenges from the tech companies they have interviewed with, and how they solved those.
Your mentor should be able to talk to you about how to make a case study slide deck, and how to present your work. They should be able to offer you feedback on how to make a portfolio site that is attractive, and the importance of craft as a differential advantage in the early parts of hiring pipelines.
They should have extensive experience being on the other side of hiring, too, — on interview panels at tech companies — and should be able to describe how those work. They should be able to explain how referrals, hiring pipelines, and hiring panels work and be able to advise you on all three of these topics.
4. Your mentor has good visual design
Many people believe that craft doesn’t matter in product design — this is probably true for people who work at more traditional companies (e.g., banks, old payment processors, ad agencies, etc.). But this is not true in tech. If you want to work in tech, you’re going to need to compete — hard.
At tech companies, compensation is higher for a reason: you are expected to produce quality work in all ways — product strategy, and execution to a high level of craft. There’s usually only one designer per feature and problem area, so your output is expected to be high. There are no visual designers waiting on your beck-and-call to polish your work — that’s all you. You are expected to go through reviews of your work with your peers, and so the software you work on should be well reasoned, and should look professional. Your mentor should be able to understand the importance of good visual design and that, at tech companies, “UI designers” are not hired. They should be able to explain that visual excellence in the product is your responsibility — not someone else’s.
Your mentor’s work should reflect this. They should be good at making software, and good at making it look professional. It’s going to be difficult for you to evaluate visual excellence, as someone who doesn’t have it, but you should look for designers who have unusual visual voices.
By contrast, you might want to avoid designers with portfolios that look generic. It indicates that they are unlikely to have much visual skill, and so they won’t be able to spot the weaknesses in your visual work. They are likely to tell you that your work “looks good” or is “fine.” They likely sincerely believe that.
They should be able to see the problems in your visual work, and explain how to get better in the most efficient way possible.
5. Your mentor builds a lot of software
Your mentor should make software for a living — as stated, this should not include websites, but digital services, and specifically at tech companies. They should have a lot of experience making software and working on software teams. They should have worked on software teams for some time now, and have been around the block with the production of software.
They should be able to tell you how product teams work at tech companies. They should be able to explain what a PRD (or spec, or brief, etc.) is, how research is used in most tech companies, how quarterly/half planning works, how roadmaps work, what product strategies are, and how to get impact on products. They should be able to explain how work gets picked up at tech companies, and what it’s like to lead a product from end to end. They should be able to explain where ideas for products and features come from. They should be able to explain the role of research at their company (if any), and companies more generally.
They should have experience working with design systems at companies, and should be able to tell you how important it is that you know much about Figma and design systems. They should be able to explain the importance of discovering edge cases while designing a feature, and what it’s like to build features in a team on a larger product. They should be able to explain how promotions work (especially at bigger companies), and how to deal with social situations that might come up at work.
They should be able to tell you what is going to make your portfolio attractive to recruiters and hiring managers. They should be able to explain what needs to be in your portfolio. They should be able to advise on what should be in your slide deck and how to explain the software you’ve worked on.
They should also be able to help you reason about software you want to make — when you’re building your own, they should be able to look at your software’s premise and its execution to tell you where there are problems. They should be able to break down your software into attendant parts and come up with optimal solutions. They should be able to tell you if the software you’re proposing makes any sense in the first place. They should be experienced in making product strategies, and should be directly involved in (or even leading) quarterly or half planning at their company.
In other words, they should be very experienced with working on software teams and building software — whether on small teams, or large ones. They should be able to advise on what the differences are between tech companies and other kinds of companies, and help you disambiguate what steps you could take in your career based on your goals in order to most quickly and optimally achieve your goals.
6. Your mentor is very technical
Your mentor should be experienced with working on software teams, and so should be experienced with software, itself. Ideally, they have built software on their own, as well, and should be able to tell you technical information about how software works and what it can do.
They should be able to explain what native apps are, what web apps are, what’s the difference between these two things, and some of the quirks of designing for either case. They should be able to help dispel technical myths common among non-technical designers (e.g., the importance of “grids,” the overstating of design systems, how developers consume your designs, etc.), and help you remain focused on what really matters when building software.
They should be able to help push you in your designs, reminding you of untapped areas in software that you could consider in whatever product you’re building. They should be able to help you push your designs technically, and impart technical knowledge about how you can consider new areas in your product work.
They should be able to advise about how to use shortcuts in your work (e.g., ripping SVGs from the web using the inspect panel, using autolayout to make things more convenient when designing) — they should have answers to the most complicated Figma questions you can have, or might not even know you have. They should be able to help you build assets and animations that engineers can actually deploy in the codebase.
They should be able to explain how analytics work, what A/B testing is, and how these work in software. They should be able to explain how to prototype complex, canvas-based, and asynchronous interactions in software.
I’ll stop here, as I think this has gotten long enough. What I want to stress here is that, for people who want to be designers, — who want to design software at tech companies, — they’ll need someone who is also a designer who designs software at tech companies. If this is the situation you want to be in, you’ll need someone who is very experienced being you — who was and is you.
Your mentor should be able to have serious reflections on what, exactly, they’d do if they had to redo their career all over again — telling you what the highest value steps are to take to reduce the time it takes to get into the industry reliably, and how to use your time most optimally. The best way to do this is to find someone who’s made a lot of software, and who can tell you the truth about how this is done — not the academic, theoretical recounts of how software is made. You need actionable, clear steps to take to make your candidacy attractive to potential customers.
Here are examples of things that tell you that you need to consider other mentorship relationships:
- They give general advice,
- They don’t work at a tech company,
- They haven’t interviewed at any (or even a few) tech companies,
- They make websites, rather than digital products,
- They don’t have a good analysis about how the industry works,
- They advise you use checklist “design processes” in your case studies,
- They can’t tell you how to improve your visual design,
- They can’t reason about software you’re building,
- They’re never made a product strategy and don’t get involved in quarterly or half planning.
Most importantly, the best way to determine all of this is to look at the software they’ve built. This is a (generally) good proxy for how rigorous they are in their own work — you want someone who will be able to encourage you to have rigor, too. If they work at agencies, local governments, brick-and-mortar-gone-online companies, etc., and they mainly build websites or simple products, you should look for other mentors. They are not likely to be able to advise you in the way you need in order to be successful.
