Most active commenters
  • mikeash(4)
  • throwawayIndian(3)

←back to thread

1764 points fatihky | 17 comments | | HN request time: 0.001s | source | bottom
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 #
1. 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 #
2. 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 #
3. brianwawok ◴[] No.12704804[source]
Could you explain how static typing makes less safe programs?
replies(3): >>12705713 #>>12705898 #>>12707581 #
4. mikeash ◴[] No.12704880[source]
How is it dogmatic? Sure, there's a lot of dogma around which one is better, but simply explaining what each one is and what's objectively different about them isn't remotely dogmatic.
5. softawre ◴[] No.12705713{3}[source]
Static typing is basically a bunch of free type-based unit tests. You can write safer programs in dynamic languages, but you need to write and maintain a lot more tests.
replies(1): >>12705873 #
6. ubernostrum ◴[] No.12705807[source]
OK, ask me that question about defining the difference and I'll argue with the question, and back up my argument with examples of how type systems are far more of a spectrum of different cases than a stark static/dynamic binary.

And then your non-engineer phone screener who's expecting the answer to match the scripted sheet will conclude that I don't know this "fundamental" thing and thus am unqualified.

replies(3): >>12707203 #>>12707572 #>>12708053 #
7. brianwawok ◴[] No.12705873{4}[source]
You can't compare static + N tests, vs not static with M > N tests.

Compare static with N tests, vs not static with N tests. In what case would the not static be safer?

8. NhanH ◴[] No.12705898{3}[source]
If the type system is not expressive enough and you have to get around it?

The claim that "dynamically type language" allows code to more closely follows the business logic has merits. And you could follow from that to claim that type system could be causing more bugs (ie less safe).

9. ojilles ◴[] No.12707203[source]
Which would be true, or rather: over-qualified.
10. dspeyer ◴[] No.12707572[source]
This isn't a question a non-engineer phone screener can ask. Coming up with first pass filters that don't require an engineer to interpret is harder.
11. dspeyer ◴[] No.12707581{3}[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 #
12. mikeash ◴[] No.12708053[source]
This is proposed as a question that an engineer would ask, not some base-level screener.
13. throwawayIndian ◴[] No.12708333[source]
> It would be like an accountant not knowing what the number 4 is.

It's a hypothetical no-go! Every person, even the fourth grader knows the number 4. So why ask a question that measures their ability to remember 4, say 4 or show that they know 4.

> I don't see how a programmer could be remotely competent without having been exposed…

Share this link with them:

http://stackoverflow.com/questions/1517582/what-is-the-diffe...

Invest in people and people will invest back in your business. Interview process that I follow at my workplace has just one goal to assess: whether or not it'd be great to work with this person and spend over ~50 hours per week with them.

replies(2): >>12708354 #>>12709725 #
14. mikeash ◴[] No.12708354[source]
Are you hiring fun people who know nothing about computers? Or are there actually more criteria than you let on here?
replies(1): >>12714684 #
15. lonewolf_ninja ◴[] No.12709725[source]
Well, following Netflix's mantra - it is a team and not family that you are hiring for. Anyone can Google and find answers, doesn't mean you would hire everyone, would it?

There are a number of basic items that a competent programmer needs to know off the top of his head. If they had to google for every single item, then their productivity goes down the drain and so does the entire team's productivity. You should fix your hiring.

16. throwawayIndian ◴[] No.12714684{3}[source]
> hiring fun people…

Absolutely! This is super super important. Fun to work with, not annoying to waste time with.

> know nothing about computers

It's sad that you think this way of people who couldn't answer your questions at the expected level.

> Or are there actually more criteria than you let on here?

Yes! One way to know if they're any good or not suitable is by giving them a problem statement like so:

'Design X, feel free to choose a language that's suitable for this problem', and then may be proceed to hint with: 'You might want to look at advantages of Static versus dynamic typing'… and then let them ask whatever questions they want to ask or read up or search or start implementing whatever.

Observe what they do -- and how fast can they get to the decision of what language and why. And how to make X (break down of steps) or if they can dive and start making X there itself. Note, if they had theoretical knowledge of what you seek during an interview it will work to their advantage naturally. Or sometimes not.

Of course, this process may not work for you as it does for us -- therefore seeking direct answers about static vs dynamic language may not be such a bad question after all (I get it), but expecting people to accurately remember what an http request or its response looks like may not be fruitful at all. It can throw good people off guard and ruin the rest of the interview for them.

17. friendzis ◴[] No.12721333{4}[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 :)