Ask a Female Engineer: Interviewing and Company Culture - <AUTHOR> http://themacro.com/articles/2016/10/ask-a-female-engineer-3/ <comment><USER2> > 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]."

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."

<comment><USER3> > 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.

<comment><USER4> 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.

<comment><USER5> 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.

<comment><USER6> Tend to be less savvy?

<comment><USER7> The data hints that they negotiate less, yes.

<comment><USER8> 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.

<comment><USER5> 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.

<comment><USER8> I like your suggestion of "disadvantaged" — it covers both the information asymmetry and the real or perceived differences in negotiating strength.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> 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.

<comment><USER10> 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?

<comment><USER11> > 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.

<comment><USER12> I disagree. Some sexual undertones have to do with ethnicity because of stereotypes of Asian women etc.

<comment><USER11> Not sure what such stereotypes you're talking about, but regardless where does your example not have to do with gender?

</comment></comment></comment></comment></comment><comment><USER13> > "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.

<comment><USER14> > 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.

<comment><USER13> > " 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.

<comment><USER14> 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.

<comment><USER15> 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.

<comment><USER14> > 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](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.

<comment><USER15> > 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.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> 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 ;)

</comment><comment><USER17> > 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.

<comment><USER18> 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.

<comment><USER19> > ... 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.

<comment><USER20> 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.

<comment><USER18> This is correct. I believe the system is anonymous to employers. My employer explicitly said they determined it was me based on context.

</comment></comment></comment></comment></comment><comment><USER21> 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-tech- interviews)

<comment><USER22> 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.

<comment><USER23> 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.

<comment><USER24> 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.

<comment><USER23> 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.

<comment><USER24> 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.

</comment></comment></comment></comment></comment></comment><comment><USER25> > 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?

<comment><USER26> > would the interviewee tend to talk to the female interviewer?

In my experience, yes, this definitely happens.

</comment></comment><comment><USER27> 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?

<comment><USER28> 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.

<comment><USER29> 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...](https://media.npr.org/assets/img/2014/10/21/womencoding_wide-4b0beb106fe1b4cfabd9799accb65e8ef8097473.jpg?s=1400)

[2] [https://media.licdn.com/mpr/mpr/p/7/005/06b/02d/33fe648.jpg](https://media.licdn.com/mpr/mpr/p/7/005/06b/02d/33fe648.jpg)

</comment></comment></comment><comment><USER30> 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.

<comment><USER31> 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://www.americanbar.org/groups/disabilityrights/resources/biad.html)

[http://ncees.org/exams/special-accommodations/ada-exam- accom...](http://ncees.org/exams/special-accommodations/ada-exam- accommodations/)

[http://www.usmle.org/test-accommodations/](http://www.usmle.org/test- accommodations/)

Are we ok with allowing discrimination like this to continue?

<comment><USER30> 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.

</comment></comment></comment><comment><USER32> "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.

<comment><USER33> 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.

<comment><USER34> 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.

<comment><USER28> 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?

<comment><USER34> 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.

</comment></comment></comment></comment></comment><comment><USER6> 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.

</comment><comment><USER35> > 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.

<comment><USER36> > 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.

<comment><USER14> 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.

<comment><USER17> In a salary-negotiation-banned situation, are you also typically prohibited from exchanging salary for vacation, while maintaining the same perceived total compensation?

</comment></comment></comment></comment><comment><USER37> In my experience distributed company is best if you want diverse team from start. I worked at company where 70% of engineers were women.

<comment><USER38> 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?

<comment><USER39> >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.

<comment><USER40> Go on - tell us what is his agenda?

</comment></comment></comment></comment><comment><USER41> _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?

<comment><USER42> 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?

<comment><USER43> And yet, in spite of their extensive training, computers are better at diagnosing.

<comment><USER42> 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?

<comment><USER44> 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.

</comment></comment></comment></comment></comment><comment><USER45> 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).

</comment><comment><USER46> 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.

<comment><USER47> 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.

<comment> atom-morgan But diversity in tech usually revolves around skin color, gender, and sexual orientation.

<comment><USER48> Which is a very, very good proxy for diversity of experience and opinion.

<comment> atom-morgan Ask Brendon Eich, Douglas Crockford, Palmer Luckey, and Curtis Yarvin.

</comment></comment></comment></comment></comment><comment><USER49> It tickles me that they have an Ada and a Grace representing women.

<comment><USER50> The names are pseudonyms

</comment></comment><comment><USER51> What's the hidden message behind being late to an interview?

<comment><USER52> The article implies it suggests that the late employees are inconsiderate or can't "execute."

</comment></comment><comment><USER53> Implement bubble sort? That's a terrible question.</comment>


Only A British Couple Could Go On Honeymoon And Build Their Start-Up - <AUTHOR> http://www.forbes.com/sites/ewanspence/2012/09/03/only-a-british-couple-could-go-on-honeymoon-and-build-their-start-up/ <comment><USER2> That's nothing: Sir Humphry Davy went on his honeymoon and took Michael Faraday along with him: <http://blog.jgc.org/2008/09/ultimate-nerd- honeymoon.html></comment>


Solving Instagram's Unshredder with Mechanical Turk and $0.50 - <AUTHOR> http://code.recollect.com/post/13372390010/mechanical-turk-unshredder <comment><USER2> The next step: turn it into a game and get it done for free. Even better, put a skinnerian ux around it and _charge_ for the pleasure of solving picture puzzles ;)

</comment><comment><USER3> Another possible way to do this is present the Turker with two vertical pieces already placed together. Ask them a yes/no question: do these two images match?

Iterate intelligently over your favorite sorting algorithm until you've placed all the images!

Note: requires more Turkers but each answer could be worth much less, maybe around $0.01

<comment><USER4> Slightly offtopic, but I am the author of the Rails/Mechanical Turk integration gem, Turkee ( <http://www.github.com/aantix/turkee> ).

The lower the cost of the HIT (and the easier the question) the more you want to make sure you're screening for bots.

Make sure you have a gold standard question. For every HIT ask two questions; ask the legitimate question that you need answered and then on top of that, ask a simple "gold-standard" question that will determine whether the answer submitted is a bot or not.

For the gold standard, I like to choose two numbers, and store the sum of their values. Along with your HIT question, be sure to ask the Turker the value of their sum.

E.g. For a survey you ask the Turker "What is your favorite color?" But then along with that, you ask them "What is four plus fve?"

Be sure to misspell one value (e.g. remove a letter, etc). If the Turker doesn't respond correctly to the "gold standard" question, programmatically reject their response.

<comment><USER5> Not sure if this matters for a "gold standard" question, but google answers it correctly:

<http://www.google.com/search?q=What+is+four+plus+fve%3F>

</comment></comment></comment><comment><USER6> Am I the only person who doesn't see this as Instagram's unshredding project as much as a DARPA one?

[http://www.popsci.com/technology/article/2011-10/darpa- wants...](http://www.popsci.com/technology/article/2011-10/darpa-wants-puzzle- solvers-reconstruct-shredded-documents)

</comment><comment><USER7> This is a really neat hack but How does the script know whether or not the solution was correct? Have they shared a real solution that solves this problem completley algorithmically, without human involvement? I could not find it.

</comment><comment><USER8> This is probably the first time I've ever cares about "crowdsourcing" or his ugly brother-in-law, "cloudsourcing". However, I can't help but imagine why they want a solution for this. Seems like Cold Wat-era spook stuff.

<comment><USER9> Would any of this help with producing a panorama? That's all I could think of.

<comment><USER10> Probably not, as then you have to play around with blending two images and (un?)distorting them to match each other's shape. _That's_ the hard part - people tend to take pictures in order rather than randomly.

</comment></comment></comment><comment><USER11> I can imagine it now, this is the first step in human evolutionary divergence between the Eloi (programmers) and the Morlocks (Mechanical Turkers).

<comment><USER12> That was strikingly similar to a comment I read just recently...

<comment><USER11> If you're trying to imply that I "stole" the comment, I posted it in the article comments _after_ posting it here (note the usernames). Figured it might spark some discussion for people not coming from HN.

<comment><USER12> I know that, I saw that it was you. I also don't have a problem with it, it just caused me to do a double take and go check the site to see if my deja vu was real. I thought I would mention that because I doubt I was the only one who had that experience.

</comment></comment></comment></comment><comment><USER13> The jQuery sorter thingy is incredibly buggy / slow. I would have been done in 1/3rd of the time if it wasn't!

</comment><comment><USER14> If more turk tasks were like this one, I'd probably consider putting some free time into it. That was actually sort of fun.

</comment><comment><USER15> This is just brilliantly simple and effective. The fact that you created a fully functional prototype is just gravy.

</comment><comment><USER16> OT: For some reason the Recollect bar that slides in from the top when I scroll down the page is _very_ distracting. It seems to violate the expectation that, when scrolling downward, page content should only be moving upward. It also feels like it's robbing me of readable screen area. I suspect I'd be much less bothered by a _position: fixed_ header that was always present.

</comment><comment><USER17> This is a very cool way to use the Amazon Mechanical Turk!

I am 99% sure that the image (at least the one that I saw) on the page is of Tokyo's Shibuya station. And the tall white and black building on the right 1/3 of the picture? That's the Cross Tower building, housing Amazon's Tokyo office.

This photo had to have been taken from one of the upper floors of the Cerulean Tower hotel.

</comment><comment><USER18> Very clever sir! I've used the Mechanical Turk for a couple of interesting tasks, lowering prices to $0.01 and having Turkers complete those tasks in less than 2 minutes which is pretty awesome! It's very interesting how we've started to create some kind of relationship with Turkers, since we've sent over 1M HITs since we started using it.

</comment><comment><USER19> Love it. This is an excellent use of mechanical turk solving real world problems.

</comment><comment><USER20> Very cool. I'd love to see the jQuery you used for this. Is that posted anywhere?

<comment><USER21> Just do a view-source on the unsolved version of this page:

<http://unshred.recollect.com>

It seems fairly simple for something that gives so much utility.

<comment><USER22> This is because the complexity is found in a library, jQuery UI, which provides sortable().

</comment></comment></comment><comment><USER23> Wow. That is truly amazing. Creative work my friend.</comment>


UX Expert, 23, Almost Refused Entry To Ireland To Hire People. Name's Flanagan. - <AUTHOR> http://techcrunch.com/2012/03/03/ux-expert-23-almost-refused-entry-to-ireland-to-hire-people-names-flanagan/

<comment><USER2> Checking the "business" box on the immigration form always causes so much hassle with customs… Honestly just easier to lie, check the "personal" box and say you're a tourist visiting the Guiness factory. It's a shame business tourists are given more scrutiny.

</comment><comment><USER3> So someone from country A tries to enter country B for work without having a work visa, is denied entry. Yawn...

It's also funny that his surname is mentioned, as if having an Irish-sounding name automatically gave you a right to special treatment.

<comment><USER2> The way I see it, someone checking "business" on their immigration form is less likely to require a work visa than someone checking "personal". If you're a business traveler, you're usually just visiting for a week for some meetings. You're not taking away jobs from a local, so why would you need a work visa?</comment></comment>


Cache Eviction: When Are Randomized Algorithms Better Than LRU? (2014) - <AUTHOR> http://danluu.com/2choices-eviction/ <comment><USER2> > When Are Randomized Algorithms Better Than LRU?

When the access pattern is random: recently used items are _not_ more likely to be accessed than other items.

Or worse: the access pattern is "anti-recent": items recently accessed are less likely to be accessed again than other items.

This is undergraduate stuff I once had to know for exams in machine architectures and operating systems.

The choice of LRU replacement is favorable when there exists "locality of reference"; that's what it's predicated upon.

All of the replacement policy choices are only substitutes for a "magic oracle": a replacement strategy which can peer into the future and know which items will be accessed soonest. With a magic oracle, we can not only retain those items in the cache in preference to other items, to great advantage, but we can automatically prefetch the correct items that are not yet in the cache but are about to be accessed.

In general, randomized algorithms provide a defense against situations in which things don't work out according to the best case assumptions. For instance, they help defend against tickling worst cases in algorithms (e.g. sorting) that have good average-case behavior.

<comment><USER3> This comment is dangerously trivializing the problem. Even in cases where the access pattern is contiguous, not "anti-recent", etc. LRU can still fail to perform. For example, if you simply iterate over a contiguous list of 5 items with a cache size of 4, you will have a 0% hit rate with LRU. With 2 random, it would be > 0% because there is a chance you wouldnt evict the item in exactly the wrong time. The main takeaway from the article is that it is this mismatch between cache sizes which can cause problems and is evident by the data. In L1+L2 caches, LRU outperforms, but in L3 2-random outperforms because at that point, you are more likely to hit this exact case.

<comment><USER2> Repeatedly iterating over a sequence items is in fact "anti-recent". Round- robin cycling is probably the simplest possible algorithm for accessing a set of items such that, at any time, the item that is accessed next is the one that was least recently visited. Proof: since that item was last visited, every other item in the set was visited.

<comment><USER3> You're missing exactly the point. "anti-recent" is a relative term. Imagine that the data set is actually 1000 items long, but we iterate through it five at a time, but we iterate over that five 10 times each before moving on to the next 5. Those five items are much more likely to be necessary than all the 995 other items, but the currently added member is less likely than the other 4 for the next loop. You see, its a relative term. If the cache size had been 5, we would say that this is a nearly perfect example of caching the most likely members to appear.

</comment></comment></comment></comment><comment><USER4> > If you have a tight loop, LRU is going to be perfect as long as the loop > fits in cache, but it's going to cause a miss every time if the loop doesn't > fit. A random eviction policy degrades gracefully as the loop gets too big.

That's the key take-away from my experience with optimizing control loops for microcontrollers with small caches. As soon as your loop is too bit, your code suddenly runs at a hundredth of the speed.

<comment><USER5> I am not sure I understand what you mean by the size of the "loop".

Conventional LRU uses linked-lists and when the LL no longer fits in the L1/L2 caches, you will see the performance hit you mention (given that accessing the associated LL node and reordering the list will most likely result in two cache misses).

Try libclc [1] for a compact _segmented_ cache of n 64B containers that exactly fit a cache line, with each container having its own eviction policy. The overhead of LRU per container (of 7 data lines) is 9.14 bits/entry and the same cache line access will give you both the data lines and the LRU order.

[1]: [https://github.com/alphazero/libclc](https://github.com/alphazero/libclc)

<comment><USER6> > Conventional LRU uses linked-lists and when the LL no longer fits in the > L1/L2 caches

He refers to the LRU-like policy of the I/D cache itself.

<comment><USER5> Got it. Thanks for the clarification.

</comment></comment></comment></comment><comment><USER7> Interesting read, but I wish he'd explain how 2-random and LRU differ better. In a nutshell, LRU tracks the time when a cache item was last accessed and always discards the oldest item. 2-random also tracks the age of all cache items, but when discarding picks two random items and discards the oldest of those two.

<comment><USER8> It doesn't discard the oldest item, it discards the item that was least recently used/accessed (LRU, like the name says). To see the difference more clearly, note that the oldest item can in fact be the _most_ recently used one.

</comment></comment><comment><USER9> Love reading this. It has always been one of those interesting things I kept in the back of my mind in my day to day.

I was very excited when I actually got to implement it on a real world project.

I was writing a scale out job which used ffmpeg to make clips of video files. To speed it up I kept the downloaded files (which could be 150 GB in size) as a local cache. Quite often a clip is made of the same file. When the disk was full (there was a separate disk for download and clip output) selected two of the downloaded files randomly and deleted the older one. Loop till there was enough disk space, or no files.

It's something I thought I would never actually get to implement in the real word, and thus far is working very well, the caching speeds things up and the eviction seems to avoid too many cache misses.

<comment><USER10> 2-random was also used in this HDFS change - [https://issues.apache.org/jira/browse/HDFS-8131](https://issues.apache.org/jira/browse/HDFS-8131).

Default block placement policy chose datanodes randomly for new blocks. This change selects 2 datanodes randomly and picks the one with lower used disk space.

</comment></comment><comment><USER11> Caffeine, a caching library for Java, has a nice write-up on more advanced cache eviction strategies. [https://github.com/ben- manes/caffeine/wiki/Efficiency](https://github.com/ben- manes/caffeine/wiki/Efficiency)

</comment><comment><USER12> Worth reading [http://open-zfs.org/wiki/Performance_tuning](http://open- zfs.org/wiki/Performance_tuning) about the Adaptive Replacement Cache algorithm ( [https://en.m.wikipedia.org/wiki/Adaptive_replacement_cache](https://en.m.wikipedia.org/wiki/Adaptive_replacement_cache) ) which is less vulnerable to cache flushes than LRU

<comment><USER13> The only big gain of ARC is the adaptive sizing. If you can live with static sizing you will do just as well with 2Q, which is not patented.

I haven't used a true LRU in quite a while because the coordinated bookkeeping required is as disaster on multithreaded programs. ARC and 2Q can be largely lock-free.

<comment><USER14> Can you explain how ARC can be more easily lock-free than LRU? ARC has to coordinate 4 doubly-linked lists and a pivot on every access.

<comment><USER13> You can implement ARC that way and there is a Go library on GitHub that does, but that is not going to scale well. Normally you won't need to evict from the frequently-used list, and there is no need to maintain LRU order on that cache during access. One need only atomically update the access time of the entry and defer ordering until such a time as eviction is required. During an access only a read lock on that cache is needed. During eviction from frequently-used you need exclusive access to all four structures, but if you can arrange for that to be rare, you'll have uncontested read access to your hot items without the need to maintain the LRU property.

<comment><USER14> That certainly helps, though you assume strict LRU vs approximate ARC. One can of course use similar schemes on LRU (like memcached does) or sampling LRU, making it approximate but reducing the lock contention. The technique that I've used is to buffer and replay events against the policy, so that reads are just a CAS into a ring buffer and replaying is under performed under a non- blocking lock. That works well with any policy and extends to other features, like expiration.

<comment><USER13> I think we'd definitely have things to discuss :-) It sounds like we agree there is rarely a good reason to maintain strict LRU property no matter what scheme or structure is being used.

BTW for expiration I have simply invalidated on next access. This seems to have worked well for me with DNS caching, for example, where basically you have three hot records (gmail.com, hotmail.com, yahoo.com) that expire every 5 seconds. In this case of course there is value in proactively refreshing cache entries with some probability proportional to the expiry time so you don't have thundering herds.

<comment><USER14> Yes, that would be fun. :)

For fixed expiration (e.g. 5 min TTL), I use time-bounded LRU queues. Then if the head item has not expired, its successors have not either. If it has, it is merely a poll.

For custom expiration (varies per-entry), I use a hierarchical timer wheel. This replaces sorting with hashing, with an amortized O(1) cost.

For refresh, that's when I do it on access since its being used. I keep a refresh timestamp and an expiration timestamp, so that a refresh can occur while the data is valid but aging, but a blocking load is required when its too stale (expired).

You might enjoy this slide deck of the ideas that I use: [https://docs.google.com/presentation/d/1NlDxyXsUG1qlVHMl4vsU...](https://docs.google.com/presentation/d/1NlDxyXsUG1qlVHMl4vsUUBQfAJ2c2NsFPNPr2qymIBs/edit?usp=sharing)

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> An algorithm that's more optimal than LRU on most workloads is Window TinyLFU. Some nice simulations and graphs can be found here: [https://github.com/ben- manes/caffeine/wiki/Efficiency](https://github.com/ben- manes/caffeine/wiki/Efficiency)

<comment><USER16> LHD is more optimal than LFU on most workloads. It's harder to implement, but more accurately computes the actual expected value of each cache item. [https://www.cs.cmu.edu/~beckmann/publications/papers/2018.ns...](https://www.cs.cmu.edu/~beckmann/publications/papers/2018.nsdi.lhd.pdf)

<comment><USER17> I glanced through the paper and didn't see a comparison to TinyLfu. Unfortunately, it seems to be a misleading name which would make one think it was simply an LFU algorithm. The description in caffeine seems to indicate that it's more of an LRU algorithm with an LFU admission heuristic.

If the overhead of the cache itself is significant, as in kernel virtual memory management. A clock based algorithm is usually preferable which uses an array to approximate node based structures. ARC and LIRS have CAR and CLOCK- Pro respectively to simulate them. CAR is vulnerable to re-use distances near the boundary of the cache size. [1] CLOCK-Pro is widely used, notably in Linux VM. [1] [https://www.slideshare.net/huliang64/clockpro](https://www.slideshare.net/huliang64/clockpro)

<comment><USER14> Naming aside, the structure is <LRU | LFU filter | LRU>. The latest version of that is adaptive, where the front LRU may grow or shrink based on the workload. This allows the cache to mimic LRU for recency-skewed workloads (e.g. job queues) and LFU for frequency-skewed ones (e.g. loops). In a stress test, ARC and LIRS had 20% hit rate, Caffeine has 39.6%, and Optimal is 40.3%.

[https://user- images.githubusercontent.com/378614/52891655-29...](https://user- images.githubusercontent.com/378614/52891655-2979e380-3141-11e9-91b3-00002a3cc80b.png)

</comment></comment></comment></comment><comment><USER18> Randomization can really do wonders at times. There are some algorithms for which the most efficient algorithm is essentially using randomness in a clever way. The Miller–Rabin primality test comes to mind. Or the randomized minimum cut problem. And even when deterministic algorithms have the same big-O asymptotic complexity as randomized algorithms, the randomized ones often perform better due to simpler code. Treap vs red-black tree is a classic example.

</comment><comment><USER19> It's also working very well for load-balancing.

[https://brooker.co.za/blog/2012/01/17/two- random.html](https://brooker.co.za/blog/2012/01/17/two-random.html)

</comment><comment><USER20> The article never explains what the difference between 2-random and pseudo 2-random is, does anyone know?

<comment><USER21> Pseudo 2-Random use Pseudo LRU. Check the Wikipedia for Pseudo LRU.

It is a tree algorithm for tracking the approximate last use time.

</comment></comment><comment><USER22> Note that LFU does not have the same limits and will adapt to access patterns that are pathological for LRU like circular accesses. LRU is an approximation of LFU based on the idea that last access time is related to the future access frequency of an object. The pathological cases where LRU fails and random eviction is better is related to the fact that such access patterns violate such premise. LFU does not have such limits because it attempts to measure the actual access frequency (smoothed by time) of an object, and uses that as prediction of the future frequency.

<comment><USER23> I have just started fiddling with treaps recently. Not applicable I suspect for a hardware cache but this thread has morphed a bit into conversations about software caches as well.

A treap is an _unbalanced_ binary tree where the tree depth is proportional to the frequency of use to get fewer indirections per access (assuming an uneven distribution of lookups). Essentially it has a MFU or LFU queue built into it and now I'm curious about how it would behave as a cache data structure.

</comment></comment><comment><USER24> It would be interesting to compare the behavior of real workloads with different cache protocols. In a "real workload" the sequence of reads and writes to memory (and the cache) come from a multiplicity of independent processes functioning co-sequentially with some distribution of lifetimes of cache ownership. In many cases, the caches will be in a non-equilibrium state and behaving badly.

</comment><comment><USER25> Note that Redis's LRU algorithm is randomized: [https://redis.io/topics/lru- cache](https://redis.io/topics/lru-cache)

> The reason why Redis does not use a true LRU implementation is because it > costs more memory.

...but it sounds like it wouldn't necessarily be totally desirable to use true LRU anyhow. :-)

</comment><comment><USER26> Random boosting could have saved Mars pathfinder [https://en.wikipedia.org/wiki/Priority_inversion](https://en.wikipedia.org/wiki/Priority_inversion)

</comment><comment><USER27> The experiments are interesting but they never explained what the strategies are. It's OK for LRU and FIFO but certainly not for 2-random!</comment>


Is Snap Inc. Building a Wearable Face Recognition Device for the NSA? - <AUTHOR> https://medium.com/@christofoomurr/is-snap-inc-building-a-wearable-face-recognition-device-for-the-nsa-94bc12aef06e#.w9sovfeyn <comment><USER2> HA! Because pimply faced teens wearing glasses when whimsical, is the NSA's best chance of collecting blanket face-data? In America at that, while the big majority of persons of interest are tucked half a world away.

Genius!!!

<comment><AUTHOR> Their Spectacles announcement was odd though. You don't think an index of millions of people's face data is valuable?

</comment></comment><comment><USER3> Come on.</comment>


What do you do after an investor says yes? - <AUTHOR> http://blog.sendhub.com/post/114498885892/what-do-you-do-after-an-investor-says-yes

<comment><USER2> One of the best parts of this, illustrated by the use of red squares, is that "sit and do nothing" isn't part of fundraising.

Common YC advice for fundraising is "optimize for speed" (with valuation, amount, brand names, etc, coming second). Don't get trapped in long diligence cycles, waiting for a lead, or other road blocks.

<comment><USER3> Outside YC, chasing a 'yes' actively to turn it into a completed investment is even more important. Optimize for speed is closely related to optimize for outcome.

One minor addition to the chart - if investor asks for a longer timeframe, respect that - and chase other investors!

<comment><AUTHOR> But a longer a timeframe where? I think waiting on signing docs after agreeing to them is far from ideal, same goes for waiting on wiring the money, unless agreed in advance.

</comment></comment></comment><comment><USER4> Relatedly: write one of these for your sales process (certainly for enterprise sales, but very useful for low-touch/medium-touch as well). It will save your sanity.

<comment><USER5> I second that - you always know what to do next...

</comment></comment><comment><USER6> In my mind until you can answer 'Yes" to the question of "Have they signed?", then they haven't said yes.

<comment><USER7> They haven't said 'yes' until they've wired the money.

<comment><AUTHOR> The gap between 'yes' and money in the bank, is why so many people have trouble with this, imo.

</comment></comment></comment><comment><USER8> A note to anybody having problems loading the flowchart image: some combination of HTTPS Everywhere and other privacy-related extensions causes the image to fail to load with an Amazon S3 or CloudFront-like error from Edgecast CDN.

The broken image URL: [https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/d92e8...](https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/d92e89be88474faafb5122dc60a6e450/tumblr_nlowhamlb31r7m6x8o1_r1_1280.png)

The correct image URL: [http://40.media.tumblr.com/d92e89be88474faafb5122dc60a6e450/...](http://40.media.tumblr.com/d92e89be88474faafb5122dc60a6e450/tumblr_nlowhamlb31r7m6x8o1_r1_1280.png) (https also works)

</comment><comment><USER9> Interesting that there's no step in the flowchart for an investor to exit the flow after a verbal yes. A 100% close rate may be normal for a YC company but in my experience it's not typical. You want to get a "No" as fast as possible, which I've seen happen at every stage of the pipeline, including after signed docs (although rarely).

<comment><AUTHOR> I agree, we've never closed 100% of yeses. However, dragging it out with one of those investors, assuming they refuse to say no is worse for them imo as it creates a clear paper trail of bad behavior which hurts their reputation.

<comment><USER10> This is true, investor and for that matter 'executive' lock-in is significantly more substantial than an individual contributor, and so (rightly so) is the investment to return. It's an interesting paradox. Reputation matters.

</comment></comment></comment><comment><USER11> how'd they make this flowchart? Its great

</comment><comment><USER12> take their money and buy a ferrari</comment>


When you DON'T need a technical co-founder - <AUTHOR>

There are startups which I think can live without techie co-founders.  It is my proposition that if your idea does not solve a core engineering problem then the need to bring in a technical co-founder diminishes.  You can get away with hiring the talent as employees rather than as co-founders.  Sure, you may need some help in putting together a demo/mockup, but that can be outsourced or done on contract.<p>Here are a few examples of startups that I think don't require technical co-founders because they are not that difficult to build (that is different from saying they don't need any technical help).  AirBnB, CardPool, Fanvibe. <comment><USER2> The danger of NOT bringing on a technical co-founder is that you're then dealing with a different type of developer/tech person. This technical person is generally the type that gets (or could get) paid good money.

So as Travis mentions in his comment, if you don't have lots of cash on hand, you could run into problems. There is really no shortage of jobs available to developers, and chances are many jobs out there will pay much better than what you can afford to pay at your startup. Unless you find the perfect person who doesn't mind making less than he/she probably could and is still 100% dedicated, you'll probably have a high turnover rate.

In contrast, you can generally assume that a co-founder is going to give you 100% all the time as they theoretically have a lot of skin in the game.

In many startups, you probably don't _need_ a technical co-founder, but you probably _should_ have one anyway.

</comment><comment><USER3> Seems to me, though, that if you're not bringing a technical co-founder, you'd better be bringing cash to the table. A technical co founder can exchange time for code. Without them, you need some other medium, which is invariably cash (or connections to cash).

</comment><comment><USER4> Yes if you have the cash AND know how to hire and manage technical teams, a technical co-founder is not really needed IMO.</comment>