Live data from Hacker News

No engineer has ever sued because of constructive post-interview feedback

blog.interviewing.io

541–550 of 646 posts

Re: No engineer has ever sued because of constructive post-interview feedback

#541

You generally don't get technical interview performance feedback because technical interviews are constrained by the interviewer to put themselves in a technically confident light against the candidate. The interview is as much a crapshoot for the interviewer, because they might be less/more/similarly skilled to the candidate, but they absolutely cannot reveal themselves to be less skilled because they would undermin…

My favorite interview question is a real life issue I faced where a short sighted database design wound biting us in a pretty serious way. It's a good technical problem to talk through, and provides a lot of useful information about the candidate, but it's also an excuse to set very clear expectations that I'm not looking for the "right" answer (in real life it took half a dozen smart people a couple hours to come up…

This does seem logical: here is a hard problem we actually faced and solved; we want to hire people who, faced with that sort of problem could solve it; let's see whether the candidate can solve that sort of problem.

You're also right that sharing the problem does place you in a position of vulnerability. It's perfectly possible that a candidate will think 'what a bunch of idiots to have gotten themselves in that mess in the first place'. Or worse, when they realise how you solved the problem, 'wow, they think they solved their problems? They're in an even worse spot now'. So I appreciate that you see this as being humble and exposing the candidate to an opportunity to know more than you.

But the reality is, when you solved that problem, you:

1) knew all of the context and constraints, spoken and unspoken

2) had a team of folks around you to bounce ideas off and collaborate on the solution

3) had access to google, stackoverflow, etc.

4) did not have to come up with a solution inside a small interview room, within a few minutes, while being judged by someone who has decision rights over your future employment

5) crucially, had found yourself in a position where you needed to know how to solve this problem. If you hadn't had that need, you would never have acquired that knowledge. So unless the candidate had also faced this exact problem, why would they know how to solve it? You work here, and you didn't...

And while it might be nice to hire someone who can, under interview conditions, jump right to the right solution shortcutting all of those processes - it would obviously fill in a knowledge gap your team demonstrably had - looking for a candidate who has already learned something that came as a hard-won lesson for your team is like a general building up an army to better fight the last war.

You can do better: Use the problem as an example of the sort of thing your team has struggled with, and ask the candidate to give examples of similar problems they have solved in their own career. You are hiring them for their hard-won lessons, and adding them to your own, not looking for someone who happens to have also won the same lessons you already have.

Re: No engineer has ever sued because of constructive post-interview feedback

#542
post #121

On the topic of form letter rejections: I WISH I even got those... durring my last job hunt most of the time the company just goes dark and stops contacting me or doesn't respond. I say this and other recruiers tell me they're shocked and yet getting ghosted seemed to be the rule rather than exception durring that time. Maybe I'm such a bad canidae that they don't even want to bother with a form letter. Strangely one…

My experience is similar. I'm currently job hunting again, and this week I spent hours reading through this month's "Who's Hiring" post, making my best effort to write cover letters addressing what each company needs and how my skills and experience can assist them. I got 2 responses. Both were impressed by my resume so I don't believe that's the issue. Its really hard not to take it personal when it's such a common…

I've found that unless you use some of the big-name e-mail providers, there's a high chance your letter wasn't even seen.

Companies tend to use some providers e-mail solutions and some of them are way too trigger-happy for spam.

It's gotten so bad, that before applying, I look at their MX records and if it's gmail, I won't even bother unless i really-really want the job. In that case I follow up with a phone-call.

Re: No engineer has ever sued because of constructive post-interview feedback

#543

Earlier quoted context omitted.

> If you make a conclusion on made up data you get bogus conclusion No. You work with made up numbers to understand the problem. Then you can make conclusions even without knowing the precise numbers. For example, my analysis doesn't change much wheter the rate of lawsuits is 0.1% or 0.01% or 0.001%. It would change if the rate of lawsuits is 1%. But I am pretty sure that the rate of lawsuits after interview rejectio…

What I'm saying is that even with the lawsuit rate that low, there is no real incentive for the company (really the people sending the emails) to behave otherwise than they already do. Actually their benefit is that low, that even a slight error of that 0.1% guess would make the whole do-good business a really bad proposition. Your (guess) data is probably right but it discounts too much the downsides. When you prese…

The incentive is “be a good person/entity.” This whole bottom-line approach and “what’s in it for me” is unfortunate to say the least. Behind every corporate establishment is a cadre of people. People with (possibly) spouses, children, non-deceased parents, neighbors, and friends. Possibly at some abstract level similar to the abstract “us.” Treat people like people, not some kind of legal liability.

Re: No engineer has ever sued because of constructive post-interview feedback

#544
post #385

Earlier quoted context omitted.

Having been on the hiring side of that, we spent way more time coming up with and testing the take home project than our applicants ever spent on it. Among other things, we'd beta test a proposed "challenge" on each other to see how well it worked out in real life before springing it on candidate. It would have been a lot cheaper not to have the take home project, but we decided it was worthwhile anyway. (Disclosure:…

You spent that much time over several dev sprints/cycles/months/whatever. Meticulously designing the expected output and quality expectations(yet not sharing any of that in the spec supplied to the candidate). All that automated testing, manual code review checklist was designed after spending that many man hours worth effort to arrive at. You have the benefit of hindsight, and insights from the process that refined…

Agreed and what your describing actually happens in a lot of work environments. I've seen a trend in the last few years where middle management is attempting to separate "programmers" from "engineers/architects". In these environments the "programmers" don't really have the luxury of sitting with the business or product teams nor the luxury of taking part in the design process.

What ensues is actually comical. During "grooming" sessions the "programmers" are meant to give accurate estimates of how long (I know time is not meant to be the metric but it always is) a story will take to complete. A story which there are many, many person hours of context baked in that the "programmer" is seeing for the first time.

Context is worth 80 IQ points --- Alan Kay.

Re: No engineer has ever sued because of constructive post-interview feedback

#545
I had the most amusing realization at work the other day: most software engineers “hate” how their coworkers write software. I took it a step further and realized I hate software I wrote a year ago. Giving objective feedback should be a cherished skill.

Re: No engineer has ever sued because of constructive post-interview feedback

#546
post #339
post #309

Earlier quoted context omitted.

Yeah, the space of things I can do quickly on the spot from practice, and the space of things I can get really good at after a few hours of re-calibrating, research, and trial and error are worlds apart. If I were hiring, I'd 100% look for people who can self-teach above all other technical qualifications (above and beyond whatever the basic competency level for the position is).

I only get an hour together or a bit more if I'm lucky. In terms of people I've hired, if they can solve and code things in real time on a white board, then they can definitely do even better with more time and research. Everyone does better with research, trial, and error. That's not unique. What's unique is problem solving on your feet in a foreign environment. I want those people.

> Everyone does better with research, trial, and error.

Better? Sure. Not everyone can go from 0 to competent in a new area within a reasonable time frame.

Re: No engineer has ever sued because of constructive post-interview feedback

#547

I'm so disappointed to read comments on this thread to the effect of "There's nothing in it for the company but risk". I once put in about 8 hours on a take home project at a company (well known in these parts) that I had tremendous respect for, only to get an email back with "sorry, not up to par. We need someone with more experience". I asked them for a couple quick points on what I could have done better. I had ze…

I had one homework assignment where the API keys they provided didn’t work. I spent 2 days playing tag with the hiring manager just to get functional credentials.

Re: No engineer has ever sued because of constructive post-interview feedback

#548
post #539
post #536

Earlier quoted context omitted.

>>There is no laundry list. Followed immediately by. >>There is an expectation that a senior engineer writes codes like a senior engineer. You have no written list, but an imaginary checklist running in your brain about how a senior engineer writes code. Other engineers have theirs. I ran some of it and guess what, in that list absence of basic documentation, unit test cases, basic exception handling, code with types…

Welp. This is the point I checkout. You do you, but I have to ask. Do you have any production experience[1] and/or hiring experience? Because you have a very fundamental misunderstanding of both, and I find it very hard to believe that someone who has written even trivial applications would think that not having sql injection is an extra requirement or is going to take too much time, or anyone in hiring position is n…

I keep repeating that this is not about SQL injection. You could be asked to write a command line app which doesn't even involve a SQL database. And yet there could a lot of such security or even other add-on's on which your code could be evaluated. We are literally discussing code quantity + time Vs Quality here.

>>Do you have any production experience >>db calls aren't randomly placed in try/catch - that will be absurd.

Calls to databases go wrong all the time. Session objects expire, if you have cert based auths, they expire all the time. Especially if you have a largish microservices stack. Or you have locks on db objects, which you would run into. Or that network got flaky, or that just a certain type of resources like maxing out on db connections. Or that you are just trying to do write something to a database that is not allowed, like a duplicate primary key.

Never assume a database or any IO call for that matter will always go right.

Always check for every possible exception that could likely be thrown and handle it appropriately. Preferably each db interaction function should be atomic, and exception should be bubbled/raised/thrown to the application/feature main loop so that appropriate action like a retry or a roll back can be taken.

>>And the None checks aren't necessary because of something which you can very clearly see in the sample code but you also very clearly don't understand.

Pretty much any large codebase, that passes objects around should always do Null pointer checks. This is because several times resource heavy objects are initialized only on certain conditions, and if such objects are passed around they must be checked.

Re: No engineer has ever sued because of constructive post-interview feedback

#549
post #282

Earlier quoted context omitted.

Non paid take home projects... Huge red flag.

I see this a lot but it seems fairly naive to expect. There’s absolutely nothing wrong with refusing to do them, but to get paid? Has anyone in the history of the world been paid for an interview take home project? Curious how it was set up and what the rate was. Did you have to file taxes? Was it 1099?

Yeah, I agree, the logistics are tough and the comment was really just a proxy for...

A company that must rely on a take home project to get a meaningful assessment of your worthiness and competency for a position is a huge red flag.

Any engineer worth their salt can tell from an on sight interview if a candidate is bullshitting about their past accomplishments.

Re: No engineer has ever sued because of constructive post-interview feedback

#550

I'm so disappointed to read comments on this thread to the effect of "There's nothing in it for the company but risk". I once put in about 8 hours on a take home project at a company (well known in these parts) that I had tremendous respect for, only to get an email back with "sorry, not up to par. We need someone with more experience". I asked them for a couple quick points on what I could have done better. I had ze…

It's the small things this whole industry is a toxic brew I'm sick of all of it

Do you have a plan on something else to do? I quit my job and got a part time job doing development in a different field after a few toxic years.

The same lack of understanding/appreciation can be felt in some jobs, but a change might be good?

Ultimately I'd work at a garden centre or something and be outside more, but the pay would be less ! In any case, hope you have a plan.

Post reply on HN