Hacker News Reader

Comment by cliffy | Hacker News Reader

I'm guessing you didn't get to do this interactively? If I interviewed someone and they seemed knew something I didn't and could prove it by actually running the query/code I would be impressed. At the very least the interviewer should have checked your claim after the interview if they were skeptical.

I think it's a real mistake when you don't let candidates write actual code and run it during interviews.

View on HN

Correct, it was a "remote whiteboarding session".

It has made me absolutely loathe non-interactive sessions. Not being able to run the actual code is ridiculous. Some of the best analysts and programmers I know of are "architecture guys/gals" who can create complex systems but may not knock out the actual code so quickly, or, as I like to call it "error message programmers".

Creating an interview test to weed out otherwise-intelligent "error message programmers" is, in my book, poor interview construction.

This is me. I've used so many different programming languages over the years that for the first week of any new project, I am definitely an error message programmer. It goes something like this on day#1

Okay, I need to iterate through a collection. Which is it again?

foreach (int element in elements), no that's C#.

for (int element : elements) .. nope that's java

for (var element in elements) .. There we go.

Probably wouldn't exactly go like this, I know js isn't typed when I sit down to write it. (except for when it is!) ;)

Regardless, I call this my "tooling up" period. Each day i'm faster, and it takes about a week to get to 100%. but then I'm golden until the project is done and I inevitably have to switch techs again. I probably need to flex more than specialists in interviews because of this. Whenever pseudo code is on the menu I breath a sigh of relief.

When I see a candidate is not sure about some syntax trivia e.g. indexing expressions in Python, names for some library functions like charAt, size, length etc. I tell them to pick one (make it up) and move on. Though lately I've been using a runnable whiteboard with autocomplete so they have been able to figure it out on their own.

It makes me sad to think how hard it would be to remove bad interviewers like above. But as long as they perform reasonably well they won't get fired, and I don't think there is any interview QC system to feed back into the org. And thus we slowly slide from A to B and C territory...

This is why the real-tests should be entirely in pseudo-code and about the logical structure.

Any optimization should happen after a basic algorithm that works and might go along the lines of (telemetry suggests our platform has a bottleneck here) how would you speed things up if there's an issue in this section?

I'm with you on this, even beyond the first week. Been doing primarily Python for more than a year now and sometimes I still slide back to my Perl days and write the C-style for.

Perl has foreach which can iterate over ranges, arrays, lists and is synonymous with for, yet works just like foreach (that's Perl just being Perl).

Yup. A company reached out to me after a few years where I'd left their recruitment process because someone else made an offer (and they were being quite slow in their responses). I'd had multiple interviews, a coding project, and apparently they had been "ready to fly me out where, had I done well, I'd have had an offer at the end of that day".

So I indulged them. I spoke to a manager who said that he'd reviewed my coding project, and been happy with it ("so we can skip that"), so we talked (largely about K8s, as I am looking for an SRE management role - I'd told them I was happy where I was but was curious, and after all they'd reached out to me).

I talked about my experiences architecting K8s from a green field mostly by myself, and he was excited.

I spoke to someone else and he was excited. Okay, I thought, this has potential.

Email from HR: "We have a tech screen lined up for you. Please nominate some languages." I went with Python. Bear in mind I haven't written substantial code in _any_ language (except YAML, hah), for years. And was looking for a _management_ role in SRE.

So I had two rapid fire coding exercises (15 mins each ostensibly). Python lists and comprehensions, and some tokenization stuff. I struggled. Google was my friend but there was a good bit of "error message programming". I walked through the processes and my thoughts. I hesitated a bit at what Big O notation some of my code was, but I recognized routes to loop optimization and could see what was happening, even if I didn't know what the name was.

"Sorry, we are unable to continue following your tech screen".

Oh well. If your SRE PMs and group managers are required to write Python list comprehensions, maybe your idea of "manager" and mine... differ.

In my FB interview I was told I wasn't allowed to run the code, which seemed completely ridiculous to me. It was even more frustrating when my interviewer told me I'd missed an edge case when I was certain I'd covered it - I'm still not sure who was right.

At least you got to type your code. I had to write mine out on a whiteboard (actually, a patch of wall with whiteboard paint).

I went to an interview where there were no spare computers, so I was asked to write out a blackjack game in Java with pencil and paper. That was a lot worse than any of the whiteboard ones I've had.

Reminds me of programming tests at my college.

Reply on news.ycombinator.com