Hacker News Reader

Comment by ransom1538 | Hacker News Reader

My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25]. Welp, he then rolled his eyes and left. Four hours of an interview ruined. Oh well. Yep. That is how tech interviews go. He went on to ruin digg.com (the rewrite everything guy) and I promised myself to never be a dick to people I interview.

View on HN

I had one with Game Closure. They flew me out to their offices after being impressed with a game I made and made it seem like I was basically granted a job, and an interview was a formality (admittedly, this did result in me slacking a bit and I was a dumb young college student with a bit of pride). The interview was purely high-level mathematics and algorithm questions which I wasn't prepared for, they said they'd be willing to pay $40,000 a year (that's nothing in Silicon Valley), and everyone was just kind of horrible. Then the CEO walked in, endlessly berated me, and honestly said I'm a fraud and a liar and I can't program. I laughed when they gave me the rejection call a week later and said they'd be willing to call me back if a new spot opened up, because really, it's preferable to just skip on the formalities after calling me a fraud.

The only thing that really did bother me was two engineers showed me a game they were working on and asked me what I thought. We talked a bit and I ended up giving them a bunch of "here's what I'd do to make the game more fun/interesting" ideas, and everything I mentioned was at some point added to that game (these were fairly basic concepts such as level designs, so it's possible they had some thoughts on their own). I learned never to give advice to a company without compensation, at least.

> and that I needed to go back and study sql

I once had an interviewer with two (TWO!) PhDs. He made sure that I knew he had two (TWO!) PhDs by handing me his business card as we sat down and casually remarking that he had two PhDs (see, right there, two of 'em, yupperoo). This behavior ("he's kind of jerk, and he has two PhDs") had been accurately foretold by the prior interviewer (that session had gone great).

The guy-with-two-degrees asked, "What is the simplest way to synchronize two threads?"

Well, "simple" is pretty fluffy and subjective, so I asked what he meant by it.

"You know, the most simple way."

It didn't get better. I probably made a mistake, and started naming a bunch of synchronization schemes. "Mutex? Semaphore? Dekker's algorithm? Spinlock?". Each mention got a response like, "No, I mean simple. Simpler!"

I never got it. The rest of his questions were similar ("What is the best way to do RPC?"). His parting words to me were, "You need to go back to school."

The specific answer he was looking for was, "mask off interrupts". Doesn't work on multiprocessor systems, so I'd not even mentioned it. I wrote their hiring manager a polite email along the lines of "thanks for the interview, here's one question that I got wrong and why."

No surprise, I didn't get an offer.

Four or five months later the firm called me back, saying that they had fired the jerk and was I interested in interviewing again? I told them I was pretty happy where I'd landed. (I did not congratulate them on firing the jerk, and I suspect they'd had trouble hiring anyone while he was there).

No sane non-narcissistic person will ever fathom doing 2 PhDs. You do a PhD to learn how to think and research things. The only reason you would imagine doing a second one (assuming you're not someone who completely misunderstood what a PhD means), is so you can boast about it.

What utter rubbish. I know several people with two PhDs - for example one guy who went from theoretical physics to economics - and they are all humble and brilliant.

If I didn't have a family to support and a mortgage to pay, I'd consider doing a second PhD, given how much I enjoyed my first.

I dont have a family or mortgage and cant fathom affording top PhDs.

I imagine you're talking about a specific econometrics professor at McGill?

I'd say he's extremely unique, it's far from the typical.

No, a former Ukrainian colleague of mine from Germany.

I also just had a double PhD apply for a job with me - one PhD in stochastic differential equations, one in machine learning.

It’s rare, for sure, but not unique.

In High School, I went to a summer chemistry program. One professor had 23 degrees, for real, ranging from chemistry to religion. I don't know if he had more than one Ph.D.

But when I got to college, one of my professors had been this first guy's student, and one of my other professors had been the second professor's student.

fwiw...

One of my professors had two PhDs: one in physics, and one in computer science. Considering that they worked on quantum computing, I’m not sure I could call it a bad choice.

I'm sorry you didn't have a good interview at Digg. My goal, then and now, is that even people who don't get an offer should leave feeling okay about the process. I clearly didn't live up to that with you, and I apologize for it.

We never made a no-hire decision based on one answer, and nobody ended an interview after one question, unless there was some sort of emergency. Site outage, fire alarm, that sort of thing.

> He went on to ruin digg.com (the rewrite everything guy)

I didn't ruin Digg. Ruining Digg was an all-hands-on-deck multi-year team effort. I wasn't involved in the decision to rewrite it and didn't agree with it. I don't know for sure who was, or what pressures were at work behind it.

What I do know is that our VPE came to me and said that we were going to rewrite Digg from scratch, and do it in six months, because the code was a mess and it took too long to do anything. Which was true.

I told him it was a terrible idea and we should figure out the end point we wanted to be at, then incrementally refactor our way towards it.

He said we'd tried that and it didn't work, so we were throwing away everything and rebuilding it from scratch. In six months.

I said that if we wanted the slightest possibility of success, we'd have to cut features to the bone and ship a minimal version we could quickly iterate on. I suggested cutting the ability to comment on stories.

He told me he didn't think we needed to do that, and we were going to ship a feature-complete version of Digg in six months, from scratch.

It was a completely bananas project, doomed from day one, and I wasn't shy about saying so — I told anyone who'd listen that I gave it a 50/50 chance of destroying the company. The promises made about what would be delivered & when were completely unrealistic and unreasonable. There was nobody articulating what we were supposed to be building, or to say no to what shouldn't get built. Into that leadership vacuum flowed a torrent of well-intentioned but (in my opinion) misdirected ideas for what the thing should be, which ate that first six months in the blink of an eye.

appreciate you giving your side of the story. thanks.

Some of this could be fixed if companies required technical questions to be vetted before they were used. (For example, by testing them on other people at the company.) Allowing people to come up with questions on their own means there is no quality control.

I wonder how many people could pass software interviews at the company they work for. How many could do it without studying and preparing for weeks? I doubt I could.

At Amazon a long time ago, people used to joke that for everyone working there, you could pick a group of interviewers that would have rejected that person.

Four eyes principle: don't let people come up with stuff on thwir own without any of their (technically skilled) collegues ever seeing it.

Good lesson to take out of a negative experience.

One bad technical interview does not mean technical interviews are bad. This has happened to me as well -- and it's a little bit satisfying when those companies fail, because often what happened in that interview is a symptom of them not having their eye on the ball.

Wow. Wow.

> I promised myself to never be a dick to people I interview.

I personally going through a personal mini trauma.

I don’t want explain what is it. But the way you think is very fascinating to me. I want to be a person like you. Not some asshole who literally ruined 1 year of my life.

Nothing to be upset about here. Sounds like you dodged a bullet last minute.

As a former digg user, I gotta say you got the last laugh on that one.

Checking his LinkedIn it seems he works for what amounts to a modern payday loan (now the users pay with privacy loss and a monthly subscription instead of high interest) website now.

Getting a little too personal there, don't you think?

Great story. Also, ianeure is a rather unfortunate username.

> Also, ianeure is a rather unfortunate username.

Why?

Sounds a bit like manure, maybe?

Brings to mind enuresis.

is there a good postmortem/source somewhere for this "rewrite everything guy"? i understand its a little personal. but i'd love to learn from things like this, without blame.

> He went on to ruin digg.com (the rewrite everything guy) and I promised myself to never be a dick to people I interview.

Sounds like the interview process worked for you. You found out that you don't want to work with him and didn't.

More ideally, the interview process would have found that OP was a better fit for the company and that the rewrite-everything guy was producing abnormal interview reviews and should be demoted.

You're absolutely right. Unfortunately the broken-ness of the interview process is not limited to the interview itself.

I've interviewed around 40-50 folks for $role at $wildly_successful_megacorp.

My qualifications: zero training, zero oversight.

I'm getting a lot better and more consistent. But I have still left a lot of interviews thinking how poorly I have done, and needing to reflect on how things could have gone differently.

It's very easy to think of interviewing folks as a chore or merely a favor to $other_manager. For something so vital to the long term health of the company, it's really appalling how little effort is put into it.

I think it's because anyone qualified to interview is probably qualified to do valuable work.

And so companies turn that around and say "Let's take our best and brightest, and have them interview candidates! Then we'll select the best candidates!"

But it's the same research / teaching faculty problem, where one skillset does not imply the other.

Interviewing is a skill, and some of the very productive can be very bad at it.

Some process should have figured out that that guy was poison.

But putting that function in the interviewing process seems awkward...

There is no such thing as a 'toxic person'. There are people who do not fit in a team, there are people who don't fit a companies goals, there are people you can't stand.

The most difficult lesson I've learned is even the worst person in the world has their uses and I only hurt myself by not admitting that.

If I can't stand a team I move on as quickly and professionally as possible because life is too short to fight pointless battles.

> He explained you don't need a group by in a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25].

He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-...

SQL isn't the most portable language. Postgres has special behavior for aggregates/having without group by which essentially creates an implicit group by, other engines will raise an error (SQL Server iirc)

Clearly not something to nitpick over in an interview

"Technically correct", the most irritating form of "correct"

Also, technically the only form of correct.

Reply on news.ycombinator.com