Live data from Hacker News

I know why rejection emails suck – I write them

triplebyte.com

401–410 of 426 posts

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

#401
post #347

Earlier quoted context omitted.

>Interviewers kept on saying things like, "I managed to pick out enough of the right words that he probably answered me, but I wasn't sure." Did it ever occur to them to ask "Sorry, could you repeat that?" Sometimes it takes a bit more effort to understand someone, whether it's because of an accent or a speech disorder or whatever. As an interviewer, you're in a position of power, and you have an obligation to put in…

Have you really never been in this situation. I have, several times. Yes, of course i ask the candidate to repeat what they said. And again when i don't get that. And again. Varying my question a little too see if they'll say it differently. I'll go about 5 times before giving up and either moving on to another topic in the desperate hope that it's the specific words that are the problem, or switching to a chat chann…

This was exactly the experience, but with the twist that it was a group interview, so interviewers would move on hoping that some other interviewer actually understood that answer.

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

#402

Earlier quoted context omitted.

> What do these people do all day, if not design and build software? Indeed this is a fascinating question, and I explored it a few times. Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling.…

How do I stop being a bottom feeder?

Cultivate programming as a skill.

Pick up a good introductory programming book. I recommend Think Python 2e:

http://greenteapress.com/wp/think-python-2e/

Go through it cover to cover and do all the exercises. All of them. Don't skip a single page or exercise, not even if you think "I already know this", and certainly not because it's too tough.

Once you're done, you should be able to start applying for jobs in whatever language that book taught you. If you're still not passing interviews, take on a serious - but manageable - programming project, such as some simple application for yourself or someone you know. If you're a web developer, a simple dynamic database-driven website is an excellent choice. If you want to do front-end, a simple Javascript game will teach you a lot.

You don't always have to apply for new jobs so early. Lots of tech shops have some teams where actual programming happens, even if most of the rest of the company is "paint by numbers" pseudo-programming. Often you can start to take on more responsibilities that involve actual coding if you show the necessary abilities. You won't have to change companies, or even change teams.

Good luck!

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

#403
post #391

Earlier quoted context omitted.

This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative? My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks. How else do I figure that out, if not by a coding exercise?

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 code, and ask them to find the bug. They have all the worst issues that folks here are complaining about, amplified: stressful, awkward, etc. In my experience these types of exercises are also more random: i.e. depend more on luck. Sometimes great candidates fail them, and poor candidates get them right on a fluke. So they are overall less indicative.

Ultimately, though, it's back to the first point: how do I test if the candidate can do their job, i.e. code?

A candidate may communicate really well, say all the right things in best-practice questions like the one you mentioned, write well in English, but still unable to code their way out of a matchbox.

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

#404
post #400

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…

It is a weird US thing, and nobody can give you numbers because the existence and outcome of these lawsuits is never talked about (most are settled out of court). But talk to anyone in HR and you'll hear, "The stories that I've seen, if only I could tell you!"

So are they real? No numbers, no talking about it, just people in HR saying "No no, I promise you, they are real!"

If everyone is so cautious about hiring for fear of litigation, do they still happen? Since everyone is so cautious.

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

#405
post #391

Earlier quoted context omitted.

This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative? My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks. How else do I figure that out, if not by a coding exercise?

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 to move on after.

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

#406

Earlier quoted context omitted.

We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient. It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then…

> they’ve just shown that they’re not going to be able to write clean code unsupervised. The opposite, shown they can’t write supervised under the gun, which never happens On the job.

Exactly. I don't think they are accounting for how some people react to interviews. I've had candidates who have been explicitly nervous and stuttering, and we've consciously had to decide not to hold that against them. They turned out to be a great hire.

I think I can do okay in coding interviews, but only if I prep for that style of work first. It's definitely different. I'm perfectly (or at least acceptably) competent in my day to day.

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

#407
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…

>You gave some random guy some feedback

I've noticed you've used "guy" 185 times in the past 5 years, but only used "girl" 58 times. This is a statistically significant difference. You will hear from my lawyers.

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

#408
post #400

Earlier quoted context omitted.

It is a weird US thing, and nobody can give you numbers because the existence and outcome of these lawsuits is never talked about (most are settled out of court). But talk to anyone in HR and you'll hear, "The stories that I've seen, if only I could tell you!"

So are they real? No numbers, no talking about it, just people in HR saying "No no, I promise you, they are real!" If everyone is so cautious about hiring for fear of litigation, do they still happen? Since everyone is so cautious.

They are real. In some organizations more frequently than others.

Anecdotally, call centers seem to be a particularly good source of interesting HR lawsuits.

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

#409
post #300

Earlier quoted context omitted.

Actually, no. You're referring to the Americans with Disability Act. What it requires depends on the "essential duties of the job" and what is consider a "reasonable accommodation". Those are judgement calls. Those judgement calls need to be made by executives on the advice of HR. My lay understanding is that the law does not insist that the job requirements change. So if being able to participate in design meetings,…

This is a really weird argument. It seems unlikely that you would succeed in legally justifying excluding deaf people from your team based on the idea that verbal communication is an essential duty of a software developer, which is the analysis that would likely be used against you. Also: if your management decided to exclude deaf people from your team, wouldn't you quit? I would quit.

The judgement call of whether to act on an argument like that is not up to you and me, it is up to HR and the executive team. If it comes to court, the validity of the argument is up to a judge.

As for protesting choices that you don't like by quitting, that is your right. Speaking personally, deciding not to hire someone because you believe that they will be unproductive in that role seems to me to be a perfectly reasonable thing for a business to do. And I don't see a moral distinction between different reasons why someone is expected to be unproductive.

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

#410

Earlier quoted context omitted.

We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient. It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then…

> they’ve just shown that they’re not going to be able to write clean code unsupervised. The opposite, shown they can’t write supervised under the gun, which never happens On the job.

If we’d ever had somebody crippled by interview stage freight, I make be able to take that seriously. The coding skills you need to pass our test is writing a for loop that mutates a dict. We’ve never had anybody forget how to do that in our interview, but we have had people come up with remarkably inefficient solutions to the problem.

I don’t think it’s reasonable to say that people’s problem solving skills (which is what we’re actually testing) become exponentially less efficient during an interview. But even if it was, the test is still doing it’s job, because what would we expect to happen when we give a person like that a deadline, or ask them to review a PR?

Post reply on HN