Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Don’t Talk to Google Recruiters

yegor256.com

Post reply on HN
Print view View original

341–350 of 674 posts

Re: Why I Don’t Talk to Google Recruiters

#341

Post by sratner »

amorphid wrote: post #231
stcredzero wrote: post #148

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…

Instead of requiring someone to know a b-tree, how about just teaching it to them in an interview, and then walking through an exercise to see if they get it? That'd be more impressive to me. If someone claims to know what a b-tree, test them on a more advanced concept that builds on using a b-tree that they are unlikely to know. Then teach them that and see if they get it. Make the interview more about working toget…

This has worked quite well for me. I tend to ask one of two types of algorithm questions:

1. Pick a simple but relatively obscure data structure, something they are unlikely to have crammed the night before. I always start by asking the candidate if they are familiar with it; the answer is almost universally "no". I then pull out a wikipedia printout and a notepad, and spend 10 minutes explaining it to them, with diagrams. Once they are sure they have understood the basic operations, I ask them to implement one of these basic operation we just walked through. The amount of code here should be ~10 lines; keep on adding simplifying assumptions until it is.

2. Pick a fundamental data structure from a high-level language runtime, something you would use without thinking: python lists, javascript objects, that kind of thing. I emphasise that familiarity with said language is not required, and list some real-world properties and performance characteristics (access speed, iteration, ordering, mutation), as well as common and less-common use cases. I then ask the candidate how they think it is implemented under the hood (i.e., if you wanted these semantics in a language that didn't natively provide them, how would you do it?) I often don't have a full answer myself, so we brainstorm the requirements and implementations together; no code, just open-ended discussion. The best candidates have often emailed me afterwards, having looked up an actual open-source implementation.

Re: Why I Don’t Talk to Google Recruiters

#343

Post by ethbro »

perfmode wrote: post #324
Drdrdrq wrote: post #318

Earlier quoted context omitted.

You're missing the point. Sure, you should make it fil gracefully on unexpected input. But Google shouldn't change APIs in a way hat causes 3rd party apps to fail at all.

Third party apps wouldn't fail if they were correct in the first place. Failing gracefully on unexpected input is the way a competent engineer would structure their program.

Is there a functional difference between "my production code suddenly stopped processing work because it rejected a newly nullable input value" vs "my production code suddenly stopped processing work because it crashed on a newly nullable input value"?

Re: Why I Don’t Talk to Google Recruiters

#344

Post by stcredzero »

SomeCallMeTim wrote: post #271
hueving wrote: post #202

Earlier quoted context omitted.

>Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. This same exact argument could be used to require every interview candidate to know assembly. >and the person who likes to think about such things…

> This same exact argument could be used to require every interview candidate to know assembly. ...because knowing assembly is actually useful to a high level developer? If it were, then yes, I'd say they should know assembly too. But I know assembly; I've written entire published games in assembly language. And yet I don't believe knowing it is actively useful any more. Knowing the basic concepts like how strings, i…

...because knowing assembly is actually useful to a high level developer? If it were, then yes, I'd say they should know assembly too. But I know assembly; I've written entire published games in assembly language.

To expand on what you are saying: If you're doing "high level development" on a business app in C++ 11 then knowing assembly and having been through a bog-standard undergraduate CS Compiler Development course will actually help you use a whole bunch of things in the C++ standard library, because you can easily guess about how such things would be implemented from first principles. Otherwise, things like smart pointers are just "magic" and just need to be used in a bunch of disconnected abstruse ways. Having the first principles knowledge lets you easily know when to use another shared_ptr, when to use a reference, and when not to use one -- all just from first principles, no arbitrary memorization required!

Hell, having that kind of knowledge even benefited someone working in Smalltalk back in the day.

Re: Why I Don’t Talk to Google Recruiters

#345

Post by sumeno »

taway_1212 wrote: post #97
sumeno wrote: post #50

Earlier quoted context omitted.

Recruiters and Nigerian scams aren't comparable. People legitimately get jobs through recruiters. I got my dream job through a recruiter who found me. Nobody gets the Nigerian Prince's money

My logic is that if something needs to be actively sold (pushed via recruiters), it's most likely average at best. I'm betting that the best jobs don't go through recruiters (or maybe they do if that's the company-wide policy, but the hiring manager already has a candidate in mind when they posts the ad).

I don't think it is really trying to sell the position, it's trying to find quality engineers who aren't looking.

Really talented engineers already have jobs and may not be actively looking to move, but if the right opportunity for the right company presents itself then they might consider it.

Re: Why I Don’t Talk to Google Recruiters

#346

Post by wott »

felixgallo wrote: post #213

As a hiring manager at Amazon, I'm super excited to talk to candidates. A new job is, after all, an incredibly important life decision on the same level as getting married or buying a house. And as a manager, making sure I hire the right people to build the kind of diverse, respectful, collaborative, representative, professional, mentoring, balanced and focused team that I can is the most important thing I can do on…

Nice! You've managed to stick almost all the corporate recruiting empty buzzwords in a single message.

Re: Why I Don’t Talk to Google Recruiters

#347

Post by sdflkd »

munificent wrote: post #248
metaphorm wrote: post #68

Earlier quoted context omitted.

the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interviewees have. It will _only_ pass candidates who are unusually good at algorithm puzzles, on whiteboards, under time pressure.

> it is not sensitive to non-algorithmic skills and talents that interviewees have. I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms. A good question: 1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out. 2. Has a…

> I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through.

Either a lie or you are unusually good at algorithms. People work > 50 hours on Leetcode, CTCI, etc. to try and get a job at Big 4. A couple of hours just reading Wikipedia articles isn't even close to the amount of effort people put into 'gaming' the system these days.

Re: Why I Don’t Talk to Google Recruiters

#348

Post by stcredzero »

Alex3917 wrote: post #177
stcredzero wrote: post #148

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…

> If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. No one is arguing that there isn't any value in knowing CS. Rather, the argument basically is that for the vast majority of developers, studying algorithms is a net loss because it's time that could be better spent learning more va…

Rather, the argument basically is that for the vast majority of developers, studying algorithms is a net loss because it's time that could be better spent learning more valuable skills.

But the op is basically implying that you don't even need the "cocktail party level familiarity." Knowing just enough first principles chemistry to know how CO2 and CO are produced can save your life. It's one thing to just know the rule you shouldn't run your car in a closed garage. It's another thing to know the general conditions where you might be producing CO, so you also know not to run your laser cutter in a poorly ventilated room.

First principles knowledge are a series of tools for reasoning about the world, your program, your software libraries, etc. Programmers thinking they don't need to know the most basic algorithm knowledge is basically the anti-intellectual stance of eschewing first principles knowledge.

Re: Why I Don’t Talk to Google Recruiters

#349

Post by Apocryphon »

SomeCallMeTim wrote: post #283
chrshawkes wrote: post #269

Earlier quoted context omitted.

Can you provide an example of an open source code base which is messed up due to ones inability to understand algorithms?

I don't have an open source example; I tend to actively avoid such projects, and so I tend to accumulate lists of the ones that seem well engineered rather than the opposite. The Quora app, though: If I'm writing a reasonably long answer and I delete a paragraph, it can take more than 10 seconds to complete. There's some profound inability to understand algorithms in there somewhere, I can guarantee it. There was jus…

Given that the Quora interview process is reputably difficult [0], and not lacking in algorithms questions [1][2], this is quite a puzzling situation.

[0] https://www.quora.com/Which-companies-have-really-hard-algor...

[1] https://www.quora.com/challenges

[2] http://www.businessinsider.com/heres-the-test-you-have-to-pa...

Re: Why I Don’t Talk to Google Recruiters

#350

Post by poikniok »

SomeCallMeTim wrote: post #271
hueving wrote: post #202

Earlier quoted context omitted.

>Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. This same exact argument could be used to require every interview candidate to know assembly. >and the person who likes to think about such things…

> This same exact argument could be used to require every interview candidate to know assembly. ...because knowing assembly is actually useful to a high level developer? If it were, then yes, I'd say they should know assembly too. But I know assembly; I've written entire published games in assembly language. And yet I don't believe knowing it is actively useful any more. Knowing the basic concepts like how strings, i…

This is a great post and I completely agree, it is amusing however to note that Quora is known in the competitive programming community for having developers quite strong at algorithms, sometimes I guess that doesn't make it through to the software though.
Post reply on HN