Why I Don’t Talk to Google Recruiters • Hacker News Board

Re: Why I Don’t Talk to Google Recruiters

#521

Post by trollsonson » Tue, Feb 21, 2017, 10:54 PM UTC

SomeCallMeTim wrote: post #382

Apocryphon wrote: post #349

Earlier quoted context omitted.

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...

Interesting. I wonder what the history of their mobile app is, though? It feels like it's a hybrid app, and it feels like it's developed iOS-first, Android-as-afterthought, so it may be the ugly stepchild of the team that gets no attention. "Does it build on Android? Ship it!" Also, if it is hybrid, it may be a JavaScript team -- and JavaScript still has that "top developers love to hate it" aura [1], so it may be th…

So you avoid open source projects, base your opinion on some crappy forum app, and when confronted with the fact that the crappy app in question was in fact from an 'algo interview' company, you write this long winded word salad about text editing on your phone.

You have no freaking clue what you're talking about. I feel sorry for your colleagues, and hope your trip back out of the valley is a pleasant one.

Re: Why I Don’t Talk to Google Recruiters

#522

Post by mathattack » Tue, Feb 21, 2017, 11:00 PM UTC

I take the recruiter's call just to get market information. Who is hiring? What are they paying? What's the market for someone like me? Or someone I may want to hire? Who is doing interesting work?

For better or worse, the "Mass hire smart people" is the most efficient way for these large companies to recruit. It's very good for ensuring universal standards of quality. But it suboptimal for specialists like the OP.

Re: Why I Don’t Talk to Google Recruiters

#523

Post by SomeCallMeTim » Tue, Feb 21, 2017, 11:02 PM UTC

stcredzero wrote: post #488

SomeCallMeTim wrote: post #390

Earlier quoted context omitted.

> 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 Agreed, and my understanding of assembly does help in those ways. I actually feel like compiler design was one of a very few classes in college that really, really…

Paraphrase: you have to compromise due to market realities. Isn't that an indictment of the poor state of training in our field?

Yes and no.

I think that the lead or "surgeon" (to quote The Mythical Man Month) in charge of any app or service development project should be well trained. Anyone who brings in a junior developer (anyone without a CS degree or equivalent, or less than 5 years of professional experience) to lead a project is asking for trouble.

But I think that average developers don't need the full training any more than a nurse needs to have a full medical degree. There are certainly things that I don't want to have to do, and while I might be able to do them better in some way than a more junior developer, they just don't matter enough.

It is a Catch-22, though: Just having a CS degree and five years of experience doesn't make a developer competent. I'd love to see some kind of certification to help separate the wheat from the chaff, so that non-experts could distinguish a top developer from a mid-tier developer.

But none of the certifications I'm aware of do anything aside from test that you've memorized the right buzzwords associated with a particular technology, and as such having such a cert is almost useless.

So yes, I'm arguing for certifications despite the fact that I view certifications as useless. If we had good certifications, maybe we could help establish a better way to distinguish developer skills. Would love to see that, but I admit it's selfishly motivated: I'm really good at programming and technical tests, so any such regimen I'd likely end up with the highest ratings, except if domain-specific knowledge was required.

Re: Why I Don’t Talk to Google Recruiters

#524

Post by enraged_camel » Tue, Feb 21, 2017, 11:04 PM UTC

hashseed wrote: post #433

enraged_camel wrote: post #331

Earlier quoted context omitted.

I'm not sure I buy that distinction. Do you believe that experimental physicists know every single formula and can recite it off the top of their head? Because unless they use those formulas constantly in their work, they end up having to look them up. Same thing with algorithms like tree traversal. You should know the theory behind them, but unless you regularly implement them, there is zero reason to commit their i…

But imagine Einstein having to look up how to derive x^2. I'd say that's a pretty close equivalent to knowing tree traversal in CS. It should just come naturally.

If one is a computer scientist, yes. If one is a programmer, not at all.

Re: Why I Don’t Talk to Google Recruiters

#525

Post by yareally » Tue, Feb 21, 2017, 11:08 PM UTC

ryandrake wrote: post #513

sqeaky wrote: post #472

Earlier quoted context omitted.

I get between 30 and 50 a month and all I really did was setup a linked in profile.

Incredible--would you mind sending me your LI profile (privately of course, email in my HN profile)? I'd love to see an example of a profile that generates that much interest, even if it's mostly low signal.

Maybe I am mistaken, but I thought that much recruiter interest on linked in is pretty typical. I live in the Mid Western United States and what was previously mentioned is also true here from my observations. Most of it comes down to having the right keywords and tags I believe. Having .net/java/mobile in your profile nets a lot of messages where I am. Words like Scala/Python/Node/Ruby/etc gets you a bit more.

80% of it is for jobs within the surrounding city, 10% for within the state and 10% out of state. That said, most of these jobs you could also find without the recruiters as well, but sometimes ones from internal recruiters (and if you're lucky a developer/dev manager) are useful.

Re: Why I Don’t Talk to Google Recruiters

#526

Post by SomeCallMeTim » Tue, Feb 21, 2017, 11:17 PM UTC

sidlls wrote: post #287

SomeCallMeTim wrote: post #212

Earlier quoted context omitted.

> We should avoid the notion that naive string concatenation is a problem that impedes our ability to deliver software, except for niche applications, this is not the case. The attitude that really basic Computer Science concepts like algorithms and algorithmic complexity are irrelevant is exactly why software projects are so frequently FUBAR. The Dunning-Kruger reference is spot on. The original author doesn't even…

> The attitude that really basic Computer Science concepts like algorithms and algorithmic complexity are irrelevant is exactly why software projects are so frequently FUBAR. You must mean "some software projects" and not "frequently." And who's proud of ignorance? Ignorance of what? And, what's more, why should it be considered a negative if someone isn't concerned, or even is proud, about ignorance of certain thing…

Other people have cited numbers, but in my opinion, most software project (greater than 75%) end up:

* Over budget in dollars or time or both

* Fragile

* Insecure (sometimes profoundly so)

* Having major UI issues

* Missing major obvious features

* Hard to extend

* Full of bugs, both subtle and obvious

Pick any five of the above at least. Keep in mind that most software projects are internal to large companies, or are the software behind APIs, or are otherwise niche products, though there are certainly plenty of mobile apps that hit 4-7 of those points.

Who is proud of ignorance? Original author:

> 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.

He proudly states that he will never be interested in learning these topics. These topics that are profoundly fundamental to computer science.

Why should it be considered harmful? Because anyone who is writing software should always be learning, and should never dismiss, out of hand, interest in learning core computer science concepts. They should be actively seeking such knowledge if they don't have it already. It's totally Dunning-Kruger to think that you don't need to know these things. His crack about learning "object oriented design" instead made me laugh: As if knowing OOD means that you don't need to know algorithms. To the contrary, if you don't understand the fundamentals, you can create an OOD architecture that can sink a project.

It's like the people who brag of being bad at math -- only worse, because this is the equivalent of mathematicians being proud of their lack of algebra knowledge.

Re: Why I Don’t Talk to Google Recruiters

#527

Post by funkymike » Tue, Feb 21, 2017, 11:20 PM UTC

praneshp wrote: post #228

valuearb wrote: post #152

Earlier quoted context omitted.

Your best opportunity as a young engineer is always with a startup with smart leadership. You'll get to do far more and learn far more. Google/Amazon/FB/MS etc are full of smart people and offer a more 9-5 type job, but you will find it much harder to do interesting things.

When I graduated, Google/Amazon/FB/MS, I knew people were smart and the job would be okay at the very least. How should I have gone about figuring out which ones are "a startup with smart leadership". I remember being overwhelmed by everyone, everyone came across as smart. So I counter your advice by saying the best opportunity for a young engineer is likely a large company that is well-known for having generally sma…

Interviews are a two way street. For most companies you should be able to talk to the hiring manager and other developers that you would be working with. Ask yourself whether as a junior developer if you will be able to learn from them. This includes technical skills, soft skills, and personality.

From my own experience I interviewed with a small company right out of school where I would have been the second or third developer (I forget now). One reason I did not pursue it is that I seemed to know more about development best practices than their existing developers; for example they did not use source control at all. While I would have had the opportunity to make a big impact on the product, I don't believe I would have grown much.

Re: Why I Don’t Talk to Google Recruiters

#528

Post by uremog » Tue, Feb 21, 2017, 11:21 PM UTC

lettersdigits wrote: post #310

roguecoder wrote: post #230

The reason I won't work at Google is because Google is incapable of hiring the engineers I want to work with. It's not a matter of whether I could pass that interview; it is whether I want to work with the code of people who can pass that interview. Whether I want to get code reviews from people who can pass that interview. Whether I want to rely on the code of people who can pass the interview not to break down in i…

> The reason I won't work at Google is because Google is incapable of hiring the engineers I want to work with That's a very bold (even arrogant, sorry) statement about 57,000+ (googled it) employees. So 57,000 are worse devs then you ? This is what i hear from your statement, correct me if I am wrong .. Many extremely talented people want to work for Google. They will take the tests, even if they don't agree with th…

> So 57,000 are worse devs then you ?

Probably not. There's plenty of better workers than me who I wouldn't want to work with.

Re: Why I Don’t Talk to Google Recruiters

#529

Post by Apocryphon » Tue, Feb 21, 2017, 11:21 PM UTC

stcredzero wrote: post #487

hueving wrote: post #441

Earlier quoted context omitted.

>It's the developer who has a clue about algorithms who is more likely to make the valuable insight. The ability to implement the sorting algorithm in the C++ standard lib is completely orthogonal to people who have this insight. People who have an understanding of complexity analysis is really all it takes to have that insight. Memorizing a bunch of datastructure algorithms has almost no bearing on this ability.

The ability to implement the sorting algorithm in the C++ standard lib is completely orthogonal to people who have this insight. Weak example! Exactly when would you want to use a shared_ptr, and when you you absolutely not want to use a shared_ptr? Why? And what pieces of 1st principles knowledge would let you simply know that in about a minute? People who have an understanding of complexity analysis is really all i…

Has modern CS education been too little first principles knowledge, too much memorization or something else that detracts from understanding the fundamentals? Maybe that's the problem.

Re: Why I Don’t Talk to Google Recruiters

#530

Post by remar » Tue, Feb 21, 2017, 11:21 PM UTC

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…

Here's the problem I have with interviewing, speaking as someone already at a big 4 company and has gone through this process already. I know exactly what types of things I need to prep for and even as someone who's competed in competitions like ICPC and TopCoder, I'm always worried that I'll get the type of interviewer who will just ask obscure questions and not go to the level of depth you mentioned when it comes to working with the interviewer to assess their problem solving skills vs just checking to see if they know the solution to some trick question - the kind that most people not knowing the solution beforehand would almost never be able to figure out within 30-60 minutes.

I'm planning on interviewing with Google in a few months just because of all the great things I've heard about their infrastructure and engineering culture, but due to these concerns I've budgeted to use my current vacation time just to get back into prepping the way I did when training for ICPC just so that I'll have confidence knowing that most interviewers probably have never studied algorithms at that level and that I'll have more confidence in not being potentially tripped up by these types of interviewers.

Most of my friends, even those at Google, have tried to convince me that this plan is overkill but I just can't get myself to leave the fate of my future into the hands of some random interviewer and then regret not doing this level of preparation if I get rejected...