Hacker News Reader

Comment by moose_man | Hacker News Reader

They need to come up with something better than leetcode. Build a project and explain it is a much better way to get a sense of skill. It's the sort of skill that won't be made extinct by ChatGPT. Your creativity and ability to architect and build a project and then explain it should be the standard. Leetcode also penalizes good engineers who have anxiety during interviews.

View on HN

Worked one place where we received seven (7!) resumes that were almost identical, with the same project of what they could do.

Not saying leetcode is the answer, but it does solve for something things.

My interviews tend to walk through the framework of a project and they can speak to me in the abstract, or an example of what that part of the project does. Say there is a standard way of connecting to the database like in Rails. They can tell me about database.yml and how it has different entries for each of the databases. Then we have a conversation about checking in passwords to git, env variables, secrets managers, etc... This avoids asking stock questions which might be coached/studied more and aims for what the person doing the work might practically know. It also keeps the discussion in a context that makes understanding the questions (hopefully) easier. My style of interviews are very much non-standardized and there has to be some trust that I have some idea what I'm doing.

Leetcode at least has some standardization around the problem. Of course everyone could have looked them up and studied the exact solution, and these solutions don't correspond very well to daily efforts. But, given everyone knows the game, it does demonstrate some horsepower I guess. Or maybe I like these interviews because I'm good at them.

They should all fail if they are all identical. You look for someone who can build something extraordinary, who takes the parameters and runs with them.

Extraordinary is too subjective in my experience

When I’m competing for one position and “we just want to see how you think” is always not true but instead a completely arbitrary set of criteria not presented to the candidate, it should be sanctionable

> Build a project and explain it is a much better way to get a sense of skill.

I HATE project interviews, because their skills aren't transferable to the next interview. Take home projects also tend to "go-over", because you want to put your best foot forward and you're betting that the other people they interview are also going to exceed time.

I don't know if this is what they meant but I read it as you describe an existing project that you've worked on, not a mini one just for the interview. That's how I've interviewed before.

I’ve encountered both, significantly more of the “build a mini project for us” variety.

I also dislike those because I’ve already got a full time engineering job and a family and don’t have time to put 4-5 hours each into every 3-hour project the interviewers ask for. But 5 years ago I did.

I’ve concluded there really isn’t a single way to interview that checks all the boxes, and if you’re running the interview process you have to pay the costs somewhere, unfortunately.

This is more of a problem than it seems at first. At one place I worked that did mini-project interview most of the hires were currently unemployed and could spend all week on it. (then claim they did it in 3 hours)

> I read it as you describe an existing project that you've worked on

IMHO, there is some risk of violating NDAs. For the most part companies don't care if you share how their tech stack works, but I get nervous about revealing IP.

I’ve been doing interviews like this for a few years now. Leetcode sucks.

Bonus points the next time a candidate (correctly) uses ChatGPT or Copilot. Let the machines do what the machines do well (grinding leetcode), good riddance.

Yeah exactly. Since these tools commoditize repetitive skills, the goal should be to see how creative and awesome the project is within the parameters given. Being creative is what you should be testing for since all these other skills are now commodities. It's the one thing we have that AI can't replicate (yet?).

Often one of the parameters given is a timeframe that no sane person would request in a real-world setting. The justification I've heard for that is "we don't wan't people spending too long on it."

Discussion: what does correctly programming with chatbots look like, specifically?

Probably easier for most to list what it doesn't look like.

I'm interested in both.

Asking a chatbot a question rather than Google. I never minded if candidates said they’d use Google for looking up something in the docs. But now you’ve got something a heckuva lot more efficient.

For example: What’s the method to select a random item from a range in Ruby? (ChatGPT used to get this wrong.) I don’t mean to say that I give trivia questions in interview, but if the need to know this came up during an interview or code pairing, having the candidate know when a chatbot response was invalid (and where to look for a correct answer) is a good sign.

I’m also open to a candidate stubbing out an idea with a chatbot/copilot and then checking the solution and adapting it to fit a given context.

Reply on news.ycombinator.com