81–90 of 132 posts
Earlier quoted context omitted.
I interviewed a guy in person and he paused for 5 seconds, then wrote a perfect solution. I tried making the problem more and more complicated and he nailed it anyway, also after a brief pause. We were done in half the time. Maybe he just memorized the solution, I don’t know. Would you fail that guy?
I might hire him, but I would insist he clock out for his 5 second paused. We can’t have him wasting company time like that.
Earlier quoted context omitted.
It depends, I had some interviews like this that I suspected. For context, most of the interviews I conduct are technical design related where we have a discussion, less coding. So in those it is quite open ended where we will go, and there are many reasonable solutions. In those cases where I’ve seen that level of performance, there have been (one or more of): - Audio/video glitches. - candidate pausing frequently a…
The point is that I interviewed the guy in person and he nailed it 200%. If you interviewed him online you would likely come to conclusion he’s a fake per the criteria you specified, wouldn’t you?
Earlier quoted context omitted.
The questions were just a proxy for the knowledge you needed. If you could answer the questions you must have learned enough to be able to do the work. We invented a way to answer the test questions without being able to do the work.
To continue the point. If the knowledge you need is easily obtained from an LLM then knowledge isn’t really necessary for the job. Stop selecting for what the candidate knows and start selecting for something more relevant to the job.
The better option is to just ask the questions in person to prevent cheating.
This isn’t a new problem either. There is a reason certifications and universities don’t allow cheating in tests either. Because being able to copy paste an answer doesn’t demonstrate that you learned anything.
> Interviewing has always been a big can of worms in the software industry. For years, big tech has gone with the LeetCode style questions mixed with a few behavioural and system design rounds. Before that, it was brainteasers. Before Google, AFAIK, it was ad hoc, among good programmers. I only ever saw people talking with people about what they'd worked on, and about the company. (And I heard that Microsoft sometime…
> And we could interview like adults, instead of like teenagers pledging a frat. I think you're viewing the "good old days" of interviewing through the lens of nostalgia. Old school interviewing from decades ago or even more recently was significantly more similar to pledging to a frat than modern interviews. > people who are genuinely enthusiastic This seems absurdly difficult to measure well and gameable in its own…
Yeah, no, not at all. Interviewing in the 90s was just a cool chat between hackers. What interesting stuff have you built, let's talk about it. None of the confrontational leetcode nonsense of later years.
I still refuse to participate in that nonsense, so I'll never make people go through such interviews. I've only hired two awesome people this year, so less than a drop in the bucket, but I'll continue to do what I can to keep some sanity in the interviewing in this industry.
> Interviewing has always been a big can of worms in the software industry. For years, big tech has gone with the LeetCode style questions mixed with a few behavioural and system design rounds. Before that, it was brainteasers. Before Google, AFAIK, it was ad hoc, among good programmers. I only ever saw people talking with people about what they'd worked on, and about the company. (And I heard that Microsoft sometime…
Prepping for interviews has been a big deal forever in most other industries though. It's considered normal to read extensively about a company, understand their business, sales strategies, finances, things like that, for any sort of business role. I think tech is and was an exception here.
Earlier quoted context omitted.
Why wouldn't something like this work? 1. Get students to work on a more complex than usual project (in relation to their previous peers). Let them use whatever they want and let them know that AI is fine. 2. Make them come in for a physical exam where they have questions about they why of decisions they had to take during the project. And that's it? I believe that if you can a) produce a fully working project meetin…
If I read your suggestion correctly, you're saying the exam is basically a board explaining their decision making around their code. That sounds great in theory but in practice it would be very hard to grade. Or at least, how could someone fail? If you let them use AI you can't really fault them for not understanding the code, can you? Unless you teach the course to 1. use AI and then 2. verify. And step 2 requires a…
Exactly the same as in professional environments: you can use LLMs for your code but you've got to stand behind whatever you submit. You can of course use something like cursor and let it go free, not understanding a thing of the result, or you can step-by-step do changes with AI and try to understand the why.
I believe if teachers relaxed their emotions a bit and adapted their grading system (while also increasing the expected learning outcomes), we would see students who are trained to understand the pitfalls of LLMs and how to maximise getting the most out of them.
Earlier quoted context omitted.
The point is that I interviewed the guy in person and he nailed it 200%. If you interviewed him online you would likely come to conclusion he’s a fake per the criteria you specified, wouldn’t you?
It’s not a rubric I’m checking off for interviews. And in person it’s more straightforward to assess a candidate than questioning if they are using any aids over video… whats your point?