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

Don’t do interviews, do discussions

thinkingthrough.substack.com

Post reply on HN
Print view View original

311–320 of 432 posts

Re: Don’t do interviews, do discussions

#311

Post by austincheney »

rsj_hn wrote: post #144
austincheney wrote: post #100

Earlier quoted context omitted.

Think about it like this. The goals are attain employment and maximize compensation. That’s it. That said you are probably best off training machine learning to do this for you. It won’t suffer the nonverbal faults associated with dishonesty, because truth to a machine is how effectively it completes the assigned goal.

> Think about it like this. The goals are attain employment and maximize compensation. That’s it. Meh, I think devoting 30-40% of your life to something is more than just maximizing compensation. In tech, at least, you normally have quite a few options about where you will work and what you will do. If you feel you need to lie just to get into the door and are convinced that you wont get the job unless you do lie, th…

The reality is that most people are not completely honest. Extreme honesty is shocking and casually associated with extreme personality types or behavior disorders.

Re: Don’t do interviews, do discussions

#312

Post by agent327 »

kube-system wrote: post #170
joshgachnang wrote: post #166

Earlier quoted context omitted.

This is really interesting! What kind of questions do you ask in the written portion?

The written portion is part of our take-home coding test. We have the candidate do a short and simple coding exercise, and at the end, there's a couple open-ended questions about their approach, what they could have done better, etc. I find it really insightful to give people a simple exercise to complete and then ask them to talk about it. The answers to the questions are almost more telling than the code itself. Yo…

If you want a job, about the last thing you are going to want to say is that you were in a hurry (meaning "I didn't care about this job enough to pay proper attention to this"). This is going to be your calling card, so it has to look great! You make it appear as if you are penalizing people for going the extra mile to complete all the requirements.

Re: Don’t do interviews, do discussions

#313

Post by auggierose »

swman wrote: post #197

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with…

I don't like it, but I get it. You can train for the algos, so just do what needs to be done and train for it. Maybe you don't like to do what needs to be done? Well, that filter worked.

Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)

Re: Don’t do interviews, do discussions

#314

Post by philbert101 »

dataengineer56 wrote: post #306
philbert101 wrote: post #250

Earlier quoted context omitted.

This is pretty pretty much what I tried to achieve here https://github.com/philbert/take-home-tech-test The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to. Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the re…

I would immediately end my interest in a company if I was asked to do this. This is far too general a problem, which will harm the interviewer as much as it will harm the interviewee. Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it. The advantages of the latter approach: * Th…

We've been using it for DevOps roles which are not highly specialised in any particular technologies and require ability to solve problems at a general level.

The test is intentionally designed to filter out candidates who cannot meet or do not want to meet the technical requirements.

Re: Don’t do interviews, do discussions

#315

Post by dataengineer56 »

philbert101 wrote: post #314
dataengineer56 wrote: post #306

Earlier quoted context omitted.

I would immediately end my interest in a company if I was asked to do this. This is far too general a problem, which will harm the interviewer as much as it will harm the interviewee. Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it. The advantages of the latter approach: * Th…

We've been using it for DevOps roles which are not highly specialised in any particular technologies and require ability to solve problems at a general level. The test is intentionally designed to filter out candidates who cannot meet or do not want to meet the technical requirements.

Fair enough, maybe that works better in devops, but it seems like it will filter out candidates who have a good work/life balance.

Re: Don’t do interviews, do discussions

#316

Post by turbinerneiter »

mark-r wrote: post #208
turbinerneiter wrote: post #24

I've lately been trying to get people to teach me something as an interview. Interviewed a guy with a PhD in organic electronics and asked him how to make an organic transistor at home. It was a great conversation, not sure yet if it was a great interview.

I once had an interviewer ask me an obscure C++ question. I didn't know the answer, so I reversed it and asked if he knew. He did, and it taught me something I didn't know before. No, I didn't get the job. I no longer even remember the interviewer's name, but I remember well the question and answer.

When I started doing interviews I also had some C++ questions (like what is the difference between const and define and some random stuff like that), that I was always unsure about: are these things actually telling me that the person is a good C++ programmer, or am I just asking some random stuff that I happen to know?

Re: Don’t do interviews, do discussions

#317

Post by sokoloff »

csydas wrote: post #273
Hermitian909 wrote: post #263

Earlier quoted context omitted.

It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal. A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in t…

Honestly, one of the safest and most powerful tools is just to continually ask "why" questions as a result of whatever they say in regards to technical details, with a scattering of "how?" questions. Others in the comments have expressed some legal concerns about "discussions" instead of Interviews, but I feel this is a hyperbolized fear based off a laypersons interpretation of US hiring law. The law requires you ask…

> The law requires you ask the same set of questions of all candidates

Does it? I have never heard of such a requirement in a law (though I’m not a lawyer). That might be an employer’s decision on policy they use to ensure compliance with the law, but I couldn’t quickly find any law requiring the questions to be uniform across candidates. (It’s also a difficult set of terms to quickly and confidently exclude the possibility that one exists.)

I guess that’s a longer (and hopefully more polite) way of saying “citation, please.”

Re: Don’t do interviews, do discussions

#318

Post by native_samples »

stackbutterflow wrote: post #284
native_samples wrote: post #280

Earlier quoted context omitted.

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…

Then why ask candidates to solve a leetcode hard or two mediums in 45 mins? If you're afraid of people who can't code any program then ask for leetcode easy.

Sure but the article isn't about difficulty of coding challenges, or where you get them from, but about doing them at all.

Re: Don’t do interviews, do discussions

#319

Post by csydas »

sokoloff wrote: post #317
csydas wrote: post #273

Earlier quoted context omitted.

Honestly, one of the safest and most powerful tools is just to continually ask "why" questions as a result of whatever they say in regards to technical details, with a scattering of "how?" questions. Others in the comments have expressed some legal concerns about "discussions" instead of Interviews, but I feel this is a hyperbolized fear based off a laypersons interpretation of US hiring law. The law requires you ask…

> The law requires you ask the same set of questions of all candidates Does it? I have never heard of such a requirement in a law (though I’m not a lawyer). That might be an employer’s decision on policy they use to ensure compliance with the law, but I couldn’t quickly find any law requiring the questions to be uniform across candidates. (It’s also a difficult set of terms to quickly and confidently exclude the poss…

Sure:

https://www.eeoc.gov/employers/small-business/3-im-recruitin...

Screen applications consistently. Apply the same standards to everyone applying for the same position.

Effectively, you should have the exact same criterion for all candidates for the same position and avoid "on the fly" questions/too heavily customizing it.

The legal discussion on all of this has basically boiled down to that you must ensure you're going through the same process for each candidate with the expected variances based on their employment/personal history (as it's relevant to the position)

I may overstate the situation slightly with that statement, but the idea is that if you ask about a networking stack for candidate A, you should ask the same probing questions for candidate B also. (Consider maybe you know that candidate B doesn't know this stack and will look "negative" on a review to the hiring managers, but you really like candidate B for other reasons)

Ultimately the idea is less about the specific questions and more that Candidate A and B are both reasonably considered in the same fashion for all of the requirements of the position, and that you aren't adding/omitting elements that may influence the applicability of the candidate in any fashion.

So let me restate: It's not required you ask verbatim the same words for each candidate (this is the lay-person over-read).

But for a given position, it should be established in advance a series of competencies that are necessary for the position and that are to be asked of each candidate. How you go about investigating it may vary from candidate to candidate, but should two interviews be reviewed, it should be expected that both interviews cover the same topics to a reasonable degree. (e.g., it is reasonable that if you ask "have you ever worked with library X" and the candidate flat out says they cannot answer questions on library X, you have reasonably covered that topic with this candidate. If you ask another candidate and they do have experience with library X and you ask some additional questions, you have not violated the spirit or letter of the requirement in this case.)

Re: Don’t do interviews, do discussions

#320

Post by chakkepolja »

native_samples wrote: post #318
stackbutterflow wrote: post #284

Earlier quoted context omitted.

Then why ask candidates to solve a leetcode hard or two mediums in 45 mins? If you're afraid of people who can't code any program then ask for leetcode easy.

Sure but the article isn't about difficulty of coding challenges, or where you get them from, but about doing them at all.

It's a vicious cycle.

As companies ask 'Leetcode easy' questions, there came to be thousands of online blogs, youtube channels etc.. which trained even the n00bs who can't write good code otherwise. If they train very well they can solve 2sum or write binary tree level order traversal without understanding much. Of course not all interviews can use novel exclusive questions, and these have a non-negligible chance of passing.

Now if you are hiring, you would think, "If these n00bs can solve Leetcode easy with practice, the good ones are solving Leetcode medium with same level of practice. So let's raise the level of questions so that we don't end up hiring these rote-learning noobs". And it continues.

I don't think there's an obvious solution to this, if you don't want to lose the statistically good heuristic of problem solving skills, in order to weed out candidates.

Post reply on HN