Earlier quoted context omitted.
Yup, we need Meta-recruiters: recruiters that can find the right recruiter for you!
But how to keep out the spammy Meta-recruiters? We'll need Meta-Meta recruiters!
Quis recruitiet ipsos recrutes?
Why I Don’t Talk to Google Recruiters
551–560 of 674 posts
Re: Why I Don’t Talk to Google Recruiters
#552Earlier quoted context omitted.
A colleague of mine gave me some excellent advice here. She redirects recruiters. I am very happy with my current job so I'm not generally interested in emails from recruiters. However, I do hav many friends who are at jobs doing things below their potential. It's always good to see if the job fits anyone's profile, even vaguely, and redirect the recruiter to them. (I don't redirect all recruiters, though, so there's…
> I am very happy with my current job The best time to interview is when you're very happy with your current job. Zero pressure, zero commitment and potentially huge upside in terms of pay and title increase.
As a young person with zero other commitments to worry about (kids, loans, etc), I'm really enjoying what I work on (and get paid pretty well) and that's enough for me for now. This could change in the future. I'll keep your advice in mind in case this situation does change :)
Re: Why I Don’t Talk to Google Recruiters
#553There 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…
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. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenate…
Where I work our core rendering algorithm which runs several times on every page load used naïve string concatenation. When I initially wrote it I knew string concatenation was inefficient but never got back to it and for 99.9% percent of cases it didn't matter! We finally hit that 0.1% case and after optimizing the algorithm, it didn't make a dent on our overall performance numbers at all.
The biggest impact to our performance has been switching one JSON serialization library for another, no algorithmic knowledge needed, just basic benchmarking skills.
Re: Why I Don’t Talk to Google Recruiters
#554Earlier 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.
I think location is very important with these sorts of profiles. I'm on linked-in, Indeed and career builder.
I normally get nearly zero recruiter emails, but late last year I changed my location preferences on Indeed and/or Career builder (I don't remember) from my hometown to Washington DC and suddenly I was deluged with the 20+ recruiter emails per month; more right after I update something on my profile.
Strangely, 1/2 of the emails are for locations far away from DC. I might try changing my preferences to San Jose and see how many more I get.
My "profile" is pretty much just my resume. Experience seems to be another important factor.
Re: Why I Don’t Talk to Google Recruiters
#555Earlier quoted context omitted.
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…
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 Sure, but that screening process should be completed before you invite a candidate for an on-site interview. I'm a hiring manager. If I say someone should spend 8 hours attending an in-person interview before I'll spend 5 minutes reviewing their resume/github…
I broadly agree with you, but let me nitpick a bit, because nothing suits HN like a pedantic quest for truth.
8 hours vs 5 minutes is a bit extreme, for a start.
Secondly, the time a hiring manager needs to spend reviewing resumes includes unsuccessful candidates as well - so it's not 5 minutes, its 5 minutes * |all_the_vaguely_plausible_candidates|. There might be 20 or 30 resumes in the pile for some of these jobs. SO the manager might be 100-150 minutes in, in order to get to that 1 person who needs a "8 hour interview" (or whatever that is; I suppose places that fly you somewhere might be burning 48 hours or more - I know people in Australia who have been flown to the US for job interviews!). If you live in town it might be more like 2-4 hours. So the ratio isn't quite as extreme as you make it out to be for the manager, even if it seems unfair to count time spent reviewing all the other candidates' resumes/githubs.
Re: Why I Don’t Talk to Google Recruiters
#556The 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…
> Frankly, passing algorithm questions is a great way to signal that I probably don't want to have to deal with your code.
Wow that's some serious sour grapes.
Re: Why I Don’t Talk to Google Recruiters
#557Earlier quoted context omitted.
My partner works at a recruitment company. Here's the thing: most recruiters are not very good at what they do and are only chasing placements. To get the most out of recruiters you need to be more pro-active, and find a recruiter or two who really understand your skill set and career ambitions. Build a relationship with them, and don't waste time with the other 90% of batch mailed crapshoots.
> Here's the thing: most recruiters are not very good at what they do and are only chasing placements. Related anecdote: There was a technology recruiter that was constantly calling me at work, despite the fact that my work number is not listed anywhere * and my LinkedIn profile having clear instructions not to do that. I decided to look him up on LinkedIn. Guess what his previous job was? Debt collector. * I figure…
HAhahahaha debt collector. We all gotta eat somehow. Tech industry casts a wide, frothy net when business is booming!
Re: Why I Don’t Talk to Google Recruiters
#558Earlier 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. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenate…
Where I work our core rendering algorithm which runs several times on every page load used naïve string concatenation. When I initially wrote it I knew string concatenation was inefficient but never got back to it and for 99.9% percent of cases it didn't matter! We finally hit that 0.1% case and after optimizing the algorithm, it didn't make a dent on our overall performance numbers at all . The biggest impact to our…
Your one anecdote obviously proves everything once and for all. The biggest recent performance gains in my personal project had to do with switching to WebRTC and switching libraries.
Knowing when you can just slap in the naive string concatenation and move on is also a useful result of the right skills. If you had better profiling tools/skills, I posit that you wouldn't have had to do the useless optimization.
Re: Why I Don’t Talk to Google Recruiters
#559Earlier quoted context omitted.
Head hunting is very profitable. If you get a recruiter email for a company that is not that company, it's _always_ junk. 100% of the time, it is a waste of time. Ignore those, and look for the ones that are from the actual company. They have their own recruiting team that you are going to be dealing with anyway, and aren't playing the numbers game or shuffling their candidates between many different companies trying…
>If you get a recruiter email for a company that is not that company, it's _always_ junk Not true. Companies hire recruiters to find employees. Not all companies (especially startups) have their own internal recruiting department. The flip side is true, though: as a company trying to hire people, every recruiter email that says "I have a perfect candidate for you" is junk. They just invent those people or send resume…
Recruiting (and hiring) is a core competency for every company. Especially for startups.
A founder should personally be handling recruiting until the company is big enough to have their own internal recruiting department.
Re: Why I Don’t Talk to Google Recruiters
#560Earlier quoted context omitted.
> 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 ar…
So if the developers knew to traverse a binary tree, how many of the 75% succeed?
There is something I've mutated to my own liking called the 80/20 rule. In software, you will spend 20% of your time making the application 80% of it's maximum potential performance. You can then spend the remaining 80% of your time gaining the extra 20%. If that is cost effective to your company, then by all means do it. If it isn't 80% is just fine and you've cut your development costs by 4/5ths.
For me, being able to "rote" an algorithm on some whiteboard falls into the last 20%, maybe. Collection.Sort, whatever it uses, is good enough. Hell, you get about 78% of that 80% by using indexes properly on your RBDBMS.