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

I know why rejection emails suck – I write them

triplebyte.com

Post reply on HN
Print view View original

91–100 of 426 posts

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

#91

Post by iooi »

ransom1538 wrote: post #63
tptacek wrote: 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…

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…

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-...

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

#92

Post by tptacek »

chrisseaton wrote: post #64
tptacek wrote: 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…

Imagine a junior developer asking your senior developer a question about how a relational database does something. There you go, now it's a work-sample for your senior developer.

Sure! It's an objective work-sample process if you can say these things about the challenge:

* It's the same for all candidates.

* It captures facets of the work as it is done on the actual job.

* It's objectively evaluated (ideally, it has a rubric established a priori, such that results can be evaluated by someone other than the person who proctors the challenge).

It's possible to devise work-sample challenges that assess communication skills. I have friends who've done it at their companies for customer service and sales roles. I'm saying, the process described in this blog post does not appear to be that.

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

#93

Post by lixtra »

werbel wrote: post #70

If you/your company doesn't have a policy of sending personal feedback please consider doing this at least for junior people. Volunteer your after work time if needed. Trying to find the first job is extremely stressful process. A junior person has no notion of his worth on the market. Each rejection even if only by a lack of any response ("I'm sorry, I'm afraid we are looking for a bit more experienced person" would…

Our HR asked me to personally call people and thank them for their declined application.

But at the same time requested to not give any feedback because of fear from litigation. Sad world.

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

#94

Post by FLUX-YOU »

wdewind wrote: post #72
FLUX-YOU wrote: post #62

Earlier quoted context omitted.

>Isn't a lot of the job of software engineering to quickly and concisely communicate complicated concepts? No, I write code daily but I might have to distill down technical concepts once a week or so (usually not even that much) and even then if I happen to be the only one who can distill it down. If your devs are often explaining basic stuff like 'what is a relational database?', you need to hire someone specificall…

Sure, people don't need to explain RDBMS frequently, but that code you wrote last week? Or that reason you can't do exactly what the PM wants? YMMV but I spend a LOT of time communicating difficult concepts to other engineers (not only mentoring juniors, but also just doing hand-offs and stuff to others), to product managers, sales people etc. Some engineers really do sit in a quiet room all day writing code, but my…

>YMMV but I spend a LOT of time communicating difficult concepts to other engineers (not only mentoring juniors, but also just doing hand-offs and stuff to others), to product managers, sales people etc.

This is a good use of time though. You won't find this on wikipedia, obviously, and is not considered basic technical information.

This is what I want to spend my time explaining.

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

#95

Post by icedchai »

minimaxir wrote: post #79
pmiller2 wrote: post #75

Earlier quoted context omitted.

Naming a company and recounting an interview experience is not doxxing.

He named a specific person before the edit, which is a bit different. Nothing wrong with naming/shaming digg.com, though.

Naming a specific person is not nice, but still not "doxxing."

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

#96

Post by m104 »

joeax wrote: 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…

Precisely. Often times a rejection isn't saying that the candidate didn't meet the job requirements or wouldn't do well in the position, it says that the employer found someone who fit the role even better or knew that they could given past hiring experience.

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

#97

Post by scarface74 »

FLUX-YOU wrote: post #86
scarface74 wrote: post #78

Earlier quoted context omitted.

If your devs are often explaining basic stuff like 'what is a relational database?', you need to hire someone specifically to do that. It's not a good use of time especially when they can go google/wikipedia those concepts and figure it out themselves. If you can’t communicate ideas and basic concepts to non technical people, you will both limit your career opportunities and not be able to get your ideas implemented…

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort. At some point, we need to start demanding basic technical competence from the people around software developers. Otherwise, people will just be interrupting you all day and how much have we collectively written about that problem?

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort.

And that’s why developers don’t get ahead....

There are basically “three levers of power” in an organization - relationship, expert, and role in that order.

The developer who knows how to build relationships is the one that doesn’t get his silly bug put on blast by the QA and gets an unofficial Skype message and doesn’t get official very visible tickets when something blows up in production and gets a quick Slack message so that he can be prepared to explain it.

It’s also the different between a developer who has to submit a ticket to netops and wait three days for a VM and one that can send an email, get it set up within 30 minutes and then create the ticket as a formality.

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

#98

Post by [deleted] »

tptacek wrote: post #88
humbleMouse wrote: post #85

Earlier quoted context omitted.

> Why are you asking questions about relational databases? Why wouldn't you ask questions about relational databases? I would expect any decent dev to know the fundamentals of relational databases.

I think you're missing my point. Qualifying candidates based on relational database skill is not a problem; if it's something they'll be expected to do on the job, you should evaluate their ability. I'm saying the kind of Socratic interview alluded to in this article isn't the best way to accomplish that.

[deleted]

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

#99

Post by save_ferris »

I once got a detailed, feedback-driven rejection email, stating very clearly and professionally where I shined in my interview, and where I didn't. I was so appreciative of the message that I made sure to follow up with the manager working on my application and thanked them.

9 months later, I found myself in a bad management situation at another company, thinking about looking for another gig when the company that rejected me reached out asking if I'd be willing to come back and interview again. I did and accepted the offer.

By giving good and candid feedback, they wound up saving months of searching for a new dev when they reached back out knowing I was a good fit for what they needed at that time. I was essentially a lead they'd already warmed months prior. It made me wonder why more companies don't think of this.

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

#100

Post by SilasX »

FLUX-YOU wrote: post #62
wdewind wrote: post #51

Earlier quoted context omitted.

Isn't a lot of the job of software engineering to quickly and concisely communicate complicated concepts? Might this actually be an accurate work sample? How else might you measure something like this? Also the next few lines kinda address what you are saying: > It also might be that they know them inside-and-out but aren’t used to answering questions on the fly, or that our question didn’t use the vocabulary they’re…

>Isn't a lot of the job of software engineering to quickly and concisely communicate complicated concepts? No, I write code daily but I might have to distill down technical concepts once a week or so (usually not even that much) and even then if I happen to be the only one who can distill it down. If your devs are often explaining basic stuff like 'what is a relational database?', you need to hire someone specificall…

Once a week (or even every two weeks) is still frequent enough to count as a core job responsibility. And the raw frequency understates its significance, considering that it can be a blocker for other employees' contributions.

Now, you're right, the technical distillation is not going to be on the level of "explain relational databases to a Joe off the street starting from square one", but it's effectively the same as the skill of "demystifying arbitrary misunderstandings and knowledge gaps other have", which is important.

Post reply on HN