Earlier quoted context omitted.
Have you ever actually got a job that you accepted through this method? Also, what wizardry did you use to get 200+ recruiter E-mails a month? Do you just have a highly optimized resume out there on all the job sites or something?
I get between 30 and 50 a month and all I really did was setup a linked in profile.
Why I Don’t Talk to Google Recruiters
601–610 of 674 posts
Re: Why I Don’t Talk to Google Recruiters
#602Earlier quoted context omitted.
> I don't think Google's hiring people thing that that's what a good developer is, as much as they think it positively correlates to good developers. I agree. However, I think they are wrong... I'll expand below. > This is also a valid concern, but Google is much more concerned about false positives than false negatives. Missing out on a good candidate is a bummer. Hiring a bad one can be a nightmare. So the process…
> That is, I'd conjecture that the good developers who can (or want to) memorize algorithms and regurgitate basic CS knowledge are one kind of capable dev, and the good developers who rely on tools to a greater degree are another kind of dev. Call them types A and B. I really dislike this characterization. I'm a googler. I've never tried to, or needed to, memorize algorithms. I don't know if this characterization com…
Naturally, it wouldn't boil down so easily in practice to these two types, even if they are the correct ones. Everybody is a mix of both (and plenty of other things); plus, we have to assume that, like you say, occasionally somebody incompetent or strongly type B "cheats" the system and gets hired.
But I guess the question is: How, to you, does "selecting for people who can solve unfamiliar, complex, problems by applying first principles" not seem to jive with my definition of category A?
Re: Why I Don’t Talk to Google Recruiters
#603Teams do their own hiring which has its downsides in terms of consistent quality, but does mean you will be interviewed by the direct manager.
Re: Why I Don’t Talk to Google Recruiters
#604I fairly often receive emails from recruiters who have 'read my profile' and found me to be 'a great fit' for some 'senior ...' role.
Had they actually read my profile, they'd have found me to be a student, who's only relevant experience is as an intern, and has accepted an offer for a graduate position.
Certainly not a fit for senior anything, but it makes me wonder how far it would go if I replied OK - do companies using these recruiters get hopelessly underqualified candidates to interview on a regular basis, and still stick with them?
Re: Why I Don’t Talk to Google Recruiters
#605Earlier quoted context omitted.
You must mean "some software projects" and not "frequently." In the 2000's and prior, it was common knowledge that the majority of software projects failed. Even if they succeeded on paper and shipped, they weren't actually used. By some estimates, it was something like 75% of software projects. If you look at the contents of "ecosystems" like Steam and the the various app stores, you'll see much the same. Most of th…
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…
"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 CS background (and without the ability to remember much of that background) is likely to know a few patterns and apply them all like a hammer to a screw. This leads to profoundly terrible designs, not only when you take performance into account, but finding the best model for the actual business problem, handling changes, permuting data in necessary ways, and other issues.
> That era was dominated by waterfall development which is notoriously prone to failure due to the slow feedback loop.
Extreme programming was the first formalized "agile" approach, and the very first agile project to utilize it was a failure. [1] A big problem was performance, in fact:
> "The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two more years' development. 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."
Nine hours to run payroll for 10,000 people. We're not talking about computers in the '70s with magnetic tapes. This was 1999 on minicomputers and/or mainframes. If that wasn't a key algorithmic and/or architectural problem, then I would be amazed.
When you're designing a system using agile, it often ends up with an ad hoc architecture. Anything complicated really needs BOTH agile and waterfall approaches to succeed. You need to have a good sense of the architecture and data flow to begin with, and you need to be able to change individual approaches or even the architecture in an agile manner as you come across new requirements that you didn't know up front.
> This is highly relevant because one not uncommon problem with highly-tuned algorithms is the greater cost of writing that faster code and then having to change it when you realize the design needs to be different
I'm going to say [citation needed] for this claim.
I gave an example in another thread of having improved the speed of a game development level compiler tool by a factor of about 1000, with no major architectural changes, and it took me about an hour.
At the same time I performed a minor refactor that made the code easier to read.
Bad design == Bad design. That's it. Good design can include an optimized algorithm. A good design tends to be easy to extend or modify.
Very rarely it makes sense to highly hand-tune an inner loop. The core LuaJIT interpreter is written in hand-tuned assembly for x86, x64, ARM, and maybe other targets. It's about 3x faster than the C interpreter in PUC Lua, without any JIT acceleration. That is a place where it makes sense to hand-tune.
> pride + [sunk] cost[s] leads to trying to duct tape the desired feature on top of the wrong foundation
That's another orthogonal error. It makes me sad sometimes to throw away code that's no longer useful, but I'll ditch a thousand lines of code if it makes sense in a project.
Every line of code I delete is a line of code I no longer need to maintain. I'm confident enough in writing new code that I don't feel any worry about deleting old code and writing new. This is as it should be. Sad for the wasted effort, yes. But I know that the new code will be better.
[1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
Re: Why I Don’t Talk to Google Recruiters
#606Earlier quoted context omitted.
one does not need to know how to write an algorithm on a white board to understand it. Seems like it would better to ask what a red-black tree is, what's it's time complexity, and what would be a good situation to use one. In fact, I would argue that one could know how to write one and have no idea of the practical use of it.
It pretty much has no practical use, that a different data structure couldn't do more efficiently.
Re: Why I Don’t Talk to Google Recruiters
#607The amount Amazon spends on airfare for these wasted trips must be staggering. I'm in Chicago and I don't know very many people who haven't gone on this strange pilgrimage to Seattle.
Re: Why I Don’t Talk to Google Recruiters
#608There 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…
I agree. Personally, I'm a bit horrified at the idea that someone who wants to be an "expert at object oriented design" would turn up their noses at "binary-tree-traversing questions". It sounds like a formula for aspiring Architecture Astronauts. It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process, although t…
Asking as a Googler who occasionally gets to dream up a neat trick here or there (and leads a team of pretty clever people, too!).
Re: Why I Don’t Talk to Google Recruiters
#609Earlier quoted context omitted.
The problem is that what interests you now may not be economically valuable next year. They want you there past one project, because the future is too murky to guarantee your current role will continue to be needed. Google et. al. are hiring generalists because they want people of a mindset such that when the entire special-purpose they hired them for dissolves, they're willing and eager to ramp up on a new project a…
You are taking a much too narrow view of "specialization". If project foo is really the only project at Google that uses the skills I like and know best, I am probably not going to apply there. I get that there are people who don't care (much) what kind of code they are working on. If those are the people Google exclusively wants, that's fine. I just won't have a place there. I do not think this is a generally-advisa…
Re: Why I Don’t Talk to Google Recruiters
#610Earlier quoted context omitted.
My experience hiring at (YouTube.. at the google campus), was similar to the original post. 3 phone screens (which I must have done ok on), and then they flew me out to CA. I went through the interview process.. got tripped up on the 'puzzle' questions (which I thought was bullshit for a Python programming job.. but whatever), and then didn't get the job. I actually agree with what was said in the original post: this…
> However, I can tell you what definitely was a complete turn-off, > was the odd obsession of seemingly everyone there with where I/(you) > went to school. Ugh, that's really frustrating. I'd like to think they were just searching for common ground, but jeez. Candidates should be judged based on what they know, not where they happened to have acquired that knowledge. I am a college dropout and I had no idea what a ra…
So you imply they're doing a bubble sort on candidates?