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:
- Hiring by skill-set is for short-term, while hiring by mindset is for long-term
- It is easier to learn a skill-set than to change a mindset
In this article, we will explore:
- The basis of the 2 beliefs advocating hiring by mindset
- If you are hiring by mindset, what mindset should you look for?
- How do you look for signs of this mindset?
- By sacrificing skill-set for mindset, how do you gauge if the candidate possesses intelligence to pick up a required skill-set?
‘Hire by Mindset’ Argument
Short-term vs. Long-term
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.
Learning Skill-set vs. Changing Mindset
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:
- Changing mindset requires fighting against how humans are wired (more on this later), so it is a long-term process
- Our surroundings does not provide a feedback loop that is short, nor objective, i.e., we are do not have enough signals to tell us if what we are doing will lead to success, and when we do get those signals, it is often too late.
What Mindset Should You Look For?
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.
- Be perfectly scrappy not be perfect
- Align with cross-company goals
Be Perfectly Scrappy Not Be Perfect
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.
Align With Cross-Company Goals
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.
Looking For Signs of Required Mindset
You can look for signs of these 2 mindset in resumes:
- Look for a variation of achievements in the resume? Does it include engineering with marketing/sales tilt? For example, does it include evangelizing a product on social media, or does it include integrating the product with various sales tools?
- Ask about what she thinks are the most important attributes of an engineer? Is there any mention of soft-skills, such as learning to work in an agile team? Is there any expression of delight when talking how engineering and business work in tandem?
How to gauge the ability to learn?
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.
Power of Observation
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:
- Each OAuth2 flow type can be categorized based on implementation difficulty, security, and use cases
- Authorization Code flow has the highest security because it has a Guard, and the Key is never handed to the App (unlike all other cases)
- Resource Owner Password Credential flow has the lowest security because it is the only flow where the User gives her username/password to the App
Details of other observations are available in the article itself.
Ability to Infer
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:
- Goal: What we want to match or not match
- Regex: The engineer should formulate or tweak this to achieve specified ‘Goal’ for given ‘String’ as input
- String: The input used to test regex
- Outcome: match, if the string and regex resulted in a match, otherwise no-match. This should correspond to ‘Goal’
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!
Code Comprehension
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:
- Is self-contained, e.g., batch scripts that perform specific tasks, to minimize distraction of peripheral code
- Contains basic programming constructs such as variables, constants, expressions, functions, data flow controls
- Contains object-oriented concepts such as class/instance variables/methods, inheritance, polymorphism/interface
- Contains some well-used patterns, e.g., abstract static factory, decorator, builder, etc.
- Contains error handling, which covers hierarchical try/catch error blocks
- Contains functional programming, which can be simple functions that focus on what the program does instead of how, e.g., map, reduce, and/or complex patterns that include passing/returning functions into/from other functions
- Contains asynchronous code, which covers code flow to test understanding of callbacks, and newer paradigms that avoids ‘pyramid of doom’ callbacks, and hides the details of asynchronous programming
- Contains parallel programming, which covers memory sharing, inter-process communication, paradigms that hides the need understand parallelism, and common parallel programming pitfalls in certain languages that will not happen in other languages
Root Cause Determination
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:
- An explanation of how things are expected to work
- Symptoms of issue
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?
- Program B does not work
- Port 2222 does not work
How can you determine the root cause?
Ascertain that program B does not work by ruling out port 2222 is not the culprit
- Install program A on port 2222 or
- Install the simplest possible program on port 2222
Ascertain that port 2222 does not work
- Install program B on port 1111
Final Thoughts
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.