Live data from Hacker News

I know why rejection emails suck – I write them

triplebyte.com

311–320 of 426 posts

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

#311

Earlier quoted context omitted.

> Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence. Not my experience. At least when hiring for programming positions, the typical fatal issue is that the candidate's coding is weak. In my first role as a hiring manager, I didn't stress coding tests for candidates with long work history on their resume. Since then, I learned better. I've s…

They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. A single question is pulled from subjects vast enough to fill up years of college and there is no time to research, as one would in the real world. Binary pass/fail with your pride/livelyhood/family on the line. Please state your last exam conducted under such conditions? Oh and your…

We always get these kinds of responses when interview testing is mentioned. This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. This is a simple test of basic competence. It's like interviewing a candidate Formula 1 driver and asking them "so which bit's the brake pedal?" If they can't tell you that instantly then they shouldn't be applying for the position in the first place.

> Please state your last exam conducted under such conditions?

University entrance exams.

University graduation exams.

Any other test that you do which you need to pass to enter or continue your career.

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

#312
post #300

Earlier quoted context omitted.

Actually that decision would not have been up to HR and the executive team, would it? In the United States, that decision was made for you at least 28 years ago, right?

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.

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

#313
post #302

Earlier quoted context omitted.

> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz. If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of…

To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent…

It's because some large percentage of your time at work is spent in meetings, writing emails, discussing things, etc. where actual ability to do the core task isn't necessary.

And then some large percentage of "enterprise software development" is just hooking up buttons and text fields to a database, and doesn't require any more algorithmic complexity than a few if() statements.

And then some large percentage of the remaining work can be performed adequately by just picking some appropriate ready-made solution off Stack Overflow.

Put them all together and chances are, you can skate by for years (and actually perform acceptably) without ever actually needing to write FizzBuzz-level code for yourself.

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

#314
post #91

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…

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

How would this differ from contains?

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

#315
post #302

Earlier quoted context omitted.

> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz. If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of…

To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent…

1) Selection bias

Good/excellent programmers rarely need to interview except as a formality. Consequently, you are, by definition, interviewing weaker programmers.

2) Tool use masquerades as programming

Visual Basic 4/5/6 was one of the original sins in this genre, but it continues now with other tools and frameworks. Being able to point-and-click a tool and plumb it together isn't programming--but people will claim it is. Then when someone asks for an actual program--those people fail.

This does not necessarily mean that those people are not productive. However, it does mean that they can't actually function in a position where they are expected to program.

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

#316
post #302

Earlier quoted context omitted.

> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz. If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of…

To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent…

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

An example is folks who work with large frameworks that are designed to be extended with little to no coding, such as WordPress and Drupal.

Then they want to advance to software engineering, so they recast their experience - of essentially configuring and deploying software, i.e. sysadmin - as "programming", and get those 5 years represented as "a full time programming position".

There's variants of that, basically "developers" doing very limited ant-work with large frameworks they don't understand and couldn't rewrite from scratch if their lives depended on it.

There's also a bunch of languages and frameworks invented for the explicit purpose that someone with little to no CS knowledge of programming talent could produce useful work.

Most of us here live in a bubble of startups where we often create products from scratch using lean (or no) frameworks. In reality, a scary amount of the "IT work" out there appears to be what I described above. Possibly a substantial majority.

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

#317

Earlier quoted context omitted.

> Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence. Not my experience. At least when hiring for programming positions, the typical fatal issue is that the candidate's coding is weak. In my first role as a hiring manager, I didn't stress coding tests for candidates with long work history on their resume. Since then, I learned better. I've s…

> I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions. Like, how? I used to hire undergraduate student sysadmins / coders, and we had zero candidates fail fizz buzz. None! The worst we saw were people who maybe had an awkward solution to the problem, typically because of unfamiliarity with the modulus operator.

I should stress I didn't ask fizz-buzz specifically, but similarly basic questions.

I should also stress (again) that back then I brought candidates directly to onsites when their recruiters sent an impressive resume with 3+ years of "full time programming experience".

I learned the hard way that most people who unknown recruiters are eager to push through your hiring funnel are unemployed for a reason.

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

#318
> giving feedback effectively is an enormous amount of work

I take a lot of issue with this. Interviewing and doing code projects is also an enormous amount of work. If a company sends an 8 hour exercise to each candidate, then in aggregate the candidates are probably expending way more person hours than the total expended by the hiring company to settle on a new hire.

I no longer do unpaid work. Of course I’ll interview, but to show them how I code on their product and work in their processes, I will only accept a contract-to-hire offer. If more people did this I believe it would exert pressure on companies to not be so wanton with what they ask of candidates, and how expendably they treat them.

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

#319

Earlier quoted context omitted.

If it's any comfort: everyone performs worse under the stress of an interview. This is widely recognized by hiring employers, and accounted for in the interview evaluation. For example, if I test-run a new question, and it takes my engineers 20 minutes to solve it, I will add 30-50% handicap for stress. I.E. if a candidate manages to solve it within 30 minutes, that's roughly equivalent. Unfortunately, there's no way…

Don't ask people to do something they've maybe never done before and will never have to do on the job (write code with a marker on a whiteboard as seconds tick down). If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem). But literal whiteboard tests are a recipe for complete blackouts.

> If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem).

I am doing just that.

> But literal whiteboard tests are a recipe for complete blackouts.

Not always. I've done a lot of whiteboard interviews too. It's a different way to discuss a problem, and one that people do use at work.

Most design sessions happen with a colleague or two in front of a whiteboard, not sitting at a workstation.

I disagree that blacking out is so common, though I understand it does happen occasionally. Also, we typically do at least 5 interviews in every onsite, one blackout wouldn't destroy the chances of an otherwise strong candidate.

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

#320
post #228

Earlier quoted context omitted.

You are a team, but you should still attempt to be objective enough in your evaluation to determine whether a new person will allow you to be a functional team. But when you say "culture fit", the implication is that the team would prefer not to change at all, not that it would accept changing into a different-yet-comparably-productive team.

Maybe I used culture fit the wrong way. I just meant the ability to get along in non-trivial situations and communicate effectively. I've met people who I have so little in common with that we couldn't even share a joke in either direction, because the recipient just couldn't understand it at all. It was so difficult to accomplish even basic things because our experiences were so different that we didn't have common…

[deleted]
Post reply on HN