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

501–510 of 674 posts

Re: Why I Don’t Talk to Google Recruiters

#501

Post by Bjartr »

stcredzero wrote: post #348
Alex3917 wrote: post #177

Earlier quoted context omitted.

> 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 r…

I find your stance well considered and it intrigues me because I don't think I agree with it. However I might agree in principle and differ on what exactly it means for someone to know first principles.

I've been through a CS education track, including algorithms and complexity, my day job has been software development for over 5 years since I've graduated college. In practice I have been able to understand complexity tradeoffs when selecting approaches and building implementations and have been able to recognize shortcomings in the same done by others and been able to improve upon what was built. The difficulty I have encountered has never been in the implementation of an algorithm. I have even taught the first principles of complexity to others sufficiently well that I have seen them make informed design decisions.

I will openly admit that not once, during all of that time, have I ever been able to whiteboard an optimally efficient (or nearly so) algorithm implementation _and be confident it was such_. Mind you, I'd love to be able to, and I'm definitely not arguing that understanding complexity isn't useful knowledge. However I would contend that being able to bang out a optimal b-tree implementation from memory on-demand isn't first principles knowledge, but is merely _trivia_ ability.

I would further argue it's not even first principles knowledge that is most important, but rather a combination of critical-thinking, enough self-awareness to notice when you've exceeded your current knowledge/experience, and sufficient humility to fix that lack rather than plod along with blinders on.

Granted, I might be less competent than I believe, but then, in practice, it would seem that incompetence can lead to genuine success. Perhaps the scope of my 5 years real-world experience is so narrow that I've simply not had the chance to encounter a situation where others would say "if you're not able to whiteboard a b-tree, you're not the right person to solve this problem". But then, I'm a full-stack developer that regularly uses Java, Javascript, and Python and have occasionally had reason to use R and C#, so it seems unlikely that my experience is that exceedingly narrow.

Sorry that this became a bit rambling, it's just a topic that's always intrigued me in how divisive it can be.

Re: Why I Don’t Talk to Google Recruiters

#502

Post by stcredzero »

sidlls wrote: post #490
stcredzero wrote: post #320

Earlier quoted context omitted.

Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. True. And people who clutter their code by using some fancy "StringStream" class when they could've just used a concatenation are also part of the problem! Sa…

Well, sure but one person's "basic" is another's "esoteric," and "when you do" is something I think is relatively infrequent. I cared deeply about this sort of thing when I was writing code for HPC modeling of physical systems, but in very specialized and narrow context. Since I've left academia I have rarely encountered a problem where understanding implementation details behind complexity was really necessary. Know…

Knowing the typical time and space complexity for an algorithm (without even understanding one bit about the implementation details) in a given category might be considered too trivial to be even basic, but I submit it's about the most "advanced" piece of knowledge for what a typical engineer really must know to write good, high quality and performant enough code.

I think we're both saying that it's generally a good level of 1st Principles knowledge for programmers to have.

Re: Why I Don’t Talk to Google Recruiters

#503

Post by stcredzero »

barrkel wrote: post #489
stcredzero wrote: post #385

Earlier quoted context omitted.

This same exact argument could be used to require every interview candidate to know assembly. Have you ever done the standard Comp Sci compiler implementation class? Do you write C++ and use the C++ standard library? If you answered yes to both questions, then you should know from first principles how just about everything in the standard library is implemented, and can use those tools with complete knowledge of when…

I'd love to agree with you - it would be good to my ego - but I just don't think you're right. People create value with software when they use code to solve problems. For some people, that means tackling a gnarly complex problem and by a combination of wits, experience and education, come up with an efficient and elegant solution. Typical example: someone working in a specialized role in back-end (i.e. not user-facin…

I've seen other people take a bunch of open source components - not knowing in depth how they worked - and put them together to create surprisingly credible solutions very cheaply, the kinds of solutions that win 7-figure SaaS deals. You don't get there with your knowledge of binary trees or compiler principles.

But having some basic algorithms knowledge might make the difference between delivering such a solution that runs reliably and quickly enough and not.

Re: Why I Don’t Talk to Google Recruiters

#504

Post by BeetleB »

stcredzero wrote: post #480
BeetleB wrote: post #420

Earlier quoted context omitted.

>Nearly every programmer nowadays knows that naive string concatenation is inefficient, and so they should use a stream or something like that. I'd rather hire someone who knows exactly why it's O(n^2) I'd love to hire a programmer that knows this is actually O(n^3), and not O(n^2). (Well, it is if you are naively concatenating N strings, each of length N characters). (Had a manager who insisted it was exponential. W…

I'd love to hire a programmer that knows this is actually O(n^3), and not O(n^2). Hint: Don't ever work for or hire anyone who would exploit the ambiguity of the English language in a hastily written comment to gain the false appearance of geeky superiority. (Exercise: how would you interpret the situation referred to in the comment to wind up with O(n^2) and how you interpret it to wind up with O(n^3)?)

While I wrote it without much seriousness, I think my comment does highlight a problem with the whole discussion here.

People like to boast about how important it is to know these kinds of complexities, but in reality they just use mental heuristics to come up with them (which is how we got n^2 and exp(n) from my manager).

For string concatenation, is it important they know how to do it in a linear fashion? Or is it important that they can actually calculate the complexity? Or do you want an in-between where it is OK that they do not really know the complexity, but can tell you that it is definitely super-linear?

I've seen people be fussy that they should be able to explain why it is n^3 (or n^2 or whatever), in a somewhat rigorous fashion. I say "somewhat" because when I then turn to them and ask them to derive the exact expression (not just in big-Oh notation), they will usually fail. Then they will go through hoops trying to explain why it is important to know it in big-Oh notation but not all that important to be able to derive the exact formula.

(There is, of course, a camp that does not believe much in big-Oh and actually prefers to know the leading constant, etc. My example is not contrived.)

I find people will nitpick to their level of granularity, and it is always easy to come up with some justification for their level of preference. But to others, it is just nitpicking.

For me, it is important to know that this is super-linear, whereas one can do it linearly. I don't care if the candidate knows it is n^3 or n^2. That is also why I did not point out my manager's error at saying it is exp(n).

Re: Why I Don’t Talk to Google Recruiters

#505

Post by coldpie »

DonHopkins wrote: post #391
ceronman wrote: post #376

Earlier quoted context omitted.

How many Google Engineers do you know? I know quite a few of them. All of them, without exception, are incredibly brilliant engineers. You might think this is just anecdotal evidence, that's correct. But also think that Google Engineers are responsible for many top quality, world class software projects. How could that be possible without really good engineers? Yes the interview process is tedious and can be frustrat…

Q: How many Google engineers does it take to screw in a lightbulb? A: Build great content. https://twitter.com/dr_pete/status/623981710003187712

I don't get it.

Re: Why I Don’t Talk to Google Recruiters

#506

Post by city41 »

stagbeetle wrote: post #485
HarryHirsch wrote: post #465

Earlier quoted context omitted.

Tracking links are always extremely bad form, though. I'd be interested in hearing from the other side, though, why such behaviour would be considered acceptable.

By tracking links do you mean custom-generated links to a certain page that reply back to some software showing that you clicked the link?

Yes, exactly. Usually they are in the form of http://sometrackingwebsite.com/someid?nextUrl=https://youtub....

Re: Why I Don’t Talk to Google Recruiters

#507

Post by sidlls »

stcredzero wrote: post #502
sidlls wrote: post #490

Earlier quoted context omitted.

Well, sure but one person's "basic" is another's "esoteric," and "when you do" is something I think is relatively infrequent. I cared deeply about this sort of thing when I was writing code for HPC modeling of physical systems, but in very specialized and narrow context. Since I've left academia I have rarely encountered a problem where understanding implementation details behind complexity was really necessary. Know…

Knowing the typical time and space complexity for an algorithm (without even understanding one bit about the implementation details) in a given category might be considered too trivial to be even basic, but I submit it's about the most "advanced" piece of knowledge for what a typical engineer really must know to write good, high quality and performant enough code. I think we're both saying that it's generally a good…

"Good" and "necessary" are different things, though. I consider it "good" to know as much as possible about things I'm interested in. I don't consider it "necessary."

Re: Why I Don’t Talk to Google Recruiters

#508

Post by stcredzero »

Bjartr wrote: post #501
stcredzero wrote: post #348

Earlier quoted context omitted.

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 r…

I find your stance well considered and it intrigues me because I don't think I agree with it. However I might agree in principle and differ on what exactly it means for someone to know first principles. I've been through a CS education track, including algorithms and complexity, my day job has been software development for over 5 years since I've graduated college. In practice I have been able to understand complexit…

However I would contend that being able to bang out a optimal b-tree implementation from memory on-demand isn't first principles knowledge, but is merely _trivia_ ability.

a) What the heck is an optimal B-Tree? (Don't you have to tune the parameters? b) I would also contend that it's trivia, and merely a way of getting at the ability to apply First Principles knowledge.

I would further argue it's not even first principles knowledge that is most important, but rather a combination of critical-thinking, enough self-awareness to notice when you've exceeded your current knowledge/experience, and sufficient humility to fix that lack rather than plod along with blinders on.

So you're not disagreeing with the value of 1st principles knowledge. Then you cite an even deeper kind of knowledge. Where exactly are we disagreeing here?

Re: Why I Don’t Talk to Google Recruiters

#509

Post by dlubarov »

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…

I do like your suggestion, but

> Make the interview more about working together and capacity to learn, and less about computer science trivia night at the pub with no beer.

Understanding b-trees is pretty useful. If you work with relational databases, most questions concerning query performance require some understanding of b-trees.

I wouldn't ask a candidate to implement b-trees (or a sorting algorithm, or red-black trees, etc.), but asking about their basic properties seems reasonable. Or better yet, asking about the performance of a realistic SQL query which uses a b-tree index.

Re: Why I Don’t Talk to Google Recruiters

#510

Post by gaius »

maus42 wrote: post #494
gaius wrote: post #410

Earlier quoted context omitted.

Everyone would love to hire Linus Torvalds for that matter Torvalds is very lucky to have found his niche because he is unemployable - the first sweary rant at a teammate and he'd be shown the door. Well except maybe at Uber.

I suspect you've got the cause and effect backwards. More likely, because he found that niche where he does not have to learn to moderate, he does not.

That's like the old advice that you should always watch how your date treats the waiter...
Post reply on HN