Absent-mindedness as dominance behaviour - <AUTHOR> http://induecourse.ca/absent-mindedness-as-dominance-behaviour/ <comment><USER3> In defense of the absent-minded, labeling it a "dominance" behavior requires several value judgements. One could readily read his examples to demonstrate, for instance, that once people attain to a certain level of status and respect (enough that they don't have to worry about people calling them "stupid") they're simply less uptight about a lot of things than other people are. They treat social chores and the location of parked cars as being precisely as unimportant as _everyone_ feels like they are. The way the author talks about the habit- "everyone would love to be absent-minded", how people can or can't "get away with it," etc- makes it sound like absent-mindedness is the _natural_ way of being. One could turn the whole idea around and criticize modern culture for requiring us all (those of us without professor-level cachet) to maintain a mandated level of neuroticism. Neuroticism that is unnecessary for real performance- since, if someone can operate effectively enough to attain tenure, "absent-mindedness" certainly hasn't crippled their professional effectiveness.

(In all of this, of course, I except the story about the guy who left the author rideless at the office. That _was_ a 'dickhead' move.)

Finally, on the claim "they only forget things that benefit them," be very careful about confirmation bias. I, for one, show up at meetings early not infrequently- but when this happens, _no one knows_ because no one else is there.

<comment><USER4> > Finally, on the claim "they only forget things that benefit them," be very > careful about confirmation bias. I, for one, show up at meetings early not > infrequently- but when this happens, no one knows because no one else is > there.

Additionally-- that fuddy-duddy professor who left their colleague hanging to attend a conference may have done 100 other absent-minded things at the conference that were detrimental to their own career. These may include:

* being late to their own presentation because they went to the wrong building

* undermining their own presentation by forgetting every colleague's polite advice to not making gross sniffing noises or laugh like a hyena at seemingly random moments in their public speech

* being completely inept at getting their laptop to play audio/video excerpts or display a graph on a screen

* forgetting to exchange contact info with someone who would have helped advance their career

* give an earnest, brilliant, persuasive response in public to an egotistical and well-respected scholar on the hiring committee for a position coveted by the professor, who then silently takes offense and uses their power to keep the professor from being hired for that position

* forgetting to follow up with an appointment with well-respected scholar who wanted to help the professor publish something that would help their career, causing that scholar to silently vow to never again waste time with that professor

(All based on real events.)

</comment></comment><comment><USER5> I work in technology in a very high scale environment. Tons of people, lots of new faces all the time, hundreds of emails, social media pings, birthdays, need to change the cat box, car overdue for an oil change, organizing a conference, my direct reports are being lazy and I have to find a good way to motivate them, oh shit I agreed to send that guy that thing in the mail, the sales guy is pissed at me because I accidentally talked to his customer and didn't loop him, oh shit haven't been into the office this week need to put in face time, ten LinkedIn invitations, oh what about that webinar....

Jesus just found a stack of business cards from that conference two weeks ago and this one person wanted to meet and I never got around to it. Did I complete that sexual harassment training? I just got four reminders saying I need to read some new policies. Oh look three calendar invites for meetings tomorrow I didn't see earlier. Did we get that vendor under NdA? My admin in the back office is on vacation I need her to finally sort the statement of work. Fuck it's almost Friday I need to write that monthly report. My boss calling me about that thing hold on...

Like me, A college professor is defined by having hundreds of students pinging them with shit all the time and it is a rolling cast of students and faces you can't remember with a monotonous list of shit you can't possibly keep track of.

A younger me wouldn't have understood what this does to my brain. The older me walks around in a state of being near to burn out and fried all day long.

It's the volume of requests and things to think about. Keep in mind most of these things aren't event my job, they are just overhead I have to deal with before I can even do my job.

I'm with the professors on this one. It's brutal.

<comment><USER6> Your comment really resonates with me. Have you found a way to balance this? I counsel others that they should focus on prioritizing the infinite task list and working on the stuff that's going to make a difference, but it feels like a tough thing to track no matter what. Any tips?

</comment></comment><comment><USER7> When I was in college I slept through four or five meetings with my advisor. But only because those meetings were scheduled months in advance, and since they were basically the only thing on my calendar, I'd just miss them unless I happened to look at my calendar the day before. But as soon as the iPhone came out I basically have never missed an appointment again, because now I can put things in the reminders app and can have events in there that are months or years in advance.

I wasn't magically dominant before the iPhone came out or more submissive afterwards, there just wasn't a good tool that matched my workflow. I'm not sure what the point of this story is, other than that it's hard to generalize from university-related situations since people in academic settings aren't always well served by mainstream scheduling and calendaring tools.

<comment><USER8> I've noticed something similar with my phone being my primary alarm as opposed to a traditional clock or radio alarm. Having more dynamic control over my tools has allowed me to rapidly craft and change that alarm to ensure the desired results. It seems like every time I've relied on a traditional alarm to wake me up it slowly and subconsciously becomes less and less effective. Once I've built up a certain "tolerance" to the sound of said alarm I'll hit snooze or turn it off altogether while still mostly, if not fully, asleep.

That said, the only sure fire method I've come up with to ensure a traditional alarm does the trick is to set the alarm across the room. This guarantees that I have to remove myself from bed, walk across the room, and then disable or snooze the alarm each time I choose not to wake up for good. In this "sure fire" case it's obvious to me that the tool itself is not sufficient and I've had to build extra steps into the process to ensure it helps me achieve my goals.

</comment></comment><comment><USER9> Lots of good replies. I'd like to add that incentives seem a better explanation than power:

The professor's incentives are entirely towards thinking up and pulling off big long-term projects. The tenure committee is not going to know or care about whether you seemed on top of your diary two years ago.

The incentives are much the same for graduate students too, another group known for sleeping through 11am teaching commitments. They clearly don't have any power, but they know damn well they won't get a job by being diligent about the small stuff.

The incentives for (say) lawyers or management consultants are massively different. Hence the firm handshakes and neat suits and always knowing what time the meeting is. Are these people less dominant, somehow?

<comment><USER10> I'd argue that they're 2 sides of the same coin. Understanding the differences in incentives between people gives you an idea of who has the power.

If you took a subsection of grad students and said that if they missed any teaching commitments, they'd be expelled, you can reasonably guess that those grad students wouldn't be sleeping through any 11am teaching commitments.

<comment><USER9> But why does this mean they have power?

The hiring committee at their next job has real power. The administrators who could fire them have some power too (although failing to impress the former is almost as bad as being expelled by the latter). This power doesn't seem to explain who's sloppy very well.

The hot-shit lawyer has loads of power, right? And is never forgetful. But his life revolves around impressing people right there in the same room. He's been both selected and trained to be be good at impressing them.

</comment></comment></comment><comment><USER11> But I am the victim of my absentmindedness, more often than others are. It's not some kind of power manipualtion bs like this article asserts, instead I am diagnosed with pretty severe ADHD.

There really are completely different explanations rather than it is all power dynamics.

For medical reasons I am not at the moment taking the meds I normally do, when I am medicated, my forgetfulness subside, and both my life as well as those I interact with improve.

This one dimensional - everything is a power dynamic - is rather reductionist bordering on insulting.

<comment><USER12> I was wondering when someone would mention ADHD. If I recall, absentminded behavior is a big part of the diagnostic criteria for ADHD.

</comment></comment><comment><USER13> I'm one of the absent-minded crowd.

I think it's hard for the orderly types to relate to the absent-minded. For them, remembering things comes naturally. They project this onto absent minded types which leaves only one explanation for them being inconsiderate or forgetful -- that they're lazy or uncaring of others. As if they thought "Yes, I remember I'm supposed to do X, but whatever... it's not important."

As someone who's very absent minded I can say that there's never any dominance tactics or purposeful lack of consideration for others. I just forget things or don't think about them.

If, in the shower, I think "hey I need to remember to buy shampoo as soon as I get out of the shower", I will literally forget about it within the 2 minutes it takes me to get out of the shower and dry off. I'll be standing out of the shower trying to remember the thing I was supposed to remember. Oh well, I just move on with my day.

It's not an occasional thing. This happens to me 9 times out of 10.

So it's no surprise that when I tell someone "yeah I'll bring X the next time we meet" I never remember to bring it.

Luckily in my life I've got friends and family that understand that it's just the way I am and that it's ok. I get the fuddy-duddy professor treatment. I've had more than a few friends tell me I'm the dumbest smart person they know.

</comment><comment><USER14> I am tired of this worldview in which every personal behavior that we don't like is _actually_ a secret manifestation of power dynamics. Nothing ever _means_ anything except as endless jockeying for social position. Nothing is good or bad or true or false or beautiful or hideous: only advantageous or disadvantageous. It's a terrible way of thinking about the world.

This nonsense is not conducive to building or maintaining a civilization. It doesn't create shared understanding: instead, it supposes that any shared understanding is actually some kind of ploy to reinforce privilege or something. It's an endless grievance machine that magnifies our worst mental impulses: suspicion, ingroup-outgroup double standards, and of course fundamental attribution error. This crap shouldn't be part of respectable discourse.

<comment><USER15> Basically every personal behavior _is_ a manifestation of power dynamics. Whether you like it or not. It's just that we tend not to notice or complain about power dynamics that we like.

The tricky thing about power dynamics is that whenever you talk about them, people get uncomfortable - both the people with power (who either feel guilty or subconsciously fearful that that power may be taken away from them) and the people without it (who are reminded of their lack of power). And so you're right, it _is_ an endless grievance machine that magnifies our worst mental impulses. This is why people usually shut up about power (think about it: the last guy who wrote a treatise on it - Machiavelli - got his name synonymized with "evil"), and it's only in times of shifts in the power balance that it comes out into the open.

<comment><USER16> _" think about it: the last guy who wrote a treatise on it - Machiavelli - <USER2> his name synonymized with 'evil'"_

Machiavelli was not the last to write about power. Foucault was famous for doing so, and Nietzsche before him.

To the extent that Machiavelli's name has a negative connotation it is it not merely because he wrote about power, but because people think he advocated a ruthless, self-serving wielding of power and, famously, that "it is better to be feared than loved".

If you look at what "machiavellianism" means, it is:

 _" the employment of cunning and duplicity in statecraft or in general conduct... In modern psychology, Machiavellianism is one of the dark triad personalities, characterized by a duplicitous interpersonal style, a cynical disregard for morality, and a focus on self-interest and personal gain."_

[https://en.wikipedia.org/wiki/Machiavellianism](https://en.wikipedia.org/wiki/Machiavellianism)

<comment><USER15> I'm a big fan of Foucault's conception of power.

I think Machiavelli is commonly misunderstood by most people alive today, though. The bulk of _The Prince_ consists of _positive_ statements, not normative ones. In other words, Machiavelli is describing his conclusions from observing a number of powerful families. He makes few value judgments of his own, but rather the book is framed as a set of tactical advice: " _If_ you seek power, these are a set of strategies that will help you attain it." At the time he wrote _The Prince_ , Machiavelli was not particularly powerful - in fact, he'd just been stripped of office, imprisoned, and tortured, and the book was an attempt to curry favor with the Medicis, the new Florentine elites. It was largely successful in this regard, in that Machiavelli was allowed to live out the rest of his life on his estate without further interference.

"It is better to be feared than loved", as a factual statement, appears to be _true_. Take a look at the approval ratings for U.S. Congress, President Trump, Putin, Xi Jinping, Mugabe, or any other powerful figure and then tell me, with a straight face, that they are loved. People take offense because Machiavelli is describing true statements _that we wish were not true_ , i.e. they judge the work on normative grounds when evidence from the framing & history of _The Prince_ suggests that it was written as a set of positive statements.

<comment><USER17> Machiavelli is massively misunderstood. 'It is better to be feared than loved' is not the real message to be taken from that chapter.

A different phrasing would be "you are better to have a promise from another for which you can compel fulfilment, than a promise for which you can't compel fulfilment".

If someone promises you something out of love, and they do not deliver, you have no power to compel them to fulfil their obligation, and so you are left with an empty promise.

If someone promises you something out of fear, and they don't deliver, you can use the thing they fear to compel fulfilment, and receive that which was promised.

It's by no means saying that in all circumstances you should aim to be feared - and it explicitly distinguishes being feared from being hated.

"Returning to the question of being feared or loved, I come to the conclusion that, men loving according to their own will and fearing according to that of the prince, a wise prince should establish himself on that which is in his own control and not in that of others; he must endeavour only to avoid hatred, as is noted."

</comment></comment></comment></comment></comment><comment><USER18> Isn't it sufficient to explain the author's data to say that academia is an environment with a high tolerance for flakiness? The fact that professors' flakiness usually works out in their favor just follows from people usually acting in a self-interested way. If I forgot about our meeting, on average I'm going to spend that time doing something that benefits me.

I've definitely had the experience of some academics using absent-mindedness for dominance, but that doesn't mean it always or even usually is.

A datapoint here is that in my experience fields that are larger and more practical/"applied" have a lot less absent-mindedness. (You could probably quantify this with e-mail response times.) But the hot fields are more competitive than the sleepy backwaters---if absent-mindedness were a dominance tactic, wouldn't we see more of it in the bigger fields?

<comment><USER19> > Isn't it sufficient to explain the author's data to say that academia is an > environment with a high tolerance for flakiness?

Yep. Other environments with a high tolerance for flakiness include online dating - there are pretty much zero repercussions for flaking on a stranger you decide you don't actually want to meet.

Many guys who've tried online dating have stories of girl agreeing to meet up then flaking on them. Does that make it a "female dominance behavior"?

I get it, it sucks to be flaked on, whether by a professor or a tinder stranger, but I don't think it's limited to one gender.

</comment></comment><comment><USER20> Breaking social norms and getting away with it is an old trick to show dominance. When you are late you show the other person that you are the one to be waited for. Zuckerberg shows who the boss is with wearing a hoodie while everybody else is wearing a suit. Obviously this works mainly if you are already in a slightly dominant position otherwise you may be viewed as a jerk.

<comment><USER21> The only purpose of a suit is to assert dominance. The hoodie is just a different spin on it.

"I won't wear a tux!"

"Of course not, dear; tuxedos are for waiters!"

-Sunset Blvd

<comment><USER20> It depends on your position. When I wear a suit it's to fit in because everybody else does it.

</comment></comment></comment><comment><USER22> I would also recommend reading the comment thread on the site, if you skipped it.

</comment><comment><USER23> > No one ever shows up early because they forgot what time the meeting was at.

I _do_ do that. But I have ADHD.

I endorse the author's suspicion that the "absent-mindedness" being described here, has not much to do with the neurological kind. It might be a dominance behaviour, or whatever else, but it certainly expresses differently than the behaviours of people who genuinely forget things they _want_ and _need_ to remember.

I forget where I parked, but that's after attempting quite hard to memorize my location while leaving the parking spot. I suspect the author's father didn't bother to _try_ to remember: quite a different experience!

</comment><comment><USER24> It can definitely be used as a power move... but claiming absent-mindedness is ALWAYS a power move is a very bold claim.

<comment><USER25> Exactly. One I'd have a hard time explaining by this model is my comical ability to get lost while driving. This has almost always hurt me-- occasionally others--but primarily me. I have the same problem navigating halls in a video game. I've worked at it and gotten better, but that weirdly specific deficit has always haunted me all the while Ive been perfectly adequate as a programmer, etc.

</comment></comment><comment><USER26> An interesting argument, but ultimately deficient. For one thing, our recollections are biased; we are probably more likely to remember instances of a behavior in which one is negatively affected than otherwise.

The author is free to form their opinions however they like, and personal reflections of this sort are really great for formulating hypotheses. But then, you need to get down to the serious business of actually systematically gathering data to test it, or at least go look into the literature.

Also, the author, casually asserts that its mostly men who do this. The author gives some good reasons why that might be. But again, this assertion of a matter of fact, is based on his own, situated, biased, unreliable, motivated recollection.

</comment><comment><USER27> It could simply be an energy minimization strategy, since it has little or no consequence (perhaps due to pre-existing status or dominance) there's no point in spending energy on that.

In a sense, to succeed you need to choose what you are going to be bad at. It's impossible to be great at everything, so focus your energy on what's important, and let the unimportant slide.

</comment><comment><USER28> Conflicted here. On the one hand, I agree that it's easier to say, "That's just the way I am, deal with it." On the other hand, folks deal with things like ADHD and depression and different cultural upbringings that make it more difficult for them to, say, remember things than "normal" people. Feels like the author is using his dad as a sample size of one as evidence for a broad statement here.

</comment><comment><USER29> As a forgetful person, I would love it if it I could control it.

But no. Sometimes it is really bad - like feeling really engaged and consciously listening, then the person goes and forgetting what they said. More often it is more insidious than this unfortunately.

</comment><comment><USER30> It could also be that university professors sometime have Aspbergers syndrome which is a form of autism.

</comment><comment><USER31> Techies are absent minded, but use tech tools to mitigate the behavior.

<comment><USER14> I can certainly be absent-minded. Lately, I've gone to a lot of trouble to start using various reminder and task applications in an effort to become less absent-minded. If I slip up, it's because I made a mistake, not because I'm trying to advertise my primate social dominance score.

</comment></comment><comment><USER32> I literally just got out of the shower and couldn't remember if I used the shower gel or not... Absent-mindedness is not (just) a social behavior.

</comment><comment><USER33> This is truly an article that makes you reflect on the stereotypes and assumptions you have about people.

For instance, before reading this I had this unexamined generalization that Canadians are all kind and empathetic, but after seeing Prof. Heath's attitude towards his colleagues...

</comment><comment><USER34> I could maybe halfway see this.

I've been working on my current job for 8 years. I've been a programmer for 30. In the last year, I've started feeling free enough to say "I don't know" or "I don't remember". Before that, I felt that I _had_ to remember, or, if I didn't, I had to find out, because I felt that I was supposed to know. But now, I've realized that it's OK for me to not know everything.

That's not dominance behavior, exactly. I'm not deliberately not remembering to put co-workers in their place. I'm also not trying to skate on my responsibilities: "You figure it out yourself; I'm too important to do that." But it is a level of security. My image of myself as a good programmer isn't destroyed if I don't remember some detail amid the tens of thousands of lines of code. And I don't fear that my boss's image of me will be destroyed by that, either.

So maybe, at least some of the time, it's not a exactly dominance behavior, but it's a behavior that only those in secure positions can afford.</comment>


Show HN: Select Sections from Images of Newspaper Clippings Using OpenCV, Python - <AUTHOR> https://amehta.github.io/posts/2019/09/select-sections-from-images-of-newspaper-clippings-receipts-etc-using-opencv-and-python/ <comment><USER2> Striking similarity to this article, with a lot of the preprocessing steps missing.

[https://medium.com/@neshpatel/solving-sudoku-part- ii-9a7019d...](https://medium.com/@neshpatel/solving-sudoku-part- ii-9a7019d196a2)

</comment><comment><USER3> So,you view the image using CV and write down the coordinates of the puzzle, put them in array and use CV to save the puzzle with different name.

Basically, you are cropping the image and saving it - which even a crappy cropping tool does. Do not consider this as a discouraging comment - programming can do better.

I understand you are looking for jobs and trying things. If I'm the hiring manager, I would rather prefer a candidate who found puzzle coordinates from the image bits/pixels and suggest cropping regions.

<comment><AUTHOR> Actually I am currently not looking as I am backpacking :)

I am just exploring the OpenCV library for fun things to do and in the process documenting simpler and smaller stuff for my reference. I do plan to have a follow up post that will automatically find the corners!

</comment></comment><comment><USER4> Nice. Would you do a follow-up showing how to automatically select corners like office lens or Dropbox do ? (I find the office lens app really really good)

<comment><AUTHOR> Yes, Indeed that's the direction I am heading towards, but I am initially starting with simple posts to keep the flow ( for myself) and also easier for people to notice the simplicity of openCV.

</comment></comment><comment><USER5> I would have liked to see the intermediate results in the article as I'm on mobile now and can't easily run the code.

<comment><AUTHOR> I will update it with the intermediate step!</comment></comment>


Asana Engineering Interview Guide - <AUTHOR> https://blog.asana.com/2016/03/asana-engineering-interview-guide/ <comment><USER2> Do these companies not recognize that moment of cognitive dissonance that surely -must- come when, as they're faced with "how do we determine if someone will be productive coming here" decide "I know; let's ask a bunch of questions we don't expect them to know! And then, let's provide a study guide so that they -can- cram before the test and come in and show they know it!"

I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve, but to implicitly admit it, -and- to also acknowledge that it isn't something you expect people to have off the top of their head by providing a study guide? What are you trying to measure?

<comment><USER3> > let's provide a study guide so that they -can- cram before the test

Did you look at the guide? I don't see anything you would be motivated to cram after reading through that other than to brush up on the "usual suspects" of data structures, but you should be doing that before any technical interview anyways IMO.

Seems like the guide is mostly intended to give candidates an idea of what to expect during their interview.

<comment><USER2> Yes. Under "How To Prepare" -

Read through technical interview prep resources HackerRank and Interviewing.io are good places to start. We're also fans of InterviewCake's Coding Interview Tips.

I.e., "here, go study and cram for your quiz". If you expect people to know the data structures and algorithms off the top of their heads (because you believe that to be useful), then why tell them to prep?

That's what boggles my mind. Technical interviews relying on data structure and algorithmic questions started with a few companies (primarily Google) thinking it was a good way to gauge how strong a candidate was. For their purposes, it might have been. But as other companies started to cargo cult it (despite their businesses requiring far less algorithmic work), a cottage industry of interview prep sprung up (Cracking the Coding Interview, various sites intended to help you practice, etc). And since that then raised the bar (you were now competing against people who were -explicitly preparing- for these kinds of questions, and frequently would have seen the exact question they're being asked, or one akin to it), companies, such as Asana, decided "Okay, to be fair to everyone, we need to warn them that we're asking these kinds of questions and so they should prepare well in advance for them".

Or...you could take a good hard look to decide if that's the skillset that is really important in your hires. If it is, you can probably give them legitimate business questions (which to be fair, Asana might do), as it will cover some of the same basics, but then giving the candidate access to Google, and access to querying and digging and figuring out how best to solve it might be a better gauge of their ability to solve those problems in the real world (unless for some reason they're going to be developing without access to technical resources and the internet). Or, you might find that your business actually requires people able to solve different problems, where implementing fisher yates is not the key technical deliverable, and so you can instead ask those kinds of questions, and see who can solve them based on what they know, and what they think to ask you during the interview.

<comment><USER3> Wow, you really read way more into that than I would have. I barely even looked at the first bullet in the "How to Prepare" section. I suspect it's was just there for completeness and I think it's basically a given that people should brush up on technical interview-type questions before going into a technical interview.

For me, the real meat of that section was in the 2nd and 3rd bullets!

The 2nd bullet is telling people to reflect on their experiences and come prepared to discuss. This may be a no-brainer for some, but for those who don't have a lot of interview experience, I suspect it's easy to get caught up with the "what should I know" mentality and forget to spend a little time reconstructing the interesting projects and situations that they've navigated in your career. For most of us, only the most recent stuff tends to be fresh in our minds.

The 3rd bullet emphasizes that you should come prepared to evaluate _them_. Again, perhaps a no-brainer for most experienced candidates, but it's nice to see the interviewers acknowledging that this is a two-way evaluation and encouraging candidates to be sure they're making the right choice.

While it's unusual for candidates to show up unprepared for technical questions, I've seen _many_ candidates show up completely unprepared to discuss their experiences or ask questions that will help them evaluate the position/team/company/manager.

<comment><USER2> Yeah, I have much less of a problem with those, as they're not "cram for this test" and instead "reflect upon what you already know/wish to know, so that you're prepared to voice it". That's useful advice if you're not used to interviewing, and worth pointing out.

</comment></comment></comment></comment></comment><comment><USER4> I came looking for some new or interesting way of doing tech interviews, but it's the same typical SV bullshit. Lol: "Hashes, sets, heaps, binary trees, linked lists, all the usual suspects." Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. I'm a strong believer that there are two primary ways of testing someone's coding ability:

1) Open-source, or otherwise public, contributions.

2) Real-world take-home assignments.

I've opted out of interviewing people because it's such a miserable experience. I guess I'm just not a sadist that enjoys watching some poor 22-year old squirm in his chair because he can't remember what the upper bound on the insert operation of a red-black tree is.

What a joke.

<comment><USER5> I agree with this sentiment wholeheartedly but bounds on balanced binary trees are worth knowing (like lookup, it's log n), since that fact is one of just two reasons you'd ordinarily ever use a tree.

However, I will offer you some Interview Candidate Self Defense, which I'll repeat from something I yelled on Twitter a few weeks ago:

If interviewers ask you about bounds for data structures, pick a fight with them over hash table complexity. If they believe it's O(1), argue it's worst case O(n). If they want you to say worst case O(n), argue that it's in the real world always O(1). It doesn't matter which is right, because these kinds of questions aren't about technology, they're about status signaling. Be the alpha nerd!

As a bonus: interviewers are evaluating you for X-factors like "confidence". You know who never got dinged in an interview for lacking "confidence"? The person who yelled at the interviewer about hash table complexity.

<comment><USER6> >If they believe it's O(1), argue it's worst case O(n)

In the case that all your keys have the same hash, right?

<comment><USER7> It seems to me this would entirely depend on the implementation and how collisions are handled.

<comment><USER8> In Java 8, collisions in Maps are stored in a tree structure so worst case is O(log n)

<comment><USER9> Is it a balanced tree? If not, worst case could still be O(n).

<comment><USER7> Haha, that would be an odd set of data indeed. I have no idea how they implement it but I hope I have made a point(I feel I have). I wouldn't be too impressed with an interviewer or interviewee arguing one side or the other about the complexity of "unspecified hashmap implementation".

Too clever by half.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> > "We want every candidate who comes into an interview with us to feel > prepared and confident."

Was expecting to then see a list of specific resources that a candidate could use to become prepared and confident. Instead, the guide provides a high-level overview of "algorithms", "data structures", and "modeling" and refers me to "HackerRank and Interviewing.io" for tips on how to prepare.

This seems like it could be improved. You value learning -- so give candidates something to learn and see if they can do it.

> Our goal is not to simulate day-to-day software development — where we read > docs and write lots of tests!

I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard.

<comment><USER11> Hey -- I work at Asana.

Great idea! Took a task to add more resources to learn from to the doc.

> I feel very confident in doing day-to-day software development. I do not > feel as confident speaking about abstract hypotheticals in front of a > whiteboard.

Hmm, the way we framed that is confusing. Thanks for the feedback! To be sure, our goal is to accurately assess what your day-to-day contributions would be like, and simulation is a really good way of eliminating accidental bias in that process. To that end, we do have every engineer submit actual code during the interview process, and we generally avoid white-board programming in favor of higher-level discussions (that may also use the whiteboard). But perfect simulation is possible (and time-consuming), so we've tried to focus on the higher order bits.

<comment><USER12> What's your primary tech stack?

<comment><USER13> We're in the middle of rewriting our stack to look like this:

\- TypeScript web code \- Using React \- Connecting to a custom, to-be- opensourced reactive datastore written in Scala called LunaDb: [https://blog.asana.com/2015/05/the-evolution-of-asanas- luna-...](https://blog.asana.com/2015/05/the-evolution-of-asanas-luna- framework/) \- Using to Amazon RDS (hosted MySQL) and Redis as our primary backing stores \- Running on top of kubernetes, docker, AWS

</comment></comment></comment></comment><comment><USER14> I recently interviewed with Asana, and unfortunately would review their process as the opposite of what they're going for.

The first sentence is not far off from what their process is. My interviews with them were composed of one helpful database problem, after which they explained how they designed their production database, followed by a bunch of frivolous algorithms problems.

I did not receive an offer from them, so take what I say with a grain of salt. Asana seemed like a company that has some great engineers, and runs well in general. I would, however, like to provide some constructive criticism for their interview process.

1\. Their engineers can use some training on how to interview. Several of them came into the room noticeably anxious. Hearing what the problems were was easy, but communication was very difficult when it came to figuring out what kind of answer they were actually looking for.

2\. The questions they use are very academic, which to me means they are mental exercises lacking practical grounding. As an interviewer, it's very uninspiring to have to solve academic problems without getting a peak into the business' real problems.

3\. The whole process wasted way too much time. Obviously I wouldn't have cared as much if they had given an offer, but I think it's important to be conscious of this nonetheless. My suggestion would be to pick topics for interviewers to cover, and cut out the repetition of the problems. Plan a process that will lead to a decision with one shorter visit, be respectful of peoples' time.

I hope that helps. I received more offers I'm excited about, and I hope to see the company succeed from the outside.

</comment><comment><USER15> The funny thing is that Asana is possibly the worst performing web app out of all the ones I use on a regular basis. I have a strong suspicion there's at least one or two O(n^2) algorithms hiding there that could use the same kind of attention and reasoning abilities they expect from their candidates.

<comment><USER16> Yes! Honestly, they need to hire someone to fix the start up time of their app, because it's the slowest by far of any webapp that I use. That should be their first hiring priority.

<comment><AUTHOR> It is one of our biggest hiring priorities and we are actively working on this.

<comment><USER17> Why not ask questions or ask for solution about that in the hiring and interviewer process? You might just find folks who love/know how to solved that kind of problems to work for you.

BTW, that is very trivial problem to solve for those who has done it.

</comment></comment></comment></comment><comment><USER18> > We'll ask you to solve some coding questions in a language and text editor > of your choice. Feel free to bring your own laptop, or we'll be happy to > provide one. Notably, we ask candidates not to compile or run their code > during this exercise, and not to refer to online resources.

Every time interviewing comes up, I have this funny feeling about letting people look things up vs. whiteboarding them out. Reading this finally broke something loose:

Coding in interviews should be as hard as the hardest coding you'll do on the job. Heck, anything in the interview should be about how you do things when the job is hard.

Now, this doesn't mean under stress. That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that.

They'll pass over people who are exceptionally good at searching / synthesizing information. They'll ding people who focus on tightening the iteration time as a way of learning faster. But that's OK. They've probably built a culture where that kind of person thrives, and they're trying to find more engineers who will thrive at Asana.

<comment><USER19> > That may come naturally. But the difference between good and great engineers > is decided when the task is hard and information is sparse. Asana is > explicitly selecting for people who are going to reason about things from > first principles and try to get it right the first time. I admire that > they're owning up to that.

> They'll pass over people who are exceptionally good at searching / > synthesizing information.

I also admire that they are upfront about this, but the attitude in general rubs my classical engineering self the wrong way.

"[R]eason[ing] about things from first principles" is not the same thing as having those first principles memorized. That was one thing my undergrad taught me repeatedly. Engineering isn't about memorizing formulas, it is about learning what those formulas mean, how to use those formulas, and when to apply them to a task at hand. Software engineering should be no different. Expecting people to solve hard and novel problems with no resources whatsoever is ludicrous.

<comment><USER20> Much of the point of "first principles" is that there aren't very many of them. If you have any trouble at all remembering them, you can be fairly certain that you have not trimmed enough.

</comment></comment></comment><comment><USER21> Ah, got to love the subscription pop-up with a close button that doesn't work. A timeless web design principle.

Aside from that, when will we get past the requirement for data structure knowledge for positions that center around web design? Data structure knowledge is available at my fingertips throughout the work day. Why must I memorize implementation boilerplate for an interview?

</comment><comment><USER22> I tried interviewing with Asana and they rejected me on the basis that I didn't have a computer science degree. For the record, I've built apps that have generated millions in revenue and I have many years of experience. If they are trying to be meritocratic and community friendly with this, they should change that aspect of their culture to reflect that.

<comment><USER23> Can you blame them? That CS degree provides essential knowledge when it comes to solving some of the world's most complex problems: to-do lists.

</comment></comment><comment><USER24> From the guide: "we ask candidates not to compile or run their code during this exercise, _and not to refer to online resources_ "

Seriously? You don't allow referring to online resources? Do you also unplug the internet connection for all of your existing programmers so they don't refer to online resources?

The whole point of the interview is to see how you would perform at your job at the first place, creating an artificial job for an interview where you swap words in the array or solving some other stupid quiz + disconnecting you from online resources is just plain stupid in my opinion.

<comment><USER25> The very next sentence there is "Our goal is not to simulate day-to-day software development", so no, they probably do not unplug the internet connection for the existing programmers.

<comment><USER24> Why don't they ask them to play soccer on the interview or see how fast a person can run, if they don't care if the candidate will perform well in their day-to-day software development?

</comment></comment></comment><comment><USER26> I did an extensive set of interviews with Asana and did not enjoy the experience. After an initial screen, I was required to complete a fairly extensive take home data science problem that involved querying an AWS-hosted database, fitting a predictive model on that test data, then writing a report summarizing which factors in my model were most important and what else I might do.

Considering that (a) some of the data in the database was erroneous, but when I alerted them about it they took a long time to respond and I had to just hack a work around, and (b) it was a huge time sink in an otherwise busy week for me, I was very proud of my solution.

It was a simple random forest model, with no exploration of optimizing the parameters, and some simple entropy metrics for feature importance. I wrote nicely encapsulated SQLAlchemy for the database side, then modular sklearn and pandas code for the model fits and plots, including calibration curves in addition to accuracy. I put it all together into an 8 page TeX write up with plots.

I got virtually no feedback, then after a long time I was asked to have a technical phone interview reviewing my submission that was with two data scientists simultaneously.

They barely asked me anything about my code design. They asked a few questions about my choice of accuracy measures and entropy scores, but it was extremely hard to understand what they wanted to hear (why do companies still think that a multi-party phone call is a good use of time??).

It was a major instance of "guess the teacher's password" which was a huge turnoff for me.

Then they asked very vague, high-level questions about designing a news-feed- like interface, and how might you determine which articles are newsworthy on an individual basis. Again, super vague. I threw out all kinds of ideas about seasonality, correlation to major events, properties of your network, ... But nothing seemed interesting to them at all. They clearly wanted someone to recite some well-known stuff Facebook already used, but none of that was part of the job ad or even related at all. It was bizarre.

After that, another mysterious block of time went by with no feedback, then I got rejected with no explanation.

Later I learned that Asana has pivoted to focus on providing Agile junk for enterprise project management, so I was relieved to have dodged that bullet, but it was still a vague and time-wasting interview process, with so much magic "guess the teacher's password" nonsense.

<comment><USER11> Hi there -- I'm really sorry that you had such a negative experience. It sounds like we didn't honor how much time you'd put into the challenge, and that sucks.

I'd be happy to share more feedback with you if you're still interested, though it seems like you've moved on happily. Feel free to reach out to firstname.lastname@example.com and we can talk more.

Regardless, best of luck where you are now.

</comment></comment><comment><USER27> > Our goal is not to simulate day-to-day software development...

I don't understand this. Why do they not want to see how well a candidate performs the tasks that they will be expected to perform on the job? Does this not result in them selecting for the wrong set of skills/knowledge?

<comment><USER28> Plus they're using this goal to justify not letting you run your code during the interview, which prohibits a "try it and see" problem-solving approach. Asana engineering team, what's wrong with "try it and see"?

<comment><USER29> You're kidding, right?

<comment><USER28> Not kidding! "Try it and see" is a legitimate problem-solving approach.

</comment></comment></comment></comment><comment><USER30> Much more interesting is the guide that this blog post mentions at [https://asana.com/eng/interview-guide](https://asana.com/eng/interview- guide).

<comment><USER31> I don't really see whats interesting about this either way. Lots of places you interview at tell you what the interview is going to be like and what you are expected to be familiar with. This is just 'write code and we'll be testing you on data structures and algorithms!'

There's some flowery language there about having a genuine desire to want to hire you unlike those 'other evil companies!'... sounds like the same shit pretty much every other company does to me.

<comment><USER32> I had also the same impression. I think one of the best approaches is let the best engineers at the company go through same interview process. If they can't get pass through the hiring bar of the company, then maybe that company should re-think their hiring process.

<comment><USER33> My current company has a very similar interview style, and I later learned that I was pretty close to not being hired because I didn't do quite as well as one interviewer wanted on a coding challenge: I ran out of time. But what I also learned is that the interviewer had never solved the problem in the language I used!

I had one of our most senior engineers, who has worked in this language's compiler, to try to solve the exercise. Instead of 40 minutes, it took him three hours!

If a candidate is going to interview in a language, for the love of god, have as a prereq that the interviewer is actually capable of doing the exercise in that language.

</comment></comment></comment></comment><comment><USER34> I had an onsite interview for a new grad engineering position at Asana recently. It's true that they test you on technical problems you don't know the answer to; sometimes it seems like they tested me on technical problems that had no answer. One of their interviewers, who was in charge of both conducting a one-on-one with me and explaining the programming questions to me, was very friendly but also had a hard time clarifying any of his questions for me. I didn't really understand him and it was obvious from his facial expressions that he believed that his explanations had sufficed from the very beginning. The questions were either too vague and could be approached from many different directions or were so specific that it was obvious the right solution would have to be found in an epiphany-like "aha!" moment of mathematical understanding. I was able to answer and program most of the questions. I have to say that I was really happy to receive feedback following my interview, which no other company did. My advice to Asana: Don't let any one interviewer dominate the experience of the interviewee (especially if you may have suspicious that the interviewer may be overly didactic or has difficulty explaining things.) Of course, that's just my experience. I ended up finding a good position somewhere else and think Asana's interviews were some of the best ones I had the honor of failing.

<comment><USER32> > Don't let any one interviewer dominate the experience of the interviewee > (especially if you may have suspicious that the interviewer may be overly > didactic or has difficulty explaining things.)

I think this a common problem. Many companies let a single interviewer has huge influence on hiring decisions. What if the interviewer himself/herself had some bias that s/he wasn't aware of?

</comment></comment><comment><USER35> Sigh, more marketing. Sorry, but at the end of the day any company that does technical interviews evaluates candidates the same ways and asks the same type of questions, having an interview guide that says things like "Instead, let's open a dialogue. Let's solve problems together and see what we can learn in the process. Let's have fun!" is just trying to get more people to apply.

And I'm not slamming algorithms or technical interviews, but its time companies stop trying to dress themselves and say it how it is.

<comment><USER11> JFYI, that's not accurate. We've been sending this to candidates for months; the genuine impetus was to try to put all candidates on a more level and accurate playing field so that we can make better hires.

That's not to say it's not self-serving; of course we benefit from making more/better hires. But it's not just marketing.

</comment></comment><comment><USER36> I had a really stellar interview experience at Asana (and, full disclosure, I didn't get an offer).

What really stood out was the pages of notes that the recruiter sent me before inviting me to apply again in a few months. I had just been through many on- site interviews at many companies, and no one came close to providing the level of feedback that Asana did. The document that I was sent can't have been too far off from the unedited notes that the interviewers shared with each other in their debrief. It really spoke to Asana's commitment to transparency and helping develop people - even those they didn't want to hire. I'm happy where I am now, but based on this experience, I would absolutely apply again in the future.

</comment><comment><USER5> I appreciate the sentiment behind documents like this, but, Asana, you can do better. When you do, you'll find it gets easier to hire people, and, perhaps counterintuitively, the quality of your hires will go up.

Specifically:

It's clear from the tone that you're trying to mitigate the hostility and unfriendliness of the conventional programmer interview. Great! But you need to do more than superficially adjust your tone. What this document describes is literally the circa-1999 software developer interview, in almost _every_ detail --- the fuzzily described coding question, the "algorithm and data structures" interview, the design review.

Everyone has heard of interviews that pointlessly refuse candidates the opportunity to consult Internet references, _like every working programmer does every time they code anything ever_. But your process goes a step further: you won't even allow candidates to _compile their code_. How can this possibly be helpful to your process?

The most alienating and hostile aspect of the conventional job interview is on-the-spot whiteboard programming. You shouldn't have programmers write code in interviews at all, if you can avoid it; instead, take a week or two and design programming questions that candidates can do at home, on their own schedule, in their own surroundings.

But if you're going to make people code in an environment that is utterly unlike the one professionals actually work in, the onus is on you to do everything you possibly can to mitigate the performance penalty you're imposing. Why not, instead of coming up with crazy rules like "no running your own code allowed", point your creativity in the opposite direction and find ways to get candidates to be more at ease with writing code with someone looking over their shoulder?

Here are some things you can do _right now_ to make your interviewing guide actually helpful to candidates:

* Provide sample questions. They do not need to be the ones you're asking in real interviews (although: if they are truly good questions, they could be!), but they should be close enough that a candidate would have no business being surprised by the real ones.

* Provide a detailed breakdown of your interviewing process. Do you phone screen? How many times? Who staffs the phone screens? What kinds of questions get asked on them? Who delivers the in-person interviews? How long do they last? These are some of the questions real candidates have about interview processes. I don't understand why more companies don't just answer them up front.

* Provide reference material for candidates. Don't point them to other people's interviewing guides! You know your jobs better than anyone else does... right? How about instead: what are the most popular books on the shelves at your team? (Bonus points: _buy those books for candidates_ ). What are some Github repositories you think represent really well-engineered software? What are some examples of really hard problems your team is still grappling with?

I hired for years and years with a battery of over-the-top technical questions and a rolodex of personal contacts. Then my team and I had a crazy idea: we opened our whole interview process up, standardized it, and took pains to make it understandable to people with no experience in our field. What we learned was that there is a huge amount of underutilized talent out there that can't (because it's locked out due to jargon and poorly described requirements) or won't (because it's denied social permission) apply for jobs unless you go out of your way to bring them in. _Many of these people are better than you are_. At least, they were for me. Stop bloodying your forehead against the wall competing with Facebook and Google for people who --- if they can navigate the process you describe --- can get an offer from those companies any time they want.

<comment><USER37> >> The most alienating and hostile aspect of the conventional job interview is on-the-spot whiteboard programming. You shouldn't have programmers write code in interviews at all, if you can avoid it; instead, take a week or two and design programming questions that candidates can do at home, on their own schedule, in their own surroundings.

Phenomenally good advice. I wonder, and I don't mean this to be a loaded question because I really don't know the answer: do other practitioners in other highly-skilled disciplines have to dance these sorts of dances to get hired? Does a doctor have to diagnose on the spot? Does an architect have to design a building on a whiteboard? Do they make a lawyer stand up in front of a group of partners and argue some case off the top of his head? Perhaps they do. I really don't know. But it seems to me that basically professional experience counts for little other than to keep the resume out of the trash folder.

<comment><USER38> Don't know about the architect, or a lawyer, but doctors do get real-life questions... although probably not the ones with years of experience and more letters in the title than in the name. A bigger difference though is that lawyers and doctors have to pass an exam to practice their profession, which already excludes a lot of people. Anyone can be a programmer.

<comment><USER37> >> Anyone can be a programmer.

Anyone can be a doctor or lawyer too. I know what you mean, I think, but I don't know if I buy the distinction. There is a formal pass-the-bar testing event for lawyers. For nurses and I believe doctors there are boards. Same basic purpose AFAIK. They take these tests when they are just entering the profession. How meaningful are they years later, compared with the experience gained in the interim? My wife is a registered nurse working in cardiac critical care for seven years. If she interviews for a new job with that employment record behind her they aren't going to ask her what an aorta is, which is sort of the equivalent of what Asana is talking about doing here (and what everyone does, to be fair).

So you seem to be saying that a professional nurse, as an example, can be trusted to know the basics after seven years of work, because he or she was required to take a hard test on graduation. But a programmer with seven years of experience must prove that he or she knows what a binary tree does? It's also worth pointing out that lawyers can get people jailed or cause them to lose their property. Doctors and nurses can kill them. So can we, occasionally, but it's rare.

The most effective interviewing technique, as far as I am concerned is to send the candidate out for lunch with a few of your engineers and tell them to find out whether he knows what he's doing. You spend an hour talking software with some people and it's awful hard to fake knowing your stuff.

<comment><USER39> "But a programmer with seven years of experience must prove that he or she knows what a binary tree does?"

you'd be surprised at how many programmers with seven years experience have no freakin clue what a binary tree does!

There is a reason fizzbuzz is phenomenal filter.

<comment><USER40> fizzbuzz filters for candidates who a) can do a trivial programming task in a unrealistic high-pressure, high-stakes environment, or b) signal membership in your group via memorization of hazing rituals.

fizzbuzz does not filter for programmers capable of doing original, thoughtful work in a realistic work environment.

</comment></comment></comment></comment></comment></comment><comment><USER41> Why does everyone love algorithms and data structures of all the CS topics so much? I would like to be asked about covariance and contravariance, LALR parsing or some basic statistics for once.

But more importantly, I would love to be asked about CS topics that arise every day in development: code organization. How many times do you get a new requirement that makes you throw all previous assumptions (that an architecture was naively built upon) out of the window? When it turns out that module A and B, which were completely different and didn't even know about each other, now need each other's data? Yes, this situation arises when original architecture wasn't thought through enough — and we all were guilty of this at one point or another.

Now, what a developer does in that situation is much more important than whether he remembers what complexity what kind of hash table (with all the chaining and hashing types) is. Does he just hack it so it works, creating a lot of fun for future maintainer? Does he decide to spend 2 days to refactor the whole system into a new architecture? Or does he find a balance somewhere in between?

</comment><comment><USER42> i dont understand why you would even listen to them, their website is such a piece of shit- terrible performance, terrible ui. maybe their infrastructure is good, but i can tell you they absolutely suck at frontend js.

</comment><comment><USER43> > We design our interview questions to see how engineers work through > technical problems they don't know the answer to yet.

That's the way to do it, I think. In my own technical interviews, I pose (relatively) simple questions that require some problem analysis, a strategy discussion, and then some coding and testing, with a goal of testing aptitude for basic programming abilities like modularization, indirection, recursion, defensive programming, unit testing, etc. I keep things interactive and collaborative and see how much the candidate can do for themselves.

<comment><USER26> The problem is that Asana seems to have preconceived ideas of what answers are supposed to look like, but the questions are vague and open-ended enough that even very good candidates can give good answers that simply diverge from the manner of thinking that the Asana question designer had in mind.

If the question has a well-defined answer, then this is good. If you are asking questions that the candidate "doesn't know the answer to" merely as a parochial side effect of the question's vagueness and the vast space of possible good approaches, then you're really only screening for people who happen to think about things the same way you already do, and thus are good at guessing what you want to hear.

I'd argue that this is very bad in terms of diversity of thought.

<comment><USER11> Hi there! That sounds bad. Could you let me know what's giving you the impression that that's Asana's goal?

We really try to explicitly avoid that kind of interview evaluation, and put strong emphasis on Communication, User empathy, and Learning, per the guide. But definitely "did they say the right answer?" is an easy trap to fall into so its entirely possible that some interviewers are doing it -- would love any concrete feedback you could give to help us avoid it in the future.

<comment><USER26> The more concrete feedback is in the previous post (you commented on that one too). But I will elaborate here:

On 8/4/15, I received a message from an Asana representative via Stack Overflow Careers. After a few back-and-forths discussing specifics about whether I was a good fit, I then agree to do the take-home test.

I received the take home test on 8/7/15\. I emailed back on 8/8/15 with a verifiable error in a timestamp column of an AWS-hosted Postgres database that was configured with some test data (data resembling some certain kinds of user data for modeling what an "engaged" user is, and what factors predict when a user will be "engaged"). I included code which could be run to demonstrate the erroneous data.

On 8/9/15 I wrote in again stating that I had created a workaround for the erroneous timestamp data, since the only way I could complete the exam was to do it on those particular days (I couldn't wait around for the exam data to be fixed).

I submitted my solution on 8/10/15\. I got an email on 8/11/15 with a note from someone in engineering apologizing for the timestamp data error, but also saying it shouldn't affect my solution. The recruiter who sent that email also said that my submission was currently being evaluated.

Then I waited a week before hearing anything. On 8/18/15 I got a response apologizing for the delay and saying that I was invited for the next round interview.

The email said I would be speaking with a person named Jack (maybe you?) a few days later (8/21/15 at 4:00 pm EST). But that call actually included two data scientists over one conference call line.

Both interviewers effectively made no comment on my software choices. In fact, when I spoke about how I cared about software design and best practices, even when working on a rapid prototype, it actually sounded as if the interviewers thought this was a bad thing and there was some awkward silence. I brought up examples of how I had worked in a very fast paced environment before (quant finance) and my team had learned some hard lessons that the naive approach of letting data scientists just write scripts for ad hoc modeling, assuming that engineering will "productionize" it later, tends to lead to some bad failure cases, and that it's far more efficient over time to simply require data scientists to construct rapid prototypes, even from the first line of exploratory, ad-hoc code, that adhere to many best practices and are only a short distance from "production" even in their first version.

Then they asked me some vague and hard-to-decipher-over-a-conference-call questions about how to measure the accuracy for the random forest model I had fitted, and about my conclusions regarding which predictors were most efficacious. Despite having used random forests for published research results and even having taught part of a course on random forests when I was a grad student, I could not make heads nor tails of what exact accuracy metric the interviewer was fishing for. I am sure that if such a question was asked in- person, with some pen and paper, or something where it's not just the vague descriptions of some stranger I've never met before, then we could have sorted it out. But the communication was just too poor over the conference call for this kind of question.

Given that I had to solve the problem in my spare time while conducting all the other stuff in my life, I felt it was quite reasonable for me to take a very conservative approach: fit a very simple model, don't waste time chasing down parameter optimizations (like depth of the trees or some huge set of features). Just walk through some very straightforward analysis, use some straightforward features, produce some common diagnostic curves (which showed a huge bias in the data labels -- almost all example users were not "engaged" ), and draw only conservative conclusions (e.g. with such severe bias in the toy data set, it's pretty hard to conclusively say anything, so don't pretend you can say more than you really can, don't recommend strong conclusions, and leave it at that). The point is to show basically a mock-up of the end-to-end workflow, from querying the data, to constructing the features, to fitting the model, to assessing the fit. The point is clearly not to do that in some kind of insanely accurate way when you're talking about a busy adult doing it in their spare time over a few days.

The two interviewers had some gripes with the specifics of my accuracy measures (which seemed really misplaced, again for an analysis done in a busy adult's spare time using erroneous toy data).

<comment><USER26> After that, the interviewers asked the questions about how to develop a news feed ranking algorithm at a super vague, high level. I spoke about how you would need to account for seasonality or cyclic effects -- e.g. election news would clearly be ranked higher in newsworthiness when approaching important elections, or the same idea for sports-related articles, etc. I talked about trying to determine which news articles are the most clicked-on by peers in your network, possibly using some centrality measures to rate certain users more as "trend setters" and use their news viewing habits as guides for what to show to others.

I was actually fairly detailed in my description of some math ideas for these things, but the whole conversation sounded like someone sucked the air out of it. The interviewers kept trying to get me to talk more specifically about aspects of the newsfeed that actually occur in Facebook's newsfeed. When I told them I don't have a Facebook account and don't know what the modern version of the newsfeed does (which is true, I don't), they sounded like they just lost all interest in talking to me. My hunch was that they wanted me to possibly talk about A/B testing, but this is kind of silly. They definitely didn't ask me about A/B testing. It was like they wanted me to guess that phrase. Plus, at least for frequentist A/B testing, there are good reasons to believe a lot of it is junk science and a lot of applied mathematicians would not consider this a reasonable idea at all. I guess I could have talked a little about Bayesian A/B testing, but my mind associated their problem with network modeling and seasonality effect modeling, not A/B testing. (I can't be sure they were focused on A/B testing -- it's just what I independently thought after the fact when struggling to understand the outcome since no one gave any feedback).

Overall, I could tell it went badly, but I could not understand what the two interviewers were trying to get me to say. As someone who has worked on a lot of math modeling problems, from undergrad and on through grad school, I thought my way of breaking down and describing ideas for the newsfeed example was perfectly on-point and technically useful. To boot, the job I was interviewing for did not (at least as it was explained to me) have anything to do with ranking problems, A/B testing, or newsfeed-like work at all.

That was on 8/21/15\. I then heard no response of any kind, until 8/28/15 when I got a form letter rejection email that simply said at that point, Asana did not want to continue the process, and gave no further details.

From start to finish it went from 8/4 to 8/28, so almost a month. I scrambled to put in a lot of hours to solve the take-home test in my spare time over a short window, and then went through two different full week long periods of silence (one after my code test was being reviewed, and one after the vague/weird two-on-one phone interview), only to receive no feed back at all on my software solution, limited and tangential feedback on my actual data science approach (feedback which didn't seem at all appropriate for something a busy adult would put together over a couple of days), and no feedback at all about the decision to reject me based on the interviews.

The overall experience left me feeling like Asana asks very vague questions and reserves the right to be dissatisfied if you don't identify the magic answer to the vague question. It also made me feel that Asana does not act in a timely manner to review code submissions or to provide interview feedback, even though Asana did require me (despite being busy outside of interviews) to complete a code test in a timely manner. It also sounded like Asana might have some data science employees who act a bit like "gatekeepers" in the interview process -- they felt a need to assert that they are better than the candidate, even if it means bringing some discussion up about specific accuracy criteria or something when it may not really be very appropriate for a quick solution to a poorly specified problem.

It's a bit like someone talking about Haskell programming for an interview, successfully solving some Monad problems in a quick way given the time constraints, and then getting grilled about unification algorithms in the Hindley-Milner type system. It's just to let the existing employee who is conducting the interview feel superior and act like it is some great filter on the incoming talent pool, when really it's mostly unrelated minutiae.

As I mentioned in the other comment, I later learned the extent to which Asana supports Agile-focused systems for enterprise project management, and this actually saddened me a lot. I always liked Asana because it embodied a type of minimalist efficiency that is fundamentally incompatible with the bureaucratic wastefulness of Agile/Scrum/Kanban/"lean" buzzword systems. I had high hopes that Asana would not be just another one of those cargo cult management junk systems, and maybe it still will avoid that fate, but agreeing to support Agile doesn't bode well.

So ultimately it was a good thing I was rejected, though I do not feel it was a fair reflection of my engineering effort on the exam, and I certainly don't feel that the evaluation was done in a way that showed respect for the amount of time and effort that I took to complete the task.

<comment><USER11> Yep, I'm that Jack. I remember you now. Thanks for the clear picture of what it's like to be on the candidate side. Efficiency is clearly a goal, and we clearly failed here given that it took us a week to get back to you after the phone interivew. I do think your interview was an outlier in that regard, but that doesn't excuse it.

Re: the questions themselves, although I don't agree with your characterization of what's going on or what we're looking for, I definitely think there's a lot of room to improve on our data-science screening. I'll send you an email with more re: what specifically came up in your interview that made us reject.

Again, thanks for taking the time to share this really explicit feedback.

(For the record, I don't really know what you're referring to re: Asana and Agile.)

<comment><USER26> Hopefully this thread's not too stale yet to escape notice.

I just wanted to add that the user above, Jack, absolutely made good on what he said.

He sent me some very well-written, extremely professional, and constructive feedback about my interview process. I am able to see a lot of things I can improve and it will help me for future interviews. I think it also highlights some things about the process that Asana can improve, and by all evidence of Jack's sincerity in the feedback, I believe Asana is very interested in ways of improving.

Don't let anyone say that _all_ I do on Hacker News is grumble about open-plan offices... in this case I am expressing my sincere gratitude and appreciation for Jack's feedback.

If I had received this kind of response in a timely manner when Asana decided not to continue the interview process with me, I would have walked away with a significant positive feeling about interviewing with them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> I have interviewed (phone screened) at Asana. It was delightful. I really liked the people I met there and enjoyed the problem I worked through over the phone. It really did feel collaborative and like we were solving a problem together just as software engineers do when they're not in this artificially combative environment we often create when interviewing.

Regarding the problem, I didn't have the best approach out of the gate. In fact, I had a vague memory of the right approach ("I seem to recall it uses two data structures, and if I really stretch I think it was X and Y, but I don't remember the details.") That made it harder to get to the final solution. The interviewer was very good at at talking things through with me in a way that didn't seem like they were frustrated or otherwise grumpy that I didn't know this particular problem cold. They apparently thought the results were encouraging enough to move to an onsite, but I got an offer from my current employer (where I am working with close personal friends) and had to pass on the chance to find out what that would be like.

All in all I think Asana is probably a great place to work. I also like the product, although it seems like you need a whole team to adopt it to make it sticky.

</comment><comment><USER45> I find it funny that startups only implement these ridiculous hiring practices _after_ they start to grow. Imagine if the founders had to quiz each other on algorithms before they agreed to do a startup in the first place. The first few hires at a startup are arguably the most important, yet they don't go through the bullshit that later stage startups put potential employees do.

<comment><USER11> > I find it funny that startups only implement these ridiculous hiring > practices after they start to grow

Hmm, I'm curious what you're assuming! At Asana, at least, our first hires went through many of the same questions that interviewers today go through, but we were just a lot less systematic about our evaluation and less scrupulous about accidentally testing for knowledge/context rather than ability. The intention of this guide was to make the interview /less/ bullshit-y, by giving people enough grounding to not be thrown off by unexpressed expectations.

</comment></comment><comment><USER46> Their subscription pop up at the bottom of the page with a close button that does nothing only makes me sure I don't want to work for them.

</comment><comment><USER47> I like the idea behind this but the actual guide is pretty thin:

[https://asana.com/eng/interview-guide](https://asana.com/eng/interview-guide)

would be great to see a more detailed guide covering the concepts they like to see master of and problem solving skills they are looking for.

</comment><comment><USER48> Disappointing. The links to Triplebyte and Stripe are far more informative.

<comment><USER11> Thanks for the feedback! What did you learn from those that yo u didn't see in the Asana one?

\- Jack from asana

</comment></comment><comment><USER49> How do these question align with the work Asana is doing? Side note: The blog site performance degrades as you keep scrolling down.

</comment><comment><USER50> Maybe you could hire someone that will design you a mobile website?

I'm not installing your app on my phone...

</comment><comment><USER51> There are many different types of engineers This guide is for software engineers

</comment><comment><USER52> this place has so much cash, they may as well hire trial by fire, create an onboarding experience for serious candidates, morph them to your liking or let them go, stop guessing with goofball interview theater.

</comment><comment><USER53> \- smart

\- gets things done

\- able to actively engage in discussion about software development

\- works hard

\- wants to work here doing this job

\- loves to learn

\- not overly dogmatic

The rest, meh.</comment>


TechLaunch Accelerator Applications Open (tri-state area) - <AUTHOR> http://techlaunch.com/apply/

<comment><USER2> I can't recommend this enough. Techlaunch helps aspiring entrepreneurs to transform their idea into a viable product.

</comment><comment><USER3> Highly recommended program. Jersey represent!</comment>


Tesla Announces Offerings of Common Stock and Convertible Senior Notes - <AUTHOR> http://ir.tesla.com/releasedetail.cfm?ReleaseID=1017594 <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=13880102](https://news.ycombinator.com/item?id=13880102)</comment>


Can Vector Supercomputing Be Revived? - <AUTHOR> https://www.nextplatform.com/2017/10/26/can-vector-supercomputing-revived/ <comment><AUTHOR> Better programmable gather/scatter (like described here: [https://www.nextplatform.com/2017/09/14/shedding-light- dark-...](https://www.nextplatform.com/2017/09/14/shedding-light-dark- bandwidth/)) can definitely open up a wider range of applications to vectorization.

<comment><USER2> What do you mean by programmable gather/scatter. GPUs already do efficient gather and scatter operations. I think the knight's landing AVX-512 even has efficient gather and scatter.

<comment><USER3> Read the linked article, and the paper linked from there. Basically the idea is that gather/scatter can be very inefficient from a cache and BW perspective. In the worst case you're using only a single element per cache line. So the idea is to "move" the scatter/gather engine to the memory controller, and pack the vectors already in the cache rather than in the register file.

Will it work in reality? No idea, but it's an interesting idea certainly worth exploring.

</comment></comment></comment><comment><USER3> More generally, I'd really like "real" vector ISA's to become mainstream [1]. We've suffered from the scourge of packed-SIMD long enough, thank you very much.

ARM SVE, RISC-V V extension, and indeed to an extent AVX-512 look pretty good.

[1] Not saying that every chip must dedicate a huge portion of the die area to a monster vector unit, I'd just like the ISA to be there so programmers and compilers can target it.

</comment><comment><USER4> It's very very very tough to compete with the economies of scale and ecosystem with modern GPU computing.

Vector supercomputing doesn't need to be "revived", it is already here.

<comment><AUTHOR> Depends. Right now they're in two different spaces. One still hanging on to graphics/gaming, the other coming from dense compute space. We'll see how long it takes them to converge.

<comment><USER4> For all intents and purposes, they've already converged: the underlying GPU microarchitectures have been fairly general purpose SIMD-ish for a long time now.

And (as one example), CUDA happily runs on any gamer "consumer" GPU.

</comment></comment></comment><comment><USER5> Those mining memory-bandwidth-hard cryptocurrencies, like zcash, may consider evaluating these. According to the article, they'll have 1200 GB/s, vs 900 GB/s for the top nVidia Volta card. (Of course, it's quite likely that this increase in memory bandwidth isn't worth it for reasons of cost, ISA suitability for the particularities of Equihash, etc., but hard to say without a lot of thinking-through.)

</comment><comment><USER6> I found it fascinating that NEC's new vector machine is now vector accelerator's on PCIe cards. First, this reminds me of how early vector processors were add-ons to existing processors. I wonder if that changes the programming model (compared to the sx-9/ace or cray j90s) and how.

<comment><USER7> And judging by Intel's Xeon Phi story, the next iteration from NEC will again be a full processor...

</comment></comment><comment><USER8> Vector engines really suffer from numerical stability problems, so for certain kinds of problems, you'll get wrong answers (but at least you'll get them fast).

<comment><USER9> Citation? They are generally IEEE compliant; there can be some differences in denorm handling?

<comment><USER8> IEEE compliance only gives you guarantees on individual arithmetic operations. Vector machines take away control over the order in which operations are performed, but floating-point addition is not associative. Changing the order in which the terms of a sum are added may lead to vastly different results, due to, e.g., truncation.</comment></comment></comment>


Ask HN: What is the general manner to fork a well-known open-source project? - <AUTHOR> I need to add some functionalities to a well-known open source project(GPL licensed) which is unlikely merged to the project as the functions is very limited to certain people.
So I would like to fork it first then add these features.
My concerns are
1. Should I contact the authors to get their permission? 2. Can I rename the forked project <comment><USER2> You don't _have_ to contact the authors to get their permission to fork the project. This is explicitly permitted by -- and, in fact, one of the primary _features_ of -- the GPL.

I would encourage you to contact them, though. Let them know about the changes you're planning to make and ask if they would be willing to consider merging your features in.

The best possible outcome is that they _are_ willing, which means you avoid the overhead of maintaining a separate fork!

If, for whatever reason, they aren't interested in and don't want to merge your features in, you fork the project and continue on with your plan. You've really got nothing to lose!

(Yes, you can rename your fork and, in fact, you absolutely _should_ rename it.)

</comment><comment><USER3> To address your doubts:

1\. You can always fork an open source project and as long as you republish the changes as open source, there's no problem at all. For some licenses, you must cite the original authors as well (GPL or Apache as examples).

2\. You can rename the project, as log as you put links to original authors and project.

</comment><comment><USER4> "which is unlikely merged to the project as the functions is very limited to certain people."

you should fork, implement the change and create a pull request first. Dont assume that they wont implement it. they might do it.</comment>


Reasons to Drop NDAs - <AUTHOR> http://www.contrast.ie/blog/five-reasons-to-drop-ndas/ <comment><USER2> It all depends on what one means by "nda."

If it means the piece of paper people ask you to sign before giving you a pitch, the author's points are largely well taken.

On the other hand:

1\. If a company fails to have its employees sign nda's, it potentially jeopardizes its trade secrets (to protect something as a trade secret, an employer must show that it took reasonable steps to treat the proprietary information as trade secret information and having employees sign nda's is a key component of this).

2\. If a supposed suitor approaches you about buying your business, and you fail to sign an nda, then the information disclosed in the buying process - which can include your most intimate and valuable business techniques and plans - can potentially be lifted by the would-be suitor and used competitively against you after the suitor abandons the deal.

3\. If you attempt to negotiate a potential strategic partnership, and you trade proprietary information relating to what would be a valuable joint venture, and do so without an nda, then, again, the prospective partner can betray you and use your valuable information against you.

4\. If you let your sales people develop all of a company's leads in their own name and using their own resources, without confidentiality agreements (i.e., nda's) acknowledging that the customer information is valuable proprietary and confidential information belonging to the company, you leave your company exposed to having its customers raided without any legal recourse. Are sales people prone to do this? Absolutely. They tend to think of customers as belonging to them and not to the company. Without the basic legal protections afforded by nda's, a company runs serious risks of losing its customer base to those who might chose to raid it.

5\. Other examples could be multiplied, almost ad infinitem, depending on the particular business context, of how it is positively naive and, indeed, stupid, to proceed in various business dealings without benefit of the legal protections needed to protect confidential and proprietary information, that is, without an nda.

While I think the author's basic points make perfect sense in the fast and loose world of "pitches," they are not generally applicable in the world of startups. As long as there are business dealings in which any party has valuable information that it wants to keep secret, nda's will continue to serve valuable purposes and are necessary and, indeed, indispensable to the transactions involved. This is from the perspective of one who has specialized in business startup law in Silicon Valley for the past quarter century.

</comment><comment><USER3> [Note: This is the perspective of a Product Manager & Technology guy, not a lawyer]

NDAs are not for "hey we have an idea we'd like you to hear about" and they are frequently misused for that. This just sets everyone up for legal issues and hurt feelings later -- when you tell somebody an idea they may have already been working on it -- you then end up in a prior art mess.

NDAs are not something you should ever put into the CRM workflow for your sales people as a measured objective, i.e. I've seen quotas of, "Get 20 leads to sign an NDA, get 10 POCs, get 5 sales." If you can't tell me about the features of your product without an NDA I'm not going to understand the product after I sign it.

NDAs make sense if you have an established relationship and you're working on something pre-patent or trade secret work together. NDAs also make sense if you're hiring a consultant to come in and help with marketing, business planning, etc.

<comment><USER4> Guy Kawasaki has a great article - [http://www.thestartuplawyer.com/venture- capital/guy-kawasaki...](http://www.thestartuplawyer.com/venture-capital/guy- kawasaki-on-ndas)

</comment></comment><comment><USER5> This is the best point: "they all say what they want to, whether or not they're under an NDA"

I've got a friend at a particular large game studio, working on a particularly popular Xbox 360 title. He is extremely tight-lipped about his work projects. It certainly isn't because of his NDA because we have builds of the game in our test labs. My job enables me to walk in and see them anytime if I really wanted. He keeps his mouth shut and I don't go prying simply because it makes us feel good.

Surprises are often a competitive advantage, especially in gaming. He doesn't want to ruin the fun of the big reveal for himself, his co-workers, the fans, or anyone else. The NDA is a formality; if management ever has to remind them of it, everyone is saddened that someone is spoiling the competitive and customer-pleasing fun.

</comment><comment><USER6> I wish this all held true for pre-patent work.

</comment><comment><USER7> I was told by patent lawyers that as soon as you expose your product to those not under non-disclosure (and a piece of signed paper is the best way to prove those exposed are under non-disclosure), the clock starts ticking on your window to file your provisional application.

<comment><AUTHOR> Clock indeed does start ticking. I remember some patent lawyers I talked to during college saying you had a year after disclosure to get your application together. The sooner the better, obviously.

<comment><USER7> yes, that's how I was trained as well.

</comment></comment></comment><comment><USER4> All you need to know about the NDA today - [http://www.docstoc.com/docs/16875061/The-Risks-and- Current-P...](http://www.docstoc.com/docs/16875061/The-Risks-and-Current- Position-Of-The-Non-Disclosure-Agreement)</comment>


Ask YC: What is/are your favorite book(s)? - <AUTHOR>

What is everyone reading these days besides web stuff? It would be great to put together a list   specific to the HN community. Fee free to include non-programming books. <comment><USER2> Also see:

<http://news.ycombinator.com/item?id=85840>

<http://news.ycombinator.com/item?id=56618>

<http://news.ycombinator.com/item?id=156137>

<http://news.ycombinator.com/item?id=45082>

<http://news.ycombinator.com/item?id=41532>

There are also many threads regarding books on specific topics(machine learning, parenting(as hackers), AI, etc.). You can check <http://searchyc.com/> to find them.

</comment><comment><USER3> Latest books:

_Made to Stick_, by Chip Heath and Dan Heath, about what makes some ideas memorable and others forgettable. Urban legends, for example, propagate quickly on a vast scale despite having no marketing budget.

_Mathematical Thought from Ancient to Modern Times_, by Morris Kline. Did you know that Gauss proved, in a section of his doctoral thesis, that partial- fraction decomposition can always yield real coefficients?

</comment><comment><USER4> Guy Kawasaki's books are great.

I actually own 0 programming books and a bunch of books on business and entrepreneurship. As my good friend @dangrover says - sometimes the books are crap, but they motivate you to build stuff. And some of them might be great.

</comment><comment><USER5> 4 hour work week

:)

</comment><comment><USER6> My favorite fiction books are collections of short stories by Thomas Ligotti.

My favorite non-fiction books are books about consciousness studies and related issues. Favorites include Hofsteder's I Am A Strage Loop and David Chalmers The Conscious Mind. Oliver Sacks Musicaphilia is another recent favorite.</comment>