Show HN: Devscreen.io – realistic tests for software engineering interviews(devscreen.io)
devscreen.io
Show HN: Devscreen.io – realistic tests for software engineering interviews
https://devscreen.io/
2 comments
It's good to see this problem getting attention. Hackerrank et al are just leetcode with a HR system integration. They're optimised entirely for the business, not the candidate. It misses the point that there is a human aspect to this, too, and not everything should be fully automated.
It has happened more times than I'd care to admit that somebody has passed an interview that I've run following company guidelines (always some algorithm puzzle on a whiteboard) and they've been terrible at the job. It sucks for everybody, the new hire and their team, too. Other times I've been on the fence about somebody in an interview and they turn out to be amazing.
One thing that worries me is that I see "projects" as a test option with this. It's just as much of a problem where companies give candidates projects saying that it should only take a few hours when, in reality, it could take days. That's time that not everybody has on top of a full time job.
It has happened more times than I'd care to admit that somebody has passed an interview that I've run following company guidelines (always some algorithm puzzle on a whiteboard) and they've been terrible at the job. It sucks for everybody, the new hire and their team, too. Other times I've been on the fence about somebody in an interview and they turn out to be amazing.
One thing that worries me is that I see "projects" as a test option with this. It's just as much of a problem where companies give candidates projects saying that it should only take a few hours when, in reality, it could take days. That's time that not everybody has on top of a full time job.
I fully agree. We don't have anything in place at the moment to stop users from adding private projects that take a huge amount of time to complete, but we are going to spend time on helping to guide customers away from that situation. I think a large reason for people spending lots of time on code projects boil down to two things: 1) the people who create the test never actually do it themselves, and only estimate how long they think it will take, and 2) Companies don't give enough guidance on what is needed and what isn't. If it's too open-ended then how does a candidate know when to stop?
We made the decision early on to aim for solutions that work well for both the candidate and the company, but where they conflict, go with what will work best for the candidate. This may seem counterintuitive from a business perspective, but it has served us well and, I think, it is the best way to go long term. Ultimately if we can give a great candidate experience then that's good for the business too.
We made the decision early on to aim for solutions that work well for both the candidate and the company, but where they conflict, go with what will work best for the candidate. This may seem counterintuitive from a business perspective, but it has served us well and, I think, it is the best way to go long term. Ultimately if we can give a great candidate experience then that's good for the business too.
I wanted to share a project that I’ve been working on for the past year: DevScreen (https://devscreen.io). I built DevScreen to give companies a way to use more realistic interview assessments to software engineers in a way that works for both the company and the candidate.
I created this because of my own experiences as both an interviewer and candidate. Many companies don’t assess relevant skills during an interview. This is a waste of time for the candidate and a missed opportunity for the company. At the extreme end of the scale, you have companies asking candidates to invert a binary search tree on a whiteboard. All that this assesses is the candidate’s ability to read ‘Cracking the Coding Interview’ and work well under the pressure of being watched. Neither are particularly important attributes of an engineer and result in companies often missing great candidates or hiring sub-par engineers.
Today, DevScreen supports three different test types: code reviews, bug fixes and projects. We spin up a new private Github Repository which the candidate will work on in their own time to complete the task. Once they’re finished, they are automatically removed from the Github repo and the company is notified so they can review the submission. The results can be sent to the relevant ATS application, if applicable. We have a small library of tests but allow private tests that are custom to each company also.
I have built a demo version of the app with sample data hardcoded on the front end to give you a feel for how it works without needing to sign up for an account. This will probably suit those of you who prefer to get stuck in rather than read about it (which, I suspect, is the majority of the HN community!). That’s available from the home page or here: https://demo-app.devscreen.io/. If there are any parts you want to see that aren’t included in the demo just let me know on the chat on the website or email support [at] devscreen.io and I’d be happy to show any part of the product you want to see. For example, only logged in users can create an interview or users. This is solely to prevent abuse of the system as we send emails to candidates to tell them that their test is ready. I want to be up front that it is still in beta, but we do have beta customers using it so I figured it was a good time to share and get feedback from the community and beta customers.