Live data from Hacker News

AI killed the tech interview. Now what?

kanenarraway.com

141–150 of 651 posts

Re: AI killed the tech interview. Now what?

#141
post #98

Licensing. We do the Leetcode interview in a controlled testing center. When you apply for a position, I look up your license number, then I know you can leetcode without wasting any of my developer resources on determining that.

Isn’t this basically triplebyte? I did their process and every company still wanted to do their leetcode interview after.

Former head of product there here: no, we didn't do this kind of identity verification. That would have prohibitively damaged people's willingness to actually do the interview. We did use various means to try to identify people signing up multiple times, and we caught plenty of people trying to duplicate themselves that way, but you didn't have to physically go to a center to do our interview.

I've considered something like that for my current company, which is doing basically the same thing, but:

(a) this has not, in practice, been a problem for us in identifying good candidates

and, far less importantly:

(b) you need very high scale to have interviewers everywhere that candidates are OR you're paying extra for a third-party controlled environment

(c) scheduling and cancellations become more difficult and costly respectively

Re: AI killed the tech interview. Now what?

#142
post #99
post #97

Earlier quoted context omitted.

Here's an interesting thought on your "gotcha" - I'm 57 years old, been programming as a career for over 30 years, a lot of languages and I have no idea what the difference is.

A function returns a value. https://stackoverflow.com/questions/721090/what-is-the-diffe...

> A function returns a value

... in Pascal/Delphi.

Re: AI killed the tech interview. Now what?

#143

Company A wants to hire an engineer, an AI could solve all their tech interview questions, so why not hire that AI instead? There's very likely a real answer to that question, and that answer should shape the way that engineer should be assessed and hired. For example, it could be that the company wants the engineer to do some kind of assessment whether a feature should be implemented at all, and if yes, in what way.…

Problem is, company A doesn't need an engineer to solve those interview questions but real problems.

Re: AI killed the tech interview. Now what?

#144

Company A wants to hire an engineer, an AI could solve all their tech interview questions, so why not hire that AI instead? There's very likely a real answer to that question, and that answer should shape the way that engineer should be assessed and hired. For example, it could be that the company wants the engineer to do some kind of assessment whether a feature should be implemented at all, and if yes, in what way.…

The even bigger challenge is that hiring experts in any domain requires domain knowledge, but hiring has been shifted to HR. They aren't experts in anything, and for some years they made do with formulaic approaches, but that doesn't cut it anymore. So now if your group wants to get it done, and done well, you have to get involved yourself, and it's a lot of work on top of your regular tasks. Maybe more work because HR is deeply involved.

Re: AI killed the tech interview. Now what?

#145
post #96

I was asked by an SME to code on a whiteboard for an interview (in 2005? I think?). I asked if I could have a computer, they said no. I asked if I would be using a whiteboard during my day-to-day. They said no. I asked why they used whiteboards, they said they were mimicking Google's best practice. That discussion went on for a good few minutes and by the end of it I was teetering on leaving because the fit wasn't go…

Yeah, very bad fit. Surprised they made an offer. Folks getting mad about whiteboard interviews is a meme at this point. It misses the point. We CANT test you effectively on your programming skillbase. So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem. It isn't that your interviewer knew all the languages, but that the language di…

> can you have a real conversation (with a whiteboard to help) about how to solve the problem

And do you frame the problem like that when giving interviews? Or the candidates are led to believe working code is expected?

Re: AI killed the tech interview. Now what?

#146

Earlier quoted context omitted.

> Also, the best (albeit the most expensive) selection process is simply letting the new person to do the actual work for a few weeks. What kind of desperate candidate would agree to that? Also, what do you expect to see from the person in a few weeks? Usual onboarding (company + project) will take like 2-3 months before a person is efficient.

Candidate would be compensated, obviously. That's why it's expensive. You don't need him to become efficient. Also I don't think it is always necessary to have such long onboarding. I'll never understand why a new hire (at least in senior position) can't start contributing after a week.

> Candidate would be compensated, obviously. That's why it's expensive

Ok... take me through it. I apply to your company and after a short call you offer me to spend 4 weeks working at your place instead of an interview.

I go back to my employer, give them resignation letter, work the rest of my notice period (2 months - 3 months), working on all handovers, saying goodbyes.

Unless the idea is to compensate me for the risk (I guess at least 6 months salary, probably more), then I do not see how you'd get anyone who is just a poor candidate to sign up for this.

> You don't need him to become efficient

So what will you see? Efficiency, being independent and being a good team player are the main things that are difficult to test during a regular interview.

Re: AI killed the tech interview. Now what?

#147

Earlier quoted context omitted.

>we ask him to show us some code he has written How do you expect them to get access to the property internal Git repo codebase and approval from their employer's lawyers to show it to third parties during the interview? Sounds like you're only selecting Foss devs and nothing more.

Most people have still written code for school or a hobby project. Maybe I'm missing empathy, but I cannot understand how some developers have no code to show. If that's the case however, just let them make a small project over the weekend and then do another interview where you ask stuff about what they've made. It's not that deep

School was a few decades ago, and the code I have on Github is mostly toy stuff I do in rainy weekends, most of us have a life without room to code outside work most of the time.

Friends, family, stuff to take care of.

Re: AI killed the tech interview. Now what?

#148
post #65

Earlier quoted context omitted.

Most people have still written code for school or a hobby project. Maybe I'm missing empathy, but I cannot understand how some developers have no code to show. If that's the case however, just let them make a small project over the weekend and then do another interview where you ask stuff about what they've made. It's not that deep

I don't code much outside of work. I have hobby projects from 10+ years ago, but they're not much more than landing pages copied from templates and wordpress installs. I mostly work in backend/data/platform engineering professionally. If I were asked to make a small project over a weekend, I'd be likely to decline rather than doing a more standard interview, or I'd use AI to do it in a reasonable timeframe (which see…

This points to another issue - when I do code outside of work, it's often specifically to try out things I don't do at work. After a day of doing backend work, I'll maybe put together a basic web UI for something. That code is likely awful because I just need it to be functional more than good, and also probably not related to the work I'd be hired to do.

My most recent real "side projects" are a terrible OSS monte carlo simulator tool that I contributed to, but cannot explain most of the code for, and a half-working React application that has performance issues I never fixed. Both are years old at this point. I'm not sure what an interviewer would gain from those.

Re: AI killed the tech interview. Now what?

#149
post #88

Earlier quoted context omitted.

> Also, the best (albeit the most expensive) selection process is simply letting the new person to do the actual work for a few weeks. What kind of desperate candidate would agree to that? Also, what do you expect to see from the person in a few weeks? Usual onboarding (company + project) will take like 2-3 months before a person is efficient.

If you work with Boring Technology, your onboarding process has no reason to be longer than a week, unless you're trying to make the non-tech parts of the role too interesting .

> unless you're trying to make the non-tech parts of the role too interesting.

Unless your role is trivial to replace with an LLM, you need to understand the business. Maybe not for really junior role, but everything above - you need to solve issues. Tech is just a tool.

Re: AI killed the tech interview. Now what?

#150
post #139

Code reviews. Teams are really sleeping on code reviews as an assessment tool. As in having the candidate review code. A junior, mid, senior, staff are going to see very different things in the same codebase. Not only that, as AI generated code becomes more common, teams might want to actively select for devs that can efficiently review code for quality and correctness. I went through one interview with a YC company…

This is harder than it sounds, although I agree in a vacuum the idea is a good one. So much value of the code review comes from having actual knowledge of the larger context. Mundane stuff like formatting quirks and obvious bad practices should be getting hoovered up by the linters anyways. But what someone new may *not* know is that this cruft is actually important for some arcane reason. Or that it's important that…

You can do code review exercises without larger context.

An example from the interview: the code included a python web API and SQL schema. Some obvious points I noticed were no input validation, string concatenating for the database access (SQL injection), no input scrubbing (XSS), based on the call pattern there were some missing indices, a few bad data type choices (e.g. integer for user ID), a possible infinite loop in one case.

You might be thinking about it in the wrong way; what you want to see is that someone can spot these types of logic errors that either a human or AI copilot might produce regardless of the larger context.

The juniors will find formatting and obvious bad practices; the senior and staff will find the real gems. This format works really well for stratification.

Post reply on HN