Live data from Hacker News

Don’t do interviews, do discussions

thinkingthrough.substack.com

331–340 of 432 posts

Re: Don’t do interviews, do discussions

#331
I read a lot of anti-diplomas ideology, especially from US culture. Over the years I've realized that the multi-years selection people go through in academia is a decent and most importantly long process to select people.

A lot of the conversation is on interviews these days, on the idea that anyone can be a genius programmer after a bootcamp. While I don't deny it's possible, I think traditional selection based on the school people went to, and building a relationship between companies and school is a good thing.

Trying to holistically evaluate a worker in a few hours is not nice. It's very intense for candidates to have such opportunities to unlock in such a short time. People prepare for interviews intensely, and can live rejections as a deep traumas as a result. Having this process happen over years in academia seems healthier, and more accurate.

Companies would benefit from having their HR spend time studying curriculums of some schools, and build relationships. That guarantees a steady flow of qualified workers.

I see this where I live here in Japan, and I'm quite found of the work culture / society it produces.

Re: Don’t do interviews, do discussions

#332
post #268

Earlier quoted context omitted.

I feel like this is a pretty big ask to do for an interview, unless you happen to have it lying around already.

Yep, agree. 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. The 5% that isn't, has no place in an interview. It's a bunch of brittle glue code automating and backing up data between my devices. "Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest... Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the inte…

> 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws.

True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP (like util functions, and an integration syncing records from your backend the Salesforce, or something tangential to the business outside the core product)

May technically be breaking your employment agreement, but I can’t imagine it would be too hard to pluck out a decent amount of code, and re-write portions of it if necessary to “anonymize” it for interviewing purposes.

Or if you happen to be interviewed by someone like me, my approach is simply “if you can’t show me the code, show me the UI and explain how the backend / frontend works, and a discussion ensues.

Re: Don’t do interviews, do discussions

#333
post #331

I read a lot of anti-diplomas ideology, especially from US culture. Over the years I've realized that the multi-years selection people go through in academia is a decent and most importantly long process to select people. A lot of the conversation is on interviews these days, on the idea that anyone can be a genius programmer after a bootcamp. While I don't deny it's possible, I think traditional selection based on t…

That's good except, as you point out, in the US where schools are paid by the individual. At least some of the anti-diploma sentiment here in the US is because we understand that it would just result in "people born rich are the only ones who can get hired for good jobs".

Re: Don’t do interviews, do discussions

#334

I think the author has not really interviewed in the past couple of months / years. Now-a-days I see interviewers skipping the pleasantries and straight jumping on to LC style questions. In fact, in a lot of companies, the first couple of rounds are online assessments where you try to pound on LC mediums or hards without even talking to anybody else

>Now-a-days I see interviewers skipping the pleasantries and straight jumping on to LC style questions

lmao software houses in Eastern EU jump straight into day-to-day stuff, 99% of the stuff was normal development, that 1% was just for lulz, to check whether you heard about stuff.

0 algo questions.

Re: Don’t do interviews, do discussions

#335

Earlier quoted context omitted.

There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'l…

Sadly this isn't some sort of mass hysteria but based on practical experience. Yes, it's hard to believe. New interviewers are routinely shocked the first few times they are asked to take a candidate through a coding test. That's why everyone should just ignore the advice in the article - it's wrong. If you want to hire competent programmers, you need to test them rigorously by watching them code, in front of you. Ev…

I am an interviewer for C++ job candidates in the automotive industry.

I do a coding task first and a Q&A afterwards — because these are the requirements.

I did many interviews. My experience is: I could skip the Q&A completely. Most candidates could answer the questions just fine after reading the Wikipedia article for 10 minutes. In the interview I can see if they already read it or not. But I don't think it matters.

What matters are the coding skills. The coding task is quite simple and half of the candidates (with master degrees and 'years of industry experience') fail. But these candidates are often good talkers when they are chatting about the benefits of agile methodology and so on.

I totally agree with you that a candidate should just write any program. I believe I know after 15 minutes if they are developers or not.

But I also agree with the idea that we interviews must calm down the interviewee and remove the nervousness. I don't want to see if they stay cool in an exam situation because daily work is not an exam situation. I want to see if they can code when they are relaxed.

Re: Don’t do interviews, do discussions

#336
post #304

Earlier quoted context omitted.

I do experience-based interviewing, and i have never encountered this problem. The great majority of the time, people are able to talk about anything. Sometimes, there are sensitive parts of prior work, but a candidate can just talk around those bits and focus on the rest. Even if someone had been working somewhere super-secret, if they aren't a junior, they have other experience to talk about. If all your career exp…

I’ve worked at some large companies and would say this is wrong. I can’t talk about most of my best examples because they’re still roadmap items.

You can’t remove the identifying details and talk about the technical challenge and usage in a generic sense? Your system or software is that specific? Can you give a now public example?

Re: Don’t do interviews, do discussions

#337
post #222

Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews. Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem. I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follo…

> In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse? As an inte…

I wonder when will diversity require to also be skill-wise: like it is required to have someone on your team who cannot code at all, just for the sake of bringing "different perspective".

Re: Don’t do interviews, do discussions

#338
post #310

Earlier quoted context omitted.

Isn’t the time spent memorizing leetcode similar to the time spent building a side-project? I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.

No, it’s not, because take home assignments are not typically reusable. Learn leetcode and it is valuable at most companies you will apply to. It’s more respectful of your time.

I was comparing leetcode to sideprojects, not take home assignments. The parent company was also talking about side projects.

Side projects will help you learn useful skills and it is the suggestion of OP that it should be used by more companies in place of leetcode interviews.

Btw, a lot of companies don’t use leetcode for hiring. In my last job hunting season, I would guess than less than 20% of processes used leetcode. Pretty far from “most” companies.

Re: Don’t do interviews, do discussions

#339
post #336

Earlier quoted context omitted.

I’ve worked at some large companies and would say this is wrong. I can’t talk about most of my best examples because they’re still roadmap items.

You can’t remove the identifying details and talk about the technical challenge and usage in a generic sense? Your system or software is that specific? Can you give a now public example?

I can, and that’s usually what I do, but there are identifying details about the very specific domain which AWS only has a single product in.

So I can talk about architecting a system, about customer feedback and redesigns, but I can’t talk about work I did that will span another three years.

I think at FAANG it’s usually fine — most people have good enough examples even without their full repertoire. But at mid enterprise or F500 companies I could see this being a bit impactful.

Re: Don’t do interviews, do discussions

#340
post #329
post #220

Earlier quoted context omitted.

Yours looks like a classic "yes but I'm different" response. Maybe you really are different. I couldn't possibly say. Just be aware of it? Or maybe there's a way to have your cake and eat it too? Like put on a stupid hat and say "I'm going to play 'Joe Obnoxious the Arrogant' and be critical, this is not how we talk design around here in general but it cuts us the to the chase about something you know. Stand up to an…

This does not seems like a generous interpretation of what op said. The slight that op mentioned could have been surgical and precise, and just enough to kick off a conversation, and not enough to trample the interviewee.

Well you don't know the interviewee to make any assumption at all. I've given /my/ honest response to the description of it. Framed as a question, while noting some of the shortcomings of that. Then provided a suggestion of how OP might get what they want without causing the problem I suggested might, and OP confirmed actually does, occur.

So yeah I think that's pretty productive and positive as these conversations go. I don't see you adding anything of utility or value to it by suggesting bad faith or lack of generosity that I don't think exists on either side. "Surgical and precise" slights by definition can't be either from a position of ignorance, about the person you're slighting or the context and constraints of the work they've done. But you might get lucky. Even without luck it might not matter, maybe nobody else in the world would tell you to boil your head other than me? And nobody whose opinion or work you'd care about? YMMV.

Post reply on HN