Why pre-screen computational designers before the portfolio review
A generative script can produce a thousand variations in an afternoon, and most of them cannot be made, cost too much, or solve nothing. The skill is defining constraints that mean something and choosing between outputs on evidence. Designers worth hiring have had their work fabricated. A short screen asks what they built from a script and what the constraints were.
What actually matters when screening Computational Designer candidates
- 01
Technical depth
Check fluency in Grasshopper, Rhino, Dynamo or Revit API plus scripting in Python or C#; ask about NURBS versus mesh workflows, solvers like Galapagos, Karamba or Ladybug.
- 02
Work that shipped
Probe built or fabricated outcomes: facade panelisation, structural rationalisation, CNC or robotic fabrication files, design option tooling adopted by other teams. Ask project names and scale.
- 03
Diagnosis under uncertainty
Test how they handle failing geometry, non-convergent optimisation, or clashing tolerances; ask about a definition that broke at scale and how they isolated the cause.
- 04
Working across the org
Assess collaboration with architects, structural engineers, contractors and fabricators; look for evidence of documenting tools, running internal training, or version control via Git or Speckle.
Pre-screening questions to ask Computational Designer 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.
Work that was built
3 questions01Can you describe your experience with parametric design tools?
Listen forParametric models built for real projects, with constraints derived from actual requirements.
Parametric work limited to form exploration, or models with no constraints that matter.
02Have you worked on complex modelling or data visualisation projects?
Listen forComplex geometry or data handled at real scale, with performance of the model considered.
Models that only work at small scale, or files nobody else can open and use.
03Do you have experience with digital fabrication and manufacturing?
Listen forOutput made physically, with tolerance, material and assembly constraints built into the model.
Designs never fabricated, or manufacturing constraints discovered after the design was fixed.
Real programming depth
4 questions04What is your experience with programming in a design context?
Listen forCode written and debugged by them, with structure that another person could pick up.
Scripts copied without understanding, or code that cannot be maintained by anyone else.
05Have you developed geometric or mathematical approaches for design problems?
Listen forGeometry understood well enough to build methods rather than apply existing components.
Geometry knowledge limited to available components, or mathematical claims that do not hold.
06How proficient are you with visual programming environments?
Listen forDefinitions built cleanly and documented, so others can understand and modify them later.
Sprawling definitions nobody else can follow, or no documentation of how they work.
07Do you have experience with structural or physical analysis in your work?
Listen forAnalysis used to inform form, with results checked by an engineer before anything is built.
Analysis output treated as verification, or structural claims made without engineering review.
Automation that saved time
3 questions08Can you discuss developing design automation workflows?
Listen forTools used by other people, with the time or errors saved described concretely.
Tools only they can run, or automation that took longer to build than it saved.
09Do you have experience automating tasks in modelling software?
Listen forRepetitive work removed reliably, with edge cases handled so the tool does not break silently.
Scripts that fail on unusual input, or automation that produces errors nobody notices.
10Have you integrated data into your design process?
Listen forReal data used to drive decisions, with its quality and relevance assessed before use.
Data used decoratively, or datasets applied without checking whether they mean anything.
Judges the options
2 questions11How would you approach a design problem without a clear solution?
Listen forConstraints and objectives defined before generating options, with criteria for choosing set out.
Options generated without criteria, or selection made purely on appearance.
12How do you balance creative and technical considerations in a project?
Listen forTechnical constraints treated as design material, with a case where a constraint improved the result.
Constraints described as limiting creativity, or technical requirements resisted rather than used.
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.
Technical depth
35%5Names specific components, libraries and solvers, explains geometry maths behind a definition, and distinguishes when scripting beats visual programming.
Work that shipped
30%5Points to delivered projects where their definition or tool drove fabrication drawings, panel counts, or measurable option-study time savings.
Diagnosis under uncertainty
20%5Describes systematic isolation of failing branches, data tree or tolerance issues, with checks on model performance and validated outputs.
Working across the org
15%5Shows tools handed over with documentation others reused, plus concrete negotiation of design intent against fabrication and engineering constraints.
A script generates a thousand options and most cannot be built. A one-way video screen asks what actually was.
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 alongside a portfolio. Enough to test scripting depth, fabrication experience and judgement before a detailed review.
How much programming should I expect?
Enough to write and debug their own tools rather than assemble visual scripts from examples. Without that, complex work stalls whenever a component behaves unexpectedly.
Evaluating answers
What is the strongest signal when screening this role?
Something built from their script. Designers who work with fabrication describe tolerance, material and assembly constraints. Anyone whose output is renders has not met manufacturing.
How do I judge their automation work?
Ask what a tool saved. Real answers quantify hours or errors removed for a team. Anyone whose scripts only they can run has automated their own work rather than the studio's.
























