Live data from Hacker News

Keeping Your Company Asshole-Free

blog.hackfwd.com

21–30 of 55 posts

Re: Keeping Your Company Asshole-Free

#21

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.

Re: Keeping Your Company Asshole-Free

#22

Earlier quoted context omitted.

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 answ…

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…

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.

Re: Keeping Your Company Asshole-Free

#23

Earlier quoted context omitted.

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 answ…

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…

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

Re: Keeping Your Company Asshole-Free

#24
Imagine Apple was asshole free from the start? It would have failed, the reality is to succeed you need to make tough decisions and people will come across an asshole (ohherrr) at some point.

Also if you worked in a place where everyone was nice all you would likely want to blow your brains out.

Re: Keeping Your Company Asshole-Free

#25

Earlier quoted context omitted.

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 answ…

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…

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

Re: Keeping Your Company Asshole-Free

#26
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...

Re: Keeping Your Company Asshole-Free

#27
post #12

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…

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

Re: Keeping Your Company Asshole-Free

#28
post #25

Earlier quoted context omitted.

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…

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

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

Re: Keeping Your Company Asshole-Free

#29

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?

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.

Re: Keeping Your Company Asshole-Free

#30
post #14

Earlier quoted context omitted.

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

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.

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.
Post reply on HN