←back to thread

1764 points fatihky | 1 comments | | HN request time: 0.203s | source
Show context
DannyBee ◴[] No.12701869[source]
FWIW: As a director of engineering for Google, who interviews other directors of engineering for Google, none of these are on or related to the "director of engineering" interview guidelines or sheets.

These are bog standard SWE-SRE questions (particularly, SRE) at some companies, so my guess is he was really being evaluated for a normal SWE-SRE position.

IE maybe he applied to a position labeled director of engineering, but they decided to interview him for a different level/job instead.

But it's super-strange even then (i've literally reviewed thousands of hiring packets, phone screens, etc, and this is ... out there. I'm not as familiar with SRE hiring practices, admittedly, though i've reviewed enough SRE candidates to know what kind of questions they ask).

As for the answers themselves, i always take "transcripts" of interviews (or anything else) with a grain of salt, as there are always two sides to every story.

Particularly, when one side presents something that makes the other side look like a blithering idiot, the likelihood it's 100% accurate is, historically, "not great".

replies(28): >>12702181 #>>12702207 #>>12702219 #>>12702265 #>>12702346 #>>12702460 #>>12702555 #>>12702650 #>>12702692 #>>12702698 #>>12702714 #>>12702888 #>>12702998 #>>12703034 #>>12703135 #>>12703156 #>>12703184 #>>12703554 #>>12703778 #>>12704177 #>>12704657 #>>12705201 #>>12705560 #>>12705982 #>>12706518 #>>12707763 #>>12708151 #>>12714459 #
ozgung ◴[] No.12702650[source]
So you're saying Google's recruiters don't tell what position they are interviewing for and that they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position. Well, that sounds like a dumb recruitment process.
replies(7): >>12702739 #>>12702813 #>>12702973 #>>12703024 #>>12703078 #>>12703204 #>>12704968 #
rb2k_ ◴[] No.12702973[source]
> they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position.

To be fair, I've interviewed people at previous companies that had patents and 15 years at IBM on their CV and completely failed even the most basic system / coding questions. (fizzbuzz style).

There are a lot of people that read great on the CV but then it turns out that they mostly kept a chair warm and organized meetings over the last decade without actually retaining any technical knowledge.

Not saying that was the case here, but it happens and it's probably worth checking people on their stated qualifications.

replies(5): >>12703176 #>>12703177 #>>12703582 #>>12703619 #>>12706484 #
johndubchak ◴[] No.12703176[source]
Perhaps that suggests you're giving them the wrong interview.
replies(4): >>12703263 #>>12703279 #>>12703318 #>>12703423 #
_t0du ◴[] No.12703318[source]
Well, general interviewing (unrelated to tech) contains various amounts of "are you lying on your resume" type questions. If someone walks in with a breakdown of 10 years dev, 5 years management, they should be able to at least comfortably answer system/coding type questions. As in, if you do something every day for 10 years, you don't forget all of it in 5.

I had a candidate in a few months ago that was interviewing for Software Development Manager, so he got an initial phone screen and then a face-to-face with myself and another dev on the team he'd be managing. I was impressed with how little he knew about programming.

"Name some data structures." "What does MVC stand for?" "Name some design patterns" etc. All of which were unanswerable. Generally when it becomes clear someone was dishonest about their skillset, the ability to get hired for any position becomes impossible.

replies(2): >>12703403 #>>12703503 #
djsumdog ◴[] No.12703503[source]
My kick-out questions:

"Could you write out what an HTTP request and response looks like on the board?"

I'm really surprised at how many people can't do this. If you've spent five years developing web, surely you've had to look at raw requests, either debugging using netcat or with wireshark or just looking at the information in the Chrome/Firefox debugger?

"What's the difference between a GET and a POST request?"

"What is the difference between a statically typed and a dynamically typed language?"

I had one candidate try to tell me Java was dynamically typed and Scala was statically typed. It was for a Scala position. They also said "statistically typed" instead of statically, even after I corrected them.

-_-

replies(6): >>12703590 #>>12703703 #>>12703918 #>>12703969 #>>12704151 #>>12704340 #
throwawayIndian ◴[] No.12704151[source]
> "Could you write out what an HTTP request and response looks like on the board?"

Why should anyone remember what an http request or response should look like? Statically typed vs. dynamically typed language?

Fuck.

Are these entry-level positions or for someone with 10 years work-ex? A simple search on Google can tell anyone the answer of these questions, why do you expect people to carry an imprint of it in their memory? If the problem they'll work on mandates knowing these things it'd be pretty easy to solve with just one search. It is exactly questions like these that are worth kicking the host organization back in the butt.

Either your interviewing process is hilariously stupid or you're just spiking it up to boost the ego here.

replies(3): >>12704371 #>>12704392 #>>12704848 #
mikeash ◴[] No.12704392[source]
Static versus dynamic typing is so fundamental that I don't see how a programmer could be remotely competent without having been exposed to those concepts enough to have internalized them. It would be like an accountant not knowing what the number 4 is. Yes, you can look it up, but if you need to then how did you ever get this far?
replies(3): >>12704462 #>>12705807 #>>12708333 #
zzzcpan ◴[] No.12704462[source]
It is also a ridiculously dogmatic question. Many people believe into a fallacy that static typing makes safer programs, for example, and expect that somewhere in the answer.
replies(2): >>12704804 #>>12704880 #
brianwawok ◴[] No.12704804[source]
Could you explain how static typing makes less safe programs?
replies(3): >>12705713 #>>12705898 #>>12707581 #
dspeyer ◴[] No.12707581[source]
I have yet to see a large static typed program that didn't -- somewhere -- run into the limits of static typing and contain a set of workarounds, using void* or linguistic equivalent. That's code a dynamic language doesn't need.

The only code you can be sure isn't buggy is code that doesn't exist.

replies(1): >>12721333 #
1. friendzis ◴[] No.12721333[source]
void* is usually not a symptom of limits of static typing, but limits of the [type system] design or human brain. You can think of it as "ok, I give up. Anything can be passed here, proceed at your own risk, compiler will not save you here, errors will show up at runtime". Even the memory safe Rust does not do without such unsafe blocks. In dynamically typed languages that is everywhere, though. I have said this before: safety benefits of static typing show up when you are working with at least data structures, not simple variables. Imagine you have an external endpoint or library call that is specified to return a single object and does exactly that. At some time after release you are the maintenance programmer responsible for implementing spec changes:

  * The object returned no longer has member/property x, it is obtained by other means;
  * The endpoint returns list of such objects.
How sure are you that tests in dynamic language cover these cases? My experience shows that tests very rarely get designed to anticipate data changes, because data is driving test design. Which is more likely for a test: a) to test whether object returned contains keys x, y and z; b) to check if the object returned is_list() (see appendix)? Static typing covers such cases. Static typing is not something that magically saves oneself from shooting them in the foot, but is nevertheless a safety tool that CAN be used. It is of course a burden if one does not intend to use it and that is the core of the debate.

Fun thing: in the second case if your code manages to convert input list to a map and assign one returned object to a key that coincides with the removed property and map access looks syntactically the same as property access (a very specific set of assumptions, though), the bug can butterfly quite deep into the code before manifesting :)