431–440 of 683 posts
Earlier quoted context omitted.
"Self-assessed" as a resume speaking for the candidate. Without running a `git blame`, the interviewer cannot say how much of the code is from the author and how much is contributed by someone else and even then asking questions is an important part of any interview.
So what's stopping them from running git blame?
Earlier quoted context omitted.
A lot of people require a github to get an interview. But nobody wants to look at what's on the github. I've interviewed hires before, and if I ask for a github, I'm going to take the time to review some of the code, otherwise why would I ask?
This is about Google, which does not require a github.
At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…
These types of interviews work really well for the "I got 1600 on my SATs and went to {insert high profile school here} crowd" There are books out there just to prep you for Google interviews I see these as very similar to SAT test prep books. I'm not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
I know some people get frustrated by those kinds of questions, but I'd just see it as a reverse weeding out process. If you still want to work at (insert company here), just build something valuable and have them acquire you. At that point they'll acqui-hire you and you'll leap frog all the people who got in because they had Knuth books memorized.
Earlier quoted context omitted.
Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often. If you're writing scripts, or JS code for web pages or something like that, then maybe you don't use CS stuff, but ... are you able to write a web browser if you had to? Are you able to write an operating system or navigational software for a spacecraft? If not, then maybe just see this as revealing sect…
> Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often. Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel. I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I d…
In any case, how would you even go about knowing whether a certain piece of existing code that you blindly pulled in from some random place is optimized for your particular use case without first being able to conceptually understand it - which is all an interview is. Nobody expects candidates to create production ready code on a whiteboard.
Earlier quoted context omitted.
This is not about numbers. A bad hire can easily cause more friction than if nobody was hired at all. Net effect for the business is negative. You're also probably severely overestimating the likelihood of a bad hire going through.
Doesn't understand bayesian logic! Doesn't understand risk management!
FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire.
Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster!
FSK: But, if you want to minimize your bad hire rate, you also have to minimize the number of good candidates you reject.
Idiot: NO! NO! NO! The way you make sure you hire no bad candidates is to be so strict that you reject lots of good ones! That's what everyone told me so it must be right!
In one ear and out the other. Why do people who don't understand statistics get to be managers? If you don't understand this statistics argument I made, you're unqualified to work in any sort of technical area.
Earlier quoted context omitted.
This has got to be the biggest hiring fallacy I've ever heard. "It's better to reject a good candidate than hire a bad candidate." That's completely false, and anyone who says that is completely ignorant of Bayesian logic. Here are some simple numbers. Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad" candidate has a 1% chance of tricking you into hiring them anyway. Every time you pass on a "g…
I understand your point, and I'm not trying to be a troll. Humans are more complex than that. I don't think you can assume that candidates will perform the same all the time. Sometimes an excellent candidate can perform badly for multiple reasons (e.g. nervousness, poor preparation, bad interviewer, personal problems, etc). It seems to me, that rejecting a good candidate, and have him/her interview again after some t…
If your flawed process rejected a good candidate the first time around, what makes you think the same flawed process won't reject them a second time?
Earlier quoted context omitted.
People have previously mentioned hallway discussions at Google routinely devolve into bragging about SAT scores and GPAs. Nothing says Google must accept sub-par technical people, but Google fails to realize you don't have to be the top 0.0001% in absolute algorithms intelligence to do great work. Google's basic theme seems to be "you must be low latency ultra smart in our narrow interest areas" to pass an interview…
In The Plex is great read for insight into their entire process. Basically, Google is run by people who have never been told "no" to anything in their lives, so they continue to think they are the best at everything until reality forces them to reconsider their delusional assumptions ("montessori naivety"). Which is unfortunate, because objectively Google doesn't actually have a very impressive track record of creati…
Earlier quoted context omitted.
If you are hiring the Homebrew dev, and your devs currently use Homebrew, why wouldn't you hire him to work on Homebrew for you?
> If you are hiring the Homebrew dev, and your devs currently use Homebrew, why wouldn't you hire him to work on Homebrew for you? Macs account for something like 8% of the total marketplace of all PC's. For developers, they account for something like 20%... another 20% on Linux, and remainder on Windows or other. So even if somehow having a paid Google employee work on Homebrew seemed advantageous, it would only ben…
Earlier quoted context omitted.
Sometimes, but not necessarily. Sometimes it's people who always have to be "right" - which means every conversation (whether about technical things or what you did last weekend) devolves into a carefully orchestrated dance of definitions that allows everyone to escape with their egos intact - because he conceives of himself as "the smart guy" or "the guy who is always right" - so if he's wrong, he changes the rules[…
Thanks for a very interesting perspective. To further your argument RE:[2], I would like to point out that comic book guy was not the one who made the magic xylophone comment. Though I did not attend CMU nor do I work at Google, so perhaps pedantic jerks are simply endemic to our profession. ;) Possibly because it attracts the sorts of people that have no problem fighting compilers, I'm not sure.
That is hilarious and quite appropriate in this context :)