Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

chrlschn.dev

Post reply on HN
Print view View original

261–270 of 286 posts

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#261

Post by shortrounddev2 »

nextlevelwizard wrote: post #254
shortrounddev2 wrote: post #28

Earlier quoted context omitted.

I literally never have anyone watching me code, and the time pressure of an interview is way shorter than a 2 week development cycle

So you have never worked in an office with other people? And yes couple hours of interview is different than two weeks sprint, but you are very naive if you think two week of work days means 80 hours of work. Plus I expect a lot more from you during a sprint than during an interview. During an interview I am fine with pseudo code as long as you can explain what you want to do. During actual sprint I actually expect t…

> So you have never worked in an office with other people?

I used to, but even then nobody actively watched me code. Everyone else had their own jobs to do

> During an interview I am fine with pseudo code as long as you can explain what you want to do. During actual sprint I actually expect tested deliverables.

So you're optimizing for the ability to write pseudocode under intense time pressure and social awkwardness. Is that the most important quality you seek in a candidate?

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#262

Post by ziddoap »

allo37 wrote: post #260
ziddoap wrote: post #249

Earlier quoted context omitted.

I don't understand how you reached that conclusion. If it is a personal interest or hobby, I do it on my own time. If it is something required for work, I do it on company time. If there is a lot of overlap, I do it whenever. Other than that, I learn and improve like any other person does. Continuing education credits, which is what started this subthread, is something required by the professional body that my compan…

Employers don't require their employees to be members of a professional order because they think professional orders are nifty- It's because certain jobs are only legally allowed to be performed by a member of said order. If you were a dentist and ran your own clinic, you'd still need to be a member of a professional order (at least in Canada and the US afaik) to practice dentistry legally, which would come with obli…

>Employers don't require their employees to be members of a professional order because they think professional orders are nifty

I didn't say they do it for nifty-ness. At risk of repeating myself again: if it is a requirement of my position, I get my employer to pay for it. Why it is a requirement doesn't matter to me.

If you want to pay for and do continuing education things on your own time and dollar, I'm not going to stop you.

>But I feel like one could argue that the informal expectation of software engineers to care about software

I didn't say I don't care. I just have plenty of other things that I care about that take priority when I am not working (spending time with my family, friends, doing other hobbies, etc.).

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#263

Post by yreg »

joelfried wrote: post #191
yreg wrote: post #148

Earlier quoted context omitted.

> then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign. What. Of course that "of the developers who have departed" all have left/been fired, that's a tautology. How is it "not a good sign"? Or is it supposed to be a bad sign that there even is a person who is not working there anymore?

I think parent meant: Assuming tenure is defined ONLY for those who have already left, 2 years is a bad sign. For a 3 year old company, if that definition is used, it is indeed pretty bad. It means that _of the people who are leaving_, people stay a couple of years, then bounce . This means people stick around long enough to get past the warmup of new employment, get used to your stack and tech, then bounce for green…

I still don't get what's bad about that. So what would be a good tenure for a 3 year old company if 2 years is bad? 2.5 years? 1 year? 6 months?

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#264

Post by nextlevelwizard »

shortrounddev2 wrote: post #261
nextlevelwizard wrote: post #254

Earlier quoted context omitted.

So you have never worked in an office with other people? And yes couple hours of interview is different than two weeks sprint, but you are very naive if you think two week of work days means 80 hours of work. Plus I expect a lot more from you during a sprint than during an interview. During an interview I am fine with pseudo code as long as you can explain what you want to do. During actual sprint I actually expect t…

> So you have never worked in an office with other people? I used to, but even then nobody actively watched me code. Everyone else had their own jobs to do > During an interview I am fine with pseudo code as long as you can explain what you want to do. During actual sprint I actually expect tested deliverables. So you're optimizing for the ability to write pseudocode under intense time pressure and social awkwardness…

[flagged]

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#265

Post by hudon »

danwee wrote: post #41
swader999 wrote: post #6

I like this article a lot and have had great success with this tactic (as a hiring manager) over the years. I often give a page or two of code as a take home assignment to discuss at the interview. They get a chance to look at it and research it on their own. And they also get a bit of the crucible of face to face thinking and reacting on their feet while you discuss it with them in the interview.

In the year 2023 tech companies are not "buying" (supply > demand) but "selling" (supply < demand); that means the hiring process should at least be equal in terms of time spent on it. Candidates spend way more time in home assignments (hours to days), while companies spend in the order of minutes to review the assigments. We think this is "normal" because "the company is OFFERING you a job"... that couldn't be less…

Considering all the layoffs, the closed positions, and job listings suddenly skewing heavily towards "staff" engineers, we are in a buyers' market (ie. the employers have all the leverage right now).

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#266

Post by n4r9 »

shaftway wrote: post #240
mcronce wrote: post #174

Earlier quoted context omitted.

I had a bug hunt as part of an interview once (or, I should say, once that I remember). It was different from that proposal in that the code was not part of the company's actual codebase - it was entirely fabricated for the test. It was fun, though; I enjoyed that more than livecoding and live-whiteboarding.

I had one that wasn't fabricated when I worked at Strip. There was an old bug in the requests library for Python where it was sending wrong data when posting a stream and the response had to be retried. The bug had already been fixed upstream. We cloned a repo, ran they tests, it failed, and the task was to identify why it failed. It was a tough process for me, since I've never really used Python debugging tools, so…

Thanks for relating your experience. I'm sorry to hear that it was uncomfortable and stressful, but it sounds like you must have reacted pretty well in those circumstances to get an offer. Do you feel like the skills assessed by the interview were reflective of what you ended up doing on the job (assuming you accepted) ?

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#267

Post by MPSimmons »

daotoad wrote: post #232
MPSimmons wrote: post #150

I consider myself a mediocre, if competent, programmer. I would like to improve my level of code reviews, but I'm on an operations team and I'm pretty much the only person who programs (it's a small company for now, but if we're successful, we'll grow pretty dramatically over the next few years). What tips would you have for doing this?

It's essentially the same advice given to writers. Read a lot and write a lot. If you can get access to review work by folks on other teams that do more coding, that would be a good start. From there, you need to allocate time to looking at changes closely. Don't just accept things at face value. Ask basic questions like "why is that there?" and "what does that really mean?" and hunt the answers down. Code consistenc…

This seems like really good advice. Thank you for taking the time to write this o ut!

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#268

Post by indymike »

ozim wrote: post #239
voiceblue wrote: post #234

Earlier quoted context omitted.

Unfortunately these types of requests come after you have presumably accepted the offer and declined alternative offers...

All “high-horse” claims work better when yo have cash in the bank and don’t need to get that job right here right now. I also decline signing NDA, providing data they should not request. Asking to cross off anything that encroaches intellectual property I might create after hours. But if I would need that paycheck ASAP all of it goes to trash and I would comply to most of shenanigans, maybe not all but still.

> Asking to cross off anything that encroaches intellectual property I might create after hours.

We're pretty big on making sure that our contract allows this as we encourage developers to do side projects - open source, etc. We do have an anti-double dipping clause.

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#269

Post by indymike »

gambiting wrote: post #235
indymike wrote: post #212

Earlier quoted context omitted.

This has never been a problem, except when someone is currently employed and is leaving a job to take one at our company. Right now, there's a lot of really good talent that does not have this issue.

>>except when someone is currently employed and is leaving a job to take one at our company. And in that case you do the check before they start with you, yes?

Of course.

Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead

#270

Post by hotnfresh »

nextlevelwizard wrote: post #256
ClumsyPilot wrote: post #34

Earlier quoted context omitted.

This reads to me as '90% of interviewers are incompetent at interviewing'. Most developers have no training in how to interview properly and little interest in learning, to most of them its a distraction and a bother. Most developers tend to ask questions about stuff they found challening or interesting, without consideration for how this related to the day to day job. Like asking a web developer to perform binary sh…

Yes. Communication is the biggest hurdle in any collaboration. I have not been part of multi stage interview process, so I don't know all problems there. But my point was more that if you find leetcode hard-to-impossible on difficulty scale, it probably means you are self taught and didn't bother with data structures and algorithms lecture/book/video/course. Again probably bad communication on my part. Our interviews…

The material’s not the hard part. You can just study that.

It’s the social environment and performance, often sustained for hours, that’s entirely unlike anything else I do. It’s not like emergencies (great at those), it’s not like being in a meeting with a hostile client (good at that), it’s not like any socially-difficult thing I do in work or life outside of it, and it’s certainly not like normal collaboration. Programming while being watched and judged is horrible and energy-sapping in its own special way.

Post reply on HN