The most common avoidable mistake we see in product development recruitment is a strong candidate being rejected because they use a different CAD package to the one on the job spec. It happens constantly, it costs businesses good people, and the reasoning behind it rarely survives examination.
Software is teachable. Judgement isn’t.
A capable design engineer who has spent eight years in Creo or CATIA will be functional in SolidWorks within weeks and fluent within a few months. The underlying discipline is what transfers, and it is substantial: parametric modelling logic, assembly and constraint management, geometric dimensioning and tolerancing, design for manufacture, materials behaviour, and the iterative habit of designing something, testing it and being honest about why it failed.
None of that is package-specific. The interface changes, the shortcuts change, and the file management conventions change. The engineering does not.
What genuinely cannot be taught in a few months is design judgement. Knowing that a wall section will sink, that a tolerance stack will bite in assembly, that a material will not behave the way the datasheet implies once it has been outdoors for two winters. That comes from having made those mistakes and paid for them. No amount of software familiarity substitutes for it.
Knowing a package doesn’t make someone good at using it
This is the part that gets lost. “Five years of SolidWorks” on a CV tells you someone has had access to the software. It tells you nothing about whether their models are robust, whether their drawings are manufacturable, or whether the person picking up their work after they leave will be able to make sense of it.
We have all seen models built so rigidly that a single dimension change collapses the feature tree, and drawings technically complete but practically unusable on a shop floor. Those were produced by people with years of software experience. Meanwhile a genuinely good engineer new to a package will typically produce cleaner, more editable, better-documented work within their first quarter, because the discipline came with them.
Screening on the package name filters for exposure. It does not filter for competence, and it can easily filter competence out.
The commercial arithmetic doesn’t hold up either
A frequent objection is licensing cost. Bringing someone in who needs a different seat, or funding training on your existing package, is presented as an unbudgeted expense.
Set that against what the alternative actually costs. A product development vacancy left open for an extra three months delays a pipeline, pushes launch dates and occupies a hiring manager’s time repeatedly. Hiring a weaker candidate who happened to know the right software costs considerably more than that over a couple of years, and it is a much harder mistake to reverse.
A few thousand pounds of training or licensing against those numbers is not a serious obstacle. It is a rounding error being treated as a decision criterion.
Candidates will often close the gap before they start
This is the practical point most briefs miss. Notice periods in product development are frequently one to three months, and strong candidates routinely use that time to prepare. Vendor certification programmes, structured online training and trial licences are all readily accessible.
Professional development is also increasingly formalised in this discipline. The Institution of Engineering Designers, the UK’s professional body for engineering and product designers, awards Chartered Technological Product Designer and Registered Product Designer status, and has incorporated specific professional recognition for CAD practitioners into its membership. Its continuing professional development framework explicitly supports members developing competence in new directions, which is precisely what a package transition is.
Asking a candidate at offer stage what they plan to do about the software gap is a reasonable question. Most strong candidates will already have thought about it.
When the software requirement is genuinely real
There are exceptions and it would be dishonest not to name them.
Short contract and interim roles are one. If someone is in post for four months to clear a backlog, there is no ramp-up period to spend and package fluency on day one is a legitimate requirement.
Highly specialised tools are another. Advanced FEA and CFD work, or niche industry-specific packages with small user bases, are not equivalent to moving between mainstream CAD platforms. The learning curve is genuinely steeper and the available pool genuinely smaller.
Deep customisation counts too. A business running heavily configured PLM integration or extensive automation within its CAD environment is asking for more than package familiarity, and should say so explicitly rather than listing a software name and hoping candidates infer it.
Outside those cases, the requirement is usually convenience presented as necessity.
That said, it’s your call
This is advice, not a condition of working with us. If you have weighed it up and concluded that package fluency genuinely is essential for your role, we will run the search on that basis and won’t spend the process arguing the point. Plenty of businesses have good reasons we cannot see from the outside: a lean team with no capacity to support a ramp-up, a client who audits the toolchain, or a previous hire that did not work out for exactly this reason.
Our job is to give you the honest view once, then find you the person you have actually asked for. Where we can add value is in being clear about what that decision costs in shortlist size, so you are making it deliberately rather than by default.
It isn’t only a CAD problem
The same pattern shows up across the discipline. In food and drink NPD, briefs get written around specific specification management or nutritional analysis systems. In packaging development, particular structural design tools appear as hard requirements. In each case the software is a tool for expressing a skill, and the skill is what should be screened.
What to screen for instead
Ask to see work and ask why it was built that way. A good engineer will explain the reasoning behind a design decision, what the alternatives were, and what constraint drove the outcome. That conversation reveals far more than a software list.
Ask about a design that failed. Not a hypothetical, an actual one. What went wrong, when they found out, and what they changed as a result. Candidates who have genuinely owned a product through to production will have several examples and will not be defensive about them.
And write the brief so it does not exclude the people you want. CIPD’s work on employer brand makes the point that candidates assess the organisation as much as the role, and a spec that reads as a rigid software checklist signals a business that values tools over thinking. Strong design engineers notice that.
How this affects the search
Product development engineer recruitment is already a narrow market, and head of product development recruitment narrower still. In technical categories, the pool of genuinely strong engineers with relevant sector experience can be small enough to count. Layering a rigid package requirement on top of that can reduce a viable shortlist to nothing, and businesses frequently do not realise that is what has happened; they conclude the talent is not there when in fact it was screened out.
As a specialist product development recruiter, part of the job is being straight with clients about which requirements are genuinely load-bearing and which are habit. Software is very often the latter.
If you’re recruiting a Product Development Engineer, Design Engineer, Product Development Manager or Head of Product Development and want a candid conversation about what your brief should actually insist on, get in touch for a confidential, no-obligation chat about product development recruitment. We aim to respond to all enquiries within one hour.
Cambridge Talent Partnership provides product development recruitment and design engineer recruitment across the South of the UK, including London, Southampton, Basingstoke, Swindon and Crawley, as well as further afield for the right role. Wherever your vacancy sits, our approach stays the same: proactive search, genuine sector understanding, and candidates assessed on capability rather than software familiarity.
