Hacker News Reader

> Some jobs require performance under pressure, but programming is not one of them.

In fact, programming under pressure is the leading cause of programming disasters. It's the exact opposite of what a rational employer should want.

Not to defend that interviewer, but sometimes it's inevitable that you do have to code under pressure. I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second, and I have to push a patch to production as quickly possible. Not that I would interview for such a situation.

You should probably roll back the commit that broke production though, instead of hastily pushing something out hoping you'll fix it.

And ideally you should've been doing a gradual rollout, deploying on a few machines first then slowly ramping it up.

And if you are in that position, it is because you have the most (or enough) context to be able to solve the problem.

In an interview situation, it is like being asked to fix a problem with skyscraper having never seen the interior before. Interviewing is low-context. You cannot test whether someone will fail under high-context pressure in an interview.

"I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second"

That's the situation you get into when you code under pressure.

No jobs are performed best under pressure. Or at least past the body's ability for a brief surge (adreneline etc.). But it happens in every occupation because overall more will be produced by pushing people than letting them pace themselves...

> programming under pressure is the leading cause of programming disasters

I don't want to straw man you, but it seems like hiring someone who is demonstrably better at programming under pressure would mitigate the inevitable situations that force employees to program under pressure.

> mitigate the inevitable situations

Conversely - the person who feels like he's good at programming under pressure might consider it no big deal and not bother to mitigate any potential "programming under pressure later" possibilities.

I will defend about 20% of the interviewer's behavior here. I've had candidates try to negotiate away requirements or get me to give them part of the answer. They'll say something equivalent to, "Hey, could this method I'm supposed to implement have an extra parameter that makes everything easy?" Sure, any problem can be made easy by taking away the hard part, but we're not doing that. Or they'll say, "So what data structure would you use?" That's for you to solve.

From time to time, I ran into candidates with a crazy attitude like this, so I learned to stand my ground. It was an unfortunate and surprising necessity. The interviewer might have been doing this but going overboard with it. (Or maybe they were just a jerk.)

Now the 80% of the behavior I won't defend:

1. An interviewer should have the soft skills to stand their ground without being harsh and implying that you suck.

2. An interviewer should know the difference between minutiae and important stuff. Partly for time management reasons during limited interview time.

3. Even if an interviewer is rough around the edges sometimes, they should understand that in this context, they are the face of the company. And it is stressful and tiring. So they should reign it in and be understanding and nice.

4. The company should be in control of their own interviewing process, at least enough that failures like this aren't common. Maybe an interviewer needs some guidance to improve, or maybe some people aren't cut out to do interviews, but they shouldn't be just left to their own devices.

So you met 8 people, and one of them was a jerk? I'd say that's a pretty acceptable jerk coefficient for a workplace. I've been in places north of 0.5.

The right number is zero and a UBI until they figure out how to stop being jerks. (My primary personal reason for supporting a UBI is I want to be able to say "No rational employer should employ you" without that implying "so you should be homeless and starve.")

But short of that, the right number is zero on the interview circuit. You can employ jerks if you have to, but don't put them in more positions where they have to interact with others than necessary. Give them the legacy products where you can't staff a team of more than one qualified person anyway. Give them an office. And keep the door closed.

Remember that a jerk is basically a 0.1x developer - an employee who causes other employees to lose productivity by spending time working around the jerkiness, taking a morale hit, etc. Even a remarkably productive jerk at best only compensates for their negative effect on people they work with, and most jerks are not consistently remarkably productive. https://medium.freecodecamp.org/we-fired-our-top-talent-best... is a good example of a company learning that lesson a little too late. A company that signals that they trust their jerks enough to make hiring decisions and to represent the company's culture to potential new hires is a company that signals they're actively cool with jerks (or incapable of noticing, which has the same effect).

If a jerk makes a good employee unhappy and they leave, the jerk is a net negative. And if you keep employing the jerks, you'll find yourself with a 0.5 jerk coefficient on your hands very quickly.

Just hiding how many jerks a company has until after the interview process is complete is not effectively any better - it could even be worse for people, as they could have had signal to avoid the jerk. The absence of evidence of some behavior or signal is not equivalent to it not being present at all.

In my experience, most companies have jerks - I’m not convinced it’s even avoidable reliably, as people come from many walks of life, and sometimes the walks form people to be jerks.

I work at Apple, where I’d say that jerks are a very low number of people I’ve interacted with (maybe a couple hundred employees so far) - I’ve seldom seen a company beforehand with less jerks percentage-wise, much less have processes that help with descalating arguments & deal with them quickly.

Your jerk tolerance is higher than mine. I really really don't like to work with people like that.

There were other reasons why I decided that Apple was not for me, but the jerk interviewer definitely tilted the scale from "yes, I could see myself working there" to "no, I will never work there".

If 12.5% of people in an office were jerks, I'd consider that a very toxic culture.

In my opinion the entire process was a jerk. An entire day of whiteboard problems? What a waste of time for everyone involved.

They were a jerk in a situation where both parties are supposed to be on their best behavior. Can you imagine how it must be dealing with them on a day-to-day basis?

That they allowed that person to be a representative of the company when someone is interviewing the company to decide if they'd want to work there... that's a bad PR move. Yes, the company extends an offer on their end, but really, both parties are making decisions. If they can't put their best foot forward.... that's a problem. If they think this was their best foot forward, that's another problem.

Apple interviews are team-specific, so I'm not sure that the existence of a single jerk on a single team's interview loop should reflect on a company with hundreds if not thousands of teams and tens of thousands of engineers.

Division. Damn. That's what calculator is for. I would just whip out my phone to do it.

Human has evolved to leverage tools to augment intelligence. If he can't understand the advantage of tool utilization, he's not a good engineer.

Humans attach prestige to solving problems the old school way. We have ladders but watch pole vaulting at the Olympics.

> Don't they have calculators at Apple? Or phones, perhaps?

He must have been from the iPad dev team.

> I decided then that I never wanted to work with that person, or with other people like them.

sounds like the interview was a complete success.

As a candidate, keep in mind the most important thing you are going to get out of an interview is to assess the job and the company. They need to make a quick decision (employ you for years based on a few hours interview), and so do you.

> The only thing that the interviewer was evaluating was my ability to do math problems in my head after being interviewed for 6 hours.

Although I agree with you about the (ir)relevance of the task, I disagree with this particular move you're making when other people do it.

Typically when people want to trivialize test results they don't like, they say it's over-fitting to the immediate situation (like IQ tests "don't measure anything intrinsic, they just measure how well you do IQ tests"). Unfortunately this criticism can be logically generalized across any statistical or empirical measure whose job is not to let people into the job/tell the truth, but minimize the impact of something bad happening if the test returns a false positive, or the opportunity cost if it's a false negative. This means two things:

(1) Because the chance of error always exists, there are always going to be people who feel gypped by the process; yet on the other hand, it is supremely difficult to come up with good measures of anything that is too costly to observe directly no matter what the domain. Thus sour grapes that want to claim over-fitting.

(2) For software companies like Apple, they can probably afford to have bullshit tests to weed out applicants, because the alternative of having to place each applicant through a probationary period for three months is quite costly, if we're willing to refute all tests as being narrow or irrelevant indicators in the manner above.

With Apple, it's still possible that they have an internal model for hiring that claims to have predictive power that relies on this particular task as a proxy in conjunction with all the other ways that they've tested you, before they move you over to a probationary period. But as the article pointed out this is also unlikely since the effectiveness of interview practices is understudied in a formal setting.

I had a similar experience with a Google phone interview once.

The interviewer asked me about a technology I knew almost nothing about, and I told him right off the bat that I didn't know much about it but I would explain what little I did know.

But then he spent the next 20 minutes asking me more questions about it, how I'd use it, how it could be implemented, etc.. It was so frustrating I should have just ended the call early.

I just become unable to do math during interviews. You know how people hate public speaking, because they feel super nervous, sweat a lot, and have trouble saying what they want? That but with calculous you haven't touched in 12 years.

If they gave me a piece of paper and let me do it without interruption, I could do it, but generally interviewers will sit there and demand you explain what you're doing.

> and he replied "sometimes you will have to fix your code on the spot"

You should have told him that "every time, you get to use a calculator". If I managed interviews, I'd have 1 person interview 1 person in a full-technical interview, without the personal questions, with 3 additional interviewers watching behind a one-way mirror. When the interview was over, I'd go in myself, and ask the candidate how well they thought they did, and how well they thought the interviewer did, with the 3 other interviewers still watching.

I came up with the wrong answer and told the interviewer that I wasn't sure if that was correct, and to let me know if it was incorrect. He blankly stared at me and said he wouldn't help me.

Meaning: presumably he's trying to be helpful, and give you a perfectly accurate representation of how people at his company interact when trying to solve problems together.

Long division under pressure? This sounds as dumb as Password Swordfish.

Next time just tell him you are a Millennial and you never heard of long division before.

So you will never work at Apple because you had 1 bad interviewer out of a sample size of 8? That seems foolish.

As a programmer I have the ability to be selective with the jobs that I take. The first 7 interviewers did not convince me that Apple was a good place to work. The last interviewer convinced me that I didn't want to work with them or people like them.

Of course, things change. It would be difficult for Apple to change my mind about working there, but it is not impossible. Ask me again in 10 years :)

My point was that Apple is a large company with many teams. I didn’t understand why OP would write off an an entire company because they didn’t like 1 team.

Stay hungry, stay foolish. Someone said that.