Why pre-screen information architects before the portfolio review
The most common failure in this discipline is a structure that mirrors the organisation rather than how users think about the subject. It looks logical in a diagram, passes internal review because everyone recognises their department, and then people cannot find anything. Architects who avoid it test the structure with users before anything is built. A short screen asks what card sorting or tree testing changed, which is the question that separates the two.
What actually matters when screening Information Architect candidates
- 01
Portfolio
Review sitemaps, taxonomies, content models and navigation redesigns they personally owned; ask for site scale, page or SKU counts, and the search or findability metrics that moved.
- 02
Craft and rationale
Probe method depth: card sorting (open and closed), tree testing in Optimal Workshop, faceted metadata schemes, controlled vocabularies, and how they chose labels over stakeholder jargon.
- 03
Feedback and iteration
Test how they handled a failed tree test or analytics showing users bypassing navigation; look for rework cycles and what the second structure changed.
- 04
Working with the brief
Assess how they work with content strategists, SEO, and engineering on CMS constraints; ask about migration mapping, redirect plans, and governance handed to content owners.
Pre-screening questions to ask Information Architect candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Structures people navigate
3 questions01How extensive is your experience in information architecture?
Listen forProjects with scale in pages or content volume, and whether they saw the structure through to implementation.
Experience described by tools used, or structures designed but never built.
02Can you describe the most complex set of content you have had to organise?
Listen forReal complexity such as overlapping categories or multiple audiences, with how the ambiguity was resolved.
Complexity described as volume, or ambiguous content forced into a single hierarchy.
03Could you describe a time when your work made a significant difference to a project?
Listen forA measurable improvement such as findability or task completion, with a baseline before the change.
Impact claimed with no measurement, or improvement described only as a cleaner structure.
Research not org chart
3 questions04Can you discuss your experience with user research and how it informs your work?
Listen forResearch they ran themselves, with a category name or grouping that came from users rather than internally.
Structure derived from stakeholder input, or research read second hand from someone else's report.
05How have you used customer journey maps in previous roles?
Listen forJourneys built from observed behaviour with a structural decision that changed as a result.
Journey maps produced as artefacts with no design consequence, or built entirely from assumption.
06Can you explain the concept of metadata and how you have used it in your work?
Listen forA controlled vocabulary defined and maintained, with a plan for who applies it as content grows.
Tagging left to content authors with no vocabulary, or metadata designed with no maintenance plan.
Tested before build
4 questions07How do you ensure a website or product is easy to navigate?
Listen forStructure validated by card sorting or tree testing before build, with what the testing changed.
Navigation validated by internal review only, or structure confirmed rather than tested.
08How have you used testing to improve user experience?
Listen forTests designed around a specific navigation question with enough traffic to conclude anything.
Tests run on tiny samples, or results claimed from a change with several variables at once.
09How do you improve an existing information architecture without a complete rebuild?
Listen forWorst paths identified from analytics and search logs, with targeted changes rather than a full restructure.
Full restructure proposed for every problem, or no ability to improve incrementally.
10Can you talk about your experience with wireframing and prototyping?
Listen forPrototypes used to test navigation specifically, at the lowest fidelity that answers the question.
High-fidelity prototypes built to test structure, or wireframes produced as documentation only.
Improving in place
2 questions11Can you provide an example of balancing business needs with user needs?
Listen forA real conflict such as promoting content users do not want, resolved with evidence rather than by seniority.
Business requests implemented without challenge, or user needs asserted with no evidence behind them.
12Have you handled conflicts or disagreements about architectural decisions?
Listen forDisagreements settled with user evidence, including a case where they were wrong and changed position.
Conflicts resolved by seniority, or no occasion where testing contradicted their own design.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Portfolio
35%5Walks through a large-scale restructure with before and after findability data, showing their own sitemaps, content models and labelling systems.
Craft and rationale
25%5Explains why a taxonomy was polyhierarchical or flat, cites card sort agreement scores, and defends label choices with user language evidence.
Feedback and iteration
25%5Describes a structure that tested badly, names the specific task success rate, and shows the revised model plus retest results.
Working with the brief
15%5Negotiates CMS and URL constraints early, delivers migration and redirect maps, and leaves a governance model owners can maintain.
A structure that mirrors the organisation passes internal review and defeats users. A one-way video screen asks what testing changed.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async, with a portfolio. Enough to establish what they structured, test their research practice, and hear what testing changed.
What should the portfolio show alongside the screen?
The reasoning rather than the sitemap. A structure diagram tells you little; the research that produced it and the testing that changed it are what indicate whether the architect works from evidence.
Evaluating answers
What is the strongest signal when screening this role?
Something testing changed. Architects who test have had a structure that seemed obvious fail with users. Anyone whose designs were confirmed by testing has either not tested or is not saying.
How do I judge whether they can work incrementally?
Ask how they improve an existing structure without rebuilding it. Real answers target the worst navigation paths first. Anyone who proposes a full restructure for every problem is expensive to employ.
























