Hacker News .hnnew | past | comments | ask | show | jobs | submit | glaak's commentslogin

You also did not wear a pink and blue striped hat, and did not get an offer. And yet, you seem to not connect your failure to wear a pink and blue striped hat with your failure to get an offer.

I'd suggest you read the section in the article about how you're evaluated. Yes, how optimal your solution is matters -- of course it does. This doesn't mean that you have to get an optimal answer though. You have to do better than the majority of candidates (maybe ~80% of candidates).

For some problems, being in the top 20% of candidate will mean getting the optimal solution. In other cases, it may not. The optimal algorithm might be trivial, and it might be more about coding skills. In another problem, it might be totally unrealistic to expect that a candidate needs to get the optimal algorithm.

Additionally, you seem to assume that since (according to you) getting the optimal answer is necessary, that it must also be a sufficient condition. That's obviously false. It's entirely possible that a candidate needs to get the optimal answer AND implement it well, in which case these other factors come into play.


> You also did not wear a pink and blue striped hat, and did not get an offer.

I don't understand the point of this quibbling.

Say I was asked 30 questions; I missed 3 of them and didn't get hired. It's a reasonable to assume that these 3 questions were considered important in the general assessment.

> You have to do better than the majority of candidates (maybe ~80% of candidates).

I know, I said I read your book. ;-)

But that doesn't substantially change the story, it means it's likely other candidates got the optimal solution or got closer to it.

Of course this is all based on my self-assessment, since Google doesn't provide any sort of feedback post-interview. But I'm pretty confident that I went well in the other questions. 4 out of 5 interviewers were pretty nice in giving feedback during the interview, even if indirectly. E.g. they'd ask progressively more involved questions on the same topic, so I more or less knew when I had answered the previous questions correctly.

> Additionally, you seem to assume that since (according to you) getting the optimal answer is necessary, that it must also be a sufficient condition. That's obviously false.

No, I haven't made any such assumption. I only assume that getting the optimal answer was the "high bit" in my case.

Apparently this works for Google, and unlike other people who have failed to get the grapes, I don't call them sour.


"Say I was asked 30 questions; I missed 3 of them and didn't get hired. It's a reasonable to assume that these 3 questions were considered important in the general assessment."

That would be true if those answers were assess on a strictly correct / incorrect basis AND those were the only things you were assessed on. Neither of those are true though in this case.

It's very possible that the questions where you didn't get an optimal answer you actually did very well on. And that there are other questions where you got the optimal answer, but it took you too long or you made too many mistakes in coding. Or you just came off as arrogant. Who knows?

I've seen many many candidates make similar assumptions to yours -- thinking they bombed specific interviews, when in fact they did very well on those. You might be correct about why you got rejected. But it's even more likely that you're wrong.

But this is absolutely true: getting the optimal solution in all interviews is not a necessary and sufficient condition.


You weren't just asked 30 questions. You were asked 30 questions and evaluated on dozens of other non-answer based factors.

Imagine: I walk in, get 27/30 and then proceed to be a sexist bigot who says I refuse to work on a team with gays or women and I decide to start claiming that you have to get 100% to get hired.

I'm not saying you did something like that, but you're just automatically assuming that that question was the pinnacle of your rejection and not the other things listed.

I mean, unless you've been implicitly implying that you're a perfect interviewer minus the 3/30 you missed...


Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program.

Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?


Of the 4, only one is asked to do what they do during the interview. Event writers submit existing copy. Or at the very least, prepare it ahead of time before submitting it. Actors auditioning know what they are auditioning for before hand. They can prepare.

Programmers, however, must take a test. It's not an interview, it's a test. Pass or fail (regardless of what people say), it's a test. It's a test of which you have little preparation for. You hope that what they are looking for is what you can provide. What they are asking for is what they will test for (this is fairly often not the case).


>And programmers are asked to program

Programmers are almost never asked to program. They are asked to solve 50-year old CS problems on a whiteboard.


Alright. Let's assume we have this guy, we'll call him a... oh, I dunno, a salesperson. And there are all these cities he must visit to sell his wares. BUT, oh-ho, there's a catch! Let me tell you how many times he can visit each city...


At Google, at least, we try to make up new questions frequently and retire old ones.


There aren't enough problem in the world for that to be possible, ignoring extremely superficial differences.

It always comes down to exercises from CLR lightly dressed up.


Sorry, but what's CLR?



"whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit."

Agreed. That would be bullshit. And those are bad interviewers if they do any of that. Companies like Microsoft, Google, Amazon, and Facebook don't do that, as a general rule. I'm sure you could find bad interviewers at any company though.


Because for programmers what they are asked to do in the interview can (and often is) very different from what they have to do on the job. Unless your job is to reverse strings on the whiteboard.


whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit.

so yeah, ask me to program. i mean, srsly program. let's hack together for an afternoon; hell, let's do a full day of paired programming to knock out a small bug in your code base. you'll learn a hell of a lot more about what i know, how i communicate, steps i take when i do when i don't know something, and what my processes are. this soft, inter-engineer-social stuff is overlooked over far too often; i wan't to work with people who will amplify my process and abilities, and in turn i'll amplify theirs. smarts don't count for enough.


I don't think this approach would scale, due to the time investment required. It also suffers from making it hard to compare one candidate to another in a fair way, unless you have everyone fix the same bugs. Having a bunch of canned bugs to be fixed doesn't seem much better than asking a CS puzzle.


I Lways ask people to slave a simplified version of an actual problem I have worked on recently. Some times I even learn some thing.

Comparing candidates is irrelevant. You just want N hires that can contribute in your environment.


I am not saying that programmers should not be validated. Interview questions that are like IQ tests that depend heavily on single spark of inspiration are poor validators of determining productive programmers.


Actually, how well people do on one of these questions seems to correlate strongly with how well they do on others, so saying that each question depends strongly on a single spark of inspiration is kind of misleading. Where do those sparks of inspiration come from? And why do some people seem to vary so much in their ability to conjure them up on demand?


Should the writer be asked about semiotics, the actor camera techniques?


Actually, it was invite-only when I was there. But that's sort of besides the point. It's irrelevant whether or not it's an "honor" to be on the hiring committee. The point is that being on the hiring committee does give you some insight as to why people tend to get rejected. Without being on the hiring committee, you really only see why you're rejecting people -- smaller sample size, biased, less diversity of questions, etc. But, for hiring committee members, you see the results of many people's interviews.


I was in Seattle / Kirkland, and it was invite only there. I showed up every week (as did the vast majority of the Kirkland HC).

But, yes, I could have been more extensive in my credentials. Unfortunately, "How to Crack the Toughest Coding Interviews by ex-Google engineer, ex-Google hiring committee member who showed up every week, ex-Apple dev, ex-Microsoft dev, author of Cracking the Coding Interview, and author of The Google Resume" was a bit too long :).


Fair :) I'm just used to MTV HC's, where you may have 75 HC members, and 10 active ones.

I expect the "newer" offices (relatively, of course) may not have this issue.


I'm on 3 of our hiring committees, and i've been at google for over 6 years. It hasn't been invite only for as long i've been here, AFAIK. Either that, or I was secretly invited!

It is irrelevant whether it's an honor, but as to whether it gives you insight, you are generally right but you did miss an important point:

The vast majority of people who are "members" of a given hiring committee often don't show up every week. A lot, in fact, show up never, but are still members. (for example, they were part of it years ago and nobody removed them, they got asked, said yes, never actually did anything, etc)

So while you are correct that it does give you some insight if you actively participated, simply being a "member" of a hiring committee is a necessary but not sufficient condition to say that you have that insight.


That doesn't seem to be a point missed so much as one that's obvious and generally unnecessary to state fully qualified descriptions of everything in casual conversation.


Except that when you are using it as marketing in a book, there are very important distinctions.

Lies of omission and all that.


A lie of omission would apply if you state a selection of true facts and ignore other ones so as to make yourself look better than you are.

In this case, I'm stating that I was a hiring committee member and not saying that I attended regularly, when I in fact did. This is not a lie of omission. At worst, you could accuse me of not offering additional qualifications.


First of all, when people are trying to diminutize your accomplishments -- saying that you don't deserve them -- it does matter. It affects not only your morale, but also your ability to achieve things in the future.

Second, the point of the article is not the being a woman is an advantage but rather, that there's good evidence that it's a disadvantage. When you have a group that is already unrepresented in the sciences who face additional disadvantages, that IS a problem.

Yes, of course you play the hand you're dealt. What other choice do you have? That doesn't mean you shouldn't fight for equality for everyone.


Also, think through what it would mean to actually get the offer (not the interview -- the offer itself) because you were female. Your recruiter isn't deciding who is getting an offer; the individual teams are. So how would this collaboration have happened such that only women from your college were given offers? Remember that Microsoft still has a very low percent of female engineers, so it's not a company wide policy.

You're telling me that a set of unrelated teams decided interdependently to specifically offer positions to women from your college? Why? Why your college? It just doesn't make sense.

My guess is that there's something much less sinister going on, such as: -- It's just a weird coincidence. (After all, they recruit from many schools.) -- Some professor referred mostly female students, perhaps even being under the mistaken impression that they were asking for good female candidates. -- The female students are your schools are actually more qualified than the male. (This is not particularly unlikely, if your school is really less than 5% female. To get numbers that low, there may be some pressure to drop out, leaving only the best women there.) -- Microsoft hires mostly PMs from your school, which are more likely than devs to be female. -- Microsoft extended offers to a number of men too, who happened to not take the offer. -- Many of these 5 students were actually given offers for a specific program dedicated to minorities. -- You're wrong about the percent of women in your CS program (very likely). -- You're wrong about the number of women / men hired.

These are just a few of the possibilities I can think of. What seems incredibly unlikely is that a bunch of unrelated teams all decided to hire only women from specifically your university. I just don't understand how that would work.

By the way, are you sure your school is <5% female? That is WAY under the national average.


I was in the Computer Engineering program at my school. There are gender statistics here going back to 2003/2004 - http://www.ece.iastate.edu/the-department/key-performance-in...

2003/2004 was 8.7% female in that program, but that was after my year. The statistic I remembered from around 2000 was 4%. Three of the five MS interns that year were also Cpr E, the other two might have been computer science, for which I don't know the ratio. I don't think there was conspiracy among groups at MS to only hire women, I think the only people from my school who got interviews that year were women. And my impression was that MS handles intern recruiting differently than fulltime.


It is unusual that all 5 people hired were female. But, remember that coincidences happen. There are plenty of schools in which all 15 people hired are male. Unless there is some reason why your school specifically would be set apart, I don't think this is anything more than a strange coincidence.

It's possible that something in the middle is going on -- a recruiter asked a professor for recommendations and he/she happened to recommend mostly women.


If the presented figures are true, the probability of that happening entirely independently by chance are about 0.3 in a million.

It is reasonable to conclude that those decisions were not independent. But you're absolutely right that the correlation may come from the school rather than from Microsoft.


I'm pretty sure the recruiter assigned to my school was specifically a diversity recruiter.


Um. Read the studies. No, the odds aren't even. In technology, they're stacked against women. (And against black people in general.)

(I would very much believe, however, that in bartending, it's stacked against men.)


> (I would very much believe, however, that in bartending, it's stacked against men.)

OTOH, bartending is a customer-facing business, and partially entails "entertainment" (e.g. the bar-tender talking with the customers), so in many cases there's an actual business reason to prefer female bartenders (when most customers are men who prefer talking to a woman bartender).

No such excuse exists in software development...


Since you're familiar with the studies, please cite them. As it stands your comment is just "RTFM!!" without even saying which manual.


The studies cited on the original article which this comment thread it attached to. Read the graphs there. Equally qualified women were rated as less competent.

http://www.technologywoman.com/2012/09/27/i-only-got-that-jo...


As I recall being told by one of my professors as an MBA student, attractive people -- both men and women -- are generally assumed to be more competent. This effect is stronger for women than men. However, attractive women in "masculine" fields, like engineering, technology, or construction, are generally seen as being less competent.


If you already objectively know that the person is qualified the fact that they are attractive is only a plus. I think the study you a mentioning is done with people that do not know the qualifications of the person they are viewing.


True, it is done with people whose qualifications are unknown. However, I would find it very hard to believe that the bias against attractive women in a "masculine" field would be removed as soon as you knew the qualifications. Diminished a bit? Sure. But removed? Unlikely. Your initial assumptions will give you a lens through which you view someone's accomplishments.


Anecdotally it may exist; statistically, however, it does not.

Let's think about your "female friend" who has lousy technical chops and a 2.5 gpa at a mediocre state university. Is every woman with a 2.5 GPA at a lousy state university getting an interview at all three companies? No? Hmm. I suspect there's something much more to her resume than what you're telling her. These companies are not all simultaneously saying, hey, let's go interview this one woman who happens to have a 2.5 gpa at a crappy school. You're just seeing it that way because you think reverse discrimination is an issue.

Fortunately, this has been studied. And guess what? Equally qualified women have a harder time having their resume selected for technical positions. A similar study was done for black people vs. white people (or, technically, black-sounding names vs. white-sounding names).

It turns out that the conscious thought people have of wanting to hire more women is secondary to their more subconscious bias.


Regarding the overall statistics; I agree, hence what I wrote about there being real discrimination against them. What I intended to claim (but perhaps could have been more clear about) is that women have these out-in-the-open advantages and even more hidden-behind-closed-doors disadvantages.

You seem to be attaching an argument to my statement that I did not intend to convey; I don't think that reverse discrimination is an issue. I think it is extremely visible, and gives you really lousy visible situations like the ones I mentioned that are obvious errors, that doesn't mean that it is a bad idea.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: