How to Evaluate Engineering Candidates with Practical Skill Tests

Engineering is a craft. A CV says "5 years of structural design experience" but cannot show whether the candidate can size a beam, read a load path, or produce drawings that a contractor can build from. Engineering candidate assessment closes this gap with practical tasks that mirror real engineering work — and the right design of those tasks is what separates a useful assessment from a frustrating one.

Start with the actual daily work

The most common failure mode in engineering assessment is academic tasks — textbook problems that test the engineer the candidate was 10 years ago, not the engineer they need to be now.

Ask a senior engineer in the role: "What do you spend the most time on?" Their answer is the assessment design brief. If they spend half their day reading drawings, the test should include reading drawings. If they spend their day in clash detection workflows, the test should include clash detection. The test should mirror the work, not abstract from it.

For common engineering disciplines, the patterns are:

• CAD draftsmen: drawing production from a sketch, layer discipline, standards adherence, dimensioning.
• BIM modellers: family creation, parametric thinking, view templates, shared coordinates.
• BIM coordinators: federation, clash detection, BCF reporting, discipline-aware judgement.
• MEP engineers: system sizing, equipment selection, schematic production, code compliance.
• Structural engineers: load path identification, member sizing, drawing interpretation, code compliance.
• Civil engineers: grading, drainage layout, profile interpretation, quantity takeoff.

Each discipline has its own daily work. The assessment should reflect it.

Provide realistic constraints

A blank canvas tests creativity. A constrained brief tests engineering. Real engineering is constrained — by budget, by code, by the architect's drawings, by the client's brief. The assessment should be constrained too.

Specify the boundary conditions: dimensions, load, code basis, project context. Give the candidate a brief that mirrors a real one — short, slightly ambiguous, requiring the engineer to make assumptions and document them. The candidate who recognises and documents the assumptions scores higher than the one who simply produces an answer.

This is closer to real engineering than a textbook problem. Real engineering involves uncertain inputs, contested decisions, and trade-offs. The assessment should expose how the candidate handles uncertainty, not just whether they can solve a clean problem.

Score the process, not just the answer

A candidate who reaches a wrong answer through clear reasoning is often hireable — they can be taught to avoid the specific error. A candidate who reaches a right answer through guessing or fluke is not — they will fail when the next problem is different.

The rubric should reward visible reasoning. Did the candidate document their assumptions? Did they show their calculations? Did they note alternative approaches and explain their choice? These are the markers of an engineer; the answer alone is not.

For practical tasks, the scoring usually weighs:

• Correctness (the answer) — 40-50%
• Method (how they got there) — 25-30%
• Documentation (assumptions, calculations, drawing standards) — 15-20%
• Presentation (clarity, professionalism) — 10-15%

The exact weights vary by role and seniority. The principle holds: process matters as much as outcome.

Time-box realistically

60-90 minutes for the practical phase. Less than that and the task is too shallow to be predictive; more and you lose candidates to fatigue and life commitments.

The time pressure should match the role. A draftsman role demands speed under time pressure; a senior structural engineering role demands depth and accuracy with less time pressure. Calibrate the time limit to the role expectation.

One useful test: have a current top performer at the target level complete the task. They should finish in 60-70% of the allotted time. If they need the full allocation, the task is too long; if they finish in 30%, the task is too easy.

What to test for L1 vs L2 versions of the same role

Most engineering roles have a junior (L1) and senior independent producer (L2) level. The roles use the same software and similar workflows but at different levels of independence and complexity.

The assessments should differ in three ways. The practical task is more complex at L2 — more components, more decisions, more documentation expected. The MCQ section is harder at L2 — fewer recall questions, more applied reasoning. The pass mark is calibrated against the role's senior performers, not against absolute standards.

AssessExpert separates L1 and L2 for AutoCAD, Revit, and other major engineering roles. Each level has its own bank and its own practical task.

Sandbox vs candidate's own machine

For engineering practicals, the work is heavily tool-dependent. The candidate needs access to CAD, Revit, or similar software. Two delivery patterns exist.

The sandbox pattern — the platform hosts the software environment and the candidate accesses it through their browser. Pros: controlled environment, no licence issues for the candidate, screen recording works cleanly. Cons: occasional latency or compatibility issues; the candidate works in a slightly unfamiliar environment.

The candidate-machine pattern — the candidate uses their own installed software and shares their screen. Pros: candidate works in their natural environment. Cons: licence variance, hardware variance, occasional setup issues that derail the session.

For most engineering assessment, sandbox is the better default. For senior roles where the candidate's specific tool fluency matters, candidate-machine can be appropriate with a careful pre-flight.

The honest cost of building engineering assessments

Engineering assessments are more expensive to build and operate than coding assessments. The reasons:

• Software licences (CAD, Revit, MEP-specific tools) for the sandbox environment.
• SME calibration time tends to be longer because engineering roles vary more by company and project type.
• Scoring takes longer because drawing and modelling work needs human review against rubrics.

Account for this in budget and timeline. Engineering assessment costs more per session than coding assessment, and it should — the signal is denser and the work is harder.

How AssessExpert handles engineering assessment

Pre-built assessments cover AutoCAD (L1 and L2), Revit, BIM coordination, MEP engineering, structural engineering, civil engineering, and planning roles. Each pairs a 30-minute MCQ phase with a 60-minute practical task in a sandbox environment. Custom roles are built by our Exam Setup team in two to three weeks. For the full discipline coverage, see CAD, BIM and Engineering Assessments.

FAQ

Should we use the candidate's own software or a sandbox?

Sandbox where possible — removes hardware and licence variance from the result.

How long should an engineering practical be?

60-90 minutes. Calibrate against current top performers — they should complete in 60-70% of the allotted time.

Can the same assessment work for different software versions?

For minor versions, usually. For major version changes (AutoCAD 2024 vs 2018 features), the assessment may need revision.

What about candidates from different regional standards (US vs European drawing conventions)?

Specify the convention in the brief, or build region-specific variants. Most assessments target one convention and accept that as the role expectation.

How do we test senior engineers vs juniors?

Separate L1 and L2 banks plus practical tasks. Same software, different complexity and expectation.

Can engineering assessment be done remotely?

Yes, with sandbox delivery and proctoring. The work is fundamentally screen-based; remote delivery does not lose signal compared to in-person.

Next steps

If you are hiring engineering roles and want to see the assessment for a specific discipline, book a demo. The first call covers your role, the discipline-specific tasks, and the calibration approach.