Comment by cmrdporcupine | Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

Parent Full thread

Yes this, and to further this, the "can't do" thing that you measured is in fact extremely partial and incomplete: you've measured that the developer can't write an algorithm on a whiteboard with a felt tip marker in front of a stranger they just met. You don't even know if they can't write the algorithm. Just that they can't do it there.

Is that important to you? Maybe it is for some people. As a person who has been in team lead and hiring capacity before, it is not for me.

I trained for interviewing at Google twice, but never really chose to give interviews despite that being a highly pressured part of the job because I could not philosophically vibe with that process. But what some people who have adopted this process are missing is that Google etc does this only because they are swamped with resumes and have their pick of bazillions of quality engineers. They don't care about false negatives, more false positives.

Startups and smaller companies should care about false negatives. It's hard to find and retain good people. Smaller companies need to aggressively find and cultivate good people to make good teams in order to be/stay competitive -- and that means accepting a diversity of ways of working.

I'm glad whiteboard interviews are dead now that everyone does "virtual" on-site interviews. When I interviewed at Google, I requested a laptop because writing on a whiteboard all day hurts my hand. Every interviewer complained about me using a laptop.

What, exactly, was the substance of their complaint(s), if any? Was it just that you made them do their job in a way different from how they are used to?

The "point" of the whiteboard interview is to see how you think and converse and interact around your coding process, not (necessarily) how accurate/good you are at writing the code. You could write pseudocode that can't compile, and as long as you can explain the algorithm and talk about its complexity you could "pass" (in theory)

Screening interviews do take place in a shared doc or other editor, I believe.

I'm sorry, I don't see how that relates to what I was asking. To be clear, I agree, I just don't understand why you chose to write this in reply to what I wrote.

The complaint of the interviewers would (likely) be that they want to see the candidate go through the whiteboard process, because of the reasons I gave. It's just part of the process. Writing in an editor takes away their ability to probe that process.

Don't get me wrong I think it's silly, but

Oh, I see. There's no literal reason why that discussion can't take place over a laptop screen, either. So, I suppose it more or less does boil down to "you are making us do our job differently from how we are used to, and we don't like it." That is supremely silly.

I've never had any company let me write pseudocode. I once tried to write "vec" instead of "std::vector" and the interview told me to write valid code on the whiteboard. (And I did explain that I was to avoid writing "std::vector" repeatedly).

template<typename T> using vec = std::vector<T>;

Or even using V = std::vector<T>;

for a concrete type T

Solves the problem. If someone denies you this, you don’t want to work there :)

I’ve managed to mostly avoid these kinds of interviews—is this for real?

Is this what lots of the folks mean when they claim tons of candidates “can’t even code?” Syntax or some names aren’t right for some particular language?

Shit, I forget the syntax for “for” loops or what the right way to get an array’s length is or what this language’s way of declaring a constructor looks like in languages I’ve written several hundred of lines of in the last few days, routinely, while under no real pressure at all. I crib off my own surrounding code for syntax hints constantly.

I’ve been doing this north of 20 years, and tend to end up as the guy to go to for tricky problems wherever I work, but I would fail 100% of whiteboard code-writing tests that gave any fucks about it being remotely correct in any particular language. I think the last time I could maybe have done it was when I knew only one language, and it was Perl, and I mostly wrote it in notepad—so, like, the first year or so after started writing code.

This was years ago (pre-covid) but what I remember was a mix of:

  - "Oh, you're using a laptop"
  - "Do you really need to use that?"
  - "Just write it on the whiteboard"
  - "It would be easier to see on the whiteboard"

They also didn't give me a mouse, so using the trackpad was slow.

What I hate most about whiteboards is how you can't easily insert lines so you have to leave lots of space. I tend to write code like an onion rather than top down.

Here's my take on it: the interview is testing your ability to "show" that you absorbed the content and process of your 4th year data-structures and algorithms classes. The whiteboard process is all about showing them that you can regurgitate what those courses taught you, likely in the manner that the prof taught you. You're essentially playing "professor" for them in front of a "class", for a short period of time. Not showing them that you can write code. The code you write on the whiteboard will look nothing like anything you'll ever write at Google.

I think one way to do well in that interview, is to pretend you're the professor and they're a student, and you're working through course material.

In the end, it's just showing them that you passed the socio-cultural hurdles they think are necessary, even if they no longer explicitly check GPAs and which school you came from at interview time.

Why?

Google is more often than not the first job these employees have after school, and many stay there almost forever after. A large percentage are masters or PhDs.

Google is founded by two Stanford grads, both children of academics, who never worked in the industry outside of Google.

Academia is hence the reference point against which Google measures things.

Google is structured in many ways just like a university. Publish or perish (Design docs, PRDs). Thesis committees (perf "calibration" committee, interview committees, etc) and review (intense code review). Even down to the physical "campus" structure. On site cafeterias, even housing/dorms (GSuites, etc)

It's something that was very foreign to me having worked in the industry for a decade before, without a degree.

> I think one way to do well in that interview, is to pretend you're the professor and they're a student, and you're working through course material.

If that's what they want, they should give out the questions in advance, and have the candidate prepare a slide deck. No professor conducts class by having students show up and fire random questions at them all semester.

More explicitly, if that's what they want, they should say that.

> no professor ...

That's one of the higher leverage activities for an instructor. Anyone can go read a book, watch a video, or do some practice problems, and lecturing at a bunch of students isn't a great way to convey information, either in absolute terms or compared to those alternatives. The instructor's job is to tell you which books to read, why the material matters, and contextualize the course against other things you care about. The particular road they tell you to travel depends on where you currently are, and a 2-way conversation is critical to getting good results.

I know all that. But, have you perhaps been in an undergrad classroom recently? It's still predominantly lecture-based.

When I interviewed at Google I was making iOS apps using Objective-C at my current job, so I decided to stick with that for the whiteboard so I wouldn't blank out on some syntax at an inopportune time.

Big mistake. The method names get so long I was kept running out of space on the whiteboard and it took forever to write it.

I don't remember exactly what I wrote anymore (it was over a decade ago), but this site[1] has some examples of really long property and method names in Cocoa (its framework), like:

splitViewControllerPreferredInterfaceOrientationForPresentation

or

initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:

Anyway, for that and other reasons I didn't get the job (I apparently didn't prepare quite the right things, despite preparing for a few hours every night for the two weeks prior, which is how long the recruiter gave me before flying me to Mountain View, so my performance for at least two of the six interviews I had that day were a bit weak).

[1]: https://github.com/Quotation/LongestCocoa

In addition to what others have said, that's an accessibility concern. There are many people who have a physical inability to handwrite.

https://en.wikipedia.org/wiki/Dysgraphia

In some ways I'm grateful for Covid's impact on the job market because I now have many alternatives to physically drawing on a whiteboard. I can use TikZ as fast as my professors can draw, and I can put that on a monitor in a conference room. I've even used it on exams before.

I would probably struggle for reasons unrelated to my actual competence as a programmer if I was forced to use a physical whiteboard during an interview. Your comment made me appreciate that I'm graduating into a different world than 4 years ago.

Reply on news.ycombinator.com