Architecture interviews usually open with your portfolio and then test whether you can carry a building from brief to site. Expect questions on why this practice, stories about clients who said no and budgets that shrank, what-would-you-do scenarios on site and with contractors, and checks on site analysis, passive design, codes, drawing sets and working with structural and services engineers. Each question shows what the interviewer is listening for, a shape for your answer and a short answer you could say out loud. Swap in your own projects before the day, and keep your portfolio open while you practise.
Search all questions by round, difficulty and level, or save the ones you want to practise.
Spark: the short, real reason you started.
Path so far: school, internships or jobs, and what each taught you.
Next: the building types or project stages you want to grow in, linked to this practice.
"I got into architecture through drawing, honestly, but what kept me in it was my second-year studio, where we designed a small clinic and I realised every line changed how someone waited, moved or felt. Since graduating I've spent two years at a mid-sized practice, mostly on housing, where I went from doing presentation drawings to running the drawing set for a twelve-unit block. That taught me how much of a good building is decided in the details. Next, I want to work on community and education buildings, which is a big part of what you do, and I want more time on site, because I've only seen two of my projects built so far."
A long story about loving buildings as a child with nothing about the real work or where you want to go.
Brief and site: who it was for, what they needed, what the site gave you.
Big idea: the one decision that shaped the scheme, and why.
Your role: the drawings, details or decisions you personally owned.
Result: what got built or approved, and what you'd change.
"I'll take the primary school extension from my last job. The brief was four classrooms and a hall on a tight site next to the existing building, and the school didn't want to lose playground space. The idea that shaped everything was putting the hall on the ground floor with the classrooms above, so the hall could open onto the playground and the footprint stayed small. I was one of three on the team. The concept was my director's, but I developed the classroom layouts, ran the daylight checks, and drew most of the construction details for the roof and the glazing. It opened last year. If I did it again, I'd push harder for a covered outdoor area, which got cut for cost."
Saying 'I designed it' about a team project, or talking only about renders and never about how it was built.
One project: name it and say what you noticed, in design terms.
The link: how it connects to your interests or experience.
What you'd add: the skill you bring to that kind of work.
"I went through your projects page and read a couple of the write-ups, and the one I kept coming back to was the library conversion. I liked that you kept the old structure visible instead of hiding it, and the way the new reading room steps down to meet the street felt generous without shouting. That's the kind of reuse work I want to do more of. In my last role I surveyed and drew two existing buildings for refurbishment, so I'm comfortable with the messy part, where the drawings don't match what's really there. I'd like to bring that care to projects like yours and learn from how your team handles the heritage side."
Praise that could apply to any practice, or naming a project you clearly haven't looked at.
What helps: the kind of feedback and ownership that brings out your best.
Evidence: a moment when that happened.
Your part: what you contribute to that culture yourself.
"I do my best work in a studio where people pin work up early and often, even when it's rough, and where critique is about the design, not the person. At my last practice we had a short weekly pin-up across all projects, and seeing how others solved problems taught me more than any course. I also like having clear ownership of something, even a small part of the drawing set, because I care more when it's mine. And I try to give back to that culture: I'm happy to review a colleague's sheets or show a junior how I set up a detail. What I find hard is a place where work only gets seen at the deadline."
Describing only perks, or asking for total freedom with no interest in review.
Situation: the project and what the client turned down.
Real reason: what you learned by asking, not assuming.
Response: how you revised, and what you held on to.
Outcome: where it landed and what you took from it.
"On a family house, I proposed an open ground floor with a double-height living space, and the client rejected it in the first meeting. My first reaction was to defend it, but I asked what bothered them instead. It turned out they worked from home and were worried about noise and heating a tall room, which the render hadn't answered at all. So I went back with a version that kept the double-height part only over the dining area, added a separate study with a door, and showed a simple section of how the heating would work. They agreed to that in the next meeting. What I learned is that a rejection is usually a question the drawings didn't answer."
Describing the client as someone who didn't understand good design.
Pressure: how big the gap was and when it appeared.
Priorities: how you decided what was essential with the client.
Cuts: what went and why that was acceptable.
Result: the building that came out, and what you'd do earlier next time.
"On a community hall, the cost plan at the end of developed design came in well above the budget. With the cost consultant I went through the big items, and we agreed with the client on what the building was really for, which was one great main room with good daylight. So we kept the roof lights and the timber roof structure over the hall, because that was the space people would remember. We let go of a curved entrance wall, simplified the cladding to one material instead of two, and cut a basement store by moving storage into the roof void. It came back within budget and the main room is still the best part. Next time I'd ask for a cost check at concept stage, not wait."
Cutting a bit from everything with no view on what the building is for.
Understand: what they want and why now.
Impact: the knock-on effect on drawings, consultants, approvals, cost and programme.
Decision: put the options and impact in writing and let the client choose.
Record: agree any extra fee or time before redrawing.
"First I'd find out what's driving it, because sometimes a smaller change solves the real problem. Then I'd work out what the change touches: which drawings, whether the structural and services engineers need to redesign, whether it affects the approval we already have, and what it does to cost and the programme. I'd bring that back quickly, ideally with two options, such as the full change or a lighter version, each with its impact. I'd put it in writing and ask the client to confirm the one they want. If it's outside our agreed scope, I'd flag the extra fee to my director before we start. I wouldn't refuse the change, but I wouldn't quietly absorb it either."
Starting to redraw immediately without telling anyone the cost or time impact.
Diagnose: compare the bids with the cost plan item by item to find where the gap is.
Options: value engineering, negotiation with the preferred bidder, re-scoping, phasing or re-tendering.
Client decision: present options with their effect on quality, time and risk.
Learn: understand why the estimate missed so it doesn't repeat.
"First, I wouldn't panic or start cutting. I'd sit down with the cost consultant and compare the bids against the cost plan line by line. Usually the gap sits in a few places, maybe market prices have moved, or bidders have priced risk into something they found unclear in our documents. Then I'd put options to the client: a list of value engineering items with what each one costs in quality, clarifying the unclear items so bidders can sharpen their price, negotiating with the preferred bidder, reducing or phasing the scope, or re-tendering. Each option has a time cost, so I'd be honest about that. The client decides. Afterwards, I'd want to understand why the estimate was out, so we get it right next time."
Quietly downgrading the specification without the client knowing, or blaming the cost consultant.
Pause: don't act on either instruction yet.
Authority: check who the agreed decision-maker is in the appointment.
Bring together: set out both options with their impact for that person.
Record: confirm the decision in writing to both.
"I'd hold off on changing anything, because acting on one instruction just moves the conflict onto the drawings. I'd check who our appointment names as the client's representative, the person who has the authority to sign off decisions. Then I'd set out both options in a short note, with what each does to cost, programme and the design, and ask for a quick meeting with both people and that representative. Often the two aren't really disagreeing; one's worried about maintenance and the other about looks, and a third option solves both. Whatever is decided, I'd confirm it in writing to everyone so it doesn't reopen later."
Going with whoever is more senior or louder without confirming their authority.
The error: what was wrong, plainly.
How it surfaced: who noticed and when.
Fix: the immediate action on site and with the team.
Prevention: the checking habit you changed afterwards.
"On an apartment project, I updated a window size on the elevations after a client change but missed the window schedule, so the two didn't match. The contractor's window supplier raised a query before ordering, which was lucky. I checked, told my project architect straight away that it was my miss, and issued a corrected schedule with a revision note the same afternoon, so nothing was made to the wrong size. Afterwards I looked at why it happened. The schedule was a separate sheet I updated by hand. I moved it to be generated from the model, and I started a simple rule of checking plans, elevations and schedules together before any issue. I haven't had a mismatch like that since."
Blaming the contractor for not spotting it, or claiming you have never made a drawing error.
Listen: understand exactly what can't be done and why.
Look: check the detail on site or with the trade if you can.
Solve: propose a revision that keeps the performance and intent.
Issue formally: answer the query in writing with a revised detail.
"I'd take it seriously, because site teams often spot things we miss. I'd ask them to raise it as a formal query and, if possible, go and look with the person doing the work. Say it's a window sill where my drawing needs the membrane to lap under a bracket that's already fixed. I'd work with them on a sequence or a slightly different detail that still keeps water out and keeps the look we agreed. If it affects fire or structure, I'd check with the engineer first. Then I'd issue the revised detail with a clear revision note and answer the query in writing, so everyone builds from the same drawing. Sometimes the answer is that it can be built, just in a different order."
Insisting the detail is fine without looking, or agreeing a change verbally on site with no written revision.
Contents: site plan, plans, sections, elevations, details, schedules, general notes.
Structure: clear numbering, grids and levels, cross-references between sheets.
Control: revision clouds, revision notes and a drawing register.
Consistency: one source for repeated information and a check before every issue.
"A good set lets a contractor build without having to guess. It has the site plan, general arrangement plans, sections and elevations, larger-scale details for junctions like roofs, windows and thresholds, and schedules for doors, windows and finishes. Everything sits on the same grid and levels, and each detail is referenced from the plan or section it belongs to, so people can find it. Every revision is clouded, noted and dated, and a drawing register shows the current version of each sheet. For consistency, I try to keep repeated information in one place, like generating schedules from the model rather than typing them twice, and I check plans, sections and schedules together before anything is issued."
Listing drawing types with no mention of referencing, revisions or checking.
Weather: outer cladding sheds most rain; a drained, ventilated cavity and a membrane handle the rest.
Heat: continuous insulation, with thermal bridges at junctions dealt with.
Air and vapour: an airtight line, and vapour control on the side the moisture comes from, which depends on the climate.
Structure and lining: the frame or wall that carries loads, and the inner finish.
"Taking a common rainscreen wall, from outside: the cladding sheds most of the rain. Behind it is a ventilated cavity, so any water that gets through drains away and the wall can dry. Then the insulation, ideally running continuously outside the structure so floors and columns don't break it, with a breathable membrane that stops wind and water but lets vapour out. Then the structure, the frame or masonry that carries the loads. On the inside there's an airtight layer. In a cold climate the vapour control usually sits on the warm, inner side of the insulation, so moist indoor air can't reach cold layers and condense. In a hot, humid climate with air conditioning, the moist side is outside, so that can flip, and I'd avoid a vapour-tight inner layer and confirm it with a condensation check. Then the inner lining. The hard part is keeping those lines continuous at windows, floors and the roof."
Listing layers with no idea what each one is for, or putting a vapour barrier in the same place for every climate without checking.
Drawings: where things go, how big, how they're arranged and how they meet.
Specification: what they're made of, the quality, standards, workmanship and testing.
Why it matters: saying the same thing twice invites conflicts; the contract sets which document wins.
"The drawings show the where and the how much: the location, size and arrangement of things and how they meet at junctions. The specification describes the what and the how well: which materials and products, the quality and performance they need, the standards they meet, how they're installed and tested. So a drawing might label a wall as a particular wall type, and the specification says exactly what that wall type is made of and how it's built. It matters because if you write the same information in both places, sooner or later one gets updated and the other doesn't, and the contractor prices whichever is cheaper. Keeping each piece of information in one place, with clear references between them, avoids that."
Saying the specification is just a list of brands, or that it doesn't matter if both documents repeat each other.
Clash: what the engineer needed and what it did to the design.
Understanding: what you learned about why they needed it.
Options: the alternatives you worked out together.
Outcome: the agreed answer and how it was recorded.
"On an office fit-out I'd designed a clean exposed ceiling, and when the services engineer's model came in, the main ducts ran right across the middle of the room at a low level. My first instinct was to push back, but I sat down with the engineer and learned the duct sizes were driven by the fresh air rates and the route by where the plant sat. We tested a few options and settled on moving the main duct run to the corridor edge, where I could box it into a bulkhead, and using smaller branches into the room. I lost a little ceiling height at the edge, which we used for lighting. We recorded it in the coordination log and both updated our models."
Talking about engineers as people who ruin designs.
Set-up: an agreed execution plan, shared origin, naming and level of detail per stage.
Federate: each discipline owns its model; they're combined regularly.
Clash detection: run checks, filter out noise, assign each real issue an owner.
Close out: track issues to resolution in coordination meetings and update the models.
"It starts before anyone models anything. We agree an execution plan: shared coordinates, naming, what level of detail each discipline models at each stage, and how often we exchange models. Each discipline keeps its own model, so I never move a beam myself; we combine them into a federated model on a regular cycle. Then we run clash detection, say ducts against beams or pipes through walls without openings. Most raw clashes are noise, so we filter them and group the real ones, and each gets an owner and a due date. We work through them in a coordination meeting and track them in an issue log until they're closed. The model is a tool; the meetings and ownership are what actually get things resolved."
Saying the software finds all the problems automatically, or editing another discipline's elements yourself.
Deadline: what was due and why it got tight.
Triage: what had to be perfect and what could be simpler.
Execution: how you split the work and checked it.
Lesson: what you plan differently now.
"On an approval submission for a housing scheme, the client changed the unit mix a week before the deadline, which affected every plan. I listed every drawing and document the submission required and marked which ones the reviewers would look at hardest, which were the site plan, the elevations facing the neighbours and the area schedule. Those got full attention. For the rest, we kept the presentation simple. I split the drawings with a colleague, and we checked each other's sheets against the checklist the evening before. It went in on time and was accepted as complete. Now I build the submission checklist on the first day of a stage, not the last week."
A story that is only about working all night, with no planning or prioritising.
Early: brief, feasibility and concept.
Develop: developed or schematic design, coordinated with engineers and costed, then approval.
Technical: construction drawings and specification, then tender.
Build and after: site stage, handover and feedback once it's in use.
"The names differ by country and contract, but the shape is similar. It starts with the brief and feasibility, where we test what the site can hold and what it might cost. Then concept design, where we agree the big idea with the client. Developed or schematic design firms that up with the engineers, with a cost plan, and often leads to the planning or permit application. Then the technical stage: construction drawings, details, schedules and the specification, which go out to tender so contractors can price. During construction we answer queries, visit site, review samples and, where we run the contract, certify progress and issue instructions. At handover there's a snag list and the as-built information, and ideally we go back after a year to learn how it's working."
Describing only design stages and saying nothing about tender, site or handover.
Finding: what you saw and why it mattered.
Check: how you confirmed it against the drawings and specification.
Action: how you raised it with the contractor and the client, formally.
Result: how it was fixed and recorded.
"During a site visit on a small apartment block, I noticed the insulation around a balcony connection had gaps, and in one place was missing where the slab passed through the wall. That would have created a cold bridge and a condensation risk. I photographed it, checked my detail to be sure the drawing was clear, and it was. I raised it with the site manager there and then, so no one would cover it up, and followed up in the written site visit report the same day. The contractor fixed it before the boarding went on and I checked the rest of the balconies on the next visit. I also added a note to inspect that detail on every floor."
Fixing it with a verbal chat and no written record, or telling the workers directly what to change without going through the contractor.
Process: ask for a formal substitution request with technical data and samples.
Test: compare fire performance, weathering, durability, warranty, appearance and fixing.
Consult: involve the client, and the engineers where structure or fire is affected.
Decide and record: accept, reject or accept with conditions, in writing.
"I wouldn't say yes or no on the spot. I'd ask for a formal substitution request through the contract, with the product data, test certificates, a warranty and a physical sample. Then I'd compare it with what we specified: fire performance above all on a facade, plus how it weathers, how it's fixed, whether it changes the wall build-up, and how it looks next to the sample the client approved. If structure or fire strategy is affected, the engineers and the fire consultant need to review it. Then I'd go to the client with a clear recommendation, because it's their building and they may want the saving. Whatever's decided, it goes in writing, with any conditions, before anything is ordered."
Approving it because it's cheaper, or rejecting it purely on looks without checking performance.
The crit: what was said about your scheme.
Your reaction: honest, including what you felt.
Change: what you did with it.
Takeaway: how you use feedback now.
"In my first year at the practice, I presented a scheme for a small café and my director said the plan looked good but the section showed I'd never thought about the light. It stung, because I'd spent days on the plan. But she was right. I'd put the kitchen on the sunny side and the seating in shade. I went back, flipped the arrangement, added a roof light over the counter, and brought three quick sections to the next review instead of one polished plan. That review went much better. What I took from it is to test ideas in section and in rough form early, before I get attached to a drawing."
Saying you've never had harsh feedback, or that the reviewer just had a different taste.
Physical: sun path, wind, topography, drainage, ground, trees, existing structures.
Context: neighbours, streets, views, noise, access, how people move past.
Rules: zoning and planning limits, setbacks, heights, easements, heritage.
Services: connections for water, drainage, power and access for construction.
"I start with a visit, at different times of day if I can, because drawings don't tell you about noise or how people actually walk past. Physically, I look at the sun path and where shadows fall, the prevailing wind, levels and drainage, existing trees, and anything the ground report says about soil. Then the context: the neighbours' windows, the street's height and materials, views worth keeping and ones to screen, and how people and vehicles get in. Then the rules: what the zoning or planning limits allow for use, height, setbacks and coverage, plus any easements or heritage limits. And the practical side, where the services connections are. Only then does sketching make sense, because the site usually suggests the first move."
Jumping straight to the building form, or treating site analysis as a sun diagram and nothing else.
Unpack the brief: users, activities, hours, room schedule, budget.
Read the site: the corner, the sun, noise, who walks past.
Options: two or three quick diagrams that relate spaces to site.
Choose and test: pick one against the brief and explain why.
"I'd start by questioning the brief. Who uses it: children after school, older readers during the day, groups in the evening? That tells me which spaces need to be separate and which can share. Then the site. A corner is a gift for a library because it can be visible from both streets, so I'd look at where the entrance is most welcoming, where the quiet reading area can get good daylight without glare, and which side is noisy. From there I'd sketch three quick diagrams, for example an open corner with the reading room above, or a courtyard plan. I'd test each against the room list, the budget and the site, pick one, and bring it to the client as a diagram before any polished drawing."
Describing a striking shape before saying anything about the people or the site.
Belief: one or two principles you actually use.
Evidence: a specific moment in a project where that principle decided something.
Openness: how it adapts to clients and contexts.
"I'd say my approach is to start from how people will use a space and from what the site gives, and to keep the building as simple as the problem allows. I'd rather put effort into light, proportion and a few good details than into shape for its own sake. You can see it in the house extension in my portfolio: the client wanted more space, but what they really lacked was light in the kitchen. So the extension is modest, and most of the design effort went into a long roof light and a deep window seat facing the garden. It's not a rigid style, though. On a school or a clinic, the same thinking leads somewhere quite different."
A vague line like 'form follows function' with no project to show what it means for you.
Core tools: the kind of software you use every day, and at which stages.
Depth: something concrete you can do with it, like setting up sheets and schedules.
By hand: when a sketch is still quicker or clearer.
Adapting: how fast you pick up a practice's own templates and standards.
"Day to day I work in model-based drawing software. For the last two years I've used it to take projects from developed design through to construction drawings, including setting up sheets, door and window schedules and the office's wall types. For early massing I use a quicker 3D modelling tool, and for visuals a rendering tool plus some image editing at the end. But I still sketch by hand at the start of nearly every project and on site, because a quick sketch over a print is the fastest way to test an idea with a colleague or explain a junction to a builder. I'm not attached to one package. Every practice has its own templates and standards, and I pick up a new tool quickly once I know what drawing it has to produce."
Listing every package you've opened once, or talking as if the software does the design for you.
Check: confirm the rule and how it applies, not from memory.
Explain: tell the client plainly why it doesn't comply and what the risk is.
Offer: find a compliant way to get the effect they want.
Hold: never issue a non-compliant design; escalate if needed.
"Say the client wants a feature stair that leaves the only escape route without the protection the rules need. First I'd check the actual requirement for our jurisdiction and building type, and if it's a grey area I'd ask the fire engineer or the approving authority. Then I'd explain to the client in plain terms: it won't get approved, and more importantly it puts people at risk. But I'd try to find a way to give them the open, connected feel they're after, for example keeping the feature stair open and adding a separate protected escape stair, or using a fire-engineered solution if one is allowed. What I wouldn't do is draw it their way and hope. I'd write the advice down and involve my director."
Agreeing to draw it anyway because the client is paying.
Understand: find out the actual concern, such as overlooking, daylight to neighbours or the street's scale.
Test options: step back the top floor, reshape the massing, or reduce floor-to-floor heights.
Client impact: show the area and cost effect of each option.
Negotiate: go back to the authority with evidence.
"I'd first ask for a meeting to understand what's really driving it. Is it the height on the street, overlooking the neighbours, or daylight to the houses behind? The answer changes the fix. Then I'd test options before accepting the loss of a whole floor: setting the top floor back from the street so it's less visible, moving area from the sensitive side to the other side, or trimming floor-to-floor heights if the services allow it. I'd show the client what each option does to their area and cost, because it's their viability at stake. Then I'd go back to the authority with drawings, views and daylight studies. If they still insist, the client decides whether to accept or challenge it."
Either cutting the floor straight away without testing options or treating the authority as the enemy.
Jurisdiction: which codes and which edition apply where the site is.
Classify: use or occupancy, building height and area, construction type.
Topics: fire and escape, accessibility, structure, energy, health and safety.
Confirm and record: a code analysis sheet, specialist input and early talks with the authority.
"I start with where the site is, because that decides which codes apply and which editions, plus any local amendments. Then I classify the building: what it's used for, how many people it holds, how tall and how big it is, and the type of construction. That classification drives most of the requirements. From there I work through the main topics, fire and means of escape, accessibility, structure, energy, and things like ventilation and sanitary provision, and write the key requirements onto a code analysis sheet that lives with the drawings. For anything unusual, a mixed-use building or a tall atrium, I'd bring in a fire engineer and talk to the approving authority early rather than find out at submission. Zoning or planning rules are separate, and I check those alongside."
Quoting specific numbers from memory as universal rules, or treating codes as something to check at the end.
Climate first: heating-led, cooling-led or both.
Form and orientation: compact form, long side facing the midday sun, careful glazing.
Envelope: insulation, airtightness, shading, thermal mass.
Air and light: cross and stack ventilation, daylight to cut lighting loads.
"I'd start with the climate, because the answer in a cold place is almost the opposite of a hot, humid one. Then the big moves: orientation and form. A compact shape loses less heat, and turning the long side toward the midday sun lets me control it with simple horizontal shading, while low east and west sun needs vertical fins or less glass. Next the envelope: good insulation, airtightness, and avoiding cold bridges. Thermal mass helps where days are hot and nights are cool. For cooling I'd use cross ventilation and stack effect through stairs or atriums. And good daylight reduces the lighting load. Only after that would I size the mechanical systems, which are then smaller."
Jumping straight to solar panels and efficient equipment without mentioning form, orientation or the envelope.
Definitions: operational is energy used to run the building; embodied is from making, moving, building, maintaining and disposing of materials.
Why it matters: as buildings run more efficiently, embodied carbon becomes a larger share of the total.
Levers: reuse existing buildings, use less material, pick lower-carbon materials, design for long life and disassembly.
Measure: whole-life assessment early, when choices are still open.
"Operational carbon comes from the energy a building uses while it runs: heating, cooling, lighting and equipment. Embodied carbon comes from the materials: extracting and making them, transporting them, building with them, replacing them over time and dealing with them at the end. As buildings get more efficient to run, the embodied part becomes a bigger share, and much of it is emitted before the building is even used, so you can't fix it later. For me that changes things early: asking whether we can reuse an existing building before demolishing, keeping the structure efficient with sensible spans, choosing lower-carbon options like timber or concrete with cement replacements where they suit, and designing so parts can be repaired or taken apart. I'd run a whole-life carbon assessment at concept stage, when those choices are still cheap to change."
Treating sustainability only as energy efficiency, or naming 'green' materials with no idea why they help.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your resume and notes are never stored on our servers. It stays out of screen share on every plan; only you can see it.