Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Keeping Your Company Asshole-Free (hackfwd.com)
48 points by andrewhyde on Oct 10, 2012 | hide | past | favorite | 53 comments


I was surprised to hear that they ask candidates to spend a couple of days working on a project, and then present that project to the company. That's a substantial time investment to ask someone to make on top of interviewing. If I was looking for work and every potential employer asked this of me, searching for a job could take weeks or months.


I agree. I am totally against hiring based on either stupid interview questions or tricky programming problems you will never see again. However, I think these guys take it a bit too far.

Maybe give them a project that only takes a couple of hours, just creating a simple module that does some very basic thing. Try to find out how they work rather than the final result.


The project/task really depends on the position applied for. All i can say is, that the project is usually discussed in advance and things can be worked out here. There are some fine folks here who were given projects which took only a couple of hours.


I have heard of companies paying a contract rate for 2 or 3 days to evaluate the candidate with the team. I wish they did that were I work now. The process here is just here's the new guy. ( now I bitching about my company, does that make me an ass-hole )


That's easy if you're currently not working, but not so much if you are. So you're screening out the employed.


Yea I know what you mean. I guess the point I was trying to make is it would be nice to have some influence from the team as we are the ones that will be working with them


Unless it's a take-home project in which case a person could do the work on the weekend. Which would also be a test of time management.


Yes, it would be. If you have good time management you would toss the project and keep looking for a position.

If a company I'm trying to find employment at wants me to take my interview home for the entire weekend, it sends all sorts of bad signs:

1. They don't see working on the weekend as unreasonable.

2. They don't value my time.

3. They aren't comfortable making hiring decisions and taking on risk. What other hard decisions aren't going to be made or are going to be made too late by this company?


To answer some of your questions:

1. Nobody here works on weekends. In fact, it's not well received, but tolerated. 2. Everybody's time is valued here and on a individual basis. 3. I'm glad i had influence on whom i will be working with on a daily basis and have not regretted it either. My workmates are awesome. Why should the management decide this all alone?

Everybody here is free to openly make reservations about the companies strategies and decisions.


Would your view change if they paid you a contractor's rate?


No, not at all. There's plenty of freelance work out there. If I wanted to freelance on my weekend, I wouldn't go job searching to do it.


I work during the week. Mornings, evenings and weekends I spend with my son. I don't let work interfere with that, nor do I let time with my son interfere with work (Mon to Fri, 8am to 7pm).

THAT is time management.


This. Give someone a project that should take no more than n hours to complete and give then n/2 days to do it, preferably including a weekend. That should be plenty of time for some folks, even employed.


That's how I did several interviews a while back. Before everyone somehow knew and loved BackboneJS, I took a functioning data-driven sorted table app, removed some of the model and controller code, left the view, and then asked them to complete it.

People either:

- Hacked together the internals to make it function, never considering any of the existing Backbone or _s functions

- Figured the existing code was a template, and rewrote it all now they thought it should've been (which can be good or bad)

- Learned enough of Backbone to complete the example with minimal code, but generally took longer because they had to learn the tool first

As a result, I got a great hire that knows when to refactor, when to leave existing code alone, and when to use AngularJS instead of Backbone!


Re slide 20: I recall reading that it's a myth that people who use the word "I" a lot are particularly self-absorbed. I recall it being suggested that the opposite might even be the case, perhaps because people were acknowledging the subjectivity of their opinions rather than presuming to present an indisputable statement of truth. I would look for a link, but the word "I" is hard to google.

Edit: I might be thinking of this, or something like it: http://www.businessinsider.com/what-does-your-use-of-the-wor...


It especially doesn't make sense because the usage of the word "I" in English is mostly because English is quite verbose.

Specifically, in most cases it's expected that you specify the subject of a sentence, which happens to be yourself a lot of the time. There's no such expectation in Japanese for example.


> acknowledging the subjectivity of their opinions rather than presuming to present an indisputable statement of truth.

I actually try hard to use I wherever possible for that particular reason. Saying "I think a message-passing style would be best for this" is more honest than "a message-passing style would be best for this".


I don't agree with this because whenever you write something it becomes obvious that it is your opinion, even if it shared by other people. If it is somebody else's opinion and not yours, you would naturally say "somebody else's said ..." If you want to emphasize that is just not your opinion, you can also say so. It is much more cumbersome to keep adding "I think" when it is implicit in the context.


When you're the boss, your opinions are often interpreted as decrees. Tempering your tone with qualifiers is necessary to get others to share their opinions honestly.


For some reason I took an immediate dislike towards the speaker, perhaps because I had previously read the article about programmers having a negative outlook (i.e. they're prone to being assholes) and his silly attempts to please the audience by making jabs at marketing and PR staff. How do you separate assholes from people you dislike for mostly unfair reasons?



Great to see this post here on Hacker News! I work at flaregames and wholeheartedly agree with Klaas, we're asshole-free and that's not an understatement. :)


I can't help but wonder why I had such a bad taste in my mouth after watching the whole vid. These cheap attempts at jabbing PR and Marketing people (not to mention naming names and Deutsche Telekom 'joke') came off to me as cheesy and badly thought.


I'm enormously glad that Apple board did absolutely not keep their company asshole-free.

Writing this on computer that asshole created.

And btw, I do not know a single Genius (with uppacase G) who is not an asshole, so go figure...


I've met Donald Knuth, Steve Wozniak and Tim Berners-Lee; none of them seemed like assholes to me. I can't think of anyone I've met, whom I respect but consider an asshole.

By "Genius (with uppacase G)" you mean an Apple Store employee?


You are most likely correct in this. All geniuses I have briefly met are indeed nice. But usually this is a mask. Wait until you get to know them really well. Or read their bioagraphies. Oh, and I don not write this in negative way, no-no, I just have observed that that's the way it is.


I think you are confusing genius with something else. I'm not sure what yet though. Possibly a badger.


And btw, I do not know a single Genius (with uppacase G) who is not an asshole, so go figure...

I do. That type of intelligence does not predetermine being an asshole. I think it's sad that people think that.


I think a lot of people have some longing or desire to be an asshole, or rather to get away with being an asshole. I suspect it is some show of their position in the social order (i.e. I am so important I can treat people with contempt and it doesn't matter). I think the organizational harm done by most assholes offsets any benefit from their other contributions, by a large factor.


I find it amazing how many people in a team don't share their insights, assets or experiences with the team. Why is that? Is it fear?


A saw a post on Twitter a couple of weeks ago from a guy who was in his last week of his job.

He claimed his employer was trying to "milk him" by asking for a handover guide for the next person taking over the role.

I think that people hold onto information for power, to protect their position and to give them leverage over their situation.


I think you're right. Like Klaas said in the presentation, such behavior usually is a reaction to the working ethics of the company. Screwing your colleagues (and the company) is rewarded by (lousy) management or management with a hidden agenda.


In my experience, which, granted is limited (3.5 years programming), one or two team members I work with very rarely share their insights.

In the case of these team members I think one comes down to fear of maybe looking daft in front of the rest of the team by saying something that they think might be wrong. The other can just be a sanctimonious prick and will ask people questions that they simply wont know the answer to, to show them up in front of the rest of the office.

So in my experience fear is certainly a factor holding a person back. However on the flip side a person lording his knowledge over other people but not sharing it in a useful way conducive to improving the general programming knowledge of the team.

They both harm the team but in different ways. I don't know how these two problems can be solved though. Maybe encouraging opinion from the people who fear sharing their points of view and being supportive of them would help.

I'm at a loss though with regards to the power-bitches that like to make people look small with their own knowledge.


As a sanctimonious prick who asks a lot of leading questions, I find it's very difficult to communicate technical insights with other members of my team by just giving them the answers to the hard questions.

What I'm guessing you'd like sanctimonious pricks like me to say:

"That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use."

This categorically does not work! Don't do it! It allows for zero shared credit, puts everyone on the defensive and leads to bickering and bike-shedding. In the best case, the person you're arguing with will disagree vehemently, go away for a few weeks, then come up with a new idea all by themselves that is exactly the same as what you were arguing for. This achieves the same result but isn't a very pleasant way to get there. Questions work marginally better.

In general my lines of questioning follow one of the following formats:

1. Is there a reason we're not using <a := some no-brainer technology choice> instead of going to all the effort of rolling our own <a>?

2. Have you thought about how that's going to work when <one or more use cases that are almost definitely going to happen that you clearly haven't thought about>?

3. Is <b> something we're just doing now to get it working and then planning on refactoring later? <where b := a horrible mess they just merged into master>

4. It looks like the script is running when I enter <script>alert('bazinga!');</script> as my username. Seeing as it's your commit that caused it would you mind taking a look at that?

In terms of sharing insight without offending people, that's about as polite as I can get I'm afraid.


Your questions 1 to 4 look pretty normal and I would ask those as well. The parent poster is mostly talking about people asking questions just to make themselves look better.


It can be a matter of interpretation. Suppose two "highly competent" programmers A1 and A2 and two "moderately competent" programmers B1 and B2 are together.

If A1 asks those questions to B1, I suspect that A2 would view them as perfectly normal, appropriate and helpful, while B2 might view them as aggressive or "trying to show A1's superiority".


Perhaps, depending on B2's self-confidence. There's still that category of people that ask questions for other reasons than being interested in the answers to those questions.


"That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use.

This categorically does not work"

meh, if that gets the job done faster then say it. The chance of a 20 minute argument vs a weeks long delay? I'll take the 20 minute argument.

But then again, leading questions get my back up. I'm a "say what you mean, don't hint at it" type.

If I get offended because someone else knows better and tells me so without being rude, then it's my problem (and my insecurity), not theirs.


> meh, if that gets the job done faster then say it. The chance of a 20 minute argument vs a weeks long delay? I'll take the 20 minute argument.

I think it's possible that you misread my comment. In this scenario you get the 20 minute argument plus the week long delay, at least in my experience.


Leading questions are good, I don't advocate people just telling the answer directly and I follow your approach in terms of leading questions. From the examples you give I would suggest you aren't the kind of sanctimonious pick that I was trying to describe.

The example I was giving and probably not stating clearly enough, was of a member, who on a number of occasions has approached other team members and asked questions out of context like an on the spot quiz.

As an aside to my first post it's also interesting to see the people that will openly admit whether they have messed up.

Anecdotally it is usually the people who are less willing to share their knowledge that will try and shift the blame.

BTW, I am revoking your sanctimonious prick status....


Most frequently it is because they are in a competitive environment and fear that they won't be given credit for their contribution.


As hinted at in a comment a few threads down, sometimes the sheer effort of trying to impart some knowledge or technique when other developers clearly don't want to hear it takes its toll.

In those situations, it is a lot less effort to allow developer B to commit whatever the hell they want into the codebase, wait until they lose interest and then go in later and clean up the mess.


It's probably the "I don't get paid for that" attitude ...


That is the worst. The "That's not my job" attitude is from people who are not team players and believe that they are above doing certain work, regardless if the work needs to be done. If you work in a problem solving profession, then you just can't have this attitude, because eventually someone is going to ask you to solve a problem outside your domain, and if you can't figure it out, then it doesn't get done or they get someone who will figure it out.

Although people bringing their stapler to the IT help desk is one of those times I might not be mad if the response was "That's not my job"


Which is a cop out anyway. Programmers don't get paid to "write code," they get paid to solve problems. Part of that is discussing options and strategies with teammates and making sure everyone is on the same page (or as close to the same page as possible when you have teammates with vastly disparate specialties and expertise).


It's always hard when you think "I was being an arsehole at that time". Hard, but good to realise. I think I had that moment just now!

In case you think I believe I'm always an arsehole, this isn't the case. But there have been times I believe I was. I'll have to work on it in future :(


I can't argue against you because I don't know the specifics. But to me, it seems those that are the most worried about themselves being assholes are the least assholish of people. People who do behave as genuine assholes never reflect upon their own behaviour.


that's really great hiring advice. i love this process!


Define asshole, please.


A person counts as an asshole when, and only when, he systematically allows himself to enjoy special advantages in interpersonal relations out of an entrenched sense of entitlement that immunizes him against the complaints of other people.

http://www.slate.com/articles/arts/books/2012/10/ascent_of_t...


Thank you. Seems I'm surrounded by assholes then with such a broad definition. My thought was that an asshole (in general sense) was someone who always put himself first. Thats why I did not understand the post as well as I'd like. Again, thanks for taking the time to explain.


The Slate link really is worth reading. Assholology is the hot topic these days, and I have frequently found that reflecting on my own asshole quotient is more worthwhile than focusing on the assholes around me, to the point where I begin to consider that assholes aren't ALL bad!


Your definition made me stop and think about how big of an asshole I really am. It is tough to somehow relate and try and measure it, because I reason a lot of social interactions and judge them as logical entities. Like you said not all assholes arent that bad, because not all of them realize they are assholes.

Though your term used to define it is wonderful. I would major in asshology if given the chance. But it would require a minor in chraminology. :)




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

Search: