I know why rejection emails suck – I write them • Hacker News Board

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

#421

Post by irq11 » Wed, Aug 29, 2018, 3:14 PM UTC

0xfeba wrote: post #405

irq11 wrote: post #391

Earlier quoted context omitted.

I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult. Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over t…

> Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. Interesting, and I won't look up the article again before writing this comment. I remember it as saying he was having a hard time finding people that can code at all, that a FizzBuzz is weeding out a large percentage of applicants. I don't recall it as a gateway…

You’re remembering it incorrectly.

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

#422

Post by irq11 » Wed, Aug 29, 2018, 3:20 PM UTC

dunpeal wrote: post #403

irq11 wrote: post #391

Earlier quoted context omitted.

I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult. Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over t…

Communication is obviously being tested in both phone screens and onsites. It's not like a candidate in a coding interview can simply start coding silently, finish, and then pass to the next stage because their code works. A big part of a coding interview is working with the candidate. > the ability to read code How do you test for that in isolation? There are exercises that do that: you show the candidate a piece of…

Again, nobody said “don’t test if a candidate can code”. You should do a minimal test, then move on to more important things, rather than beating the same horse.

”In my experience these types of exercises are also more random”

Well, “your experience” also says that you regularly encounter senior candidates who can’t code at all. I doubt the statistical validity of your experience.

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

#423

Post by rezashirazian » Thu, Aug 30, 2018, 1:42 AM UTC

TripleBye articles are generally bad. They're a mishmash of random ideas that feel A/B tested for the highest possible SEO return. I still remember reading through this: https://triplebyte.com/blog/a-taxonomy-of-programmers when it was first published trying to make sense of it.

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

#424

Post by EliRivers » Fri, Aug 31, 2018, 8:46 AM UTC

pvaldes wrote: post #415

EliRivers wrote: post #385

Earlier quoted context omitted.

Hiring has become such a litigation-prone Where? I've never seen anyone sue a company for not hiring them, and no company I've ever worked at has been sued for not hiring someone. If it was litigation-prone, I'd expect to see some litigation. I don't work in the US; maybe this is a weird US thing? Maybe people who do work in the US can give us some numbers? What proportion of companies one has worked for have been su…

> I've never seen anyone sue a company for not hiring them http://www.dailymail.co.uk/news/article-6067331/Swedish-Musl...

Well, now I've seen one. Such a big deal that it made a national newspaper. That suggests it's not very common.

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

#425

Post by brennebeck » Sun, Sep 02, 2018, 3:13 AM UTC

canthonytucci wrote: post #393

brennebeck wrote: post #353

Earlier quoted context omitted.

Sure, you try to make lemonade. That doesn’t mean it will be a success.

Have you seen Star Wars: The Empire Strikes Back? I've never heard "try to make lemonade" only "make lemonade" In my experience difficult problems can be solved if people keep a good attitude and are invested in making things work, even when success seems unlikely. But sometimes you will fail. I was interested to know what sort of problem space the parent had their bad experience in, and to hear more about how things…

Yes, I have. One of my favorites, actually.

And definitely nobody says, “try to make lemonade...”. That goes against the saying, I agree.

My point was just that even when you take the “when life gives you lemons” approach sometimes you won’t be getting that lemonade after all. As such, I also didn’t think it to be the best phrase for what (I thought) you were trying to convey.

I agree with your reply, 100%. Thinking a bit more as I write this, I may be wrong above (in this reply; about the wrong phrase) and it is, in fact, the best idiom. Not sure. But now I’m definitely on the fence, at least (compared to above, where I was on one side of the fence).

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

#426

Post by BrandoElFollito » Sun, Sep 02, 2018, 9:15 PM UTC

will4274 wrote: post #418

gaius wrote: post #382

Earlier quoted context omitted.

The team of consultants asked to NOT be given any performance data I call shenanigans, because people are not made redundant, positions are. Who gets laid off is related to their job not existing anymore, nothing to do with them as an individual person.

I'm not quite sure I understand. Calling "shenanigans" generally means disagreement but your second sentence is entirely consistent with what I wrote - the company had overscaled and needed to eliminate redundant positions, regardless of whether those that held them were high performers or low performers. If you are disbelieving my claim, what evidence could I provide to convince you that it's true?

I think this is a misunderstanding. If I understood correctly, you are saying the company needs to reduce its size and therefore randomly eliminate people at some positions (say, need to reduce engineering by 10%), while the other commenter was challenging the fact that the company needs, as a whole and independently of the position to reduce its staff by x%.

Both are possible.