This reminds of restaurants throwing out food because the risk of giving it away is too great, but as far as I know no one has ever gotten in trouble because of it.
No engineer has ever sued because of constructive post-interview feedback
401–410 of 646 posts
Re: No engineer has ever sued because of constructive post-interview feedback
#402Earlier quoted context omitted.
Do any of the take-home projects actually only require 2 hours though? Maybe some of them have a recommended time around there, but isn't it basically required to spend longer?
This is one more problem, programmers are really bad at estimating time required for completion. When it comes to these things programmers designing the interview tend under estimate the effort required to finish the projects. What makes this whole thing complicated is how they go about measuring quality, extensibility, or if they measure feature completion. Most companies that give you a take home assignment also ge…
Programmers are bad at estimating time to completion for their own work, it's true. But to ask them to estimate someone else's time is unfair because that depends heavily on the individual. Some will finish in 2 hours, and that is probably who they'd like to hire.
Re: No engineer has ever sued because of constructive post-interview feedback
#403Earlier quoted context omitted.
Ah so a good interview question for a candidate is something that YOU have experience in. Does that seem odd? Do you think you would be an expert in something the candidate had experience in? Probably not. Should you find out how they speak about something THEY are experts in? Probably. But like the OP said, tech interviews are about posturing so that the interviewer feels better about themselves.
does that seem odd? Not at all! How can anyone evaluate a someone else's performance in a domain if they don't know the domain? You ask the question many times over so you can judge performance relative to others. Yes, the interviewer should be familiar with the topic of the interview.
If the idea is the answer is not important, the process is, then how many variables should you have? Your way, you have two variables:
1. Knowledge of the domain 2. Process
So, your question is not matching your goals.
Re: No engineer has ever sued because of constructive post-interview feedback
#404Earlier 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…
I don't expect you to believe that we took that all into consideration, but we really did. Several people said it was genuinely fun.
Re: No engineer has ever sued because of constructive post-interview feedback
#405Earlier quoted context omitted.
> because apparently 'cat error.log | grep 'ERROR:' | wc -l' is not how real programmers find error count I've been on the other end of that, where we were explicit that the goal of the exercise was to solve problem X with technology Y so that we could gauge the applicant's skill with Y. And yet, we'd still get submissions that used Z because it was way better at solving X than Y was. Well, yeah, we know that. That's…
If you know that Z is the best way to solve X then why would you ask them to solve X with Y? Why not give them a problem to solve that Y is best suited for? It sounds like you got multiple solutions that used the best tool Z, but yet you reward people for being fine with using an inferior tool. That's not exactly the pool of applicants I'd want to bias my search towards. Edit: I just want to add that I don't mean to…
Well, in the parent case X might have been "count the unique lines in a file", Y might have been Python because they were interviewing for a Python job, and Z might have been "cat | sort | uniq".
What the interviewer wants to know in this example is whether the author understands Python and file IO and data structures. Sure, you'd use the Unix pipeline in a production setting because it's better tested and faster. But in an interview context, that doesn't tell you whether the candidate is more likely to store item counts in a list or a dict, and that's what you're really trying to dig into.
Re: No engineer has ever sued because of constructive post-interview feedback
#406Because giving good feedback is hard work, and candidates won't always take it well (even if they don't sue). If the employer has already decided not to hire you, there's just not that much in it for them. For what it's worth, as an interviewer I'm happy to give feedback in person, at the end of the interview, if the candidate asks for it. It's much easier to do when you're both in the same room, and asking e.g. "is…
I hate it when candidates put me on the spot at the end of the interview, because it feels like they're trying to get me to tell them (or at least hint to them) if they're going to get an offer or not. Even if that decision were wholly within my hands (it rarely is), I'm not ready to discuss it with them at that point. The other way it sometimes goes, if I do cave and give some feedback, is that they try to disprove…
Agreed, I'm way more willing to give feedback after the decision has been communicated.
Re: No engineer has ever sued because of constructive post-interview feedback
#407I'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…
You probably wouldn't like the feedback. Most interviews these days are random because our field is obsessed with finding 10x megarockstar GTD superprogrammers. I can't think of a single field where interviews are such awful experiences. All interviews could be simple Q&A sessions to make sure the person isn't a charlatan and then sell them on the position. HR isn't a science, and it never will be. The FAANGs spend g…
>The FAANGs spend god knows how much time and money on it, and they admit that their interviews aren't better than a coin flip.
I'm curious what this means. Whiteboard style interviews aren't perfect, but at the very least they demonstrate 1. You can communicate with another engineer on a technical problem (simply writing the code with no explanation isn't sufficient), and 2. You have the determination to study CS topics for a long enough time to be prepared for an interview.
Both of those skills should have at least some correlation with success at your job, certainly better than a coin flip.
Re: No engineer has ever sued because of constructive post-interview feedback
#408Earlier quoted context omitted.
>I've never placed much weight on being able to write a program on the spot. I don't disagree, and personally I hate in person coding exercises, but if you keep the question simple and allow the candidate to code in their native language, something fizz-buzz like will go a long way in weeding out the people who have languages on their resume but can't code. At our company we offer two simple coderpad tasks to be done…
> You pay attention to the candidates who use templates, destructors, smart pointers, even if they make mistakes those are the ones you probably want to hire. Maybe I don't know enough C++ to understand this, but I don't understand why using fancier features would make you like the candidate more when they are making mistakes. Unless you ask them to write a templated linked list, why would you grade them for automati…
>Maybe I don't know enough C++ to understand this, but I don't understand why using fancier features would make you like the candidate more when they are making mistakes.
It's not about cool features. It's about using the correct modern features which make the code safer and easier to follow.
Templates are a relatively advanced feature but trivial to write for such a case and I'm looking for a candidate who understands containers are typically generic and knows how to add the two lines. I take it as a marker of experience.
There's no excuse other than inexperience or old fashionedness to not use smart pointers.
Destructors are also a sort of minimal knowledge because they show that a candidate thinks correctly about memory management.
There isn't really a score to what we do. And in all honesty the first few times we gave the test I didn't really know what to look for, this is my first time from the other side. But it isn't too much to expect a competent cpp programmer to know these things and I'm looking for candidates who are willing to use the open ended opportunity to flex their muscles, provided their code is well structured and doesn't have severe, obvious bugs. I don't claim that this is perfect but it seems suited to screen for the basic kind of knowledge we look for. These are not entry level positions either.
Re: No engineer has ever sued because of constructive post-interview feedback
#409Honestly, I'd even take a rejection letter at this point. A lot of places have gotten into the business of not letting you know if you got rejected.