Google's “Director of Engineering” Hiring Test • Hacker News Board

Re: Google's “Director of Engineering” Hiring Test

#961

Post by wst_ » Sun, Oct 16, 2016, 1:59 AM UTC

chetanahuja wrote: post #417

pjlegato wrote: post #268

Earlier quoted context omitted.

And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details, in the same sense that you no longer need to know exactly how many transistors and diodes are used to build the adder on the CPU. It simply no longer matters in almost all cases. Your time is much better spent mo…

"Now, in 99% of commercial software engineering" Whatever this thing... this... stringing together a 100 random github projects to get a webpage that kinda of works about 80% of the time is called -- please let's agree not to call it "software engineering".

You are jumping into conclusions too fast. There are plenty of good software engineers who work with high level languages and technologies on a daily basis. You just have to know your tools, no matter what you do.

Re: Google's “Director of Engineering” Hiring Test

#962

Post by tjalfi » Sun, Oct 16, 2016, 6:45 AM UTC

Merovius wrote: post #670

So… someone care to explain to me where I'm going egregiously wrong, apparently? Because, at least on my machine with the code I spewed out quickly, the Kerningham way of counting bits is ~6x slower than a lookup table (including generating the table itself). http://sprunge.us/IIEH The Kerningham way code seems faster for very sparse arrays (i.e. only one bit set per uint16), but slower otherwise.

You weren't doing anything wrong. He discusses two methods: https://graphics.stanford.edu/~seander/bithacks.html#CountBi... https://graphics.stanford.edu/~seander/bithacks.html#CountBi... The second option will probably beat a byte lookup table. GCC switched from a lookup table to similar code. If this still isn't fast enough, try using SIMD registers and the Harley/Seal method based on carry save adders (http://www.hackersdelight.org/hdcodetxt/popArrayHS.c.txt). If you like this sort of bit twiddling, you probably would enjoy Henry Warren's Hacker's Delight.

Re: Google's “Director of Engineering” Hiring Test

#963

Post by noufalibrahim » Sun, Oct 16, 2016, 7:26 PM UTC

eternalban wrote: post #665

noufalibrahim wrote: post #194

Earlier quoted context omitted.

My father is a civil engineer and late in his career, he interviewed for a senior position at a construction company. He figured out that the interviewer didn't know what he was talking about early on the interview and confronted him with that. The interview came to a end, he was put in touch with a senior engineer at the company. He didn't take the job for other reasons. I don't think this kind of rubbish would fly…

A civil engineer is a professional engineer. I would assume your father is a certified PE [1]. This rubbish flies in our industry since we are not professional engineers. [1]: https://en.wikipedia.org/wiki/Principles_and_Practice_of_Eng...

This is interesting. Is this similar to things like the bar council for lawyers? I don't know if there is something similar to this in India where I'm from.

Re: Google's “Director of Engineering” Hiring Test

#964

Post by friendzis » Sun, Oct 16, 2016, 10:15 PM UTC

dspeyer wrote: post #886

brianwawok wrote: post #709

Earlier quoted context omitted.

Could you explain how static typing makes less safe programs?

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.

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 :)

Re: Google's “Director of Engineering” Hiring Test

#965

Post by pjlegato » Sun, Oct 16, 2016, 11:47 PM UTC

chetanahuja wrote: post #412

pjlegato wrote: post #268

Earlier quoted context omitted.

And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details, in the same sense that you no longer need to know exactly how many transistors and diodes are used to build the adder on the CPU. It simply no longer matters in almost all cases. Your time is much better spent mo…

"And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details.." And that, ladies and gentlemen, is how we ended up with npm.

This is a false dilemma. Npm-level programming and being able to rewrite the whole operating system from scratch are not the only two options.

Re: Google's “Director of Engineering” Hiring Test

#966

Post by ummonk » Mon, Oct 17, 2016, 3:54 AM UTC

joss82 wrote: post #834

gcp wrote: post #593

Earlier quoted context omitted.

(Very) embedded developer speaking here. What's this L1 cache you speak of?

It's level 1 CPU cache, the fastest (and smallest) cache. It caches both instructions and data. https://en.wikipedia.org/wiki/CPU_cache

It was a joke. Some embedded processors lack a cache.

Re: Google's “Director of Engineering” Hiring Test

#967

Post by kajecounterhack » Mon, Oct 17, 2016, 2:25 PM UTC

bogomipz wrote: post #638

kajecounterhack wrote: post #440

Earlier quoted context omitted.

Thanks, I am realizing now that it was SRE. All I can say is I'm definitely a fan of how we interview SWEs and I'm sorta bummed this is how SRE interviews go. TIL.

Are SWE and SRE interview the same? I thought they were different enough job descriptions that it would require different interview questions.

They are different, but a lot of the skills are similar. SREs need to problem solve and while they may need to have more domain-specific knowledge I'm not sure a facts quiz administered by someone non-technical is the best way to do that.

Re: Google's “Director of Engineering” Hiring Test

#968

Post by optimuspaul » Mon, Oct 24, 2016, 8:28 PM UTC

HereBeBeasties wrote: post #611

optimuspaul wrote: post #510

Earlier quoted context omitted.

I agree. Why the hell would you ask someone at that level basic questions like fizz buzz? It's absurd. I also tend to shy away from asking coding questions in interviews, they don't tell me much about aptitude for critical thinking and culture fit. Skills can be taught but culture is much harder. ... But I'm not saying to throw in some questions that don't prove that they are actually competent, just be casual about…

The question is, "why wouldn't you?" If the person is competent they will dismiss it in seconds and you can move onto something more interesting.

But this is Director level. You are wasting your time and their time. Far more important things to be factoring in for a director level.

Re: Google's “Director of Engineering” Hiring Test

#969

Post by recursive » Wed, Oct 26, 2016, 4:13 PM UTC

lazaroclapp wrote: post #687

mst wrote: post #623

Earlier quoted context omitted.

The number of web devs I've encountered who regard my ability to talk HTTP over telnet as black magic makes me sad.

In all fairness, if you can talk normal HTTP 1.1 over telnet with some service, someone configured TLS wrong ;) And if you can talk HTTPS over telnet unassisted... well, I am truly impressed.

What? HTTP 1.1 doesn't require TLS.