It's hard to predict if someone will be a great fit at a company. That's why candidates are often put through multiple rounds of multi-hour interviews, do take-home tests, and need strong referrals.
Filtered aims to make that easier by giving you the tools to match certain candidate behaviors with their associated future success (or failure) at your company.
Below are four key places to review in Filtered that will help you better understand any candidate:
1. Listen for specific details about doing past work
Despite their best intentions, every candidate exaggerates their skills and experience. That's because the act of getting a job is marketing; they don't want to say something that would make them less likely to get an offer!
However, you'll need to see through the big fluff words when listening to a video response. For example:
"For my senior project, I built a webservice on AWS using NodeJS which got menus from restaurants near the campus. It took a long time.... but I think it came out pretty great."
is more likely to be fairly close to reality than a statement like:
"For my senior project, I built a webservice on AWS using NodeJS and MongoDB for the database and it was deployed to amazon."
The signal is the phrase "It took a long time". That candidate actually has an opinion about what it was like to be present during the experience. Unless that candidate is a brilliant liar, I would put money on the fact that they put in some honest hours to finish their project and learn things in the process. For the other candidate, it's better to be skeptical and ask follow-up questions about that topic.
Because of this fact, it's recommended that you ask open-ended questions related to previous experiences like working or school instead of trivia-like questions with a right or wrong answer. You can imply someone's level of competence ad culture fit by understanding how much exposure they have had in the past to similar working environments to your own.
2. Look at what they searched and when they searched for it
Blue triangles on the code pad timeline are where Filtered detected a highly-relevant tab was opened. These tabs will be things like:
Forums where people talk about code
Documentation for specific libraries or frameworks
Blog post related to coding
Searches for the question name or content
For example, the image below shows that the candidate viewed two websites in the first few minutes of their test which provide an answer to the beginner question they were being given ("find the smallest number in a list"). This is usually a negative sign:
On the other hand, this candidate viewed a page on a coding forum (StackOverflow) which helped them do a simple type conversion in JavaScript. In small amounts, this is seen as normal, or even encouraged behavior because:
This candidate had been coding and testing for a while before making this search.
The challenge they were being asked to solve had very little to do with converting data types.
Using the code example from the StackOverflow post resulted in only a few characters worth of new code.
Even very senior developers forget basic things about programming and have to reference the documentation. They are focused on solving larger, harder problems and lean heavily on docs like it is a box of tools. The timing of and content within the opened tabs is the most important part when making a judgement call.
3. Watch the parts of the timeline where they compiled a lot
Grey triangles in the code pad timeline represent compiles (literally clicking the "run" button during the test to see if their code did what was intended).
The timing and clusters of these triangles typically represent behaviors. For example:
No compile points over a long period of time mean the candidate is focusing on writing code to scaffold their plan or implement the solution (or, they are away from their keyboard to make an omelette).
Tight clusters of compile points suggest that the candidate is making small adjustments to the code to achieve a particular result. Occasionally, this means they are stuck on something and are using trial-and-error to figure it out.
It's normal to see candidates compile once or twice at the beginning of the timeline because they are testing out the Filtered system.
Once you pick a timeline point to review, you can start the playback to see which things were changing.
One thing to note: 99.9% of challenges cannot be fully solved by only compiling one time. If you see this from a candidate who scored well, it means that the candidate either completed the work in their own IDE and transferred it to Filtered, or the candidate found an answer online that they dumped into the code pad.
4. Scan their code for evidence of best practices
Just like the rings of a tree are able to show its age, small details in the code can show you someone's level of experience.
My personal favorites are:
looking for code comments which show empathy towards other people who might read the code, and
looking for multiple small functions, which suggest that the candidate has strong abstraction and planning skills
Have more questions?
Reach out to us at support@filtered.ai