For those who are bored with the "new opportunity" emails from Google and maybe other companies: rather than trolling recruiters with obnoxious responses, you can just ask them to add you to the non-contact/ignore list and most probably they'll not bother you ever again.
Why I Don’t Talk to Google Recruiters
611–620 of 674 posts
Re: Why I Don’t Talk to Google Recruiters
#612I acctually love questions about how to best traverse a tree, binary or not. Maybe I'm ready for an interview at least? But why is it me who should be put through a four-hour white board coding session? I would collapse after 40 minutes. They can code. Why can't they be the ones at the white board? I can "architect" and correct their mistakes. They would still be able to evaluate my competence.
Re: Why I Don’t Talk to Google Recruiters
#613The 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…
What is it with developers and their code-centric view of employment? Any idiot can "write code" in 2017. It's not particularly difficult. You might do it slightly better but still your profession is not by a long shot "difficult".
Can you work in a team? Can you communicate? Do you dress in a presentable manner? Can you explain technical ideas simply? Do you know anything beyond cutting code?
It's simply not good enough to be some lone-ranger ubercoder anymore. Coders are a dime a dozen.
I'd actually rather take someone with a degree in statistics or physics, let them learn to code on the job, and I'd be able to apply them to an order of magnitude more problems than your typicall mathematically illiterate self-styled genius who can write a bit of code.
Programming is the easy part, stop deluding yourself into thinking what you do is difficult. It isn't.
Re: Why I Don’t Talk to Google Recruiters
#614Earlier quoted context omitted.
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…
This has worked quite well for me. I tend to ask one of two types of algorithm questions: 1. Pick a simple but relatively obscure data structure, something they are unlikely to have crammed the night before. I always start by asking the candidate if they are familiar with it; the answer is almost universally "no". I then pull out a wikipedia printout and a notepad, and spend 10 minutes explaining it to them, with dia…
I really like this approach; can I interview with you? :P
Re: Why I Don’t Talk to Google Recruiters
#615Earlier quoted context omitted.
that's absurd. you should name the price you expect, and not go below your minimum. would you hire a plumber that refuses to name his rate, and then when pushed, tells you a number 5 times higher than normal? why do you think any other employment negotiation is any different? if you "never name a number", the person on the other end is going to know you're inexperienced and operating on cargo cult mythology, and will…
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.
Re: Why I Don’t Talk to Google Recruiters
#616Earlier quoted context omitted.
That's strange, none of my interviewers there had any objection to my using Python. This was a few years back; perhaps things have changed.
After I did my phone interview and study problems in Python, I was told when I got onsite for whiteboard problems that they really preferred C++ or Java. It was a little late for me to switch mindsets day-of, didn't get enough recommendations to hire.
Weird. That is definitely not standard practice, at least as of a few months ago. Candidates provide their preferred languages and are supposed to be matched with interviewers who are familiar with them.
Re: Why I Don’t Talk to Google Recruiters
#617I think the recruiting process is designed to minimize type II errors (false negatives), namely someone who passes the process but would later turn out to be a bad recruit. Inevitably, the type I error (false positives) grows, those who are good but rejected in the process. I don't understand this risk averseness in the recruiting process by the employers. Especially, in countries with favorable dismissal laws for em…
Having someone around who the team likes, but can't code their way out of a paper bag (type I) is still a problem.
If you have a culture that you're there to work, and to make the company money then it's not as big of a problem as it can be if you've got a ball pit.
Re: Why I Don’t Talk to Google Recruiters
#618There is no standard way to interview a software engineer. Whenever one of these threads come up we see multiple posters explaining their process, and while each process has it's upsides and downsides, no two are exactly the same. For a company the size of Google, with the amount of applicants they receive, I would assume that an interview standard is absolutely necessary. It's not perfect, but for 95% of developers…
I got part way through one interview process with Google -- never again. I'll stick to buying lotto tickets, the odds of 'winning' are about the same and the payout is higher. Not to mention lotto isn't quite the tremendous time-suck that playing the Google interview game is (I mean, sometimes you get stuck waiting in line behind the old lady buying $500 worth of scratch tickets so you can buy your one powerball tick…
There is no proof that joining Google is a lottery ticket(ie: whether you get in is luck). I have interviewed at Google, Amazon, Msft all multiple times and have passed every single one of their interviews multiple times(ie: I've never failed). If you want to attribute it to luck, then luck is when preparation meets opportunity.
Re: Why I Don’t Talk to Google Recruiters
#619A lot of things things come up over and over again that is why I have a copy and paste file of what I use often. 90% of the time what I need is in my file. Everyone should be given a standard copy and paste file with the algorithms that come up often rather then needing to be written from scratch. Also now you can save $50,000 per employee by being able to hire from lower then the top 1%
Re: Why I Don’t Talk to Google Recruiters
#620Earlier 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…
What made you reimplement the rendering algorithm and/or switch JSON libraries (eg were these changes backed by data/measurements)?