Photo by Mark Rabe on Unsplash
Unless you are Google, or the likes, you are neither flush with cash nor are you dominant enough that your company can operate in equilibrium for long periods. In other words, you cannot afford to hire engineers who are simply focused on one single thing that demands high skill-set. Instead, your engineers will be adapting to ever changing priorities to continuously explore new ways to grow, and capture market share, by cobbling together scrappy projects using pre-made building blocks like libraries, and web services.
So how should we hire?
We should hire by mindset rather than skill-set. This is based on 2 underlying beliefs:
In this article, we will explore:
When you hire someone for her skill-set, she can hit the ground running quickly. However, she may not have the mindset to adapt when her job scope, skill-set requirement, project goals, etc., change. It is likely that she will feel betrayed, and uncomfortable, thus becoming unhappy, and unproductive.
When you hire someone for her mindset, she is mentally prepared to adapt as the company evolve with market demands, competitor landscape, operating conditions, etc.
In engineering, you learn something, apply it, and you get the output in code that either works or not; the code may not be perfect but a little code review, or mentorship should fix that. In other words, the feedback loop between learning, application and outcome is short and objective, which makes it addictive to invest time and effort into learning thus speeding it up.
Mindset, on the other hand, is easy to talk about but hard to change. Most read popular literature on how to become successful, e.g., Rich Dad, Poor Dad, Seven Habits of Highly Successful People, etc. but how many go on to be successful? Making mindset change is difficult, and different from the process of learning a skill-set for two reasons:
As Alfred Lin and Brian Chesky pointed out in Y-combinator’s startup school, company culture is ‘everyday core values and actions of employees in pursuit of company mission’.
The mindset you are looking for in a hire should be tied to the company culture; you want the new hire to act in accordance with your company culture while striving towards the company mission.
You would be inclined to believe that you have to figure out the mindset required for your unique company culture on your own, and that is assuming if you have already figured out what your company culture is, which is the hardest part. Overwhelmed?
Don’t be. This study demonstrates that despite company culture variations, there are some core values that are common across all company culture.
Here are 2 important core values that we need most in a new hire because they are the most difficult to cultivate; they conflict with natural human tendencies, which are particularly strong among engineers.
Most engineers take pride in their ability, and constantly strive for perfection. They often persist on the task in hand till the end, to reinforce the belief in their ability, and even when it is done they insist on polishing the minor details. These traits make an engineer feel extremely uncomfortable to continuously switch tasks in and out as the tasks are being constantly re-prioritized to meet the ever-changing company needs. Failure to overcome the feeling of leaving tasks in incomplete or imperfect state renders an engineer unhappy and unproductive.
Engineering and innovation is important — full stop. However, they become important after the company identifies a product-market fit, i.e., at least 40% of customers want to pay for a product feature. Most engineers lack entrepreneurial experience thus are unfamiliar with product-market fit concept, and fueled by the media feting engineering triumphs, they end up feeling that doing non-technical or marketing/sales-related tasks are a waste of both the company’s precious time and their engineering skill. Instead, engineers have the responsibility of adopting a more entrepreneurial mindset, and the management have the responsibility of involving engineers in non-engineering decision-making.
NOTE: To be fair, management has also been at fault for eroding engineers’ believe in marketing/sales-related tasks; they are often poor at communicating the importance of those tasks, with more than a handful guilty of dictating the engineers to do so because they of their authority.
You can look for signs of these 2 mindset in resumes:
If we sacrifice skill-set and hire for mindset, we need the engineer to have the aptitude to observe, infer, read code, and determine root cause, in order to pick up a new job skills quickly. Here is how you can spot these signs of intelligence.
This is a diagram comparing all the 4 different flows of OAuth2. One does not need any understanding of OAuth2 in order to observe, and derive some high-level conclusions.
NOTE: If you are curious, OAuth2 is the framework used to request permission from a user to access her data or perform something on her behalf, e.g., a ‘Login with Twitter’ button enables the web service to read a user’s Twitter profile.
An observant person will notice:
Details of other observations are available in the article itself.
The ability to infer is critical because few problems require coding from scratch; engineers often find a pattern that best matches the problem they are trying to solve, and tweak the pattern.
‘regex’ is a good way to test inference ability, especially so, if the person is unfamiliar with it.
NOTE: Regex provides a very concise yet precise syntax to specify what patterns you are looking for in a string.
Start with a specification of what we want to the candidate to work on:
Here is an example, with the correct ‘Regex’, i.e., the ‘Outcome’ is match, and satisfies the ‘Goal’:
Goal: Match only valid google URLsString: www.google.comRegex: /google/Outcome: match <===== 'Outcome' satisfies 'Goal'
Test this out on an online interactive regex tool, e.g., https://regex101.com. Using the interactive tool shortens the feedback loop between regex creation and outcome, so it helps both the candidate to test her regex, and for you to see her train of thoughts.
Here is an example when a ‘String’ results in ‘Outcome’ of no-match, and but still satisfies the ‘Goal’ provided
Goal: Match only valid google URLsString: www.abc.comRegex: /google/Outcome: no-match <===== 'Outcome' satisfies 'Goal'
On https://regex101.com, a negative match looks like:
This should help her understand the underlying mechanism of regex, and the online tool.
Now provide variations of ‘Goal’ and ‘String’, and require the person to tweak the ‘Regex’ for a match or not
Example String Variation #1
The ‘Regex’ /google/
that has satisfied the ‘Goal’ so far will fail in the below example when the ‘String’ isgoogle.evil.com
.
Goal: Match all valid google URLsString: google.evil.comRegex: /google/ <===== Incorrect 'Regex' to achieve 'Goal'Outcome: match <===== Should be no-match
How would you need to change the regex so that the ‘Outcome’ is no-match? We do not expect the candidate to be able to write regex, but rather we want them to explain how they tweak the ‘Regex’, e.g., ‘we can check for google.com instead of just google’ — the improved ‘Regex’ would be:/google\.com/
Example String Variation #2
The newly tweaked ‘Regex’ /google\.com/
will violate the ‘Goal’ again when the ‘String’ is fake-google.com
.
Goal: Match all valid google URLsString: fake-google.comRegex: /google\.com/ <===== Incorrect 'Regex' to achieve 'Goal'Outcome: match <===== Should be no-match
How would you need to change the ‘Regex’ so that the ‘Outcome’ is no-match? We would expect the candidate to brainstorm around the idea of matching anything starting with ‘google.com’ or anything with ‘.google.com’ — the improved ‘Regex’ would be:/(^google|\.google)\.com
You get the idea!
To test code comprehension, the candidate should not be disconcerted by the programming language of the code she has to read, and she should be allowed to google for the syntax, or better still ask aloud about programming syntaxes. Depending on the depth of programming knowledge required, it is best if the code she is tested on:
Bugs happen even in well-written code, thus root cause determination is a required skill-set. The best way to test this skills-set is to look through your bug database and you can present one of the many scenarios you have faced while troubleshooting your service/product/application. Each scenario should contain:
Here is a general debugging problem:
Explanation of how things work:
Each web program can run on what is known as a port, which ranges from 0–65335. You can access the web program using a browser by pointing to https://abc.com:{port}
Symptoms:
You installed a program (program B) on port 2222, and tried accessing at https://abc.com:2222, but you do not see anything.
However, on the same server, there is another piece of program (program A) that is running on port 1111 and can be accessed using a browser https://abc.com:1111
Questions and expected answers:
What could be the possible problem of not being able to access program B?
How can you determine the root cause?
Ascertain that program B does not work by ruling out port 2222 is not the culprit
Ascertain that port 2222 does not work
We have all hired or worked with people whom we felt was not a good fit in the company. When that happens, before frowning on the people, we should look at the company’s hiring process to understand if it has been designed to attract the right the type of people needed to make the company successful; this entails understanding of the operating conditions of the company and its standing within the industry.
If there is interest in other types of sample interview questions, please leave comments, and I will put together a simple site to share.