Going through stacks of resumes can be a mind-numbing experience. Except for a few standouts and obvious “no’s” the vast majority seem to blend into one gigantic question mark. What to do?
One option is to just focus on the standouts. But then these are everyone’sstandouts and you end up spending all of your time fighting off other suitors. After much persuading, you might even get someone to interview only to find out that they’re not all that interested after all.
Another option is to try to screen them (via phone screen or take home) with a coding challenge. This usually involves implementing an algorithm. But knowing these algorithms doesn’t correlate well with competency in many (most) software engineering roles. Here are some quotes from folks who make this point eloquently:
This one is really nice:
I personally resonate with that last tweet. My academic training and interest in solving puzzles makes me pretty good at coding challenges. In fact I spend some of my free time solving challenging Project Euler problems likethis. But I really don’t think I should be employed as a software engineer. I hate reading other people’s code and don’t have the patience to build a complicated system. These are vital skills that I just don’t have. And that’s why I have a different job at Lytmus :-).
Conversely, a strong web or mobile developer might fail a coding challenge but be terrific at their job. The developer of Homebrew famously failed a coding challenge and was summarily rejected during a job interview. Deciding not to read one of the many books available to “crack” interview questions can be a real liability!
The bottom line is that testing people indirectly by asking them questions that do not correlate well with their job performance results in a very weak signal. Even after someone has “aced” the test you have to evaluate them all over again.
Here’s how the Lytmus Platform solves this problem:
You are looking at a shared Lytmus VM. Notice the editor (Sublime) with file browser, pre-existing code, a terminal window and a browser with inspector open. The environment can be pretty much what you want. Both the candidate and evaluator can work together to get something done. Rather than implementing a linked list, the task might be to make webpages more responsive. A system administrator could be asked to bring up a crashed server. A QA engineer could be asked to identify and log bugs. The possibilities are endless. Everything happens within a web browser so there is no download.
The entire session is recorded and available to both parties after the session has terminated.
But there’s more :-)! You can use the Lytmus platform to create and send out “Tryouts” to candidates. Tryouts ensure that candidates see the same rich environment and work on specific tasks. Their solutions are autograded for correctness and a report is automatically generated with a variety of metrics on their performance. The signal from these Tryouts is much stronger than that from an algorithms challenge.
If this sounds intriguing, please get in touch with me at abhay@lytmus.io or go to our website and sign up for future updates.
— Abhay Parekh, Co-Founder & CEO
