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

Re: Why I Don’t Talk to Google Recruiters

#651

Post by twic » Wed, Feb 22, 2017, 8:16 PM UTC

astrange wrote: post #615

twic wrote: post #478

Earlier quoted context omitted.

If you have a good idea of the price you expect, based on a clear understanding of what you can command, then this is an excellent idea. The standard "don't name a number" advice is based on the assumption that most candidates don't have that. They know what they earn right now, but they don't know what they could be earning. In that situation, you want to sweat some information out of the recruiter by getting them t…

What currency is the 130k in? If they made you move here to SV, it may not be a raise.

Pounds. It involved moving just over a mile from my old job.

Re: Why I Don’t Talk to Google Recruiters

#652

Post by crestedtazo » Wed, Feb 22, 2017, 8:35 PM UTC

lwhalen wrote: post #407

ryandrake wrote: post #31

Unlike most of HN (it seems), I like hearing from recruiters, because despite the very low signal-to-noise ratio, there's always that remote chance that one of them could be able to set me up with a "dream job". It's zero cost to me to politely reply to a recruiter and ask for more info, and I try to at least respond to everyone. What I've found is that they must have a lot of candidates they're juggling because fall…

I take it one step further: the email address on my resume is a black hole. Its only purpose is to feed an autoresponder who kicks back a warm, generic, email thanking the recruiter for their time, acknowledging they have a difficult job, and lays out my requirements for any position: what I am and am not interested in doing, my salary/hourly/per-project requirements, my location requirements (100% remote), etc. At t…

Thank you for your contribution

Re: Why I Don’t Talk to Google Recruiters

#653

Post by mbrumlow » Wed, Feb 22, 2017, 8:40 PM UTC

stcredzero wrote: post #648

mbrumlow wrote: post #643

Earlier quoted context omitted.

> But the real value is in being able to analyze an application's performance and deal with concepts like recursion. Implementing a delete on a binary search tree or traversing one has nothing to do with analyzing performance. If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization. Or at least have a alternative recursion question if the candidate sa…

If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization. Yes, surely! Have the algorithm explained, or even diagrammed for them with pseudocode. Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is…

My apologies. I must misinterpreted your reply.

If I read them in a different mindset then i can take them as a complement to what I said. That knowing how to analyze application performance and concepts like recursion are more important than rote memory. And that interviews should focus on things that can't be ""look up" then read a one paragraph blurb for 3 seconds". I can fully agree to that.

Once again, I am sorry I misread your reply and dumped a wall of text on you.

Re: Why I Don’t Talk to Google Recruiters

#654

Post by arenaninja » Wed, Feb 22, 2017, 8:49 PM UTC

remar wrote: post #491

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

I work at a "big 4" company that's also known for having difficult algorithms questions and I can confirm that sub-par developers still pass through. After talking to a lot of my friends in the industry, my theory is that most devs these days are basically just using sites like leetcode to train and memorize implementations of algorithms which end up being the same questions used by interviewers that use leetcode as…

See, your case is exactly when I would expect to be quizzed for algorithmic complexity and the like. And I would most likely fail! I understand pass by reference / pass by value but I would have to study hash tables (which I'm familiar with) and self balancing search trees (which I have heard of, but have not, to my knowledge, encountered).

Re: Why I Don’t Talk to Google Recruiters

#655

Post by stcredzero » Wed, Feb 22, 2017, 9:12 PM UTC

SomeCallMeTim wrote: post #605

acdha wrote: post #479

Earlier quoted context omitted.

Do you have a citation supporting the claim that those failures were due to poor performance and not far more significant problems like failing to correctly model the actual business problem or handle changes? That era was dominated by waterfall development which is notoriously prone to failure due to the slow feedback loop. This is highly relevant because one not uncommon problem with highly-tuned algorithms is the…

> Do you have a citation supporting the claim that those failures were due to poor performance and not far more significant problems like failing to correctly model the actual business problem or handle changes? "Poor performance" isn't the only negative result of using an insufficiently experienced developer, or a developer who doesn't have a full grounding in algorithms and data structures. Someone without a full C…

The C3 system only paid 10,000 people. Performance was something of a problem; during development it looked like it would take 1000 hours to run the payroll, but profiling activities reduced this to around 40 hours; another month's effort reduced this to 18 hours and by the time the system was launched the figure was 12 hours. During the first year of production the performance was improved to 9 hours.

And I happen to know for a fact that naive string concatenation was a big part of the performance problem! (Bringing it back to my original comment.)

Re: Why I Don’t Talk to Google Recruiters

#656

Post by stcredzero » Wed, Feb 22, 2017, 9:18 PM UTC

sjellis wrote: post #624

krzyk wrote: post #241

Earlier quoted context omitted.

In every single company I've been for the last 15 years, I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I really don't think that every programmer in Amazon or Google is faced with algorithm problems everyday, that's probably localized to some projects that deal with those, not the majority of progra…

I like the analogy of jet fighter pilots vs. airline pilots. Most programmers are metaphorically airline pilots, doing a routine job that is more about following the processes than elite skills, but some people wish that they were doing something more complex than they are.

And yet, there are still occasions where the airline pilot needs to draw on deeper skills. We know this from many deaths averted by good pilots, and needless deaths resulting from poorly trained pilots.

The failed landing of Asiana Airlines at SF and the Air France Airbus that dropped into the ocean are two good examples.

Most programmers are metaphorically airline pilots, doing a routine job that is more about following the processes than elite skills, but some people wish that they were doing something more complex than they are.

Programmers who think they can only get by with the "routine" skill level are like airline pilots who think it's just fine for them to do the checklists, run the autopilot, and know nothing else. Who would you rather have piloting your plane?

Re: Why I Don’t Talk to Google Recruiters

#657

Post by stcredzero » Wed, Feb 22, 2017, 9:27 PM UTC

jdlshore wrote: post #592

stcredzero wrote: post #361

Earlier quoted context omitted.

It is a basic question about one very narrow skill set that is relevant for some, but not all, programming jobs. I could just as easily say "we should be asking every programmer to handle a six-box grid layout" on a white board. It's a skill set that's relevant to almost all of programming jobs. Quick: give me an example of how time/space complexity can be relevant to layout manager code. (Can't do it? Dunning-Kruger…

> Can't do it? Dunning-Kruger just reared its ugly head again. @stcredzero, I've seen your name pop up time and again on this thread. I don't think you realize how rude you're being. You clearly think that Data Structures 101 is important knowledge, to the point of saying that most software project failures are caused by lack of that knowledge. Others in this thread take a more moderate position. Can you accept that…

I don't think you realize how rude you're being.

I am being what I need to be. I find it remarkable that some people are receiving this information and prioritizing protecting their ego, rather than investigating what motivates such sentiments. Perhaps that difference should be exploited in interviews?

You clearly think that Data Structures 101 is important knowledge, to the point of saying that most software project failures are caused by lack of that knowledge. Others in this thread take a more moderate position.

Let me clarify: I think that Data Structures 101 is important knowledge, to the point of saying that a significant number of software project failures are caused by lack of that knowledge.

Others in this thread take a more moderate position.

They either don't have the knowledge and don't appreciate what they don't know. Classic Dunning-Kruger. Or, they have the knowledge but haven't been in the right kind of projects where someone not knowing really bit them hard. ("It never happened to me, so it must not be that big a deal.")

Find me someone who has the knowledge and who has been "bit hard." You can find them in these threads. Read what they say carefully. It's much more than a matter of opinionated debate.

Re: Why I Don’t Talk to Google Recruiters

#658

Post by stcredzero » Wed, Feb 22, 2017, 9:28 PM UTC

lorenzhs wrote: post #626

stcredzero wrote: post #495

Earlier quoted context omitted.

to be even more precise :) Or, you should demonstrate the self awareness to realize that you're just playing with the ambiguity of English in a hastily written comment. Exercise: in what precise context would time/space complexity be O(n), and in what precise context would it be O(1)? (Though the emoticon is probably an indicator that you already knew all this.)

I'm well aware how to analyze a dynamically growing array (each insert "pays" for two moves in the future), but I'm not sure what you're getting at. The amortized complexity of appending an element to the end is θ(1), worst-case non-amortized θ(n) when the growing needs to happen.

Then do that N times. Then re-read the text and think of the context being discussed.

Re: Why I Don’t Talk to Google Recruiters

#659

Post by walshemj » Wed, Feb 22, 2017, 11:26 PM UTC

elliotec wrote: post #571

walshemj wrote: post #474

Earlier quoted context omitted.

Back in the day I worked for a company that had in a single division more engineers that google has employees :-)

Who? IBM?

BT Systems Engineering division effectively the heir to Tommy Flowers

Re: Why I Don’t Talk to Google Recruiters

#660

Post by stcredzero » Wed, Feb 22, 2017, 11:44 PM UTC

mbrumlow wrote: post #653

stcredzero wrote: post #648

Earlier quoted context omitted.

If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization. Yes, surely! Have the algorithm explained, or even diagrammed for them with pseudocode. Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is…

My apologies. I must misinterpreted your reply. If I read them in a different mindset then i can take them as a complement to what I said. That knowing how to analyze application performance and concepts like recursion are more important than rote memory. And that interviews should focus on things that can't be ""look up" then read a one paragraph blurb for 3 seconds". I can fully agree to that. Once again, I am sorr…