Start with the CV filter. \u201cReact, 3 years\u201d tells you something useful about an engineer. \u201cFigma, 3 years\u201d tells you almost nothing about a designer. Tools are the floor. Every mid-level designer on the market is fluent in Figma. What you actually want to know \u2014 how they think about users, how they handle constraints, whether they can defend a decision \u2014 none of that shows up on a CV.<\/p>\n\n\n\n
Then there\u2019s how you look at portfolios. If you review them in the same manner you would a GitHub repository, you will focus on the polished end screens and hire based on visual taste. That is the incorrect thing to grade. Visual refinement is essential for a mid-level designer. What distinguishes a good hire from one you regret is UX judgment, which does not reside in the finished mockup.<\/p>\n\n\n\n
The take-home reflex is the next trap. Coding challenges are normal in engineering hiring; a speculative unpaid design task isn\u2019t the equivalent. It filters out your best candidates. Experienced designers won\u2019t do free work for a hiring pipeline \u2014 the ones who agree are the ones you didn\u2019t want. If you need a work sample, pay for a short scoped exercise or, better, run a proper portfolio walkthrough.<\/p>\n\n\n\n
Skip the live whiteboard too. “Design this app right now” mostly measures how well someone performs under artificial pressure, which isn’t what you’re hiring for. Run a portfolio walkthrough instead \u2014 the candidate talks through a case study of their own choosing, you interrupt with real questions. You’ll learn more in 30 minutes than a whiteboard gives you in an hour.<\/p>\n\n\n\n
Also cut the number of rounds. Engineering pipelines often run four or five stages \u2014 recruiter screen, coding challenge, live technical, systems design, culture. Designers don\u2019t expect that shape, and by round three you\u2019re testing endurance, not fit. Three rounds is usually enough: portfolio walkthrough, a decision-focused deep-dive with the hiring manager, and one conversation with a stakeholder they\u2019d actually work with. Any more than that and your best candidates drop out before your offer clears legal.<\/p>\n\n\n\n
References work differently for designers too. For an engineer, another engineer\u2019s reference tells you most of what you need to know. For a designer, ask their previous PM or product lead \u2014 the person who saw the work actually land in production and can tell you whether the designer pushed back on bad requirements or just shipped whatever was in the ticket. Another designer\u2019s reference is useful, but less predictive. Designers who ship products are best rated by the people who shipped products with them.<\/p>\n\n\n\n
None of this is unique to Belarus. It shows up wherever teams import a dev-hiring playbook to a design role \u2014 which is why our UI\/UX designer recruitment<\/a> practice runs a different pipeline from our engineering side.<\/p>\n\n\n\n <\/p>\n\n\n\n You don\u2019t need to be a designer to review a portfolio well. You need to ask the right questions and know what a strong answer looks like.<\/p>\n\n\n\n The first thing to look for is structure. A strong case study reads: problem, constraints, process, decisions, outcome. If a portfolio is just final screens with a paragraph of description, that\u2019s a red flag. Not because the design is bad. Because you have no way to assess how they got there. Nielsen Norman Group<\/a> has been documenting what good UX case studies look like for two decades; if you want a mental template, that\u2019s where to build it.<\/p>\n\n\n\n Look at the messy middle too. Discarded directions, research notes, sketches, alternatives they considered and rejected. Evidence of thinking beats evidence of taste. A designer who can only show you the final answer either didn\u2019t do the work or doesn\u2019t know how to talk about it \u2014 either way it\u2019s a problem. The framework in the Interaction Design Foundation\u2019s materials<\/a> on evaluating design thinking is a solid starting point if you want a shared vocabulary with your team.<\/p>\n\n\n\n Ask what they actually did. Portfolios overrepresent team wins; the person in front of you may have owned the whole thing or may have polished someone else’s mockups, and you can’t tell from the case study. Both are legitimate roles \u2014 just be sure which one you’re hiring.<\/p>\n\n\n\n Weight business and product impact over aesthetics. \u201cThis redesign lifted checkout conversion 14%\u201d beats \u201cthis looks beautiful\u201d every time. If a designer can\u2019t tell you what problem the work solved and how they measured it, that\u2019s another signal.<\/p>\n\n\n\n A few red flags worth naming plainly. Portfolios made only of Dribbble<\/a> shots with no context. Portfolios made only of concept redesigns of famous apps \u2014 Spotify, Airbnb \u2014 because those have no real constraints, no stakeholder, no launch. Identical template case studies where every project follows the same structure and the same buzzwords. And a designer who can\u2019t explain why a particular decision was made (\u201cwe tried X first, but users didn\u2019t recognize the pattern, so we moved to Y\u201d).<\/p>\n\n\n\n Watch for the good signals too. Someone who reframes the brief before jumping to a solution thinks in problems. Someone who volunteers what didn’t work knows how to iterate. Someone who treats engineering handoff as a conversation, not a spec, knows how products actually ship. The mockups won’t tell you any of this \u2014 the way they talk about the mockups will.<\/p>\n\n\n\n One local note. Experienced Belarusian designers often publish their portfolios on Readymag<\/a> or Framer rather than PDF. A plain PDF isn\u2019t disqualifying. But a bare \u201ctext-left, image-right\u201d template is itself a signal \u2014 a designer\u2019s portfolio is a design artifact, and how they present their work tells you something about how they\u2019ll present product work internally.<\/p>\n\n\n\n Two things to fix before you look at any salary data.<\/p>\n\n\n\n First, this market operates in net USD per month. Not annual USD. Not Belarusian rubles. That\u2019s how offers get made, how counteroffers get compared, and how candidates talk about pay. If your recruiting spreadsheet compares annual gross totals across markets, you\u2019ll misprice every offer you make.<\/p>\n\n\n\n Second, ignore the Western aggregators. Glassdoor, ERI, SalaryExpert \u2014 their data on Belarusian UI\/UX roles is thin, contradictory, and in some cases visibly broken. Calibrate an offer against them and you’ll either come in low and lose the person or come in high for no reason.<\/p>\n\n\n\n As directional orientation, the local market for UI\/UX designers splits roughly into three bands in net USD\/month. Juniors with 0\u20132 years and a portfolio of student and small commercial work: around $800\u2013$1,500. Middles with 2\u20135 years, shipped product work, able to own a feature end-to-end: around $1,500\u2013$2,500. Seniors with 5+ years, able to own a full product area and defend decisions to stakeholders: $2,500\u2013$4,000 and up. Treat these as a starting point. Actual current figures move with the market and should be checked against live posted-vacancy data before you make an offer.<\/p>\n\n\n\n Two forces distort the bands. International remote competition sets the ceiling \u2014 the strongest Belarusian designers are being pitched by teams paying US or Western European rates for remote work, and that\u2019s the number you\u2019re really competing with, not the local median. And for seniors, if your offer isn\u2019t within reach of what they could get from a foreign employer, it will get counter-offered. Best to know that going in. Our IT salary research<\/a> tracks what strong candidates are actually being offered, market by market.<\/p>\n\n\n\n Titles are a trap too. A \u201cSenior UI\/UX Designer\u201d in Belarus doesn\u2019t necessarily map to a \u201cSenior Designer\u201d at a US product company. Local market titles tend to compress \u2014 a strong Middle in Belarus is often doing work a Western Senior does day-to-day, and someone with a Senior title on paper might be closer to a strong Middle. Anchor on scope of ownership and years of shipped work, not on the word on their LinkedIn. It\u2019s the same reason title-to-title dev band comparisons don\u2019t translate cleanly: the ladders are shaped differently.<\/p>\n\n\n\n Don’t budget off the offer number. Taxes, contributions, and \u2014 if you don’t have a Belarusian legal entity \u2014 the cost of running employment through someone who does all sit on top of it. The right payroll and EOR setup<\/a> shows you where those costs sit.<\/p>\n\n\n\n The contractor-versus-employee choice shifts that math too. Full-time employment via an EOR is more expensive upfront \u2014 fixed contributions, statutory benefits \u2014 but locks in the relationship and removes ongoing hiring risk. A contractor arrangement is cheaper per month and easier to end, but strong designers avoid it for anything longer than a few months. They want stability, and if you\u2019re not offering it, the person you actually wanted to hire will take a full-time role somewhere else.<\/p>\n\n\n\n Same shape as the dev pipeline. Different content at every stage.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n![\"\"](\"https:\/\/recruitment.by\/wp-content\/uploads\/2026\/08\/female-web-designer-office-with-laptop-1024x682.jpg\")
<\/figure>\n\n\n\nHow to actually review a design portfolio<\/strong><\/h3>\n\n\n\n
Salary: what it costs and where the real numbers are<\/strong><\/h3>\n\n\n\n
What to change in your pipeline<\/strong><\/h3>\n\n\n\n
JD<\/strong><\/td> Stack + years of experience<\/td> Product context, scope of ownership, maturity of the design function they\u2019re joining<\/strong><\/td><\/tr> Screen<\/strong><\/td> Keyword match + GitHub<\/td> Portfolio review + case-study questions<\/strong><\/td><\/tr> Assessment<\/strong><\/td> Unpaid take-home<\/td> Paid short exercise OR deep portfolio walkthrough<\/strong><\/td><\/tr> Interview<\/strong><\/td> Live technical<\/td> Case-study presentation with follow-up questions<\/strong><\/td><\/tr> Offer<\/strong><\/td> Dev salary band<\/td> Design-specific benchmark in net USD\/month<\/strong><\/td><\/tr> Onboarding<\/strong><\/td> Repo, docs, standups<\/td> Access to product decisions, users, and stakeholders<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n