One thing that really annoys me about HN is how damn contrarian everyone always tries to be. Responses typically take the most absolute narrow and unforgiving interpretation of any point you are trying to make and subsequently use that to spin a counterpoint.
1) If people agree with the idea they'll probably just nod their head, or upvote. If they disagree it is more likely they'll post something rather than just downvote (people feel the need to explain perhaps why they downvoted)
2) Geeks feel the need to say something contrarian to show how smart they are. It is a way to tell everyone they have a bigger intellectual penis than everyone else.
I honestly think (1) is the real key. I constantly decide not to submit comments when it turns out I've used a bunch of words to just say "I agree", and hit the upvote button instead.
Also, to another of your parent's gripes - if someone only responds to a narrow point, it should be safe to assume they agree with the other, or broader, points, and that's why they didn't respond to those.
But silent agreement and loud disagreement does make it seem like everyone is mad at each other all the time.
Regarding #1, wow. That's a pretty remarkable insight.
Everyone thinks of the karma/reputation feedback mechanism in terms of how it promotes civil discourse, but in this case it's fairly remarkable to think of how it could be biasing the conversation toward a negative tone. Maybe it's usually civil negativity, but it's negative nonetheless. I can see how people would tire of this eventually.
I wonder if there'd be a simple way of limiting the bias? Slashdot's modpoint classes comes to mind, but then that opens a whole host of other problems...
#1 is why I think HN should show up vote counts to the non-authors. I think the tone of HN would seem less negative if we could see how many people actually agreed with the comment everyone else is arguing against.
It may make #2 worse though. People love to argue against the majority, especially geeks, especially on the internet.
It's flattering to oneself to be contrarian; Not only have you already considered what has been presented, you've also thought about it and have a counter-argument. You're cleverer than the author of the article; she still entertains that idea while you have long ago dismissed it.
Thought that's rarely the case. What usually happens is someone will read a clever article, get upset that they didn't come up with it and choose a narrow interpretation or a minor nitpick to attack the piece, thereby making themselves feel better.
This is very well articulated and at least partly rings true for me. However, after typing out a response of the nature you described, I hit the back button rather than submit.
Funny. I thought that was my thing. Typing out a disagreement comment, then read it and think: "How will this discussion end? Will any good conclusion come out of it, or will it be mere sword flailing?".
More often than not, I hit back instead of submit.
Maybe it is also a reaction to what is often remarked upon as the falling signal to noise ratio: if everyone may expect to be skewered, then fewer will be encouraged to post.
I hate it when discussion's turn into a fight over semantics rather than the actual substantive argument. I am interested in how the world actually is rather than someone else's abstraction.
To actually add something to the conversation (and sadly, to be just a bit contrarian), I hope nobody reads this as "oh darn, I better not take an opposing view for fear of being voted down as contrarian." I actually do like reading respectfully contrarian responses. Not the childish ones you describe, but the ones which have a bit of thought behind them. I think a better term is "devil's advocate."
Yup, seams like only the greater of minds and personalities will acknowledge or even accept inputs from others and ADD to it. The default seams to be distortion along the simple and absolute black & white spectrum and then stating the opposite to be (much more/really) true.
While in certain "communities" this maybe is driven by the profession it self (oh, CS and all its true/false 0/1 domains ;), very seldom "cooperative discussion" is presented as something beneficial... just check most newspaper and tv reports... we get controversy presented as the way to go while the world is clearly much more complex as to be grasped in simple black/white true/false terms.
For single humans tending to such patterns in thinking certain medical conditions are associated with... in our societies looks like we embrace it much more thoughtlessly. All has to be a controversy (Parties, Companies, People)
Yeap, it's a jungle out there. I try not to play games of anyone appearing to cobble a name for themselves by inventing drama. Brinksmanship is most often a lose-lose gambit. Let the argumentative types reveal themselves, for the best course is to laugh at wasted energy and move on to the next task.
Also, anyone that bothers to publicly point out to you a misspelling is someone with too much idle time and not enough decency. One must hope for more cunning and aggressive frenemies so you may be judged accordingly.
I see that. I don't find it overly common. And if someone's disagreeing with either an inconsequential point or misconception of what I've written, I'll point it out.
I find that productive discussions do grow out of conversations with people who can note both what they agree with and what they don't. I've actually learned quite a bit from this.
I once worked with an individual with a PhD in Mathematics who wrote some of the most god-awful code you could possibly imagine. In an algorithmic test, he would have bested anybody I can think of.
Intelligence and usefulness at tasks are incredibly complex topics for discussion. If you think you can reliably go from A to B, you're dead wrong. The only reliable metric is, if you want skills A, test for A. If you want skills B, test for B.
I am actually pretty decently ranked on Interviewstreet because I do have a personal interest in algorithmic stuff (I was top in Australia for a little while :)). I used to do your codesprints just for fun.
My feedback to you would be that Interviewstreet is heavily heavily geared towards academic algorithmic questions which the average developer would not have a chance in hell of solving. For example, in order to solve some of your old Hacker Rank questions within the time and memory constraints you pretty much have to know the studied and documented solution you would only ever be exposed to in doing a masters degree in CS. Heck, your problem descriptions were often thin veneers around the exact academic statement of the problem.
Despite the fact that I'm someone who actually does excel at these types of problems, I think they are absolutely the wrong way to hire people and whenever I've seen companies actually use Interviewstreet it makes me cringe - and yes I know companies set their own questions, but you lead by example and so most questions are abysmal.
I would argue that, say, a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter (infrastructure, taste, independent thought) precisely because they have zero real world experience.
"a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter"
Why do people keep implying that only new grads understand algorithms as if it's some kind of fact? In my experience, new grads don't tend to know algorithms any better than they know anything else.
Good engineers keep learning about algorithms because the knowledge is timeless.
Ridiculous. Good engineers solve engineering problems. The huge number of successful engineers out there in the world solving problems without remembering their CS course notes tells you everything you need to know about how important much of the algorithmic subject matter is.
Uh huh. I can fix my car without knowing metallurgy and fluid dynamics, but you wouldn't want me building you an engine.
Just because people are getting by doing the technical equivalent of changing sparkplugs doesn't mean that I want to hire them to do something more difficult.
And you don't immediately give a recent grad a large project with no oversight. You give them time to learn that stuff, and they'll pick it up with experience. But someone who demonstrably cant understand how computers work? That's who you need to avoid.
I repeat now what I said then: I think there's a very simple rule anyone can and should follow to not fuck up interviews: Don't ask people to do things in the interview you wouldn't expect them to do in the job.
Examples:
(1) Do people in this job regularly write code on the whiteboard? Lack access to a search engine? No. Then don't do it in the interview.
(2) Do people in the job design spice racks for blind people? No. Then don't ask them to do this in the interview.
(3) Do people in the job regularly find themselves coding something on the level of fizz buzz? Yes? Go ahead and ask!
(4) Do people in the job regularly find themselves writing code to find loops in a graph? Yes? Go ahead and ask (though, let's be honest - this is exceedingly rare in comparison to how often it is deployed in interviews)
Verify people have the skills they need to do the job you're hiring for. It really is as simple as that.
Just as with all the other such articles, there are probably going to be comments on this one talking about how interviews like this are the exception. That you just got crappy interviewers and as the article itself notes, you probably didn't want to work there anywhere.
If you are the kind of person who would write this comment, stop now. The truth is the vast majority of technical interviews for developer positions are conducted in this bullshit manner today. The only way to solve this is to do what this article is doing and continue to draw attention to the fact that the way people are hired for software developer positions is completely and utterly broken. We need to make shitty technical interviews the exception, not the norm.
I've been in interviews in the past where I've just wanted to scream at the interviewer - Why, why aren't you asking about my portfolio? Look I've built amazing things that people love. With my own hands. To a high quality. On time. You can see and touch them. And it's exactly what you want me to do here in this role. JUST LOOK.
Nope. Hey it would be great if you could please while standing on your head, design a spice rack for a blind person (I've seriously been asked this), with one hand touching your nose. Oh and can you wear this red clown nose. This shit's important.
Awhile back I brought in two candidates for an interview. One candidate's resume had experience going back to the early 90s, programming games on the original Game Boy in assembly, and pretty much every platform after that. Lots of senior developer titles, lots of products to his name.
The other candidate had graduated a couple of years ago from a game programming school, and worked on a couple of miserable movie tie in games.
I was looking forward to the first candidate for weeks, I thought about not even calling in the second candidate, but opted to anyway "because why not".
So I get to the interviewing part of things. "Heya, we are doing embedded development here, so we have to do a lot of basic things like data structures on our own. Here is a binary search tree, can you give me the code to walk it in order?"
15 minutes later, not a line of code. OK, so, instead, walk a link list. Nope, the rest of the hour went by and he wrote a sum total of 1 IF statement, and it was wrong.
Candidate B? Holy shit. So the walking a BST took less than 5 minutes, he did Find First Cousin in a tree in another 5 or so, he then spent 15 minutes implementing a bit packed RLE system, and another 15 minutes doing some other random crazy crap I asked him to do.
He blew through all my interview questions in under an hour.
Unless I have some assurances that a candidate actually wrote the code on the projects on his or her resume, I am going to demand that the candidate write some bloody code on a board.
Not being able to walk a linked list sounds pretty dire. Is it possible that candidate A hadn't written tree-walking code recently? Did he have access to reference materials?
I aced my CS degree, but a few years later, after endless CRUD, I was given a task at work which involved constructing and analyzing hierarchical data. After realizing that it would be modelled with a tree, and a few minutes with my textbook and it all came back to me. If I had been given the same task in an interview, I may well have flunked it.
I personally allow candidates access to Google and whatever else they need on programming tests. That's how they'd solve problems in real life, so why make them relive their final college exams in an interview?
Hopefully the recent news articles about Google's data-driven analysis of these techniques will start moving things in the right direction... there is ZERO predictive value to many of these questions, and they bring with them a tremendous - and unaccounted for - cost around interviewing & rejecting qualified people.
That's not quite what the analysis of their hiring practices says. All it says is that among those that pass, it does not predict their future success with the company. It may however be a good predictor of negative success--those that don't pass would not have gone on to do well at Google. Of course their data cannot determine that.
In defense of scripted interviews, if your doing a lot of highering it's useful to get a less biased view of the candidates. It's really easy to rank outgoing personable people you like far higher than they deserve, but if they completely fail FuzzBuzz your going to dig a little deeper.
That's not to say you sould only asked scripted questions, but there are plenty of good developers the question is often are there weaknesses a good fit vs there strengths.
I think that's a key point. If a candidate seems mostly okay, but then something goes wrong, dig deeper and don't just immediately send the form letter rejection.
Now, if you dig deeper and discover they are actually not good enough for you, then send the form letter rejection, but don't hallucinate their incompetence out of only a few chats while completely ignoring their entire portfolio and/or work history.
Would you say all data structures and complexity questions are bullshit? Mrainteaser / estimation questions? Is all coding bullshit, or only on whiteboards? Only coding algorithms from college? Is asking someone to code 'fizz buzz' bullshit? I'm interested to hear where you consider the boundaries to lie.
Or have I misread your post, and you mean something else?
1. Do you want a team member who can plan, investigate and research unforeseen problems, brainstorm and contribute to the code? Then the one on whiteboards is bullshit UNLESS it is a brainstorming question - with a laptop next to it - and you are both working on the problem together - and ideally neither of you know the answer.
2. Or does you company have a clear knowledge of what lines of code are needed to be written for the next 5 years. Then sure, go ahead and do the whiteboard interview. Or just train a monkey, at least they are cute and cheap.
A whiteboard interview typically just tests memory recall under a stressed situation. It might be what you need if you require a hacker for a Die Hard sequel where there is only 90seconds to figure out how to line up the encrypted polycube nano-algorithm before nuclear meltdown is initiated. Or if you require a monkey.
I think there's a very simple rule anyone can and should follow to not fuck up interviews: Don't ask people to do things in the interview you wouldn't expect them to do in the job.
Examples:
(1) Do people in this job regularly write code on the whiteboard? Lack access to a search engine? No. Then don't do it in the interview.
(2) Do people in the job design spice racks for blind people? No. Then don't ask them to do this in the interview.
(3) Do people in the job regularly find themselves coding something on the level of fizz buzz? Yes? Go ahead and ask!
(4) Do people in the job regularly find themselves writing code to traverse linked lists? Find loops in graphs? Yes? Go ahead and ask.
Verify people have the skills they need to do the job you're hiring for. It really really is as simple as that.
Is this a joke? So the examples that she gives as to why KA is terrible are:
(1) He used a pie chart where perhaps a bar or column chart would have been more suitable.
(2) She's "pretty sure" he got the explanation of confidence intervals wrong, but was "so confused by the end" she can't be sure.
(3) The p-value video was accurate but dull.
And all this plus some other _very_ minor complaints ("he mispronounces the adjectival use of “arithmetic”, which is a bit embarrassing" - Seriously??) is enough to justify a massive tirade that makes accusations Sal is lazy, doesn't care, is incompetent, etc? I'm certainly more than willing to hear valid arguments KA is not perfect, but this is just rubbish from someone who frankly seems bitter nobody cares about her videos.
Bar charts are always preferable to pie charts. But the video was about "reading pie charts", so this is perhaps the one occasion when using a pie chart can actually be justified.
But if you're going to give instructions on reading a pie chart, the pie chart that you give as an example should at least make some sense in that format. Time-series data represented in a pie chart is abnormal.
I can personally relate to the part about no going back to just being a worker bee once you've tasted blood.
For me I did my "startup" at a pretty early age (I didn't call it a startup then - it was just me building software and selling it online) and it has forever changed my perception of the workplace. I've tried slotting back in to some regular jobs since then and it hasn't really worked out all that well - I get anxious, frustrated with the slow pace, second guess too many decisions, wonder why everyone around me doesn't have that same passion/enthusiasm, etc.
Short of doing another startup, I've found contracting to be a good middle ground for me (for the time being).
> I get anxious, frustrated with the slow pace, second guess too many decisions, wonder why everyone around me doesn't have that same passion/enthusiasm, etc.
Same here, and the frustration is compounded when you get slogans like "take ownership" thrown at you, but then find out you're not allowed to own the project, just the problems.
I think a lot of things like "take ownership" are working ideas lost in translation, applied by people that don't properly understand how to apply them.
For example, it works well where employees are given the responsibility to take ownership of things. Some guy who runs a business that runs well on that premise writes a blog post about, or an article that's printed on page 23 of Inc. Magazine. Some middle manager reads that article and thinks "yeah, that could help me get to this quarters target" and tries to implement it in a company that isn't structured that way. Since he doesn't want to restructure, he simply tells his employees "yeah, you should take ownership now, that's an order", and the inevitable happens.
Strong disagree for me. I have no such issues with making "ear" selections and I find the overall responsiveness of the device to be incredible with the latest 4.3 release.
According to discussions I've been reading about this [1], it seems that more than _half_ of the applications on BB App World come from just four developers: a staggering 67,500 apps.
Drives me batty.