Live data from Hacker News

I know why rejection emails suck – I write them

triplebyte.com

161–170 of 426 posts

Re: I know why rejection emails suck – I write them

#161
> I recently talked with an employment lawyer about this, and he didn’t think that specific feedback on technical performance put companies at risk. So legal risk, despite being frequently cited, seems unlikely to be the real driver of policies here.

This was either written very poorly or lacks serious basis to conclude thoughts about employee feedback (of which drives the thesis of the whole article).

First - "I talked to a lawyer and he didn't think it was a risk", does not sound very much like legal advice. Is there precedence for civil cases that were thrown out due to the basis of "just giving technical feedback"? How often do firms that provide "just technical feedback" get sued and how often do they settle those suits?

Second - I think most people want feedback on "how they interviewed" and not "were they the right fit for the job". This is where you get into a gray area of legality, because anything you might say may get misconstrued as discrimination. "Oh you think I was too nervous during my interview...well I have X condition that makes me like that and you can't reject me for that"

Third - feedback on technical skills? To what avail does this hold for the candidate? Example:

Potential Employer: "You couldn't reverse a string, so work on string reversals."

Potential Candidate: "Ok, I'll go learn a string reversal so I can ace my next interview"

Feedback on interviews is imperfect because the hiring process is imperfect.

Re: I know why rejection emails suck – I write them

#162
post #83

I'm going to go against the grain and say that interview feedback is overrated (at least for senior people). If you got offered the job, then there's your feedback. If not, the interviewing company isn't going to tell you any more than you could already discern yourself by playing back your answers and conversations with the interviewers. If you honestly feel you aced the interview, then other factors are in play - p…

A rejection brings closure. If I spend four hours answering these silly Big O questions, the least the company could do is give me a definitive yes/no in a timely fashion.

Re: I know why rejection emails suck – I write them

#163

When I was a hiring manager, I used to always include a personal note that included suggestions and constructive criticism for the candidate. In a couple of cases, those people replied to me, demonstrated some actions towards those goals, and I hired them later, when I had more available positions. And those that I didn't hire, I encountered them at other companies. It was flattering to hear them say they remembered…

I interviewed for an internal position once and got similar feedback, by phone, from the HR person. She was on the phone with me for about an hour and, in all honesty, that rejection phone call made that one of the best interviews I've ever had. I didn't get that job, but it gave me a lot of constructive advice and I ended up getting the next one I interviewed for.

That's nice and helpful, especially since tech interviews can be taxing. Sounds like they actually liked you and probably would've hired you under different circumstances.

I had terribly frustrating experiences interviewing. Mostly just taking a bunch of tests and interviewing two, three times, and not hearing back for months. What sticks out was a post-interview for a large company that aggressively recruited from my uni. When I asked how I could have improved the answer was, "You ask too many specific questions about the company and software platform. Be more focused on the interviews." "For example?" "It isn't appropriate to discuss how wages are adjusted according to location or salaried overtime policies or the tech stack... in an interview..." I took that one as the, "not gonna drink the Kool Aid." box being checked. Dodged a bullet there, though, seeing as her answers did not exactly inspire faith.

Re: I know why rejection emails suck – I write them

#164
post #91

Earlier quoted context omitted.

If I understand correctly from this post on dba [1], HAVING without GROUP BY would have the same effect as WHERE. Seems like they were just being pedantic for no good reason. [1] https://dba.stackexchange.com/questions/57445/use-of-having-...

If one of the columns you're SELECTing has some sort of complicated expression in it (e.g. `UNIX_TIME(colA) - UNIX_TIME(colB) AS duration`), I think you can refer to that column by name in HAVING, but not in WHERE. It's a pretty niche thing though; I can't remember if I've ever actually used it.

I believe you’re correct.

However because HAVING takes place after all the results are fetched and processed (so it can do GROUP BYs) HAVING can’t use indexes.

So while the two will give you identical results if you’re not using a GROUP BY, the HAVING version could be thousands of times slower. Or worse.

Re: I know why rejection emails suck – I write them

#165
post #141

I believe that the article is fundamentally wrong. The bulk of the article is true. But companies are not lying when they say that legal risk is a reason not to send feedback. Triplebyte is in the unusual position of being able to say, "Everyone who has enough technical skill gets through the interview." And that fact is sufficient to defuse their risk. But real companies don't have the luxury of ignoring non-technic…

On the point of legal risk, I’m concerned by the authors naïveté in believing that as long as you’re not actually discriminating based on race/sex/religion, you won’t be accused of it. The more data you put out there, the more likely that someone will crunch it and find some statistical patterns that they will label “racism” or "sexism". Even if you’re innocent, you will get dragged through the mud in the press and m…

The upside is that you've treated a human being with decency. People you treat decently in rejection help you with later hires. If you're going to argue the fantastical downside, you should at least acknowledge the possible upside (which my company, and apparently TripleByt, have both experienced).

Re: I know why rejection emails suck – I write them

#166
post #40

When someone can’t answer an interview question about relational databases, it might be that they don’t know anything about relational databases. I thought you all were better than this. Why are you asking questions about relational databases? Why not just have candidates accomplish the thing you're assessing with an actual relational database ? I know you're work-sample-literate! But if your feedback emphasizes comm…

> Why are you asking questions about relational databases? Why not just have candidates accomplish the thing you're assessing with an actual relational database? It's not the same thing. Browse around the various SQL tags in StackOverflow and you'll see plenty of candidates who can "accomplish" things using relational databases yet have positively no idea of how they work. When shit hits the fan they're asking strang…

I think the better example of a problem would be asking them how MySQL handles something when you really care about relational databases/SQL in general.

Obviously if the job is highly MySQL specific and they need to know all the quirks that’s relevant.

Re: I know why rejection emails suck – I write them

#167
post #27

Earlier quoted context omitted.

>Every few months, I check that all our recommended resources are still up-to-date, available, and free. What are your recommended resources for technical improvements in coding interviews?

We have a blog post with some recommendations based on what we've seen at Triplebyte: https://triplebyte.com/blog/how-to-pass-a-programming-interv... I think it's a pretty good starting point. I also like Cracking the Coding Interview and I think there's definitely a place for timed coding challenge sites like leetcode - especially if you've been in a role where you're mostly working on larger-scale problems rather t…

Can you tell me what companies find attractive about: "...producing smart, working code quickly[;] on the fly," (emphasis mine)?

I understand there are a lot of substandard programmers in the marketplace. However, why is it that this specific criteria is the one the industry is so attracted to? Could it be that kids are proficient at these kind of games? Because I can tell you that in the 1980s, 1990s, and early 2000s, I wasn't being asked to write a regular expression parser under time pressure.

Others in this thread say they've done Triplebyte take-home tests, only to end up in a "go fast-fast-fast!" interview in the end.

Why is speed so important? Every popular [aA]gile methodology today is implicitly -- if not explicitly -- against such "machismo" programming. If you're pair programming, how is this ever relevant?

Whenever I see someone say leetcode, hackerrank, and Cracking the Coding Interview is the "answer" it translates to "only the young need apply" in my head.

Re: I know why rejection emails suck – I write them

#168

Earlier quoted context omitted.

It is harder to build a work-sample regimen than to just send candidates to interviewers, sure. But then, the point of Triplebyte is that they're eating all that work for you. Regarding "fleets of laptops" and environments and all that jazz: these seem like unforced obstacles. Just have the candidates use their own machines. Here's a crazy idea: have them use their own offices/couches, too. Regarding security practic…

Just have the candidates use their own machines. We tried inviting candidates to bring their own laptops, and it turns out often they didn't _have_ laptops - or we'd tell them there was a Java-based test and (perhaps due to a miscommunication or because this is an uncommon interview practice) they'd arrive with a laptop without a working Java VM or compiler. Needless to say, you can't objectively compare two candidat…

If you insist on doing the interview in person, why not just tell them ahead of time what their environment needs to do when they get there? Give people instructions and a script (formal or just a numbered list of steps) that determines they're ready to go.

Better yet, just don't make people do that stuff in your office.

Why bother videorecording interviews at all? I'd have problems writing a line of code with someone breathing down my neck. If you did it to me on the job, I'd chase you out of the room. I feel like a lot of these problems are, like I said, unforced.

Agree to disagree about the degree of difficulty of getting clean environments to candidates. You're either serious about recruiting as an engineering problem or you're not. "Not" is fine, but then don't pretend like there's some kind of rigor in deciding which corners you're willing to cut.

I'm not making this stuff up; this is how we've been hiring people for about 10 years now, and every time I hear someone explain how challenging or untenable our process is, I keep wondering, "what am I doing wrong to make this work so well for us?"

Re: I know why rejection emails suck – I write them

#169
post #141

I believe that the article is fundamentally wrong. The bulk of the article is true. But companies are not lying when they say that legal risk is a reason not to send feedback. Triplebyte is in the unusual position of being able to say, "Everyone who has enough technical skill gets through the interview." And that fact is sufficient to defuse their risk. But real companies don't have the luxury of ignoring non-technic…

[deleted]

Re: I know why rejection emails suck – I write them

#170

Earlier quoted context omitted.

I have been doing mysql database type things for 15 years solid. Once during a job interview at digg.com, someone [ok ok doxx removed] asked: "what is a having statement in sql?". I jumped in explained how you can filter aggregated sets performed by a 'group by' and rambled on and on. He stopped me and said, "You can use a having statement without a group by, are you sure you know how they work." I have never seen th…

This person probably wanted you to say that there might be a performance problem in filtering a result set using HAVING, instead if selecting rows using WHERE, if the query optimizer fails to see the equivalence. And the only reason why they knew was because they fixed that very same problem one week before, after debugging it for three days, as it is often the case with bad interview questions. Edit: shouldn't assum…

Have you ever seen anyone using having in place of where honestly?
Post reply on HN