Hacker News Reader

Comment by dmkirwan | Hacker News Reader

There is evidence that traditional software engineering interviews[1] assess a candidate's ability to perform under pressure better than their ability to do the job. I find it crazy that you need to spend weeks studying leetcode-style problems after doing the job all day in order to prepare for an interview.

Coincidentally, I've started working on a product to help this[2]. The general idea is that tasks like pull-requests, bug fixes and realistic take home projects are a better way to test candidates. Everything is done using Github, the tasks are all realistic and candidates can use their own laptop and development environment. It's not fully ready yet, but if anybody wants to chat about it just use the info@ address for the site.

[1] https://www.sciencedaily.com/releases/2020/07/200714101228.h... [2] https://devscreen.io/

View on HN

If you can capture the candidates ability to setup a BTD (build-test-debug) loop, their ability to find and fix bugs, and that they know enough tooling to get it into production (and troubleshoot deployment), then you have successfully checked 80% of the job requirements for...almost every programming job out there.

I'm lost on the "tooling to get it to deployment" test idea. Deployment seems both company (and industry) specific and trivially easy to learn compared to programming skills.

Great! Today you learned something new: sometimes software deployment is complicated! Get more experience, and you'll find less trivial deployments. "Trivial deployment" is the goal of many systems, and is rarely met.

I never said deployments were trivial. I said they were trivial compared to programming skills. And I also said they are both industry and company specific.

Expecting a random hire to already be familiar with your deployment process and tools seems very strange. I've done deployments in many situations and, well, I wish there was an industry standard. But as you point out there are many conflicting tools and using them is never turnkey.

They are industry and company specific, but so is any concrete problem you'd ask anyone to work on. They don't t need to be familiar your specific tools, but they need to be familiar with why they exist and be able to do something similar on their own if needed. Even at a place like Google, where deployment is extremely mature, it's still important to know what's needed to roll your own. As you say, these things are never turnkey.

That paper has been widely misunderstood in these discussions. Both groups were given the same whiteboarding questions. The only difference was whether the interviewer was in the room.

Having the interviewer in the room clearly creates a higher pressure situation.

Sure. But the study does not conclude that coding-challenge interviews are what tests for anxiety management. It only speaks to the effect of having the interviewer be present. But people cite this paper as though it makes an argument against coding-challenge interviews as a whole.

Is the interviewer typically in the room or no when doing a Leetcode whiteboard interview?

Typically yes.

But if a company did leetcode questions without the interviewer in the room, I find it exceedingly unlikely that people would shout "Interviewing has been saved! It now tests skill rather than anxiety!" As such, the conclusions of this paper don't seem especially relevant to the discussion about interviewing processes.

Well, it seems like either you don't understand the concept of incremental improvement, or you're being deliberately obtuse. Taking a good portion of the anxiety out of the situation can only help, right? I don't think anybody is pointing at this paper and saying "if we do this one thing, then interviewing is fixed," except people who are looking for a straw man, do you?

This is cool!

Reply on news.ycombinator.com