Successful Recruitment and Onboarding - Technical Side of Things - title image

Successful Recruitment and Onboarding – Technical Side of Things

In this first of two posts series we uncover a few insights of how to achieve a successful recruitment and onboarding from a technical point of view

Over the years I’ve had the honor of interviewing, recruiting, onboarding and mentoring quite a few engineers for multiple project types and various roles, each with its specific nuances and special requirements. As such, I will share a few insights that could be beneficial to anyone who reads this post and this with an important disclaimer – I have never been an employee of Human Resources (HR) and as such I will represent the technical side of things. Again, as in most of my posts, a lot of the information I give in this post is to simply save time and effort, to make the process smoother, more efficient and eventually successful.

Bear in mind that the Employment Life-cycle in an organization is a very complicated issue with multiple models such as 11 stage model, 7 stage model and so on. I will simplify the discussion in this post to 4 stages, in chronological order; Recruitment – from the initial communication between the employee and the organization through the recruitment process until the employee’s first day on the job; Onboarding – the first few months of employment more or less until the employee runs “solo”; Retention – continuous employment until announcement of leaving\termination; Separation – the process of separation between the employee and company till years after the employee has left the company.

I did not realize how much content there is to this topic when I started writing about it so, to keep the different posts at reasonable lengths and reading time, this topic will be divided into two posts. This, the first, post will cover Recruitment and Onboarding that are somewhat related while the second future post will be dedicated to Retention and Separation.

Recruitment

So, we have decided that we need an additional member for our team and even have a budget for a new recruit. Very much like any other project where we should have clear requirements, we have to define to ourselves what we need for our team. This definition serves a twofold purpose; first, it will save a lot of time for our colleagues in HR screening of candidates and at the same time save us none-relevant CV reading and individual interviewing and secondly, when we clearly narrow down our recruitment needs we perform some kind of a professional head count assessment for our project which helps us identify the gaps and the role-to-job fit of our team.
The role definition must include:

  • Technical domain: SW, SE, Mech, Physics etc.
  • Job description: this is super important both internally towards the technical team and HR and externally towards the candidates. What will be the recruit’s responsibilities? What his\her day-to-day will look like? Who will his\her team-mates be? Here, of course, is the place to add any personality requirements for the job especially leadership, working solo, creativity or out-of-the-box thinking, inter-personal skills (not all of us have these), initiative and so on.
  • Experience: junior, experienced, senior, master Yoda Smiley
  • Education: high-school diploma, BSc, MSc, PhD, MBA and all/or other abbreviations you may require. If professional diploma courses or any other education is required that also has to be mentioned here.
  • Role Level: individual contributor, team leader, group leader, technical lead, project lead etc.
  • Must have (and nice to have) technical expertise: for example, in physics you would have here topics such as optics, lasers, heat transfer, ion-excitation etc, or even tools you worked with like Zemax, Quadoa or OSLO. This is very important since you wouldn’t want to discover only during the interview that the physicist in front of you was working on theoretical nuclear physics when you were looking for an experimental lasers expert.
  • Conditions: work from home, work in the office or in the laboratory, traveling salesman…
  • Closely related professional domains: that would immensely assist the HR team to find better candidates for the role, since the boys and girls from HR often would not make a connection between the different technical roles inside a certain field and this simply because it’s not a part of their knowledge base – they are not the technical professionals and of course they aren’t supposed to be. For example, when looking for a physicist in a company working with laser cutting for the metal industry a closely related field would be high power lasers in the medical industry. That is even more important when working in a niche technological field.
  • Salary level: this is important in the definition level. We can’t expect a senior engineer to come on-board when our budget allows us only for entry level salaries. Some companies have enough flexibility that when the right candidate arrives, they “bend-up” the proposed salary to meet the candidate’s demands, but that’s the exception and not the rule.
Job Definition Checklist

Interviewing

Interviews are the next step in recruitment. First, in my opinion it is very difficult to identify/assess how good the candidate is only by a 60-90 minutes interview (BTW, my personal interviews always tended to be the full 90 minutes and even then, more often than not, that was insufficient), so if your specific technical field may include some kind of an example exercise make use of the opportunity e.g. a quick but meaningful code project in SW or a product presentation in Product Management. If and when this is not the case, an interview should try to cover the most important things in the role definition. When I look for a creative and innovative engineer, I tend to come up with a question that I myself am not sure what the solution for it is, this gives the candidate an opportunity to share his/her abilities to brain-storm with others. When juniors are being interviewed, they’d have to know at least how to put into practice some of what they’ve learned in college or any other institute. For me the most difficult interviews were with Master Yodas since these candidates were more knowledgeable than I in almost every field, so other than a few technical questions to make sure I was talking to the Master and not the apprentice (yes, I had those as well) go over to personality and team fitting questions.

Try to avoid puzzles, they test only memory and not innovative thinking – everybody already knows the solution for the 3 bulbs puzzle Smiley.

Write down your impressions of the candidate shortly after the interview

A good tip for interviewing for a technical role is having a list of topics to cover in the interview and right after the interview to fill it in for the candidate. It serves three purposes: 1. if some important topic was left out of the interview you may invite the candidate to another interview or alert the next interviewer in line to note that particular topic. 2. After 3 days and\or 10 candidates we tend to forget or mix-up the different interviews, so unless we met Luke Skywalker himself, we will not have a clear memory of the different candidates and here’s where the list comes in very handy. 3. Differentiating and taking out from the equation a very good flowing interview for example, I’ve had a few cases of interviews that went very well and had great chemistry with the candidates in which the discussion was very pleasant, but then only when looking at my list of topics I realized that the candidates were not professionally a good fit for the role.

One other tip is to take very seriously the red flags, if any, HR reps raise in their interviews. These are rare cases, but when they do happen it means we must take a closer look what the candidate brings to the table before hiring him\her to work.

Finally, when you have a good feeling about a strong candidate, do not delay with it. Make sure your end is covered as fast as possible to hire that person before someone else does.

Remember, it is also a matter of luck in the perfect recruitment. When we are so pressed to fill a position we sometimes have to make compromises with what we have, knowing perfectly well that it is a not a perfect fit, and yes, we sometimes get it wrong. It could be because the candidate was a master in interviewing and not a master in his field, it could be because red flags did not come up in the interviews and it could be because we were simply mistaken and thought that we had found our employee.

Onboarding

A properly adjusted onboarding process may be the difference between a good recruitment and a bad one. The onboarding is divided into two parts; the what and the who. Contents or professional material that has to be passed down to the new employee – that’s the what and the mentor or buddy that escorts the new employee in the organization – that’s the who. The “what” includes the following: orientation around the facility, social introduction to the relevant parties in the core team and outside, quick introduction with all the different disciplines involved in the project, company and product overview, procedures and processes, vendors and clients when relevant and of course the technical field related material; if it’s System Engineering then go over the relevant requirements and architecture documents and reviews; when it’s semiconductor inspection the relevant info is the stage in the semiconductor process (front-end, back-end etc.) and the physics of the device; if it is a solid-state laser product go over all the relevant physics of solid-state lasers and so on. Some of this will be face-to-face learning, some will be self-learning, but remember that this is the only real opportunity when the new recruit has proper time to sit and learn so, the more thorough this stage will be the better.

Onboarding Content

The “what” must include also 2-3 off-the-main-route projects that have a perfectly defined end point. These projects should be off-the-main-route in order to allow a safe and comfortable learning curve for our new team member and they must have a clear end point to allow us, on the one hand, to evaluate the performance of the employee and on the other hand to give the new recruit some self-confidence and a sense of fulfillment. The complexity, speed and scale of data that needs to be transferred is dependent on the employee. Someone fresh out of university will require a completely different onboarding program than that of an engineer with 20 years of experience and so would, of course, the expectations off them.

The “who” is no less important. Not everyone, personality wise, has the patience or the approach to mentoring and this especially when dealing with complete newbies. Apart from that, we tend to partner up the new employees with the most experienced member of the team who in many cases may be the wrong choice; the experienced engineers are sometimes worn out and tired of mentoring and express apathy towards the office and everyone in it. In such cases it would have a detrimental impact on the new employee’s motivation and enthusiasm as well as the mentor’s and we definitely wouldn’t want that.

Pairing the new recruit with non-fit mentor may result in two frustrated employees

There is however a simple and effective way out of this. Have the new employees’ immediate buddies be the ones who have had enough time in the organization and who have the right set-of-mind and personality to serve as buddies and leave the elders and anti-social professionals for dedicated training in their fields of expertise. This is a win-win solution. On the one hand the new employees have an immediate address for all their immediate questions and problems and on the other hand the pass-down of professional data has a well-structured path from the older generation to the younger. BTW, in such a case the immediate buddy may not be fully adequately equipped to evaluate the professional outcomes of the aforementioned first 2-3 projects, so we will achieve an additional goal by having both the designated buddy and the new recruit also professionally communicate with the elders for project evaluations. I have met my share of elders who were very happy with onboarding processes such as this.

Remember that even master Yoda needs constructive criticism over his work as a Jedi so, even if the first projects have been performed to perfection, make sure to go over the outcome with the employee so everyone will be on the same page.

Important note: there is no real differentiation between internal recruitment (role change within the same company) to that of external recruitment. All of the above applies in both instances but with the advantage of more accessibility of discerning what the candidate’s capabilities are.

Recruiting and Onboarding Juniors

There is a Catch-22 in the industry with juniors. On the one hand we all seek for engineers with some experience whereas on the other hand fresh graduates have the handicap in joining the industry since there are insufficient roles for employees with zero experience.

Recruiting a fresh junior is always a gamble. You may get an amazing team member or a terrible one. However, it occurred to me that the better qualities of juniors may be enhanced if an excellent mentor is there to guide them. So, when it comes to juniors, before deciding and forming the job description check who gets to mentor them. If it is one of these natural-born teachers with high professional standards and high fidelity to the job you may start a little junior school with this mentor. Just make sure to coordinate it with this person and have him\her completely on-board.

The recruitment and onboarding processes go hand-in-hand and represent the initial steps of an employee in our team so this will be a good place to stop for this post. In the next post we will discuss the retention of an employee in the team and finally the inevitable separation from the team.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top