Ask a Female Engineer: Interviewing and Company Culture(themacro.com)
themacro.com
Ask a Female Engineer: Interviewing and Company Culture
http://themacro.com/articles/2016/10/ask-a-female-engineer-3/
312 comments
> Someone I know joined a company where the recruiter told her that they give all their employees at that level this same salary so there's no room for negotiation unfortunately.
Oh wow. this happened to me recently. I foolishly believed that it was true since I've heard of companies like Reddit that have policies like these.
Oh wow. this happened to me recently. I foolishly believed that it was true since I've heard of companies like Reddit that have policies like these.
People encountering this need to name and shame more. This is straight-up using asymmetrical information as a zero-sum weapon. It is hard to find salary information ahead of time, Glassdoor notwithstanding; and it is also hard to know how sleazy they are to employees.
It isn't hard to write a comment about it that will show up in a search engine, and while that is far from perfect, it will allow employees who have freedom of motion to steer clear of slimy firms and those who don't to at least be able to negotiate from a slightly less-weak position.
It isn't hard to write a comment about it that will show up in a search engine, and while that is far from perfect, it will allow employees who have freedom of motion to steer clear of slimy firms and those who don't to at least be able to negotiate from a slightly less-weak position.
[deleted]
This is likely also a bigger problem for women, who tend to be less savvy and less aggressive about negotiating for salary to begin with.
If you don't negotiate the salary it's your own problem. I honestly don't get it.
Tend to be less savvy?
The data hints that they negotiate less, yes.
There is some data suggesting that but you, and the original commenter, are jumping to conclusions that it's caused by lower “savviness”.
One commonly mentioned alternative explanation is simply that people will quite reasonably not risk negotiating aggressively when they perceive their negotiating power as being lower. Given the number of women or non-Caucasian/Asian men who've reported being paid less or held to a higher standard than peers, I would seriously consider the possibility that the data is showing us a symptom rather than the cause of the pay-gap.
One commonly mentioned alternative explanation is simply that people will quite reasonably not risk negotiating aggressively when they perceive their negotiating power as being lower. Given the number of women or non-Caucasian/Asian men who've reported being paid less or held to a higher standard than peers, I would seriously consider the possibility that the data is showing us a symptom rather than the cause of the pay-gap.
Yes, I am aware of that and thank you for saying that so clearly. Savvy was perhaps not the best word choice, but I was attempting to be succinct and trying to avoid writing multiple paragraphs. Perhaps disadvantaged would be a better term here, given that we do not know the exact cause. But I do suspect one factor is that women have less access to important information via having a beer and shooting the breeze with the guys type acticities. I have seen online discussions that suggest to me women have less savvy -- which comes from the French savior meaning essentially know how -- because they have less access to group knowledge of such things.
One of the problems is that when women lack such knowledge, they come across as less confident because, in the statistical sense of the word, they literally are less confident. In other words, in an absence of hard information, you cannot be sure if the figure you are asking for is too high, too low or just right. But when they evince this lack of confidence, people usually try to give them pep talks rather than hard data. It gets treated like a lack of self esteem rather than a lack of information.
I do think you are correct that women simply cannot afford to negotiate as aggressively and this is a factor. But I also think they lack access to knowledge that a lot of men are exposed to casually simply because they are male and this makes it easier for them to hang with the right crowd and get anecdotes, etc. And that piece is what I was trying to capture with the word savvy.
I am a woman. I know a lot about negotiating. I remain poorly equipped to negotiate on salary because I lack information. Having general savvy about negotiating technique is insufficient. You cannot play hard ball if you do not have hard information particular to the problem space in question.
One of the problems is that when women lack such knowledge, they come across as less confident because, in the statistical sense of the word, they literally are less confident. In other words, in an absence of hard information, you cannot be sure if the figure you are asking for is too high, too low or just right. But when they evince this lack of confidence, people usually try to give them pep talks rather than hard data. It gets treated like a lack of self esteem rather than a lack of information.
I do think you are correct that women simply cannot afford to negotiate as aggressively and this is a factor. But I also think they lack access to knowledge that a lot of men are exposed to casually simply because they are male and this makes it easier for them to hang with the right crowd and get anecdotes, etc. And that piece is what I was trying to capture with the word savvy.
I am a woman. I know a lot about negotiating. I remain poorly equipped to negotiate on salary because I lack information. Having general savvy about negotiating technique is insufficient. You cannot play hard ball if you do not have hard information particular to the problem space in question.
I like your suggestion of “disadvantaged” — it covers both the information asymmetry and the real or perceived differences in negotiating strength.
Also women who try to negotiate can get retaliated against.
At this point I'm always going to fall into one of two boats:
1) I don't need a job. You'll pay me what I want or no deal. In those cases things like what this recruiter pulled won't work.
2) I need a job. In this case it doesn't really matter to me.
1) I don't need a job. You'll pay me what I want or no deal. In those cases things like what this recruiter pulled won't work.
2) I need a job. In this case it doesn't really matter to me.
I've been in both situation. I first encountered (2) when I was looking for my first fulltime job back in college. I had little idea of how much I'm supposed to get paid so I told the recruiter: "I had no idea how much I worth, but one day I'll find out. And if I realized I'm low-balled, I'll left for another company immediately and all the resource your company spend on training me will go nowhere." It worked for me. But I guess it won't work for those really sketchy recruiters since all they care is take their commission.
Little ballsy, Raises a good point as well. I'll need to keep that in mind when I go for my first FT job
Interestingly enough, recruiters get paid a % of the salary as a commission most of the time. This means they actually have an incentive to get you higher pay.
But they also can't keep bringing in people above a company's ask. It's a balance that has to be managed.
But they also can't keep bringing in people above a company's ask. It's a balance that has to be managed.
The biggest gap for the recruiter is between no and yes. The tiny increase they get for themselves for negotiating hard on behalf of their placement rounds to zero in most cases. If it costs them a placement, the opportunity cost is huge.
I have always been in (1) or (2), but can think of (3) I'd love to be at this job (because of company mission, etc) . Maybe it is a subcase of (2)?
I think that would be a subcase of (1). Would be "give me what I want" which would be other reasons than "pay me what I want".
Absolutely, I should have phrased it that way from the start. I don't view salary as the end all be all, however I'll be the one to choose what I'm willing to take a discount for, not them.
> I foolishly believed that it was true since I've heard of companies like Reddit that have policies like these.
A lot of large companies have tiered salary levels that are not in any way tailored for the individual. In Germany, we have a Tarifvertrag in virtually every large company, which fixes the salary.
A lot of large companies have tiered salary levels that are not in any way tailored for the individual. In Germany, we have a Tarifvertrag in virtually every large company, which fixes the salary.
>For example, I’ve told recruiters about my salary expectations and had them laugh and say “no one gives that kind of [salary/equity/vacation/benefits].”
I had a similar experience looking for my first job in Chicago a few years back.
I met with a fairly large general recruiting firm in the area just so they could feel me out.
I named my expectation of 50-60k to which the recruiter replied.
"You know... when I moved to Chicago I was living on 18k"
Not exactly the type of response I expected.
I had a similar experience looking for my first job in Chicago a few years back.
I met with a fairly large general recruiting firm in the area just so they could feel me out.
I named my expectation of 50-60k to which the recruiter replied.
"You know... when I moved to Chicago I was living on 18k"
Not exactly the type of response I expected.
"Wow, you came to Chicago as a software engineer too? Tell me about how you got into recruiting?"
Ugh what one should even say to that? "sucks to be you"?
I would have walked out after hearing that. How could a recruiting firm be of any help to you if their goal is to get you to accept a low paying job asap. They'll be fighting with you every step of the way. I would rather search for a job on my own, even if it means eating ramen every day for months.
> “no one gives that kind of [salary/equity/vacation/benefits].”
Everything is negotiable, including when you hear things like that and "that's not our policy", etc.
Everything is negotiable, including when you hear things like that and "that's not our policy", etc.
[deleted]
This is super common. You just have to know it is something recruiters say to try and get a prospective recruit to accept a lower compensation package and work around it.
I clicked on this thread by accident. Was worth it.
I am glad she mentioned how awful it is to have only one female employee.
I was the only woman in an office. One of my co workers made a pretty horrific comment (not about me, but about women in front of me). Someone went to HR and we had sensitivity training...but everyone assumed it was me because I was the only woman. Maybe I SHOULD have gone to HR, but I didn't want to because I feared being the obvious complainant. Which I ended up getting the side-eye for anyway.
I realized I would much rather work somewhere with at least 2 other women.
I was the only woman in an office. One of my co workers made a pretty horrific comment (not about me, but about women in front of me). Someone went to HR and we had sensitivity training...but everyone assumed it was me because I was the only woman. Maybe I SHOULD have gone to HR, but I didn't want to because I feared being the obvious complainant. Which I ended up getting the side-eye for anyway.
I realized I would much rather work somewhere with at least 2 other women.
I'm not sure how much this has to do with quantity of x as opposed to quality of x.
I've worked in small teams where I was the only Asian person among a team of white men, and I neither noticed any hints of racism nor sexism.
I've also worked in teams where it's been highly diverse in ethnicity though not gender, and again, never noticed any hints of sexism.
Though I have certainly worked in a company with a number of women, including a female co-founder/CEO who was absolutely sexist... against women. I'm not suggesting women are bad CEO's or that diversity is bad, I'm saying that from my experience, it hasn't been about the diversity of the team so much as the type of people in the composition.
Also from my POV, I'm not sure how having a random % of women makes more or less sense than a random % of black people or Latino's. Like if a company is predominantly composed of white men, does adding a white female make it more diverse than adding a black man?
I've worked in small teams where I was the only Asian person among a team of white men, and I neither noticed any hints of racism nor sexism.
I've also worked in teams where it's been highly diverse in ethnicity though not gender, and again, never noticed any hints of sexism.
Though I have certainly worked in a company with a number of women, including a female co-founder/CEO who was absolutely sexist... against women. I'm not suggesting women are bad CEO's or that diversity is bad, I'm saying that from my experience, it hasn't been about the diversity of the team so much as the type of people in the composition.
Also from my POV, I'm not sure how having a random % of women makes more or less sense than a random % of black people or Latino's. Like if a company is predominantly composed of white men, does adding a white female make it more diverse than adding a black man?
I don't see what this has to do with my comment. I didn't say all men are sexist or all teams are sexist, just stated that there is safety in numbers.
You're lucky nobody said something racist about Asians when you were the only Asian. Otherwise, you would have been in the same situation. But that's it: luck. It could happen to anyone and then the workplace could turn hostile.
You're lucky nobody said something racist about Asians when you were the only Asian. Otherwise, you would have been in the same situation. But that's it: luck. It could happen to anyone and then the workplace could turn hostile.
I'm not sure how much this has to do with quantity of x as opposed to quality of x.
Quantity matters. Everything is contextual. If one is in a "hypo-minority" situation, then one is more likely to stand out. Being unique can be nice, but being irrevocably marked as unique, with no respite can feel like being trapped. Being singled out is simply more likely if you are truly singular.
Like if a company is predominantly composed of white men, does adding a white female make it more diverse than adding a black man?
I think that very much depends on the people involved. So in this, you are right. But quantity does matter a lot.
Quantity matters. Everything is contextual. If one is in a "hypo-minority" situation, then one is more likely to stand out. Being unique can be nice, but being irrevocably marked as unique, with no respite can feel like being trapped. Being singled out is simply more likely if you are truly singular.
Like if a company is predominantly composed of white men, does adding a white female make it more diverse than adding a black man?
I think that very much depends on the people involved. So in this, you are right. But quantity does matter a lot.
> I've worked in small teams where I was the only Asian person among a team of white men, and I neither noticed any hints of racism nor sexism.
I don't think your situations are comparable. Women are ~50% of the population and sexual undertones have nothing to do with ethnicity, but everything to do with gender.
I don't think your situations are comparable. Women are ~50% of the population and sexual undertones have nothing to do with ethnicity, but everything to do with gender.
Also, I think it is MUCH more likely for a team to have only one woman than only one Asian. From my experience working as a dev in the US, anyway.
At any rate, I've never been on a team that didn't have several Asians. But I've had many co workers tell me they've never worked with a woman before (which in itself is awkward to hear unprompted, haha).
Thanks for pointing out that race and sex are not comparable. It's true, they really aren't.
At any rate, I've never been on a team that didn't have several Asians. But I've had many co workers tell me they've never worked with a woman before (which in itself is awkward to hear unprompted, haha).
Thanks for pointing out that race and sex are not comparable. It's true, they really aren't.
You might be confusing sexuality and sexism.
I'm sorry that happened but I don't think it's indicative of some trend in the industry.
I've been a minority almost my entire life. Most of the issues with being a minority are not really present on software engineering teams. The demographics are too widespread.
There is no in-group. I would estimate 50-60% of software engineers are immigrants. That group is further segmented by country of origin. Everyone is different from each other.
Country of origin transcends both gender and race in terms of shared experiences and commonalities. American born people of all races and gender are more likely to befriend each other than to befriend a person who speaks broken English.
This diversity on software engineering teams minimizes the effects of being different because everyone is different from each other.
Software engineers also tend to be more introverted and immigrants are more polite (due to unfamiliarity with American culture).
For people to make inflammatory comments and get away with it, they need to have allies and be part of an in-group. These prerequisites are much more difficult to fulfill as a software engineer.
Software engineering is one of the best professions to be a minority in.
I've been a minority almost my entire life. Most of the issues with being a minority are not really present on software engineering teams. The demographics are too widespread.
There is no in-group. I would estimate 50-60% of software engineers are immigrants. That group is further segmented by country of origin. Everyone is different from each other.
Country of origin transcends both gender and race in terms of shared experiences and commonalities. American born people of all races and gender are more likely to befriend each other than to befriend a person who speaks broken English.
This diversity on software engineering teams minimizes the effects of being different because everyone is different from each other.
Software engineers also tend to be more introverted and immigrants are more polite (due to unfamiliarity with American culture).
For people to make inflammatory comments and get away with it, they need to have allies and be part of an in-group. These prerequisites are much more difficult to fulfill as a software engineer.
Software engineering is one of the best professions to be a minority in.
There is always an in-group, it's just a matter of which one. I have worked at places where I was part of the in-group, and places where I wasn't. Sometimes it was nationality. Others, the school you came in. The gender divide is not a big issue in some places, while in others I've ended up talking to HR about harassment that I saw in front of my own eyes. I've been the shoulder to cry on, literally, in one of those cases. And don't get me started with discrimination due to sexual orientation.
It's really easy to know when you are not part of the majority though: When you don't see any differences and everything looks cheery and happy, congratulations, you are not treated as a minority.
We can't really boats about the industry when we have 15% women and about under 10% African-American. I've worked at a place where we had a large architecture meeting: 25 architects, zero women. The company boasted 50-50 gender split, but with vert few exceptions, you could make a great guess of role and gender. Guess that men sitting in an engineering pod are developers or managers, and that women are either QA or systems analysts, and you'll get it right. The testers had the same CS background as the developers, except they were paid a good 30% less. The rest of the women came from recruiting and HR. You could also guess which department they worked on just by looks too.
I know four women that have dropped out of software engineering in the last year, just because the toll of being treated differently made them lose any love they had for the industry, and are now doing jobs that pay way less, but where they don't have to work twice as hard as a man to get half the recognition. One of them is rather unattractive by your typical standards. When she quit her last job, many people didn't even know she had been working there for years: She might as well have been socially invisible.
Maybe you've been very lucky in your career, and haven't seen the discrimination, or maybe you really are part of the in-group and don't know about it.
It's really easy to know when you are not part of the majority though: When you don't see any differences and everything looks cheery and happy, congratulations, you are not treated as a minority.
We can't really boats about the industry when we have 15% women and about under 10% African-American. I've worked at a place where we had a large architecture meeting: 25 architects, zero women. The company boasted 50-50 gender split, but with vert few exceptions, you could make a great guess of role and gender. Guess that men sitting in an engineering pod are developers or managers, and that women are either QA or systems analysts, and you'll get it right. The testers had the same CS background as the developers, except they were paid a good 30% less. The rest of the women came from recruiting and HR. You could also guess which department they worked on just by looks too.
I know four women that have dropped out of software engineering in the last year, just because the toll of being treated differently made them lose any love they had for the industry, and are now doing jobs that pay way less, but where they don't have to work twice as hard as a man to get half the recognition. One of them is rather unattractive by your typical standards. When she quit her last job, many people didn't even know she had been working there for years: She might as well have been socially invisible.
Maybe you've been very lucky in your career, and haven't seen the discrimination, or maybe you really are part of the in-group and don't know about it.
> We can't really boats about the industry when we have 15% women and about under 10% African-American.
Disagree. We have amazing contributions from a variety of people from Europe, South America, and Asia. It's not perfect, and it should get better, but it's nothing to be ashamed about.
It's interesting how the NBA happily celebrates black culture and black people who represent their game despite the fact that they are overrepresented relative to the general population, but the tech industry basically never celebrates the contributions from a variety of immigrants and non-whites in its own industry.
Disagree. We have amazing contributions from a variety of people from Europe, South America, and Asia. It's not perfect, and it should get better, but it's nothing to be ashamed about.
It's interesting how the NBA happily celebrates black culture and black people who represent their game despite the fact that they are overrepresented relative to the general population, but the tech industry basically never celebrates the contributions from a variety of immigrants and non-whites in its own industry.
And can't even safely mention whites.
This argument (or more specifically, personal accounts) doesn't really respond to the original argument about a high % of immigrants.
Why is there always an in-group?
What is the in-group of a place with:
- 10% Asian Americans
- 10% Indian Americans
- 10% various white European immigrants
- 15% Indian immigrants
- 20% Asian immigrants (14% Chinese, 4% Korean, 2% other)
- 25% white Americans
- 5% Black/Hispanic Americans
- 5% Black/Hispanic immigrants
(With 10% females spread among those race/country lines)
What I see happen is that the various groups separately cluster based on country of origin. None of the groups are dominant, so no one person (even a leader of a group) will feel comfortable making inflammatory remarks.
Many times everyone on the team is introverted and no groups form at all.
>Maybe you've been very lucky in your career, and haven't seen the discrimination, or maybe you really are part of the in-group and don't know about it.
Ad hominem? I've been a minority in the most formative years in places where being different is tough and I understand the difficulties. I contrast the experience and demographics of work with those years.
Why is there always an in-group?
What is the in-group of a place with:
- 10% Asian Americans
- 10% Indian Americans
- 10% various white European immigrants
- 15% Indian immigrants
- 20% Asian immigrants (14% Chinese, 4% Korean, 2% other)
- 25% white Americans
- 5% Black/Hispanic Americans
- 5% Black/Hispanic immigrants
(With 10% females spread among those race/country lines)
What I see happen is that the various groups separately cluster based on country of origin. None of the groups are dominant, so no one person (even a leader of a group) will feel comfortable making inflammatory remarks.
Many times everyone on the team is introverted and no groups form at all.
>Maybe you've been very lucky in your career, and haven't seen the discrimination, or maybe you really are part of the in-group and don't know about it.
Ad hominem? I've been a minority in the most formative years in places where being different is tough and I understand the difficulties. I contrast the experience and demographics of work with those years.
The ingroup there is pretty obvious: being a dude.
I don't know how that's even a question -- one group composes 90% of the workplace, and its a group that enjoys special privileges.
Racial discrimination and in-grouping isn't the only kind of in-group.
I don't know how that's even a question -- one group composes 90% of the workplace, and its a group that enjoys special privileges.
Racial discrimination and in-grouping isn't the only kind of in-group.
The point is valid, but this obviously puts organisations trying to recruit their first female employees in a bit of a pickle. For the benefit of the common good (getting more small businesses and startups to hire more women) it might be better to asses a business's desired trajectory rather than its current state... right?
Exactly.
I've definitely interviewed female candidates for a small startup where they decided not to proceed once they found out they'd be the first woman on the team. I certainly don't hold it against them, but it really does make increasing diversity a lot harder if nobody is willing to be the first one.
It's a great example of how hard it can be to change the trajectory of systems even when everyone earnestly works towards change.
I've definitely interviewed female candidates for a small startup where they decided not to proceed once they found out they'd be the first woman on the team. I certainly don't hold it against them, but it really does make increasing diversity a lot harder if nobody is willing to be the first one.
It's a great example of how hard it can be to change the trajectory of systems even when everyone earnestly works towards change.
Well I guess it's a good thing you avoided a few very sexist candidates...
I wish I could say I'm a perfect martyr for the feminist cause, but I'm not.
I'd rather have a happy and productive career than an ugly sexual harassment and wrongful termination suit.
I'd rather have a happy and productive career than an ugly sexual harassment and wrongful termination suit.
Huh - I wonder if you could use that as leverage during pay negotiation.
"Oh, you don't have any other women on staff? You need to know that thats going to be sort of rough for me, in complicated gross ways. I'll still do it, but only if you pay me an extra 10% compensation pay on top of what you were otherwise going to pay me. (Which you can stop doing as soon as you hire another woman)."
"Oh, you don't have any other women on staff? You need to know that thats going to be sort of rough for me, in complicated gross ways. I'll still do it, but only if you pay me an extra 10% compensation pay on top of what you were otherwise going to pay me. (Which you can stop doing as soon as you hire another woman)."
As a man, this would make me extremely uncomfortable for a lot of reasons. Not the least of which because it implies to me that you think all men are scummy creeps and that you need extra money to deal with us.
That's a hell of a reach from what she said, to put it mildly. To justify your inference she would need to be asking for extra money for dealing with any men, ever.
I feel like that's just going to get them to retract their offer in a lot of cases.
Isn't it sexist to pay someone differently (more in this case) just because of their gender?
Completely agree. This stance clearly makes sense from any individual's perspective.
Yea that was an idea I got out of this that I think will take to heart, at the very least teams should have a couple of women in them, even if it might make one team all men (the 15% women in tech number is really annoying; the better solution would just be to have half of each team be women).
You should've laughed to divert any suspicions. When someone makes a racist joke about me I chuckle and wait for my turn. Because I don't want to watch what I am saying all the time. He did not make an attack, he lowered his shield. And then suffered the consequences.
Believe me, it really wasn't funny...
Like, it was violent and creepy and Elliot Rodgers-esque. I would have looked like a psycho to the other co workers if I laughed. As it stands, the offending co worker looked like a psycho.
(He got fired. But I was a bit scared for my safety.)
Like, it was violent and creepy and Elliot Rodgers-esque. I would have looked like a psycho to the other co workers if I laughed. As it stands, the offending co worker looked like a psycho.
(He got fired. But I was a bit scared for my safety.)
If it was violent, creepy, and reminiscent of a mass-murderer comment directed towards women, I would think it a good thing that people would suspect you were the one to stick up for women, seeing as you had the most to fear from such a hateful person. It's a good thing that at least one person reported them, since the unfortunate human norm is for a bystander to ignore those in need of help / defense / solidarity.
If "everyone assumed it was you" and then gave you "the side-eye" for the consequences of this nasty person's comment's getting reported, fired, then this seems like clear signal that that workplace was no good in that way and it's time to find friendlier waters.
How do you think this would have gone differently had there been two more female employees? The hateful one would have kept a tighter lid on their true personality? The side-eye would have been more them vs us, or again, left thought but not expressed?
Anyways, lack of diversity sucks.
If "everyone assumed it was you" and then gave you "the side-eye" for the consequences of this nasty person's comment's getting reported, fired, then this seems like clear signal that that workplace was no good in that way and it's time to find friendlier waters.
How do you think this would have gone differently had there been two more female employees? The hateful one would have kept a tighter lid on their true personality? The side-eye would have been more them vs us, or again, left thought but not expressed?
Anyways, lack of diversity sucks.
Not everyone was there for the comment and HR did not say what the comment was or who said it.
For 90% of my co workers, it was just "we all have sensitivity training for sexist comment reported to HR and only one woman, soooo..."
For 90% of my co workers, it was just "we all have sensitivity training for sexist comment reported to HR and only one woman, soooo..."
Lack of diversity doesn't suck assuming the company hired the best talent for the role. Diversity for the sake of diversity is horrible and makes you dislike the people for just being there
> "As opposed to fox-and-hare looped link lists or implementing a binary tree or something else I’ve done a hundred times in an interview and not once in my actual job."
This. Interviewers, stop asking questions that only a fresh college grad should have at the forefront of their mind.
One of the best interview's I've had, was actually for a job I didn't get. It was for a game development company, and they actually posed problems and questions one might face in their day to day work. For example, writing an efficient collision detection algorithm.
This. Interviewers, stop asking questions that only a fresh college grad should have at the forefront of their mind.
One of the best interview's I've had, was actually for a job I didn't get. It was for a game development company, and they actually posed problems and questions one might face in their day to day work. For example, writing an efficient collision detection algorithm.
> This. Interviewers, stop asking questions that only a fresh college grad should have at the forefront of their mind.
These aren't questions "only a college grad should know" they're often questions that are baseline knowledge for understanding programming vs just having a few rote cargo cult "skills".
I have been on both sides of the interview process at Google, and I remember when I was prepping to conduct my first interview, one of my teammates gave me some advice. He suggested I open with something along the lines of "merge two sorted lists". Someone who couldn't do this with a minimum of effort barely fits the definition of "knowing how to program" (let alone being a good engineer). And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test.
Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter.
These aren't questions "only a college grad should know" they're often questions that are baseline knowledge for understanding programming vs just having a few rote cargo cult "skills".
I have been on both sides of the interview process at Google, and I remember when I was prepping to conduct my first interview, one of my teammates gave me some advice. He suggested I open with something along the lines of "merge two sorted lists". Someone who couldn't do this with a minimum of effort barely fits the definition of "knowing how to program" (let alone being a good engineer). And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test.
Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter.
> " And yet, a non trivial chunk of the candidates he had met with didn't clear this bar! Starting with an assumption that your candidate can handle complex questions when they can't even program can just muddle the issue, and there's very little advantage to skipping over the basic test."
And yet, I'd be surprised if almost all of those who didn't pass his "basic test" went on to be gainfully employed, and successful, building X app at X company instead of at Google.
And yet, I'd be surprised if almost all of those who didn't pass his "basic test" went on to be gainfully employed, and successful, building X app at X company instead of at Google.
That may be true, but I've never been at a company that was desperate enough to hire cargo cult programmers. Interview jitters aside (that's an unfortunate artifact of the coding interview), not having a grasp of loops, iteration, and the most basic of data structures is a low, low, low bar for "knows how to program".
I'm not even being particularly picky here. Big companies can be notorious for hiring CS grads from great programs and never having them do any actual computer science, and I agree that that bar is unnecessary for good engineering. But this filter isn't _unrelated_ to the job of being an engineer (or even a code monkey!), it's basic, basic programming. I'd imagine it does a great job of removing the kind of candidates who are capable of trivially avoidable bugs that become time bombs down the road.
I'm not even being particularly picky here. Big companies can be notorious for hiring CS grads from great programs and never having them do any actual computer science, and I agree that that bar is unnecessary for good engineering. But this filter isn't _unrelated_ to the job of being an engineer (or even a code monkey!), it's basic, basic programming. I'd imagine it does a great job of removing the kind of candidates who are capable of trivially avoidable bugs that become time bombs down the road.
Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult. Many of Googles products implode shortly after getting released making software quality irrelevant. Also many successful Google products were originally made by other companies, presumably with different hiring processes, that joined Google.
That said, from what I've heard it isn't the questions themselves so much as the overall interview process that puts people off.
That said, from what I've heard it isn't the questions themselves so much as the overall interview process that puts people off.
> Seems almost like your arguing against yourself here. Hiring people based on things they won't use seems an awful lot like a cargo cult.
First of all, that's not what cargo cult means....https://en.wikipedia.org/wiki/Cargo_cult_programming. What you're describing (though it doesn't apply to what I was saying) is also a bad thing, but you can't just use random phrases to mean whatever you want.
More to the point: You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists? Because as I've mentioned multiple times, those are the basic, basic skills being tested by a question like "merge two sorted lists". One might have actually have occasion to write that algorithm on the job, but the real point is to test for a basic understanding of control flow and performance. I can barely imagine a programming job that would never have occasion to use those things, and most of the actual engineering you do in the simplest engineering jobs involve tasks of similar complexity. This isn't me blindly defending whatever interview policy Google happened to have; I'm talking about the adjustments I personally made to find what works over the course of a couple dozen interviews.
> Many of Googles products implode shortly after getting released making software quality irrelevant.
Now this is just embarrassing. Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides. I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant.
First of all, that's not what cargo cult means....https://en.wikipedia.org/wiki/Cargo_cult_programming. What you're describing (though it doesn't apply to what I was saying) is also a bad thing, but you can't just use random phrases to mean whatever you want.
More to the point: You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists? Because as I've mentioned multiple times, those are the basic, basic skills being tested by a question like "merge two sorted lists". One might have actually have occasion to write that algorithm on the job, but the real point is to test for a basic understanding of control flow and performance. I can barely imagine a programming job that would never have occasion to use those things, and most of the actual engineering you do in the simplest engineering jobs involve tasks of similar complexity. This isn't me blindly defending whatever interview policy Google happened to have; I'm talking about the adjustments I personally made to find what works over the course of a couple dozen interviews.
> Many of Googles products implode shortly after getting released making software quality irrelevant.
Now this is just embarrassing. Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides. I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant.
> First of all, that's not what cargo cult means...
Per the definition on the linked wikipedia page cargo cult programming is "ritual inclusion of code or program structures that serve no real purpose", "results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle" and "organizations that attempt to emulate more successful development houses". It's of course based on the concept of cargo cult behavior, where you try to achieve success by imitating external properties without the substance.
I'm saying that Google by having things like a challenging admissions process, predictable career path, stark focus on credentials, all-inclusive perks and campus environment are trying to imitate an elite school which is an environment where many people at Google felt successful. By doing that they recruit computer science heavy coders which, at least when they are inexperienced, tend to overly rely on CS style programming (advanced techniques, optimizations, correctness) in favor of other concerns of software engineering (organizational friction, code flexibility, overall design). There's evidence that candidates that want to work at companies like Google often cram these types of questions without necessary having used them in real world projects. I would say both imitation of academia, over reliance of CS as a factor in recruiting and the risk of neglecting software engineering in favor of computer science techniques is relevant to the concept of cargo cult and cargo cult programming.
> Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides.
The whole point of the cargo cult concept is that you do things that in the end is ineffective. We all know that Google has a lot of smart people, with credentials and that can write code. Yet, that doesn't always seem to produce good result as far as shipping products. Yes, one could blame management but that is also a factor of company culture.
> I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant.
Why would you accuse me of "irrelevant asides" and then bring up "random 14 year olds". Software quality is subjective. One could argue that writing, both as part of developing and documenting software, is essential for software quality. You seem to use a lot of rhetoric that isn't relevant to the discussion at hand.
> You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists?
That's not the point. There are other ways to find out if people can manage these things that doesn't favor people with a theoretical background. Other method might be looking up peoples portfolios, having them submit code they've written, pair programming or reasoning around example code.
Googles hiring process is adopted for how Google works. Having a common theoretical framework might be important at Google. But that doesn't mean that people who doesn't fit into that profile can't be good software engineers, nor that this process is even feasible for other companies.
Per the definition on the linked wikipedia page cargo cult programming is "ritual inclusion of code or program structures that serve no real purpose", "results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle" and "organizations that attempt to emulate more successful development houses". It's of course based on the concept of cargo cult behavior, where you try to achieve success by imitating external properties without the substance.
I'm saying that Google by having things like a challenging admissions process, predictable career path, stark focus on credentials, all-inclusive perks and campus environment are trying to imitate an elite school which is an environment where many people at Google felt successful. By doing that they recruit computer science heavy coders which, at least when they are inexperienced, tend to overly rely on CS style programming (advanced techniques, optimizations, correctness) in favor of other concerns of software engineering (organizational friction, code flexibility, overall design). There's evidence that candidates that want to work at companies like Google often cram these types of questions without necessary having used them in real world projects. I would say both imitation of academia, over reliance of CS as a factor in recruiting and the risk of neglecting software engineering in favor of computer science techniques is relevant to the concept of cargo cult and cargo cult programming.
> Your argument is so bereft of anything resembling logic that you have to resort to completely irrelevant asides.
The whole point of the cargo cult concept is that you do things that in the end is ineffective. We all know that Google has a lot of smart people, with credentials and that can write code. Yet, that doesn't always seem to produce good result as far as shipping products. Yes, one could blame management but that is also a factor of company culture.
> I suppose they should just hire random 14 year olds to do their engineering since software quality is irrelevant.
Why would you accuse me of "irrelevant asides" and then bring up "random 14 year olds". Software quality is subjective. One could argue that writing, both as part of developing and documenting software, is essential for software quality. You seem to use a lot of rhetoric that isn't relevant to the discussion at hand.
> You seriously think that engineers won't have occasion to use loops, iteration, and data structures resembling lists?
That's not the point. There are other ways to find out if people can manage these things that doesn't favor people with a theoretical background. Other method might be looking up peoples portfolios, having them submit code they've written, pair programming or reasoning around example code.
Googles hiring process is adopted for how Google works. Having a common theoretical framework might be important at Google. But that doesn't mean that people who doesn't fit into that profile can't be good software engineers, nor that this process is even feasible for other companies.
>Hiring people based on things they won't use seems an awful lot like a cargo cult.
Yes, but in this case, it's a cargo cult of over-qualification. Hardly a bad thing.
>Many of Googles products implode shortly after getting released making software quality irrelevant.
That is a function of leadership and poor product planning and has nothing to do with the quality of the engineers there.
Yes, but in this case, it's a cargo cult of over-qualification. Hardly a bad thing.
>Many of Googles products implode shortly after getting released making software quality irrelevant.
That is a function of leadership and poor product planning and has nothing to do with the quality of the engineers there.
While that may be the case for some employees, I expect that for any programming work to be done at all, you're able to merge two sorted lists. If a candidate cannot do that I have little faith their abilities to program in general. Note that this is not CS stuff at all, but beginner programming tutorial stuff.
I hear you. We should acknowledge, though, that this goes well beyond merging sorted lists. My guess is that there are lots of people who can do this but are filtered out by considerably more difficult questions.
Even with merging two sorted lists, remember that you're asking people to merge two sorted lists at a whiteboard while explaining what they're doing, under somewhat stressful conditions, which may trip up someone who could do this easily at a keyboard.
Even with merging two sorted lists, remember that you're asking people to merge two sorted lists at a whiteboard while explaining what they're doing, under somewhat stressful conditions, which may trip up someone who could do this easily at a keyboard.
[deleted]
>He suggested I open with something along the lines of "merge two sorted lists".
We (my team at Amazon) don't start with a softball, but we try to make sure every question can be down-leveled if someone is struggling. My current one degenerates to: "insert numbers in a sorted list, then find the index of a number in the list". A surprising number of people struggle with this.
I know lots of people get tripped up by graph and tree problems (myself included) because they don't use them in real life often, but simple lists are another story. At FaceGoogAzon scale you can't always rely on array.sort().
We (my team at Amazon) don't start with a softball, but we try to make sure every question can be down-leveled if someone is struggling. My current one degenerates to: "insert numbers in a sorted list, then find the index of a number in the list". A surprising number of people struggle with this.
I know lots of people get tripped up by graph and tree problems (myself included) because they don't use them in real life often, but simple lists are another story. At FaceGoogAzon scale you can't always rely on array.sort().
For a sysadmin/devopsy position I asked the interviewees to write a program in any language that gave the average of numbers given as command line args.
Not one did it successfully. Most didn't even try. The best one assumed five numbers given. But we had to hire someone, and it wasn't this one. The deciders just hired the nicest person.
Not one did it successfully. Most didn't even try. The best one assumed five numbers given. But we had to hire someone, and it wasn't this one. The deciders just hired the nicest person.
Wow. Were these candidates with CS degrees? What was the problem? Did they not know how to parse command line args in any language? Not know how to compute an average? Not know how to do anything on the command line (or outside an IDE)? Something else?
We didn't go into it unfortunately.
I don't want to ask it of the one we hired because I don't want to cause bad blood. :-(
It's possible that what little programming they did in their 'information science' (or whatever degree, not straight CS) only involved Windows programming, and nothing on the command line.
I don't want to ask it of the one we hired because I don't want to cause bad blood. :-(
It's possible that what little programming they did in their 'information science' (or whatever degree, not straight CS) only involved Windows programming, and nothing on the command line.
> Bear in mind that this was at Google, and these were candidates who had already made it past the first line filter.
Are you sure that Google's first line filter is actually good?
Are you sure that Google's first line filter is actually good?
I don't think super highly of it in an objective sense, but I do think that they have the resources (and probably the know-how) to do a better job at it than the vast majority of hiring situations (smaller companies, etc). And I do have a high opinion of the engineering talent at Google, who are involved in the phone interview process (which I guess I was lumping together with actual HR first-line resume screening).
In "merging" it is assumed that there won't be any repeated values? that is the first question that came to my mind.
That's just an implementation detail whose answer wouldn't really change the difficulty of the question much. When actually interviewing (at any company), I'm always much more precise about the question and usually give representative sample input/output.
Would the candidates just clear the interview by mugging up on algorithms.
Consider the fact that coding under pressure is hard and it probably doesn't mean that the candidate is incapable of merging two sorted lists. Right now I can think of a way to do it:
var ar = [];
ar1.map(function() { ar.push(arguments[0]); }
ar2.map(function() { ar.push(arguments[0]); }
FYI, this doesn't merge two _sorted_ lists.
The correct answer would be to loop while neither list is empty and always put the smaller element into the new array and remove it from the original list.
Then you iterate over each of the lists individually (one of them will already be empty) and copy over the remaining elements at the end.
Edit: See http://stackoverflow.com/questions/5958169/how-to-merge-two-... for some solutions (in one of the answers there, they made the same mistake.)
The correct answer would be to loop while neither list is empty and always put the smaller element into the new array and remove it from the original list.
Then you iterate over each of the lists individually (one of them will already be empty) and copy over the remaining elements at the end.
Edit: See http://stackoverflow.com/questions/5958169/how-to-merge-two-... for some solutions (in one of the answers there, they made the same mistake.)
Oh shit. I just failed the interview then. I'm just not that smart, more of a code monkey type, not really a mathematician computational type programmer. I want to be better, but I think I'm just cut out for line of business type things where you don't need any CS knowledge even though I will have a CS degree soon.
That's what I mean, just because the question is abstracted to be pure numbers doesn't mean that it's mathematician computational type stuff. This is a basic enough task (data structures, iteration) that someone who can't do it wouldn't meet any reasonable definition of "knowing how to code".
By the way, I don't think that group includes you: I'm quite sure you'd be able to pass it in an interview context. You'd probably be paying more attention to the details of the question in an interview and I usually give sample input/output to reduce the chance of a candidate accidentally overlooking a word in the question.
By the way, I don't think that group includes you: I'm quite sure you'd be able to pass it in an interview context. You'd probably be paying more attention to the details of the question in an interview and I usually give sample input/output to reduce the chance of a candidate accidentally overlooking a word in the question.
I would correct to 'any reasonable definition of being a professional software developer'. There are tons of programming tasks that require coding literacy but do not require even knowing what a linked list is (e.g. simulations written by really smart people pursuing a Physics Ph.D., perl scripts done by wise UNIX-beard sysadmins, etc). That said, I agree this is a reasonable sanity-check test for someone who is asking about a developer job at a software company, and I also agree that it is easy to make mistakes in commenting an off-the-cuff answer to it on an online forum that one wouldn't make in a real interview.
I mean, I've gotten 3rd grade arithmetic wrong in my own HN comments before! ;)
I mean, I've gotten 3rd grade arithmetic wrong in my own HN comments before! ;)
> There are tons of programming tasks that require coding literacy but do not require even knowing what a linked list is
I think people are assuming that I force the candidate to do this in C or something and munge about with next pointers and sentinel nodes. They're free to do so if they'd like, but usually they have a pretty high degree of control over what language they use and in this problem, what data structure it starts in (including arrays). As mentioned upthread, that means the problem literally reduces to something like loops, iteration, conditionals, collections. These abstractions are fundamental enough that again, any reasonable definition of coding includes them. Physics PhDs writing simulations occasionally have to deal with more than one particle (or whatever), and if they have no clue how to "do X for every Y", they won't get very far.
This isn't just hypothetical for me: I've interviewed PhDs (including non-CS ones), and pretty much all of them blew past this first filter. I've worked with people whose only prior programming experience was during their math PhD, and they generally were pretty great at programming (and pretty horrible at engineering). The latter is easy to teach (this guy became one of my best engineers) but the former is much more fundamental, much harder to teach, and generally something you want at time of hire.
I think people are assuming that I force the candidate to do this in C or something and munge about with next pointers and sentinel nodes. They're free to do so if they'd like, but usually they have a pretty high degree of control over what language they use and in this problem, what data structure it starts in (including arrays). As mentioned upthread, that means the problem literally reduces to something like loops, iteration, conditionals, collections. These abstractions are fundamental enough that again, any reasonable definition of coding includes them. Physics PhDs writing simulations occasionally have to deal with more than one particle (or whatever), and if they have no clue how to "do X for every Y", they won't get very far.
This isn't just hypothetical for me: I've interviewed PhDs (including non-CS ones), and pretty much all of them blew past this first filter. I've worked with people whose only prior programming experience was during their math PhD, and they generally were pretty great at programming (and pretty horrible at engineering). The latter is easy to teach (this guy became one of my best engineers) but the former is much more fundamental, much harder to teach, and generally something you want at time of hire.
They're not necessarily linked lists, could be arrays as well. I can't really imagine any physics PhDs not knowing how to index arrays...
I think you misread the GP; the GP was stating that there are probably physics PhD students who do fine without knowing linked lists. I think you are right that knowing how to index arrays would be a necessary skill for them.
I have just learned how to merge two sorted list because I do believe it is a good thing to know and I appreciate the algorithm. I have no memorized it, just an iterative vs recursive tree traversal.
I hope I can encourage you to think of yourself in a different light. You made a mistake. Grab the code you wrote, write some test data and see what it does. Fix it. It just takes practice -- over and over and over.
Since you say that you will have CS degree "soon", I'll assume you are fairly new to programming. Making mistakes is something that you will do for your whole career. A mistake does not make you one kind of programmer over another. Even many mistakes does not. It just means more practice.
Having the courage to post code off the top of your head in a world-wide forum, means you can have the courage to transcend where you are now. Keep trying to improve -- whatever it takes, and don't unnecessarily limit yourself.
Since you say that you will have CS degree "soon", I'll assume you are fairly new to programming. Making mistakes is something that you will do for your whole career. A mistake does not make you one kind of programmer over another. Even many mistakes does not. It just means more practice.
Having the courage to post code off the top of your head in a world-wide forum, means you can have the courage to transcend where you are now. Keep trying to improve -- whatever it takes, and don't unnecessarily limit yourself.
I interview people. I don't care at all that they make a mistake. I want to get into the candidates train of thought, and see how they react to feedback. If you made a mistake like that it would be excellent for that purpose. You showed comprehension of lists and basic problem solving, so you're already ahead of the midfield.
We ask a couple difficult algorithms questions in our interviews but I also think that is pretty indicative of the day to day work you might have to be doing at positions we hire for.
If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment.
Of course there are other parts of our interview as well, but I've found an initial interview with a difficult algorithms problem does a great job filtering out bad programmers. Once we've filtered out the bad programmers we'll do a second interview that involves code from a project we've used in production before.
If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment.
Of course there are other parts of our interview as well, but I've found an initial interview with a difficult algorithms problem does a great job filtering out bad programmers. Once we've filtered out the bad programmers we'll do a second interview that involves code from a project we've used in production before.
> If someone is offended by being asked to code something like this then they are probably going to be offended by the work they'll have to do once they start employment.
I don't agree with you because it's not the same context. In a day to day job context, you can focus on doing it correctly while in an interview there are a lot of factors that can affect your focus/creativity/attention.
I don't agree with you because it's not the same context. In a day to day job context, you can focus on doing it correctly while in an interview there are a lot of factors that can affect your focus/creativity/attention.
In my experience it is the opposite. At a whiteboard inteview, you can focus on the code and the algorithm.
In the real process, you might on any given day also have to wrangle with your build system, meetings, the structure of existing code, the test setup, colleauges who need help, debugging tools.
Now that might be an argument for why a whiteboard interview is inadequate. But not for why an whiteboard interview is distracting.
In the real process, you might on any given day also have to wrangle with your build system, meetings, the structure of existing code, the test setup, colleauges who need help, debugging tools.
Now that might be an argument for why a whiteboard interview is inadequate. But not for why an whiteboard interview is distracting.
A while ago, I worked with an all male team of about 20 programmers. The odd thing was, though, that there were a lot of women writing code, but not officially as production programmers. They were in high level support positions, mainly working on infrastructure and data, and helping my team work within in their system. This role is now commonly referred to as dev-ops or data analyst, elsewhere, and pays very well. But, because their job title was "L2 support", they were paid less and missed out on a bunch of perks.
I had a friend in "support" who had build a lot of a data normalization system that I often worked with, and we talked about the phenomenon a couple times over lunch. Basically, she was a little offended about the lower pay and the "support" title, but would rather keep her work / life balance and relatively powerful position within the infrastructure stack, than join the production team for a raise. In hindsight, someone should have fought for the whole L2 support department to be better paid; there was certainly money for that (we were in a wildly profitable niche), and the support engineers had the high ground. But we were both young technical types, and didn't have the business / legal skills or the confidence to confront management.
I'm not sure how things have played out there in the years since I left, but if they wanted to, that entire L2 support team could take off and form a devops / analytics consulting firm, and probably multiply their incomes by some small integers. Then they could hire from the product team too, if they needed web/UI ;)
I had a friend in "support" who had build a lot of a data normalization system that I often worked with, and we talked about the phenomenon a couple times over lunch. Basically, she was a little offended about the lower pay and the "support" title, but would rather keep her work / life balance and relatively powerful position within the infrastructure stack, than join the production team for a raise. In hindsight, someone should have fought for the whole L2 support department to be better paid; there was certainly money for that (we were in a wildly profitable niche), and the support engineers had the high ground. But we were both young technical types, and didn't have the business / legal skills or the confidence to confront management.
I'm not sure how things have played out there in the years since I left, but if they wanted to, that entire L2 support team could take off and form a devops / analytics consulting firm, and probably multiply their incomes by some small integers. Then they could hire from the product team too, if they needed web/UI ;)
> Founders can use tools like Culture Amp to do anonymous surveys.
I wouldn't respond to one of those truthfully - I give four or five stars on everything, and never write any complaints in the free-form text fields. If possible, I just avoid doing them - especially if it's a small company, but at larger companies they tend to be per-team, so it works out the same.
I wouldn't respond to one of those truthfully - I give four or five stars on everything, and never write any complaints in the free-form text fields. If possible, I just avoid doing them - especially if it's a small company, but at larger companies they tend to be per-team, so it works out the same.
It's a good idea to have that policy and be careful.
I submitted a comment in a similar office survey service and despite my submission being anonymous, shortly after submitting it, a superior had a meeting with me to address what the anonymous complaint was about, having determined the comment was from me.
In this case I was very glad they figured it out because it ended up being a low risk way of bringing up my concern, but had I not had such a great employer, the result could have been me getting fired or something similar.
The comment was only one short sentence and there were 50-100 people employed at the company, so if you want to be honest on platforms like this, I would limit what you say and obfuscate as much as you can. It doesn't take much to identify you.
I submitted a comment in a similar office survey service and despite my submission being anonymous, shortly after submitting it, a superior had a meeting with me to address what the anonymous complaint was about, having determined the comment was from me.
In this case I was very glad they figured it out because it ended up being a low risk way of bringing up my concern, but had I not had such a great employer, the result could have been me getting fired or something similar.
The comment was only one short sentence and there were 50-100 people employed at the company, so if you want to be honest on platforms like this, I would limit what you say and obfuscate as much as you can. It doesn't take much to identify you.
> ... but had I not had such a great employer ...
> despite my submission being anonymous, shortly after submitting it, a superior had a meeting with me
I'm glad you had a good experience, but a great employer wouldn't have lied to you about the survey being anonymous.
> despite my submission being anonymous, shortly after submitting it, a superior had a meeting with me
I'm glad you had a good experience, but a great employer wouldn't have lied to you about the survey being anonymous.
There's a difference between "This survey is anonymous"/"Hey, Bob ranked his satisfaction with his manager as 1/5", and "This survey is anonymous"/"Here's a list of complaints from your team"/"Oh, this one is a complaint about how X impacts Y - I know Bob's the only one who's expressed interest in that in the past, I bet it's from him".
If my employer told me a survey was anonymous, I would expect anonymity on the Rank/Rate/True-False type questions, but assume that any freeform comments would be identifiable to someone as being from me based on style, content or something else.
If my employer told me a survey was anonymous, I would expect anonymity on the Rank/Rate/True-False type questions, but assume that any freeform comments would be identifiable to someone as being from me based on style, content or something else.
This is correct. I believe the system is anonymous to employers. My employer explicitly said they determined it was me based on context.
It depends on the survey mechanism: If you are only selecting scores from 1-5, aren't saying a word, and the minimum unit of aggregation is 10 people, and it's all handled by a third party, you can be truthful. But any time you enter text, nothing is really anonymous.
There can still be issues of group identification: If a manager gets far worse scores than their peers, nothing guarantees that higher management will actually do something about the manager, vs believing that they just have a team with bad attitudes, and tell the manager to fire the person that they think si the biggest troublemaker, but if that's the case, chances are you wanted to get out of Dodge anyway.
There can still be issues of group identification: If a manager gets far worse scores than their peers, nothing guarantees that higher management will actually do something about the manager, vs believing that they just have a team with bad attitudes, and tell the manager to fire the person that they think si the biggest troublemaker, but if that's the case, chances are you wanted to get out of Dodge anyway.
A former classmate of mine posted on her blog yesterday about some of her tech interview experiences. She didn't generalize about inclusive culture, but her perspective is enlightening.
http://stephaniehurlburt.com/blog/2016/10/5/a-few-stories-of...
http://stephaniehurlburt.com/blog/2016/10/5/a-few-stories-of...
Looks like she really dislikes being asked to code in an interview. She just wants to have a friendly conversation. She will be a great fit for consulting firms that bill by the hour.
For what it's worth, I hate and am doing everything I can to kill the coding interview as typically practiced.
Giving a take-home exercise and having part of the interview be a collaborative review of it? Good idea, works well.
Developing exercises where interviewer and candidate pair on a problem, using real coding tools and looking things up as necessary? Good idea, works well.
"Here's the whiteboard, here's a problem, code it up" -- doesn't usefully distinguish qualified from unqualified candidates, doesn't give you meaningful information about job-relevant skills, serves only to make people squirm and serve as a "yeah, but I had to do it to pass the interview, too, so now you do". Get rid of it forever.
Also, any set of questions designed not to determine someone's programming ability but instead to act as a proxy for something else, like "went to Stanford", goes out the window first chance I get.
Giving a take-home exercise and having part of the interview be a collaborative review of it? Good idea, works well.
Developing exercises where interviewer and candidate pair on a problem, using real coding tools and looking things up as necessary? Good idea, works well.
"Here's the whiteboard, here's a problem, code it up" -- doesn't usefully distinguish qualified from unqualified candidates, doesn't give you meaningful information about job-relevant skills, serves only to make people squirm and serve as a "yeah, but I had to do it to pass the interview, too, so now you do". Get rid of it forever.
Also, any set of questions designed not to determine someone's programming ability but instead to act as a proxy for something else, like "went to Stanford", goes out the window first chance I get.
If you cannot write a basic loop and if statement of maybe 10-20 lines on a whiteboard, you're going to have a hard time in a team of developers trying to collaborate in problem solving.
This is not implementing van Emde Boa search structure, but simple stuff any entry level programmer must comprehend for a general programming posistion.
This is not implementing van Emde Boa search structure, but simple stuff any entry level programmer must comprehend for a general programming posistion.
If you want a coding exercise you can have one.
If you think the only way to have a coding exercise is to pose a whiteboard problem, then my advice is get out of this industry, now.
If you think the only way to have a coding exercise is to pose a whiteboard problem, then my advice is get out of this industry, now.
I give my candidates a choice of a whiteboard or a laptop and projector. Most people choose the whiteboard. Some outright say that they need to look at it at home. The latter will not be able to participate in a meaningful way in a team, and as much as I want to, I don't have work for a loner.
But my point is that, as a team you need to be able to express ideas in a format that other developers can reason with you in a live setting. Nothing beats a whiteboard in that regard. You can use a projector and a computer, but what if you need to draw a graph or something else?
It's not a tall order to ask them to be able to do this. And please don't forget that I'm not asking people to implement RB search trees, but usually a simple loop and an if statement. Reverse a list using a for loop, transform this string into a palindrome, is this string a palindrone, remove all duplicates in a list - stuff like that.
But my point is that, as a team you need to be able to express ideas in a format that other developers can reason with you in a live setting. Nothing beats a whiteboard in that regard. You can use a projector and a computer, but what if you need to draw a graph or something else?
It's not a tall order to ask them to be able to do this. And please don't forget that I'm not asking people to implement RB search trees, but usually a simple loop and an if statement. Reverse a list using a for loop, transform this string into a palindrome, is this string a palindrone, remove all duplicates in a list - stuff like that.
> If you think the only way to have a coding exercise is to pose a whiteboard problem, then my advice is get out of this industry, now.
Asking coders with 10 years of experience to write 10 lines of pseudoish code is wrong!! Try avoiding a coding exercise in interviews for coding positions at all costs. In the worst case make it a take home exercise. This is the only way to save this industry!!! Got it!
Asking coders with 10 years of experience to write 10 lines of pseudoish code is wrong!! Try avoiding a coding exercise in interviews for coding positions at all costs. In the worst case make it a take home exercise. This is the only way to save this industry!!! Got it!
That's a rather quick conclusion. In the blog post she writes that at least once she helped debugging code, so perhaps she just prefers to have some association around a problem, instead of just a bare bones problem to solve. There are many people who are like that, especially the ones who tend to "deep process" problems in their thoughts in order to gain a clear picture of it. They are probably likely to be able to solve complex problems in a domain they're familiar with, but not quite so good at solving problems without any context.
Also there's the self confidence issue, common for many people, even while not a lot of people speak out about it. Ask someone with low self confidence to stand next to a white board and "implement" solutions to random problems, and he/she will freak out. At the same time, these people might very well excel in a more nurturing, friendly environment. Yet at the same time, people who are actually self confident and able to solve problems without much context on a whiteboard, might start running in circles once faced with unfamiliar problems that do not directly map to the algorithms they already know.
I found that just talking about code or problems with someone, can tell you lots of things about the ability of a person. Also, most likely, the candidate will already have some code put online, and god forbid companies are too lazy to look at it, rather than stroking their own ego by asking out of context questions that they already know the answer to.
Also there's the self confidence issue, common for many people, even while not a lot of people speak out about it. Ask someone with low self confidence to stand next to a white board and "implement" solutions to random problems, and he/she will freak out. At the same time, these people might very well excel in a more nurturing, friendly environment. Yet at the same time, people who are actually self confident and able to solve problems without much context on a whiteboard, might start running in circles once faced with unfamiliar problems that do not directly map to the algorithms they already know.
I found that just talking about code or problems with someone, can tell you lots of things about the ability of a person. Also, most likely, the candidate will already have some code put online, and god forbid companies are too lazy to look at it, rather than stroking their own ego by asking out of context questions that they already know the answer to.
"Ask someone with low self confidence to stand next to a white board and "implement" solutions to random problems, and he/she will freak out. At the same time, these people might very well excel in a more nurturing, friendly environment."
I don't think a company interviewing a candidate needs to be holding their hand during the interview process. I understand that someone might perform a lot worse when whiteboarding, but an interviewer should be taking that into account.
I don't think a company interviewing a candidate needs to be holding their hand during the interview process. I understand that someone might perform a lot worse when whiteboarding, but an interviewer should be taking that into account.
Perfect correlation between good interviews and getting an offer does not inspire confidence in how accurate the descriptions are. Times like these you want to hear the other side of the story.
If an excellent candidate doesn't get an offer, it's probable that something went wrong in the interview process. And if there are only three examples of rejections, there's not enough data to talk about unexpected correlations.
> If an excellent candidate doesn't get an offer, it's probable that something went wrong in the interview process
Google sees about half of their employees come from at least a second interview attempt, implying that qualified people fail at least 1/2 the time. Maybe you're claiming that their process is terrible? Or that most companies are significantly better at hiring than them? As the only data point I can find, though, it seems pretty damning.
> And if there are only three examples of rejections
It's unclear to me why only rejections count. 7 for 7 is a lot more concerning than 3 for 3.
FTR, out of the 6 interview processes I've gone through I can think of 2 that don't correlate in this way (one in each direction). So I think I have some basis for suspicion.
Google sees about half of their employees come from at least a second interview attempt, implying that qualified people fail at least 1/2 the time. Maybe you're claiming that their process is terrible? Or that most companies are significantly better at hiring than them? As the only data point I can find, though, it seems pretty damning.
> And if there are only three examples of rejections
It's unclear to me why only rejections count. 7 for 7 is a lot more concerning than 3 for 3.
FTR, out of the 6 interview processes I've gone through I can think of 2 that don't correlate in this way (one in each direction). So I think I have some basis for suspicion.
She shouldn't be feeling bad and wasting time on some of those interviews (unless she's really desperate for a job, which I hope isn't the case anymore). Early rudeness ought to be an instant no-go, things won't get better if there is no obvious reason for that. Interviewers who clearly hate their job would make me wonder what kind of unpleasant tasks are waiting for me. Formal interview detached from actual job and modeled after some Google suggest a company that is prone to CYA and doesn't really know what they want from their people, probably not a great place unless you are feeling extraordinarily helpful and charitable today.
> There’s another side to the equation too, which is being a female interviewer meeting with male candidates... it will subtly or overtly turn into a situation where the candidate is speaking and addressing questions or answers to my coworker. This happens even when I am leading the interview...
I wonder if this goes both ways. If a male was leading the interview, and they were interviewing a female, would the interviewee tend to talk to the female interviewer?
I wonder if this goes both ways. If a male was leading the interview, and they were interviewing a female, would the interviewee tend to talk to the female interviewer?
> would the interviewee tend to talk to the female interviewer?
In my experience, yes, this definitely happens.
In my experience, yes, this definitely happens.
Great work doing this and good luck. Have a couple of ignorant questions:
1). Is it correct that there is no consensus on say, the top three reasons that females are under represented in computer science? It's frustrating that so many lay people voice just opinions and anecdotes. Is the real research starting to agree on what are the most important factors yet?
2) Some people say genetics is one reason females are underrepresented. For example they say, maybe on average females simply tend to be less interested in the subject. Is there any data that actually supports, or excludes this notion?
1). Is it correct that there is no consensus on say, the top three reasons that females are under represented in computer science? It's frustrating that so many lay people voice just opinions and anecdotes. Is the real research starting to agree on what are the most important factors yet?
2) Some people say genetics is one reason females are underrepresented. For example they say, maybe on average females simply tend to be less interested in the subject. Is there any data that actually supports, or excludes this notion?
Nope. There is no consensus. Sociology, psychology and biology are all intertwined as part of the reason so conclusions are heavily based on interpretations (therefore open to bias).
I think the closest ones to the truth are those who explore the early years and how they relate to the careers they will choose.
For example this study[0] on neonatal babies (meaning not yet influenced by culture/society) concluded that males are more interested by mechanics and females ate more interested in faces; reinforcing the idea that females are more social oriented and males more exploration oriented.
By the way, one of the reasons there is no consensus is the controversy that generates reaching any conclusion that is not "it's just that society is sexist"
[0] http://www.sciencedirect.com/science/article/pii/S0163638300...
I think the closest ones to the truth are those who explore the early years and how they relate to the careers they will choose.
For example this study[0] on neonatal babies (meaning not yet influenced by culture/society) concluded that males are more interested by mechanics and females ate more interested in faces; reinforcing the idea that females are more social oriented and males more exploration oriented.
By the way, one of the reasons there is no consensus is the controversy that generates reaching any conclusion that is not "it's just that society is sexist"
[0] http://www.sciencedirect.com/science/article/pii/S0163638300...
There is a nice norwegian documentary about, that we are kind of brainwashed that genders are equal, and that the reason for underrepresentation is nurture, but in the movie they hint at different studies, that it is not solely nurture, these is really a lot in our genes too.
https://www.youtube.com/watch?v=E577jhf25t4 (it has english subs)
Or just check this part https://www.youtube.com/watch?v=E577jhf25t4&feature=youtu.be... if you don't want to watch the whole ~40min documentary
https://www.youtube.com/watch?v=E577jhf25t4 (it has english subs)
Or just check this part https://www.youtube.com/watch?v=E577jhf25t4&feature=youtu.be... if you don't want to watch the whole ~40min documentary
1) No real consensus, but IIRC the percentage of women among new hires in many big companies is about the same as percentage of women graduating from CS, which hints at where the problem definitely isn't (sexism when hiring).
2) I read about some statistics that women are less likely to be engineers in countries with high standards of living(e.g. Sweeden) compared with countries with lower standards of living (e.g. India). If true, given that engineering jobs are paid better, that would imply that once money isn't the main motivator, women either show less interest in engineering, or prioritise other things (e.g. people-facing jobs, or work-life balance).
2) I read about some statistics that women are less likely to be engineers in countries with high standards of living(e.g. Sweeden) compared with countries with lower standards of living (e.g. India). If true, given that engineering jobs are paid better, that would imply that once money isn't the main motivator, women either show less interest in engineering, or prioritise other things (e.g. people-facing jobs, or work-life balance).
For point 2, that's what they said about medicine, law, pretty much any other male-dominated field you can name. Even if there's a difference in interest among adults, why should that difference in interest be due to genetic factors rather than cultural differences in how we raise boys vs girls and how teens are peer pressured?
Edited to add: by the way, back in the 50s and 60s, computer programming was female-dominated.
Edited to add: by the way, back in the 50s and 60s, computer programming was female-dominated.
That's actually not true. There is a graph that's often used to support this point [1]. But using a better graph, we can see that CS is in line with engineering (CS is definitely more "engineering" than it is "science") [2].
[1] https://media.npr.org/assets/img/2014/10/21/womencoding_wide...
[2] https://media.licdn.com/mpr/mpr/p/7/005/06b/02d/33fe648.jpg
[1] https://media.npr.org/assets/img/2014/10/21/womencoding_wide...
[2] https://media.licdn.com/mpr/mpr/p/7/005/06b/02d/33fe648.jpg
Might be representative of the west. Good number of females are seen in Indian companies. But they usually drop off after getting married.
Part of the problem here is that I think we, in tech, have really forgotten how stressful it is to be given a technical exam at a whiteboard, especially with an undercurrent of finding charlatans who "can't even do basic programming!" Many people from other professions and graduate programs describe their oral exams as among the most stressful academic experiences they've been through, because it's unusually embarrassing to fail publicly and people are afraid of "freezing". And that's when there's a pretty clear and well publicized study route, with an ostensibly consistently graded exam, with professors and/or industry practitioners who are experts in their field, with feedback and mechanisms to ensure fairness and integrity.
We get all the stress, but none of the protections, in tech. And we never really get to stop doing it.
I've been through the washing machine enough times that I am pretty resistant to it, though it does still get to me as well. Early career, I did feel pretty humiliated after some of these experiences. Sometimes, I think we lose sight of this. When I described what it was like to "interview" at google and other places, people outside tech kind of shuddered. Their interviews are more like conversations - yes, you need to know what you're talking about, but you don't stand in front of a committee, at a whiteboard, getting treated like a grad student going through quals (if only!) every single time you interview at a new company!
I've heard some questions about whether this is just an inevitable part of being a programmer. If it is, fine, but then please, let's stop scratching our heads about why there's a supposed "shortage" of programmers. If an extremely unpleasant quasi-hazing is a necessary part of applying for a developer job (every single time), then let's not be surprised when people decide they don't want to work in this field anymore, don't want to enter it in the first place, are reluctant to change jobs, or, alternatively, prefer careers in actuarial work, law, medicine, nursing, or other fields where they get to take their exams under conditions that are far more respectful of the candidate and result in a lasting, meaningful credential, respected in their field, so they don't have to do it over and over.
We get all the stress, but none of the protections, in tech. And we never really get to stop doing it.
I've been through the washing machine enough times that I am pretty resistant to it, though it does still get to me as well. Early career, I did feel pretty humiliated after some of these experiences. Sometimes, I think we lose sight of this. When I described what it was like to "interview" at google and other places, people outside tech kind of shuddered. Their interviews are more like conversations - yes, you need to know what you're talking about, but you don't stand in front of a committee, at a whiteboard, getting treated like a grad student going through quals (if only!) every single time you interview at a new company!
I've heard some questions about whether this is just an inevitable part of being a programmer. If it is, fine, but then please, let's stop scratching our heads about why there's a supposed "shortage" of programmers. If an extremely unpleasant quasi-hazing is a necessary part of applying for a developer job (every single time), then let's not be surprised when people decide they don't want to work in this field anymore, don't want to enter it in the first place, are reluctant to change jobs, or, alternatively, prefer careers in actuarial work, law, medicine, nursing, or other fields where they get to take their exams under conditions that are far more respectful of the candidate and result in a lasting, meaningful credential, respected in their field, so they don't have to do it over and over.
Further more, we have legal protections for those with disabilities when taking these certifications that is not accounted for in the tech sector.
http://www.americanbar.org/groups/disabilityrights/resources...
http://ncees.org/exams/special-accommodations/ada-exam-accom...
http://www.usmle.org/test-accommodations/
Are we ok with allowing discrimination like this to continue?
http://www.americanbar.org/groups/disabilityrights/resources...
http://ncees.org/exams/special-accommodations/ada-exam-accom...
http://www.usmle.org/test-accommodations/
Are we ok with allowing discrimination like this to continue?
Interesting observation about the legal protections you mentioned.
While it's just one case, I think this is illustrative of how seriously certification, licensing, and other exams are taken in the rest of the world. Exams can be useful and perhaps even essential, but they aren't trivial. It's a big deal to put someone through this. It is important to have safeguards to ensure fairness, integrity, and consistency.
One of the reasons we don't have this in tech is that companies have no incentive to be transparent about their exams, because they fear lawsuits. They'd much rather reply "we've decided not to pursue your candidacy further at this time" than tell you specifically what you did wrong during their technical exams (they really aren't interviews, they are exams - calling them interviews just confuses people who aren't familiar with what goes on in tech).
The thing is, these exams really are formal affairs. My understanding is that if you applied to google, there is a database entry somewhere with your name, screen captures of what you wrote at the whiteboard, notes on your performance, and a score. However, the person who has been through the tests have more or less no rights to any of this information.
I suppose some people might say "well, that's their business, if you don't like it, don't apply." My response is, yeah, exactly. I believe tech culture turns off a huge number of people - these interview exams are a notable part of this, along with back visibility, open offices, micromanagement, and concerns about career longevity are other. I believe that people with choice, those who aren't obliged to work for a particular employer in a particular field as a condition of living in the US are choosing not to work in tech. There's a constant drum beat about this shortage, from a field that puts candidates through this constantly.
I do think that tests without any protections for the examinee is one of many things tech may need to reconsider to attract people with choice into this field. I see no reason for government to get involved in helping tech get workers without while going about business as usual.
While it's just one case, I think this is illustrative of how seriously certification, licensing, and other exams are taken in the rest of the world. Exams can be useful and perhaps even essential, but they aren't trivial. It's a big deal to put someone through this. It is important to have safeguards to ensure fairness, integrity, and consistency.
One of the reasons we don't have this in tech is that companies have no incentive to be transparent about their exams, because they fear lawsuits. They'd much rather reply "we've decided not to pursue your candidacy further at this time" than tell you specifically what you did wrong during their technical exams (they really aren't interviews, they are exams - calling them interviews just confuses people who aren't familiar with what goes on in tech).
The thing is, these exams really are formal affairs. My understanding is that if you applied to google, there is a database entry somewhere with your name, screen captures of what you wrote at the whiteboard, notes on your performance, and a score. However, the person who has been through the tests have more or less no rights to any of this information.
I suppose some people might say "well, that's their business, if you don't like it, don't apply." My response is, yeah, exactly. I believe tech culture turns off a huge number of people - these interview exams are a notable part of this, along with back visibility, open offices, micromanagement, and concerns about career longevity are other. I believe that people with choice, those who aren't obliged to work for a particular employer in a particular field as a condition of living in the US are choosing not to work in tech. There's a constant drum beat about this shortage, from a field that puts candidates through this constantly.
I do think that tests without any protections for the examinee is one of many things tech may need to reconsider to attract people with choice into this field. I see no reason for government to get involved in helping tech get workers without while going about business as usual.
"It’s important to me that recruiters and interviewers are respectful. Nothing is worse than a condescending interviewer."
What does this have to do with 'female'? This is the norm in high tech for everyone - sadly.
Am I under the impression that this girl thinks that she's being singled out as a girl on this? Because I got it most of the time during my career. Not saying it's right, but I don't think it's a gender issue.
What does this have to do with 'female'? This is the norm in high tech for everyone - sadly.
Am I under the impression that this girl thinks that she's being singled out as a girl on this? Because I got it most of the time during my career. Not saying it's right, but I don't think it's a gender issue.
My understanding is that this article series is not about experiences that are uniquely female. Rather, it's just generally about the experiences of female engineers. Many experiences are likely to be the same as for a male engineer, but not all. I really like this approach, as I think it makes it easier to understand their perspective.
Yes that's exactly it. Glad you like the approach.
Because interviewers are more likely to be condescending to someone they don't respect, and many of them don't respect women.
Yes, this stuff happens to many people, not just women. But it happens to them on an alarmingly regular basis.
Yes, this stuff happens to many people, not just women. But it happens to them on an alarmingly regular basis.
That's the extreme case, but there is also the less malicious one where because of stereotypes and average distributions at a particular company, people just assume women they are speaking to to be less technical than they are and try to 'helpfully' explain things at an unnecessarily basic level. Say, a system's engineer explaining their work to a female college as if she were a front end developer by default, where they would ask a male college what their experience was before making that assumption.
This is an easy mistake to make if you are a kernel hacker in an organization that has, say 20% female developers overall, but where only 2% of kernel hackers are women. Easy to make, not malicious, but not much less annoying because of it, specially if you are the 10th person to assume that. From your point of view, it is a very efficient cache prediction strategy, since you'll get it right 90% of the time[1], but from theirs, it means half their queries end up miss-predicted...
[1] Yes, I am assuming 50% of all developers are kernel hackers, you can switch to something more realistic like product vs infra, front vs backend, etc. Also, the point is not about "lower-level systems programming being real-er programming!", but about making assumptions based partly on gender.
This is an easy mistake to make if you are a kernel hacker in an organization that has, say 20% female developers overall, but where only 2% of kernel hackers are women. Easy to make, not malicious, but not much less annoying because of it, specially if you are the 10th person to assume that. From your point of view, it is a very efficient cache prediction strategy, since you'll get it right 90% of the time[1], but from theirs, it means half their queries end up miss-predicted...
[1] Yes, I am assuming 50% of all developers are kernel hackers, you can switch to something more realistic like product vs infra, front vs backend, etc. Also, the point is not about "lower-level systems programming being real-er programming!", but about making assumptions based partly on gender.
Think about what you just said about assumptions and how that dovetails with lack of respect. GP didn't suggest said lack of respect was necessarily malicious. Just that it exists and is uncomfortable. How does a perception being the result of stereotyping make it any more excusable?
First of all, I agree with the GP and I am emphatically agreeing with you here that such stereotyping is uncomfortable, unneeded and something that urgently needs to go away. But it is still somewhat different from fully dismissing someone as 'less than' because of gender, and the later (appallingly) still happens.
In some circles, you will get people who think along the lines of "yeah, of course there is sexism in industry, I mean, look at Bob, he keeps cracking jokes about women and browses The Red Pill at work. But I am not like Bob, I don't have anything against women, I am trying to help, ergo I can't be sexist". Yet these people can be condescending without generally meaning to disrespect or make less on anyone. When confronted with a woman who is very technical and assertive about that fact, they quickly adjust to treat her as technical, but their default assumption still goes to 'relatively less technical than me' when meeting any new female developer (and doesn't when meeting a male college). I was trying to point out that sort of thing is a problem too.
In some circles, you will get people who think along the lines of "yeah, of course there is sexism in industry, I mean, look at Bob, he keeps cracking jokes about women and browses The Red Pill at work. But I am not like Bob, I don't have anything against women, I am trying to help, ergo I can't be sexist". Yet these people can be condescending without generally meaning to disrespect or make less on anyone. When confronted with a woman who is very technical and assertive about that fact, they quickly adjust to treat her as technical, but their default assumption still goes to 'relatively less technical than me' when meeting any new female developer (and doesn't when meeting a male college). I was trying to point out that sort of thing is a problem too.
Almost 100% of the interviews I've had in tech in business were borderline condescending, and I'm a dude.
I would suggest this has nothing to do with gender, and that wanting 'less condescending interviews' is merely a gripe about the current state of the entire economy. Not only is it not tech specific, it's not even industry or nation specific.
I would suggest this has nothing to do with gender, and that wanting 'less condescending interviews' is merely a gripe about the current state of the entire economy. Not only is it not tech specific, it's not even industry or nation specific.
This is why I taught my daughters the four magic words when it comes to getting paid:
FUCK YOU PAY ME
It's all about an aggressive attitude towards compensation. It's why I make so much and others whom I believe deserve more than me do not. They just aren't aggressive enough. You have to be aggressive by default when it comes to compensation. It's not about the words per se, but the attitude.
FUCK YOU PAY ME
It's all about an aggressive attitude towards compensation. It's why I make so much and others whom I believe deserve more than me do not. They just aren't aggressive enough. You have to be aggressive by default when it comes to compensation. It's not about the words per se, but the attitude.
> For example, I’ve told recruiters about my salary expectations and had them laugh and say “no one gives that kind of [salary/equity/vacation/benefits].” This has happened to me multiple times, most frequently when the company was offering a below-market compensation package.
This happens to men and women. Recruiters suck, it's not a gender bias in most cases, it's that the role attracts a certain kind of person.
A lot of this doesn't need to be viewed through the lens of gender. The fact is our industry has a lot of money in it and that attracts all kinds of jerks/sharks/shady people. Men deal with all of this on a daily basis as well. I'm just starting to think we don't spend as much time organizing as a group and instead just put our heads down and take it/fight through it in isolation.
This happens to men and women. Recruiters suck, it's not a gender bias in most cases, it's that the role attracts a certain kind of person.
A lot of this doesn't need to be viewed through the lens of gender. The fact is our industry has a lot of money in it and that attracts all kinds of jerks/sharks/shady people. Men deal with all of this on a daily basis as well. I'm just starting to think we don't spend as much time organizing as a group and instead just put our heads down and take it/fight through it in isolation.
What bugs me the most is when employers take advantage of this to shift the playing field to the disadvantage of all workers and the "useful idiots"[1] cheer it as progress for a marginalized subset of workers. One example is Reddit's decision some time ago to make their offers non-negotiable. Letting the employer make 100% of the decision as to how surplus is divided between employer and employee is quite obviously a net negative for employees, but it was spun as a positive move by the CEO due to reducing the disparate impact of women being less likely to negotiate.
By contrast, when Google found out that they had a gender skew in promotion rates, they actually looked at the data and realized that the issue was that women employees were promoted at the same rate but put them self up for promotion at lower rates. Instead of taking more control out of every employee's hands, they launched a drive to make managers pay more attention to talented employees and encourage them to self-nominate for promotion. At the time, this closed the promotion-rates gender gap at the relevant levels.
Criticism of gender equity initiatives in tech is often taken as criticism of the goal, but much of the time it's simply a criticism of the cynicism and stupidity involved in the implementation.
[1] Apologies for the inflammatory language on its face but I'm referencing a specific term that's somewhat less insulting. https://en.wikipedia.org/wiki/Useful_idiot
By contrast, when Google found out that they had a gender skew in promotion rates, they actually looked at the data and realized that the issue was that women employees were promoted at the same rate but put them self up for promotion at lower rates. Instead of taking more control out of every employee's hands, they launched a drive to make managers pay more attention to talented employees and encourage them to self-nominate for promotion. At the time, this closed the promotion-rates gender gap at the relevant levels.
Criticism of gender equity initiatives in tech is often taken as criticism of the goal, but much of the time it's simply a criticism of the cynicism and stupidity involved in the implementation.
[1] Apologies for the inflammatory language on its face but I'm referencing a specific term that's somewhat less insulting. https://en.wikipedia.org/wiki/Useful_idiot
> This happens to men and women
> A lot of this doesn't need to be viewed through the lens of gender.
...and so this is one more example of where feminism helps everyone.
> A lot of this doesn't need to be viewed through the lens of gender.
...and so this is one more example of where feminism helps everyone.
Not really, because optimizing for the wrong thing means you can make changes that hurt everybody and mistakenly think you've helped. Take Reddit's move of banning salary negotiations: control over how the surplus of the employment relationship is broken up was taken completely out of the hands of the employee. All employees (including women) are hurt by this, and yet a blinkered model that sees nothing but gender disparity would celebrate this as a narrowing of a gender gap. There are smart ways to address disparate-impact gender gaps, but insisting that feminism is the only lens through which to view a problem is not one of them.
In a salary-negotiation-banned situation, are you also typically prohibited from exchanging salary for vacation, while maintaining the same perceived total compensation?
In my experience distributed company is best if you want diverse team from start. I worked at company where 70% of engineers were women.
The percent of female CS graduates is ~20-30%.
Why are companies with female % that is similar to the female CS graduate % considered sexist but a company that overhires female engineers (to such a degree as to be suspicious of sexism) is seen as diverse?
Why are companies with female % that is similar to the female CS graduate % considered sexist but a company that overhires female engineers (to such a degree as to be suspicious of sexism) is seen as diverse?
It's just as sexist but it's not PC to stand up for the rights of men or white people.
It's really hard to prove discrimination on a small scale, both majority male and majority female companies are probably recruiting from their employees friend network, so it is very possible that neither is discriminating on the basis of sex.
Meaning, they are hiring in proportions which are consistent with their applicant pools, those pools are just different because of friend networks.
People that study these things always take a macroscopic view and talk about sexism/racism in the industry in aggregate and rarely in any specific company.
Meaning, they are hiring in proportions which are consistent with their applicant pools, those pools are just different because of friend networks.
People that study these things always take a macroscopic view and talk about sexism/racism in the industry in aggregate and rarely in any specific company.
it's a feedback loop in society
if you don't know female engineers you might not see yourself doing this. especially if you parent neither see this as a fitting career path
if you don't know female engineers you might not see yourself doing this. especially if you parent neither see this as a fitting career path
>Why are companies with female % that is similar to the female CS graduate % considered sexist but a company that overhires female engineers (to such a degree as to be suspicious of sexism) is seen as diverse?
Nobody said that except you, which betrays your agenda.
Good engineering talent is in short supply and has been for two decades now. It certainly won't do any harm to explore alternate recruiting channels.
Nobody said that except you, which betrays your agenda.
Good engineering talent is in short supply and has been for two decades now. It certainly won't do any harm to explore alternate recruiting channels.
Go on - tell us what is his agenda?
>Good engineering talent is in short supply and has been for two decades now. It certainly won't do any harm to explore alternate recruiting channels.
There is always an opportunity cost. Exploring alternative recruiting channels means not utilizing recruiting channels that have been optimized to find talent regardless of race/gender.
>Nobody said that except you, which betrays your agenda.
Articles that state that software engineering companies are sexist because they don't have a 50/50 gender split are very commonplace.
My agenda is not being discriminated based on my race or gender fyi.
There is always an opportunity cost. Exploring alternative recruiting channels means not utilizing recruiting channels that have been optimized to find talent regardless of race/gender.
>Nobody said that except you, which betrays your agenda.
Articles that state that software engineering companies are sexist because they don't have a 50/50 gender split are very commonplace.
My agenda is not being discriminated based on my race or gender fyi.
I'm with ergo, you should explain your assumptions.
I don't think companies are considered sexist based on the ratio of men/women. They're considered sexist when they _act_ sexist and don't work very hard to cultivate a good environment.
It is. Companies like Google are frequently hounded to find out 'what they are doing about their gender crisis' even though their numbers reflect graduation ratios.
I think there are a lot of groups that have an obligation to change things, but that doesn't necessarily mean they're bad either. Google is big enough to actually affect the up stream numbers, I'm glad they're working at it.
> considered
By whom?
By whom?
> The percent of female CS graduates is ~20-30%.
In the US?
If you're hiring from the whole planet, that's not the valid measure.
In the US?
If you're hiring from the whole planet, that's not the valid measure.
> hiring from the whole planet
this is difficult for a variety of reasons.
this is difficult for a variety of reasons.
So what if 70% of applicants are not women. Do you turn down better men just do meet a woman quota? That seems the wrong way to get diversity.
If a great man comes along hire him. If a great woman comes along hire her.
If you have a quota of X you are going to hire less qualified people, thus creating a culture of quotas and not performance.
If a great man comes along hire him. If a great woman comes along hire her.
If you have a quota of X you are going to hire less qualified people, thus creating a culture of quotas and not performance.
Quotas aren't necessarily the best ideas, but if 90% of your applicants are men, and men and women have the same pass rates, what you have to work on is resume sourcing. This is especially true in companies that mostly hire referrals: You are mostly hiring people that are like the people you have, so you'll lose diversity on average.
You also have to look at differences in the middle of the pipeline. Imagine you only give a phone screen to 5% of female applicants, but 10% of male applicants. You have to think very hard about why that happens. Maybe your ways of rating resumes have a built in bias.
For instance, imagine that I only interviewed new grads that had at least two internships in large tech companies. A rubric like that looks neutral, but you'll discover that the demographics of CS graduates vs those that have those two internships are very different (far fewer women, and a lot more people that will identify themselves as asian).
You also have to look at differences in the middle of the pipeline. Imagine you only give a phone screen to 5% of female applicants, but 10% of male applicants. You have to think very hard about why that happens. Maybe your ways of rating resumes have a built in bias.
For instance, imagine that I only interviewed new grads that had at least two internships in large tech companies. A rubric like that looks neutral, but you'll discover that the demographics of CS graduates vs those that have those two internships are very different (far fewer women, and a lot more people that will identify themselves as asian).
> Quotas aren't necessarily the best ideas, but if 90% of your applicants are men, and men and women have the same pass rates, what you have to work on is resume sourcing.
I agree with your approach, but the gender is not the only diversity metric. If you push this toward ethnicity, religion, sexual orientation, introversion, geekness level, you might end up in a difficult situation and your company will look like Noah's ark. Instead, what I would do is to specify the tasks that needs to be carried out and define metric to measure it, then do a blind hiring. Attributes like graduation or work experience is irrelevant if the candidate passed the test. During the probationary period, if the team doesn't like the new members or the other way round, you can let them go.
I agree with your approach, but the gender is not the only diversity metric. If you push this toward ethnicity, religion, sexual orientation, introversion, geekness level, you might end up in a difficult situation and your company will look like Noah's ark. Instead, what I would do is to specify the tasks that needs to be carried out and define metric to measure it, then do a blind hiring. Attributes like graduation or work experience is irrelevant if the candidate passed the test. During the probationary period, if the team doesn't like the new members or the other way round, you can let them go.
If you try to increase diversity by implementing a quota system you are doing it wrong.
The right way is to look for qualified candidates from multiple backgrounds. For example, plenty of companies recruit from MIT but how many recruit from Spelman College?
The right way is to look for qualified candidates from multiple backgrounds. For example, plenty of companies recruit from MIT but how many recruit from Spelman College?
> If a great man comes along hire him. If a great woman comes along hire him.
Lol.. oops.
Lol.. oops.
:(
Sorry man, your post has now been sucked into the toxic pit of horrible people both male and female. Also known as twitter. I tried to set the record straight, but alas I have less followers. You are now a horrible person and your typo is forever enshrined.
https://twitter.com/laggdotme/status/784502966728269824
https://twitter.com/laggdotme/status/784502966728269824
Curious to know what company that is - I've never witnessed more than a small ratio.
In terms of the interview itself – I hate pop-quiz-style rapid-fire questions. Things like “What is the time complexity of bubble sort? What is hopscotch hashing? What’s the CAP theorem?” And on and on for fifteen minutes and twenty-odd questions.
But how else is the interviewer going to prove how smart they are, and signal their dominant status to you?
But how else is the interviewer going to prove how smart they are, and signal their dominant status to you?
Pop quiz style is much better than asking a single question and then diving deep into it.
The most important part is that the candidate can say "pass" and that you don't force them to squeeze out a shitty answer.
There is simply no better way to find out the breadth of someone's knowledge than to quiz them over a broad range of things. Think about it: this is exactly what engineers do with each other naturally and in a fun way over time.
"Hey, do you know about X?"
Compare this with Google's idiotic idea of asking a single question and judging the candidate on that randomly selected question.
No one who knows their stuff will fail to answer a long list of pop quiz questions well...but anyone of any skill level might not know the answer to any particular question.
The most important part is that the candidate can say "pass" and that you don't force them to squeeze out a shitty answer.
There is simply no better way to find out the breadth of someone's knowledge than to quiz them over a broad range of things. Think about it: this is exactly what engineers do with each other naturally and in a fun way over time.
"Hey, do you know about X?"
Compare this with Google's idiotic idea of asking a single question and judging the candidate on that randomly selected question.
No one who knows their stuff will fail to answer a long list of pop quiz questions well...but anyone of any skill level might not know the answer to any particular question.
I am not sure I agree with this focus. As someone who does not exactly do single-question technical interviews but more like two- or three-question ones, my goal is somewhere in the vicinity of measuring the software engineering version of IQ. Granted, free form technical interviews are well known to be bad at this, but all the other ways seem worse.
Bloom's taxonomy[1] is useful here I think. Assessment ideally shouldn't stall at 'understand' or 'remember'. I do agree it is important to know about a large variety of things. The more specialized the job is, the more important it is for a candidate to do a decent subset of it on day 1. But sometimes you can explore a candidate's knowledge through 'apply' (use X to do Y) or 'analyze' and 'evaluate' (do Y), such as in a system design question, to see the structure of their thought process rather than something more scattershot.
Finally, regarding skipping a question, sometimes you can sense that a candidate's knowledge is limited in some area, which is a good time to just move on and try to go deep on something else. Not everyone has been afforded the same opportunities and has the same amount of experience. Software is a job where the potential to grow can do you better than a fixed skill set, especially if you see hiring as similar to making an investment.
[1] https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/
Bloom's taxonomy[1] is useful here I think. Assessment ideally shouldn't stall at 'understand' or 'remember'. I do agree it is important to know about a large variety of things. The more specialized the job is, the more important it is for a candidate to do a decent subset of it on day 1. But sometimes you can explore a candidate's knowledge through 'apply' (use X to do Y) or 'analyze' and 'evaluate' (do Y), such as in a system design question, to see the structure of their thought process rather than something more scattershot.
Finally, regarding skipping a question, sometimes you can sense that a candidate's knowledge is limited in some area, which is a good time to just move on and try to go deep on something else. Not everyone has been afforded the same opportunities and has the same amount of experience. Software is a job where the potential to grow can do you better than a fixed skill set, especially if you see hiring as similar to making an investment.
[1] https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/
I'm pretty sure Google has multiple interviews with multiple questions.
The best revenge for that is to ace the technical questions, and then ask painfully, acutely relevant questions about the company's financials, their development process, their technical debt, and their competition.
Please note that I have never been called back after doing that.
A genuine technical interview can and will be cut short immediately once it becomes clear that you are not bullshitting on your resume. The person who still asks that 20th question after you have already answered the previous 19 correctly is just being an ass, and playing stupid, time-wasting games with your interview.
Please note that I have never been called back after doing that.
A genuine technical interview can and will be cut short immediately once it becomes clear that you are not bullshitting on your resume. The person who still asks that 20th question after you have already answered the previous 19 correctly is just being an ass, and playing stupid, time-wasting games with your interview.
Heh. I did that once (with financials, I do learn what I can before going in). It was astounding how uptight and offended the interviewer got. Pretty sure he was an outlier, but it was very satisfying. I ended it by telling him I wasn't interested, and the reaction was even more satisfying.
That's the only time I've been that intentionally rude. He really deserved it, though. And (consistent with my other comment in this thread) I'd name them, but (a) they went out of business a long time ago, and (b) I can't quite remember the name of the firm. Something "clever" ca. 2004, missing a vowel.
That's the only time I've been that intentionally rude. He really deserved it, though. And (consistent with my other comment in this thread) I'd name them, but (a) they went out of business a long time ago, and (b) I can't quite remember the name of the firm. Something "clever" ca. 2004, missing a vowel.
> then ask painfully, acutely relevant questions about the company's financials, their development process, their technical debt, and their competition.
Is it rude to do that in an interview? How am I supposed to decide if I want to work for a company without some insight into those things?
Is it rude to do that in an interview? How am I supposed to decide if I want to work for a company without some insight into those things?
If those are rude questions then I don't want to work there - not in this economy. We need to be picky who we work for so that company culture is favorable for employees. If we start working for whoever just cuts a paycheck then we become just another cog in the machine.
You can ask any question in a politer way and in a ruder way. Compare.
A: What does your competition look like in this space?
B: What's your plan for overcoming Company Y's huge lead in market share?
A: Tell me about your development process.
B: So what percentage of your process overhead is cargo cult edicts from upper management?
A: How much runway do you have? How long before profitability?
B: When the current owners look for their exit, how screwed will I be?
A: How do you deal with technical debt?
B: Show me the worst code in your repo.Exactly. If you're interviewing for a startup and you don't know what funding round they're on or how much runway they have, you're setting yourself up to get screwed.
Or is a junior engineer "just following orders." This is quite common practice, actually.
The end result is the same, if there is another option available: run
If the company focus on trivia that much on interviews and let juniors run the show expect no good senior working in there. That's never going to end well.
If the company focus on trivia that much on interviews and let juniors run the show expect no good senior working in there. That's never going to end well.
My response to such questions is usually along the lines 'Sorry, didn't realize I was interviewing for my ability to perform 5-second google searches.'
If 'getting the job' in that instance is the metric of success, then it doesn't work well at all, but in quality-of-life terms it's served me well.
If 'getting the job' in that instance is the metric of success, then it doesn't work well at all, but in quality-of-life terms it's served me well.
Being passive aggressive in an interview will never get you the job. Huge red flag on the hiring side. If you don'the like the interview style enough to not want the job, just politely leave.
It's pretty clear that the commenter's intent was not to turn the interview around and get hired, with that remark.
Why be rude to the interviewer even if that is the case? What does such juvenile rudeness accomplish?
Is it genuinely offensive to be asked the complexity of bubble sort? If such a question causes you so much offense that you lash out involuntarily, then you have some serious personal problems to work out.
Is it genuinely offensive to be asked the complexity of bubble sort? If such a question causes you so much offense that you lash out involuntarily, then you have some serious personal problems to work out.
Is it genuinely offensive to be asked the complexity of bubble sort?
Offensive, no. Just trite and tedious.
And more fundamentally, simply not indicative of the high quality, (genuinely) cerebral environment the interview subject, back in the original article, is looking for.
Why be rude to the interviewer even if that is the case?
I get that it's generally better to be polite. But when the same kinds of tedious and disspiriting (and sometimes downright condescending, and/or simply time-wasting) behaviors come down the interviewing pipe, over and over again... I can understand the temptation to bypass decorum, and allow a gut-level, emotional response to surface.
Being as while we might generally prefer to keep things professional -- we're not potted plants, either.
Offensive, no. Just trite and tedious.
And more fundamentally, simply not indicative of the high quality, (genuinely) cerebral environment the interview subject, back in the original article, is looking for.
Why be rude to the interviewer even if that is the case?
I get that it's generally better to be polite. But when the same kinds of tedious and disspiriting (and sometimes downright condescending, and/or simply time-wasting) behaviors come down the interviewing pipe, over and over again... I can understand the temptation to bypass decorum, and allow a gut-level, emotional response to surface.
Being as while we might generally prefer to keep things professional -- we're not potted plants, either.
Literally two seconds on Github will prove out that, yes, I can write code. That means we should be talking about something substantiative rather than wasting my time. So turn it around: why should I respect an interviewer who isn't respecting me?
(I should note that, as a consultant, nobody ever asks me to whiteboard some code for them, despite often committing into their own repos and doing work that is no less important to them as a company. Almost like the hoop jumping is just some power-move crap on the part of the interviewer.)
(I should note that, as a consultant, nobody ever asks me to whiteboard some code for them, despite often committing into their own repos and doing work that is no less important to them as a company. Almost like the hoop jumping is just some power-move crap on the part of the interviewer.)
I've given interviewers a piece of my mind before. Frankly, most interviewing practices, even at places which allegedly are highly selective, boil down to 100% cargo-culting, and when I encounter that I have no issue with telling the interviewer that and hanging up or walking out. At that point in the interview I'm not there to validate their approach or make sure they feel good; I'm there to communicate to them what I know, and what I know -- from experience -- is how useless most of the common interview processes are.
>What does such juvenile rudeness accomplish?
If a few more people were genuinely afraid of being humiliated for blindly cargo culting google's hiring practices it might go out of fashion quicker.
At least, that's my hope. Which is why I usually tease people for doing this (yes, that upsets them).
If a few more people were genuinely afraid of being humiliated for blindly cargo culting google's hiring practices it might go out of fashion quicker.
At least, that's my hope. Which is why I usually tease people for doing this (yes, that upsets them).
>humiliated
I think you need to pause, take a step back, and consider who is actually making an ass out of themselves in that situation.
I think you need to pause, take a step back, and consider who is actually making an ass out of themselves in that situation.
Put it this way: stupid people on a power trip can say some stupid things when they're angry at having their authority challenged. I've relayed those things word for word on to the non-technical boss when they subsequently come into the room to ask 'team fit' questions.
It's more effective when you're over-the-top polite when you set the trap with leading questions though.
Trolling gives me a bit of mild amusement in what is otherwise a dud investment of my time. The only people who seem to have a problem with that are people who have an exaggerated respect for authority figures (always unhealthy).
If, on the other hand, the interview process is obviously relevant to the job at hand and thorough I go out of my way to compliment the interviewer to their boss even if I know I failed.
It's more effective when you're over-the-top polite when you set the trap with leading questions though.
Trolling gives me a bit of mild amusement in what is otherwise a dud investment of my time. The only people who seem to have a problem with that are people who have an exaggerated respect for authority figures (always unhealthy).
If, on the other hand, the interview process is obviously relevant to the job at hand and thorough I go out of my way to compliment the interviewer to their boss even if I know I failed.
If you're being passive aggressive, you've already signaled that you don't want it but you are taking the opportunity to point out to the interviewer how small-minded they are to make them reflect on the fact that they wasted their time as well as yours.
Politely leaving without saying anything doesn't improve the situation for anyone. These pop-quiz questions need to be stopped.
Politely leaving without saying anything doesn't improve the situation for anyone. These pop-quiz questions need to be stopped.
If you're happy to allow fellow humans to continue along a poor path, sure. I believe in establishing feedback loops and giving people opportunities to grow.
Tongue-in-cheek aside, of course passive-aggressive isn't the ideal path to improving interview processes. :P
Tongue-in-cheek aside, of course passive-aggressive isn't the ideal path to improving interview processes. :P
I think you are missing the point.
If you do not know such things then how are you going to take them into account when you have to solve a problem?
If you do not know such things then how are you going to take them into account when you have to solve a problem?
When have you ever needed to know the exact complexity function for bubble sort (beyond the simple fact that it's in a class well above that of any algorithm you'd typically want to use) in order to solve a real, actual work-related problem? Right there, on the spot?
That's the point of the "hate" behind these questions.
That's the point of the "hate" behind these questions.
OK, I'll bite.
Point one, it checks if you understand the most primitive sorting algorithm out there. Pretty low bar assessment of your general CS knowledge.
Point two, it checks whether the candidate has understanding of computational complexity.
Now you might argue that you don't need any of that in the day job, but that's on you. If the interviewer wants to check you have fairly basic minimum of understanding of very basic CS concepts, that's a suitable question to ask.
Point one, it checks if you understand the most primitive sorting algorithm out there. Pretty low bar assessment of your general CS knowledge.
Point two, it checks whether the candidate has understanding of computational complexity.
Now you might argue that you don't need any of that in the day job, but that's on you. If the interviewer wants to check you have fairly basic minimum of understanding of very basic CS concepts, that's a suitable question to ask.
Do you see any problem with the idea that:
"Has memorized the complexity class for one particular, indisputably marginal sorting algorithm"
is equivalent to
"Has an understanding of computational complexity"?
Now you might argue that you don't need any [understanding of complexity] in the day job
That is quite clearly not what what said.
"Has memorized the complexity class for one particular, indisputably marginal sorting algorithm"
is equivalent to
"Has an understanding of computational complexity"?
Now you might argue that you don't need any [understanding of complexity] in the day job
That is quite clearly not what what said.
In theory there is a difference, in practice - none. People would at least know what that is (and hence have no problem gauging bubblesort complexity), or you'd have blank stare back.
Just wonder what would you suggest as an alternative, if you need to confirm basic algorithms proficiency and understanding of big-O? You inevitably arrive to an algorithm question, and bubblesort is as good as any.
Just wonder what would you suggest as an alternative, if you need to confirm basic algorithms proficiency and understanding of big-O? You inevitably arrive to an algorithm question, and bubblesort is as good as any.
Or you'd have blank stare back.
Actually the blank stare means "What is this, sophomore year again? I can't believe anyone still cares about bubble sort."
Just wonder what would you suggest as an alternative?
Look at their GitHub/Mercurial account (which you've been ignoring all this time in your desperate search for something to nail them on, but if you would spend a second or two looking, you'd find is chuck full of algorithm stuff -- much of it way more intricate than bubble sort). And ask as many questions as you like based on some project you find there.
Or, pick a problem you're working on that's algorithm-related (but which you genuinely don't fully know how to solve). Use that as discussion material. What approach they'd suggest, given that the data are sparse / not evenly distributed, whatever.
You know, as if they were a peer. Not an interrogation subject.
Actually the blank stare means "What is this, sophomore year again? I can't believe anyone still cares about bubble sort."
Just wonder what would you suggest as an alternative?
Look at their GitHub/Mercurial account (which you've been ignoring all this time in your desperate search for something to nail them on, but if you would spend a second or two looking, you'd find is chuck full of algorithm stuff -- much of it way more intricate than bubble sort). And ask as many questions as you like based on some project you find there.
Or, pick a problem you're working on that's algorithm-related (but which you genuinely don't fully know how to solve). Use that as discussion material. What approach they'd suggest, given that the data are sparse / not evenly distributed, whatever.
You know, as if they were a peer. Not an interrogation subject.
The majority of my peers don't have a GitHub account, most of them quite competent programmers. Do you suggest to discriminate applicants based on their public activity? Do you suggest it's somehow more fair than a general question?
I like how you cast me into some mean soulless generalized interviewer and started bashing down your pain points, while I actually don't interview people. But a simple algorithm question is not out of line on a programming interview; it's not whiteboarding or take home assignments. It doesn't take much time to answer, it shows you have some very basic CS knowledge at least. I did not use bubblesort outside of CS101 class some 25 years ago and had to actually think about its runtime complexity, but it was not hard and it did not take long.
Again if you think basic CS knowledge has nothing to do with your job that's on you. Should add that I'm not really comfortable being grilled in any way on the interviews, it's not a very good dynamic. But I don't see any general, dignified way to filter out non-performers. Unfortunately just credentials are not enough in our trade.
I like how you cast me into some mean soulless generalized interviewer and started bashing down your pain points, while I actually don't interview people. But a simple algorithm question is not out of line on a programming interview; it's not whiteboarding or take home assignments. It doesn't take much time to answer, it shows you have some very basic CS knowledge at least. I did not use bubblesort outside of CS101 class some 25 years ago and had to actually think about its runtime complexity, but it was not hard and it did not take long.
Again if you think basic CS knowledge has nothing to do with your job that's on you. Should add that I'm not really comfortable being grilled in any way on the interviews, it's not a very good dynamic. But I don't see any general, dignified way to filter out non-performers. Unfortunately just credentials are not enough in our trade.
Do you suggest to discriminate applicants based on their public activity? Do you suggest it's somehow more fair than a general question?
Actually, yes. But that's just a matter of personal taste.
Again if you think basic CS knowledge has nothing to do with your job that's on you.
Hmm -- you keep coming back to this supposition, for some reason. And again, that's not at all what I was saying.
Should add that I'm not really comfortable being grilled in any way on the interviews, it's not a very good dynamic.
At least we're on the same basic page, then. The main difference I guess is that (1) I see the issue of maintaining "dynamic" -- the overall tone of bilateral respect, in the interview process -- as not just important, but very important, arguably crucial in fact; (2) dynamic aside, the "quiz-show" approach is rife with methodological weaknesses (for example, it highly favors those who cram on the material - or were simply lucky, and happened to have heard your questions before in there interview process); and (3) I find it quite easy to assess ballpark competence in tech folks (and to find red flags for incompetence) just from unprompted, regular discussion.
But again, that's me, not you. You can apply whatever filters you like. Like Steve Jobs said (in a different, but related context) ultimately either they'll work or they won't -- and everything will sort itself out.
Actually, yes. But that's just a matter of personal taste.
Again if you think basic CS knowledge has nothing to do with your job that's on you.
Hmm -- you keep coming back to this supposition, for some reason. And again, that's not at all what I was saying.
Should add that I'm not really comfortable being grilled in any way on the interviews, it's not a very good dynamic.
At least we're on the same basic page, then. The main difference I guess is that (1) I see the issue of maintaining "dynamic" -- the overall tone of bilateral respect, in the interview process -- as not just important, but very important, arguably crucial in fact; (2) dynamic aside, the "quiz-show" approach is rife with methodological weaknesses (for example, it highly favors those who cram on the material - or were simply lucky, and happened to have heard your questions before in there interview process); and (3) I find it quite easy to assess ballpark competence in tech folks (and to find red flags for incompetence) just from unprompted, regular discussion.
But again, that's me, not you. You can apply whatever filters you like. Like Steve Jobs said (in a different, but related context) ultimately either they'll work or they won't -- and everything will sort itself out.
I've had at least one point in my career where bubble sort was the right tool for the job.
If I have to do a very careful performance decision on something as well trodden as a sorting algorithm, I'll walk to the bookshelves, pick up The Art of Programming, Volume 3, and let Knuth handle it for me.
As a software engineer, there are things I do all the time: Reading unfamiliar code and third party documentation, do some debugging (often based on logs), and try to write code that is well factored and thoroughly tested. I want to know whether any prospective teammate is good at those things for their experience level.
Interestingly enough, the general algorithm questions are easier the newer you are, and the less you know about all the topics I mentioned, because more often than not those are learned on the jobs, while the basic algorithms are learned in college. I end up reading papers on algorithms at work, but they are not algorithms that I expect to be general knowledge, and that I'd expect people to read on the job when they are applicable: How many candidates are going to be able to explain hyper log log, Paxos or Lamport clocks on command? Is knowing all of those three by heart a sensible pass/no pass signal? I for one don't think so.
As a software engineer, there are things I do all the time: Reading unfamiliar code and third party documentation, do some debugging (often based on logs), and try to write code that is well factored and thoroughly tested. I want to know whether any prospective teammate is good at those things for their experience level.
Interestingly enough, the general algorithm questions are easier the newer you are, and the less you know about all the topics I mentioned, because more often than not those are learned on the jobs, while the basic algorithms are learned in college. I end up reading papers on algorithms at work, but they are not algorithms that I expect to be general knowledge, and that I'd expect people to read on the job when they are applicable: How many candidates are going to be able to explain hyper log log, Paxos or Lamport clocks on command? Is knowing all of those three by heart a sensible pass/no pass signal? I for one don't think so.
But that's the whole point -- it's a corner case.
And hence, kind of silly to use as material to grill people on.
And hence, kind of silly to use as material to grill people on.
I do not think that these questions probe some corner cases. Rather these probe the general knowledge about the field.
Bubble sort question probes the understanding about the complexity theory, hopscotch hashing about concurrent algorithms and CAP theorem about problems with distributed databases.
Naturally when these questions are not open for discussion and instead only a short answer is expected then there is in my opinion something wrong with the interviewer or with the company.
You have to understand that the other side knowns in fact nothing about you and I find these questions to be quite fair to improve the situation.
Bubble sort question probes the understanding about the complexity theory, hopscotch hashing about concurrent algorithms and CAP theorem about problems with distributed databases.
Naturally when these questions are not open for discussion and instead only a short answer is expected then there is in my opinion something wrong with the interviewer or with the company.
You have to understand that the other side knowns in fact nothing about you and I find these questions to be quite fair to improve the situation.
Bubble sort question probes the understanding about the complexity theory,
It's just that, again, you're picking a very marginal example to do that with.
And more fundamentally -- simply asking someone "What's the complexity of $foo"? doesn't tell you anything about whether they "understand" complexity. It only tells you whether they've adequately memorized that particular cell on their crib sheet.
As they are thoroughly incentivized to do, thanks to people employing interview techniques like these.
It's just that, again, you're picking a very marginal example to do that with.
And more fundamentally -- simply asking someone "What's the complexity of $foo"? doesn't tell you anything about whether they "understand" complexity. It only tells you whether they've adequately memorized that particular cell on their crib sheet.
As they are thoroughly incentivized to do, thanks to people employing interview techniques like these.
I definitely agree with you that shallow quizzes are not very informative and are alone not a good methodology for job interviews.
Naturally this question in isolation is not very informative and it is hard to differentiate if the answer to it comes from a more general understanding or is just memorized. It has to be supported with other questions and wider discussion.
What I want to say is that in a larger context this question is still not unfounded and it is hard for me to consider this or any other listed questions as a signalling a dominant status.
Naturally this question in isolation is not very informative and it is hard to differentiate if the answer to it comes from a more general understanding or is just memorized. It has to be supported with other questions and wider discussion.
What I want to say is that in a larger context this question is still not unfounded and it is hard for me to consider this or any other listed questions as a signalling a dominant status.
If you do not know the complexity class of the bubble sort then you probably do not a have formal CS education. It also follows that it is possible that when you see a similar bad solution then you are not able to recognize it as such.
I think that these three questions showed are quite good and fair (for example I did not what is Hopscotch hashing, but it looks quite important after looking it up, so thanks for this).
Some of such questions might be possibly indifferent for the position you were applying, but seeing some hate behind these questions is in my opinion quite unjustified.
I think that these three questions showed are quite good and fair (for example I did not what is Hopscotch hashing, but it looks quite important after looking it up, so thanks for this).
Some of such questions might be possibly indifferent for the position you were applying, but seeing some hate behind these questions is in my opinion quite unjustified.
> If you do not know the complexity class of the bubble sort then you probably do not a have formal CS education. It also follows that it is possible that when you see a similar bad solution then you are not able to recognize it as such.
This is absolutely absurd. I have a CS degree from Berkeley (universally considered one of the best CS programs in the world), and I spent the last few years on an unusually CS-focused team within Google (specifically, artificial intelligence). Off the top of my head, I could easily imagine not remembering what exactly bubble sort is. What's the use of retaining the details of an algorithm that's literally held up as the "don't do this" solution to sorting? The most I can imagine being useful is knowing the theoretical best case average complexity of a sort. And my job is wayyy more CS-focused than the average engineering job at Google (let alone elsewhere). You heavily overestimate how useful rote memorization is to real-world productivity.
Whether a candidate _understands_ these concepts, on the other hand, can actually be illuminating. If you described bubble sort to someone and asked him to describe the complexity, then you're getting all the signals you're describing about CS understanding and education. (though there's controversy about the usefulness of these skills as well)
This is absolutely absurd. I have a CS degree from Berkeley (universally considered one of the best CS programs in the world), and I spent the last few years on an unusually CS-focused team within Google (specifically, artificial intelligence). Off the top of my head, I could easily imagine not remembering what exactly bubble sort is. What's the use of retaining the details of an algorithm that's literally held up as the "don't do this" solution to sorting? The most I can imagine being useful is knowing the theoretical best case average complexity of a sort. And my job is wayyy more CS-focused than the average engineering job at Google (let alone elsewhere). You heavily overestimate how useful rote memorization is to real-world productivity.
Whether a candidate _understands_ these concepts, on the other hand, can actually be illuminating. If you described bubble sort to someone and asked him to describe the complexity, then you're getting all the signals you're describing about CS understanding and education. (though there's controversy about the usefulness of these skills as well)
You're not going to get anywhere arguing with people who believe these are useful questions.
Though to be honest, Google uses those kinds of questions and apparently treats them as useful, so I'm not sure why you'd have wanted to work there.
Though to be honest, Google uses those kinds of questions and apparently treats them as useful, so I'm not sure why you'd have wanted to work there.
I've been on both sides of the interview process at Google over the last half decade (I no longer work there) and I can tell you that asking people to recite random facts by rote was not part of their interview guidelines for as long as I was there. This includes a couple dozen interviews I conducted and the candidate notes of the other interviewers.
I got hit with a barrage of random trivia during one of the phone screens I did last year.
Eventually got fed up with their process, told the interviewer what I thought of it and hung up.
(which, to point out at least one upside, is the only way I've ever discovered of getting a company I don't want to work for to stop bugging me with recruiter spam)
Eventually got fed up with their process, told the interviewer what I thought of it and hung up.
(which, to point out at least one upside, is the only way I've ever discovered of getting a company I don't want to work for to stop bugging me with recruiter spam)
I agree with you. But I think that you actually prove that this is not that absurd question at all because you actually described exactly the content of this question and why it is asked about (at least in my opinion).
Naturally if there is no option for the discussion when somebody does not know the answer off the top of their head then this would be really absurd and pointless situation.
This question is not good for selecting out somebody for their specific knowledge, but it is in my option a good one to prune out candidates that manage to demonstrate their general ignorance about the field.
Naturally if there is no option for the discussion when somebody does not know the answer off the top of their head then this would be really absurd and pointless situation.
This question is not good for selecting out somebody for their specific knowledge, but it is in my option a good one to prune out candidates that manage to demonstrate their general ignorance about the field.
> Naturally if there is no option for the discussion when somebody does not know the answer off the top of their head then this would be really absurd and pointless situation.
Ah ok, I guess I misunderstood you. Though this "absurd and pointless situation" does in fact happen: There definitely is a class of interviewer who will expect off-the-top-of-your-head detailed knowledge (like being able to remember bubble sort's details from just its name).
Ah ok, I guess I misunderstood you. Though this "absurd and pointless situation" does in fact happen: There definitely is a class of interviewer who will expect off-the-top-of-your-head detailed knowledge (like being able to remember bubble sort's details from just its name).
If you do not know the complexity class of the bubble sort then you probably do not a have formal CS education.
No, it means you're smart and have learned to sift out unimportant matters of detail ("Was bubble sort, which I only ever had to think about for a week or two the first half of my sophomore algorithms class, and was only ever brought up as a negative example anyway, O(n^2) or O(n^3)?") in order to focus on much more interesting and useful stuff.
No, it means you're smart and have learned to sift out unimportant matters of detail ("Was bubble sort, which I only ever had to think about for a week or two the first half of my sophomore algorithms class, and was only ever brought up as a negative example anyway, O(n^2) or O(n^3)?") in order to focus on much more interesting and useful stuff.
Pretty much spot on and that was my point. You can answer to this question, you know what is complexity class, you know that it is a negative example and it is rather bad.
See, I am not a recruiter or interviewer, but this question feels to me like an useful one to prune out ignorant fools who start to lament how unfair is to ask such questions instead of giving more or less correct answer.
Naturally if short direct answer is the only accepted answer and there is no way to discuss these things with the interviewer then I would also walk away.
See, I am not a recruiter or interviewer, but this question feels to me like an useful one to prune out ignorant fools who start to lament how unfair is to ask such questions instead of giving more or less correct answer.
Naturally if short direct answer is the only accepted answer and there is no way to discuss these things with the interviewer then I would also walk away.
> If you do not know the complexity class of the bubble sort
not knowing or remembering doesn't preclude one from understanding that one approach or technique can be more (or less) costly than another.
not knowing or remembering doesn't preclude one from understanding that one approach or technique can be more (or less) costly than another.
These facts can be easily googled.
Yes, if you take them as just mere facts. But if you are not aware of CAP theorem and its implications then how do you know that you should google it?
I haven't received a formal education in CS, and I know about CAP and what it means.
Reading the Aphyr "Jepsen" series is what helped me learn it... when I was still in high school. And this was necessary because I was curious about which database I needed to use for a particular side project I was writing.
It's totally possible to just Google "bubble sort complexity" or "CAP" and learn about it.
Reading the Aphyr "Jepsen" series is what helped me learn it... when I was still in high school. And this was necessary because I was curious about which database I needed to use for a particular side project I was writing.
It's totally possible to just Google "bubble sort complexity" or "CAP" and learn about it.
Just to assure that my point was well understood.
Yes, you can today easily find quite a lot of information and learn about it, but this was not the situation the original poster lamented about.
The claim was that when faced with such question, one can just google it and read the answer. Problem solved. Because these are just some random facts like who is the president of France.
My point was that in my opinion these questions actually probe the general understanding about the CS field.
Yes, you can today easily find quite a lot of information and learn about it, but this was not the situation the original poster lamented about.
The claim was that when faced with such question, one can just google it and read the answer. Problem solved. Because these are just some random facts like who is the president of France.
My point was that in my opinion these questions actually probe the general understanding about the CS field.
You act as though CS knowledge is some high priesthood of supreme mathematical reasoning insulated from the internet.
As a matter of practical use, most of the time details about algorithms and data structures, from implementation through complexity analysis, can easily be regarded as "mere facts." Those times when this doesn't apply are times when somebody applying formal academic level CS is surely required, but these are far less frequent than most programming tasks require--even at Google.
As a matter of practical use, most of the time details about algorithms and data structures, from implementation through complexity analysis, can easily be regarded as "mere facts." Those times when this doesn't apply are times when somebody applying formal academic level CS is surely required, but these are far less frequent than most programming tasks require--even at Google.
No, this was not my intention. Sure people do not know all the facts and all the implementation details and corner cases of some specific algorithm, but I would expect them to have some basic knowledge.
This is like knowing that lookup complexity of the hash table is usually O(1) (but could become O(n)) and one should use it instead of list when frequent lookups are necessary.
I am not an interviewer, but I think that the questions listed were actually quite good pruning questions and if you do not know them, well, there are the search engines and you can look them up for the next time instead of starting lamenting about the unfairness and showing the ignorance that is in in this case in my opinion demonstrating the serious negligence.
This is like knowing that lookup complexity of the hash table is usually O(1) (but could become O(n)) and one should use it instead of list when frequent lookups are necessary.
I am not an interviewer, but I think that the questions listed were actually quite good pruning questions and if you do not know them, well, there are the search engines and you can look them up for the next time instead of starting lamenting about the unfairness and showing the ignorance that is in in this case in my opinion demonstrating the serious negligence.
if someone is unaware of CAP, they're unlikely to have been working in an environment where it was relevant. if this same person starts working in an environment where it's relevant, i'd wager that it will be hard to remain unaware.
I have a CS degree. I learned about the CAP theorem, and I work with the nature of it daily. But my mind have ventured beyond the CAP theorem, it's implications are now mere facts of distributed systems, and the name "CAP theorem" had simply sliped out of my mind. If you want to quiz knowledge, rather than google-fu and name dropping, ask if you can make a distributed system with consistency and availability.
I think this indeed would be a better approach.
Instead of asking about Bubble sort, ask what is generally the complexity of a naive sorting algorithm and how good it can get for a general case.
I have investigated immutable hash tables but I do not know much about concurrent hash tables. This is my blind spot, so I do not know what the relevant question about the Hopscotch hashing would be.
Instead of asking what is CAP theorem, ask if you can make a distributed system with consistency and availability at the same time.
I think that this was the intention behind these questions after all and is the reason why I am trying to argue in support of them.
Instead of asking about Bubble sort, ask what is generally the complexity of a naive sorting algorithm and how good it can get for a general case.
I have investigated immutable hash tables but I do not know much about concurrent hash tables. This is my blind spot, so I do not know what the relevant question about the Hopscotch hashing would be.
Instead of asking what is CAP theorem, ask if you can make a distributed system with consistency and availability at the same time.
I think that this was the intention behind these questions after all and is the reason why I am trying to argue in support of them.
There's a middleground between those extremes. There's lots of knowledge that isn't relevant most of the time, but when it is relevant its worth its weight in gold. (And often these things aren't so obvious that people will google search them.)
When I'm trying to evaluate a candidate, I want people who proactively search out knowledge in that middle zone. People who understand complexity theory, and CPU caching behaviour, and the C10k/C10M problem just because they know they might need it some day. Because they want to work on problems where this stuff is relevant.
This sort of knowledge is the difference between hearing "our website is slow - I think its the database?" and "our website is slow - I took a look and our database server has run out of open file handles. But I'm still confused - that shouldn't explain the latency we're seeing."
The CAP theorem is a great example of this sort of middleground might-be-useful knowledge. Understanding how your database will behave in the face of network partitions is exactly the sort of thing that separates good engineers from great ones.
When I'm trying to evaluate a candidate, I want people who proactively search out knowledge in that middle zone. People who understand complexity theory, and CPU caching behaviour, and the C10k/C10M problem just because they know they might need it some day. Because they want to work on problems where this stuff is relevant.
This sort of knowledge is the difference between hearing "our website is slow - I think its the database?" and "our website is slow - I took a look and our database server has run out of open file handles. But I'm still confused - that shouldn't explain the latency we're seeing."
The CAP theorem is a great example of this sort of middleground might-be-useful knowledge. Understanding how your database will behave in the face of network partitions is exactly the sort of thing that separates good engineers from great ones.
I have a CS degree, I focused quite a bit on distributed systems. I also deal with it day to day. But if you asked me what the CAP theorem is, I'd have to look it up. Same for bubble sort. If we first establish how it works I can figure out the complexity, but why memorize stuff I can look up on wikipedia if I need it?
"CAP theorem" is a pretentious name for the idea that in the event of network partition you have to give up availability or consistency. Or both ;)
And yes, I too keep forgetting this name but I could talk about the issue if they explained what real problem they have.
As for bubble sort, I'd just write
And insertion sort actually is better. It can be made to work online, keeping all elements seen so far sorted before receiving the next element. And I think it ought to be more cache friendly than bubble sort.
And yes, I too keep forgetting this name but I could talk about the issue if they explained what real problem they have.
As for bubble sort, I'd just write
for (i=1; i<n; i++)
for (j=i; j>0; j--)
if (X[j-1] > X[j])
swap(j-1,j);
And insertion sort actually is better. It can be made to work online, keeping all elements seen so far sorted before receiving the next element. And I think it ought to be more cache friendly than bubble sort.
> But how else is the interviewer going to prove how smart they are, and signal their dominant status to you?
1. This isn't the sole and probably not even the dominant reason for such questions.
2. When people resort to such intimidation you can out-alpha them by threatening to leave as if they were not worth your time (has to be convincing, ofc). Intimidation is a specialty of the insecure so this trick can work, though you may want to consider whether such job is going to be fun.
1. This isn't the sole and probably not even the dominant reason for such questions.
2. When people resort to such intimidation you can out-alpha them by threatening to leave as if they were not worth your time (has to be convincing, ofc). Intimidation is a specialty of the insecure so this trick can work, though you may want to consider whether such job is going to be fun.
Do doctors also feel hurt when they are being asked questions on "how would you handle the patients with such and such symptoms" and expected to give a textbook answer?
That analogy would make more sense if software engineering required as many time-sensitive split second decisions as doctoring does.
Doctors go through years of schooling involving a substantial amount of memorization as well as board exams, residencies and so on before they're allowed to do much doctoring at all. This is the case because it is crucial that they not forget in an exam that neck pain combined with a headache could be a sign of meningitis, etc.
If an engineer needs to know which sorting algorithm is best, taking some time to research and google it is not going to cause a problem. That's why questions like this are bad, even offensive--they make people feel as though they're bad engineers when actually they're being put through an ineffective interviewing process.
Doctors go through years of schooling involving a substantial amount of memorization as well as board exams, residencies and so on before they're allowed to do much doctoring at all. This is the case because it is crucial that they not forget in an exam that neck pain combined with a headache could be a sign of meningitis, etc.
If an engineer needs to know which sorting algorithm is best, taking some time to research and google it is not going to cause a problem. That's why questions like this are bad, even offensive--they make people feel as though they're bad engineers when actually they're being put through an ineffective interviewing process.
> it is crucial that they not forget in an exam that neck pain combined with a headache could be a sign of meningitis, etc.
Why is it crucial if it's just a "5 second google search"? And not every doctor is dealing with serious life threatening illnesses, just like not all developers are working on bootstrapping their uber for cats with Angular 2 and pouchdb.
Why is it crucial if it's just a "5 second google search"? And not every doctor is dealing with serious life threatening illnesses, just like not all developers are working on bootstrapping their uber for cats with Angular 2 and pouchdb.
> Why is it crucial if it's just a "5 second google search"?
Because you can't google every single symptom. And sometimes the symptom is only mentioned very briefly in passing. And sometimes the patient is hiding the symptom. And sometimes the important piece of information isn't a "symptom".
So, you need to have these in your head so that you can connect the dots to "I thought it was X, but new data Y suggests it might be Z. I need to go push on abdomen, put stethoscope to stomach, right now while patient is sitting in my office." A good example of a non-symptom that would go into your diagnosis--patient just got divorced and started dating again ... hmmm, STD's are probably back in the probability pool again, might want to check for one given the other symptoms.
Where computers are useful, but, sadly, we don't have good implementation is spotting localized trends. If one person comes down with Karposi's Sarcoma, that's an anomaly. If 10 people come down with it, that's a problem. It would be good to have databases with data from multiple doctors so that we could let the computers spot those things.
Because you can't google every single symptom. And sometimes the symptom is only mentioned very briefly in passing. And sometimes the patient is hiding the symptom. And sometimes the important piece of information isn't a "symptom".
So, you need to have these in your head so that you can connect the dots to "I thought it was X, but new data Y suggests it might be Z. I need to go push on abdomen, put stethoscope to stomach, right now while patient is sitting in my office." A good example of a non-symptom that would go into your diagnosis--patient just got divorced and started dating again ... hmmm, STD's are probably back in the probability pool again, might want to check for one given the other symptoms.
Where computers are useful, but, sadly, we don't have good implementation is spotting localized trends. If one person comes down with Karposi's Sarcoma, that's an anomaly. If 10 people come down with it, that's a problem. It would be good to have databases with data from multiple doctors so that we could let the computers spot those things.
I mean, my doctor usually just types my symptoms into Google anyway...
It's crucial because people can die. That is not something you can say with someone's code being written this exact second. There is always time to research, test, experiment, and change.
> It's crucial because people can die
Not every illness is lethal, for most of them you can just make it worse. Even less requires quick decision. Also, software evolves and scales much quicker than humans which makes our industry less standardised.
> That is not something you can say with someone's code being written this exact second. There is always time to research, test, experiment, and change.
In my world, there is a risk assessment which defines if we have time to research, test, etc. or just fix it on the go, because it is not a big deal if it occurs. In other cases we have a cold sweat and dead silence during deployment, don't we?
Not every illness is lethal, for most of them you can just make it worse. Even less requires quick decision. Also, software evolves and scales much quicker than humans which makes our industry less standardised.
> That is not something you can say with someone's code being written this exact second. There is always time to research, test, experiment, and change.
In my world, there is a risk assessment which defines if we have time to research, test, etc. or just fix it on the go, because it is not a big deal if it occurs. In other cases we have a cold sweat and dead silence during deployment, don't we?
The idea of a doctor who is unsure giving an answer instead of taking time to research is scary. Maybe that's why misdiagnosis is so common:
http://www.ncpa.org/sub/dpd/index.php?Article_ID=23148
http://www.ncpa.org/sub/dpd/index.php?Article_ID=23148
"Despite these statistics, many doctors are reluctant to report diagnostic errors, even anonymously, despite the likelihood of moderate to severe harm on the patient"
Not sure why doctors don't look after their patients. Is it because there is no incentive to? If they do bad diagnosis that means the patient comes back and the doctor gets more money. As long as they don't get sued there's really no harm to the doctor.
As a software engineers we are incentivized to perform well. A crappy system means time spent debugging issues, money lost for our employer. We also take pride in building good systems so we can take that experience to the next company and get s higher wage or position.
Not sure why doctors don't look after their patients. Is it because there is no incentive to? If they do bad diagnosis that means the patient comes back and the doctor gets more money. As long as they don't get sued there's really no harm to the doctor.
As a software engineers we are incentivized to perform well. A crappy system means time spent debugging issues, money lost for our employer. We also take pride in building good systems so we can take that experience to the next company and get s higher wage or position.
And yet, in spite of their extensive training, computers are better at diagnosing.
As far as I'm aware, computers are better at diagnosing a very small and very specific subset of diagnoses. If I'm wrong about this and there's a computer out there who can diagnose patients with better or equal accuracy than the average physician, please link me to the study proving so immediately, because I desperately want this in my life, and so do ninety percent of my colleagues. (There's a stubborn subset who wouldn't trust a computer if Asclepius himself descended from the heaven to sing its praises. The rest of us have ten times more work than time and would gladly welcome the help.)
As it is, we can't even seem to find a program that can analyse an ECG better than an overtired and exhausted resident at 4 am, which is really quite a low bar to cross.
As it is, we can't even seem to find a program that can analyse an ECG better than an overtired and exhausted resident at 4 am, which is really quite a low bar to cross.
Yeah, I'd like it, too. But the only one of which I'm aware is IBM's Watson, and that's still wildly impractical.
Computers are better at diagnosing when the problem is very specific or low/counter-probability.
So, let's take heart attack diagnoses in emergency rooms--a fixed procedure laid down by following statistics is WAY better than human judgement.
Generalized abdominal pain--computers aren't so good. There are a lot of possibilities and most of them are about equal. The doctor is more likely to tease out the problem over time through conversational randomness.
Some obscure genetic disease--a computer is going to be FEROCIOUSLY better than a human. A computer can keep all of those .00001% options in mind as tests and diagnoses rule out the far more common problems until the low-probability things pop up into statistical relevance.
So, let's take heart attack diagnoses in emergency rooms--a fixed procedure laid down by following statistics is WAY better than human judgement.
Generalized abdominal pain--computers aren't so good. There are a lot of possibilities and most of them are about equal. The doctor is more likely to tease out the problem over time through conversational randomness.
Some obscure genetic disease--a computer is going to be FEROCIOUSLY better than a human. A computer can keep all of those .00001% options in mind as tests and diagnoses rule out the far more common problems until the low-probability things pop up into statistical relevance.
You think software for those computers that are better at diagnosing was created by engineers who don't know the difference between a stable and unstable sorting algorithm?
There is a massive delta between knowing that, and being able to code examples of each from memory on a whiteboard during an interview.
Also, it may surprise you, but there are many highly experienced and extremely capable programmers that didn't study computer science in college. Filtering those people out because they can't answer programming trivia questions is, at best, hugely short-sighted.
Also, it may surprise you, but there are many highly experienced and extremely capable programmers that didn't study computer science in college. Filtering those people out because they can't answer programming trivia questions is, at best, hugely short-sighted.
If you're writing diagnosis software, your approach to sorting should be "use sort()". Sorting is not your core competency, diagnosis is.
Actually, yes. It's very likely that the core algorithms for these systems were written by "crossover" types (e.g. math PhDs) who are perfectly capable of getting up to speed with the esoteric aspects of these systems, without having to go back and master the standard undergraduate CS curriculum.
It's called being flexible and able to learn, and it's the single most important thing you're supposed to get out of your formal education.
It's called being flexible and able to learn, and it's the single most important thing you're supposed to get out of your formal education.
I have discovered over and over that most genuinely good things are created by one smart person. After that person creates it, then the masses can run with it.
Bittorrent is a great example. All the pieces had existed for a while, but Bram Cohen put them all together into one place. After that, lots of people created other BitTorrent clients. However, without that first, smart person, it wouldn't have appeared.
Bittorrent is a great example. All the pieces had existed for a while, but Bram Cohen put them all together into one place. After that, lots of people created other BitTorrent clients. However, without that first, smart person, it wouldn't have appeared.
Only in certain, highly procedural use cases. But in the large, no.
In my experience (which is from asking friends who are medical doctors), their medical ability is not examined during the interview. There are no questions of this nature.
Who said anything about... feeling "hurt"?
I think that user Stratoscope has noticed something more interesting: https://news.ycombinator.com/item?id=12661902
He finds that such trivia quizzes are strongly biased towards supporting younger candidates who are fresh out of college.
He finds that such trivia quizzes are strongly biased towards supporting younger candidates who are fresh out of college.
The word is "hate", so it seems to be a personal taste. So the question does not naturally follow.
Why are you so cynical about this? Don't attribute to malice what is explainable by ignorance.
Yeah, it's often difficult to find the line between asking someone basic questions to confirm they have the skills/knowledge/experience they claim to have and just firing random academic/esoteric questions at them that would be easily googleable. I'm not sure the questions matter as much as the interpretations of the answers (or lack therof). If you say you have experience with a framework I'll ask enough specific questions to know whether or not you've worked with it. I don't care if you miss questions that you may not have come across. And of course as the interviewee it's important to recognize that you shouldn't be expected to know every nook and cranny of every detail unless you claim to know it.
It's muddied somewhat by the sarcasm, but malice isn't necessarily implied nor salient in the OP's point.
What room is there for ignorance in figuring out how to conduct a technical interview?
Are you joking? Interviewing involves many skills. Technical interviewing moreso
Right. So why would we be forgiving of people being ignorant about it?
I mean, yes, it's certainly possible to be ignorant about it, lots of people are. But unless you somehow want to hire people who are completely uncorrelated with being good employees, the distinction between unwittingly and wittingly being a terrible interviewer seems a bit thin.
I mean, yes, it's certainly possible to be ignorant about it, lots of people are. But unless you somehow want to hire people who are completely uncorrelated with being good employees, the distinction between unwittingly and wittingly being a terrible interviewer seems a bit thin.
I never implied we should be tolerant of ignorance. "It isn't necessarily malice" is what I basically said. That's not the same as "It's ignorance and that's great."
And the distinction isn't thin. It's the difference between an easily solvable problem and a really hard to solve problem.
And the distinction isn't thin. It's the difference between an easily solvable problem and a really hard to solve problem.
This is why I love working at companies with open books. All of our salaries are posted on our intranet, along with every other expense the company has. It only works when the company is entirely self-funded, though, so it takes a little hunting to find them. (We also have 100% open meetings except for HR issues, which I've come to love too -- it's cool to be able to see what sales or R&D are up to).
She mentions to make an effort towards diversity at the end.
As a latino, diversity for diversity sake never made sense to me. What am I a lego piece or something? Meritocracy.
As a latino, diversity for diversity sake never made sense to me. What am I a lego piece or something? Meritocracy.
Diversity of experiences and opinions are good, in my opinion, because they allow problems to be approached in ways that I wouldn't otherwise have considered, if it was a singular mono-culture.
I don't think "diverse" experiences and opinions (at least the ones related to race and gender) matter as a software engineer. Race/gender does not affect the experiences and opinions that do matter.
The ones that do matter are related to topics like specific technology backgrounds (PhD in distributed systems vs. machine learning), functional vs. OOP, Java vs. C++, etc.
It might matter to a small degree in product management, although technically every little detail can matter.
Race/gender are also poor boundaries to segment for diverse experiences and opinions. Upper middle class, liberal black people benefit the most from affirmative action. They aren't much different from upper middle class white people.
Software engineering is already diverse by the most divisive measure: by country of origin which completely eclipses differences between races and genders.
The ones that do matter are related to topics like specific technology backgrounds (PhD in distributed systems vs. machine learning), functional vs. OOP, Java vs. C++, etc.
It might matter to a small degree in product management, although technically every little detail can matter.
Race/gender are also poor boundaries to segment for diverse experiences and opinions. Upper middle class, liberal black people benefit the most from affirmative action. They aren't much different from upper middle class white people.
Software engineering is already diverse by the most divisive measure: by country of origin which completely eclipses differences between races and genders.
> Race/gender does not affect the experiences and opinions that do matter.
How about things like (the admittedly heavily-used) example of Apple's health app lacking a period tracker?
How about things like (the admittedly heavily-used) example of Apple's health app lacking a period tracker?
That's a project management issue, not a software engineering one
Sure, but project management teams presumably also have a diversity problem, and engineers can certainly be a part of feature creation / selection.
> Software engineering is already diverse by the most divisive measure: by country of origin which completely eclipses differences between races and genders.
That would suggest that there is no need for gender diversity in international politics, and that a group of men, each representing their own country, provides all the necessary diversity needed.
> That's a project management issue, not a software engineering one
Software engineers should be involved in project design. Coder monkeys can get away with "I code what I'm told without providing any further input to anything else".
That would suggest that there is no need for gender diversity in international politics, and that a group of men, each representing their own country, provides all the necessary diversity needed.
> That's a project management issue, not a software engineering one
Software engineers should be involved in project design. Coder monkeys can get away with "I code what I'm told without providing any further input to anything else".
Specialization for the most part yields higher efficiency. Engineers have not been trained gauge audience needs. It is as inefficient for an engineer to be involved in product design as it would be for the PM to be involved in the actual coding.
>Coder monkeys can get away with "I code what I'm told without providing any further input to anything else".
Being a coder monkey has nothing to do with influence in product development. You can have no influence on the product being created, and still have complete autonomy over the technology used to create the product. You contribute feedback on the technology side: implementing this feature will take X time and result in Y cost in run time.
The product is generic. Two completely different projects with the same X, Y, Z constraints end up with almost identical engineering solutions.
>Coder monkeys can get away with "I code what I'm told without providing any further input to anything else".
Being a coder monkey has nothing to do with influence in product development. You can have no influence on the product being created, and still have complete autonomy over the technology used to create the product. You contribute feedback on the technology side: implementing this feature will take X time and result in Y cost in run time.
The product is generic. Two completely different projects with the same X, Y, Z constraints end up with almost identical engineering solutions.
The notion that all white men form a monoculture is just as racist and sexist as the notion that only white men are suited for engineering
But diversity in tech usually revolves around skin color, gender, and sexual orientation.
Always found this odd when class is the biggest workplace demarcation in the US.
Which is a very, very good proxy for diversity of experience and opinion.
Ask Brendon Eich, Douglas Crockford, Palmer Luckey, and Curtis Yarvin.
It might be, but political affiliation, religion, and age would be equally good proxies. But these aspects rarely if at all get addressed.
No it isn't. In fact, almost all of the "diverse" teams I see are a monoculture of opinion. They are all people who buy the standard SJW nonsense fully and hate anyone who doesn't. They actively try to stamp out diversity of opinion.
I can't wait to work in environment where we can have conflicts over these things instead of focusing on actual work.
A white man from Alaska and a white man from Rio de Jainero will have much more diverse experiences than a man and a woman from San Francisco.
Even if you're not into diversity for it's own sake, there's still the situation where someone who merits it less gets a job over someone who merits it more, due to their ethnicity.
Same here, it's not like you're re-populating the planet where diversity is important.
It tickles me that they have an Ada and a Grace representing women.
The names are pseudonyms
What's the hidden message behind being late to an interview?
The article implies it suggests that the late employees are inconsiderate or can't "execute."
Implement bubble sort? That's a terrible question.
[deleted]
anon839(1)
Some recruiters are seriously sketchy. Someone I know joined a company where the recruiter told her that they give all their employees at that level this same salary so there's no room for negotiation unfortunately. After she joined, she asked what other people were making, and found out that even a new grad had higher compensation than she did despite the fact she had several years of experience already.
Apparently, they tried to do the same thing to that other employee, but that other employee had another offer and just said that he would take the other offer, to which the recruiter apparently responded, "Oh wait, I'm sorry actually I think we can do something about that. I was looking at the wrong sheet."