Live data from Hacker News

Organizational Skills Beat Algorithmic Wizardry (2015)

johndcook.com

91–100 of 101 posts

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#91
post #82
post #72

Earlier quoted context omitted.

I mean, CRUD doesn't have to be simple. It can get complexity from the underlying data, or dealing with 100 million users at once, or it having to return results FAST. Just because you don't have to write some novel algorithm doesn't mean you're not solving hard problems.

I think the parent wanted to say that their problems are rather tedious than hard . I'm currently in a very similar situation - a project in which we have a table of records, two of which are special in a certain, business-related way, but need to be presented along with the others, so to get around this we place "ifs" here and there - a lot of them. It's a generally simple project that has been turned into something…

> I think the parent wanted to say that their problems are rather tedious than hard.

That idea - the distinction between tedious and hard - is going into my mental toolkit. Thank you.

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#92
post #77

Earlier quoted context omitted.

> It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part. Really? That's not how I read it. And when I asked OP, that's not how he responded. The examples of questions that he said he would ask had been stripped of any algorithm-related questions, or any questions that involve coding.

Neither serpix nor acroback answered again here, so it was someone else who responded.

I'm talking about serpix. When I asked him "if you don't thik that algorithm questions should be asked, then what should?" he replied with a list of pointless questions.

Then you said "it's really hard bit that's being criticized here, not the algorithm bit."

No, it's the algorithm bit that serpix was originally criticizing, as evidenced by the fact that when he replied to me he didn't include algorithm questions from the list of things that he would ask.

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#93

Earlier quoted context omitted.

You need to ask questions that let them show off their full understanding of a system. People without organization skills will focus on one area and not explain the whole. My favorite is to have someone explain to me what happens when a browser makes a HTTP request to a web URL, which has . Network guys will tell you all about the request and response, web developers will focus on the front end, devOps will tell you…

Personally, I would answer that question by telling you how the HTTP protocol works because, in my mind, that's what you're asking for. If you're going to ask that question, I think you need to be more clear about what you're looking for. I don't think there is any value in interviewers being intentionally vague in order to test if a candidate can guess what they're thinking.

You presume I want a specific answer -- I don't. I want to know how they think about a system. In your case, you laser-focused in on 'HTTP'. OK, that tells me a bit about how you think. If you were to say the question was too vague, that also would tell me how you think. If you were to ask for more clarification, that might be a really good first response. There is no right or wrong answer. Interviewers don't always seek specific answers. I'd argue that the best interviewers never seek specific answers, they ask questions that help us learn who you are.

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#94
post #47

Earlier quoted context omitted.

I have been a janitor (or pretty much that) during my MD studies, then I have been a nurse, then a doctor, then a programmer. I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own). In the IT field it's different though. Every junior is absolutely sure they are better than their team lead (been there, done that, also been the team lead). Every QA thin…

> I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own). Much harder, no doubt. More valuable though… a good portion of that value comes from having a clean hospital to begin with. (Not that I am not talking about market value, which is obviously much lower than that of doctors, thanks to the larger supply of janitors, and how much cheaper it is to t…

Not trying to dismiss your thoughts, but I never met a janitor who believed something like this. They knew perfectly well that they are easily replaceable, that their work is easy etc. It might be because of culture/location of course - Eastern Europe in my case. Also, have in mind that the hospitals I worked in are quite different from what you imagine when you say "a hospital" and especially "a clean hospital" :D. One of the reasons I switched careers and locations.

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#95
post #47

Earlier quoted context omitted.

I have been a janitor (or pretty much that) during my MD studies, then I have been a nurse, then a doctor, then a programmer. I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own). In the IT field it's different though. Every junior is absolutely sure they are better than their team lead (been there, done that, also been the team lead). Every QA thin…

Thanks for sharing. > I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own). More than once I've heard staff (not janitors though) talking depreciatively about doctors (e.g. "he thinks he knows everything", "he said X but my uncle says Y"). I think if you read what I wrote a bit more charitably you'll see that my point wasn't really about janitors. I…

I absolutely agree with your comments. I just joined in to give my 2 cents with some real experience and to give more nuance to the discussion. I do agree that medical and IT fields are different (and that's what I tried to explain in my original comment)

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#96
post #47

Earlier quoted context omitted.

Are you guessing, or have you actually asked?

I have been a janitor (or pretty much that) during my MD studies, then I have been a nurse, then a doctor, then a programmer. I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own). In the IT field it's different though. Every junior is absolutely sure they are better than their team lead (been there, done that, also been the team lead). Every QA thin…

It’s a bigger divide when we go across teams. Most programmers distinctly look down upon sysadmins and as a sysadmin and developer I really have to say that the sheer number of former blue collar workers that became sysadmins compared to developers does not help the perception. But more importantly, a lot of engineers have a sheer disdain for sales as if they don’t work hard and the same goes back even further where engineering students look down often on most liberal arts students (never mind that the liberal arts and business students are the ones that they’ll be working for probably statistically speaking).

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#97
post #57
post #16

Earlier quoted context omitted.

If you learned Ada, Modula-2, Pascal, or BASIC, though, it might not be so relevant. COBOL, FORTRAN, Smalltalk, and Perl 5 are somewhat useful, akin to, maybe, jQuery in the web world.

JQuery is not a language. Like saying I “cuisine art” to a chef. Riiiiiight.

Sure, but jQuery from ten years ago is still jQuery. What iteration is Angular on now? Its doesn't have the churn that more recent web frameworks have.

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#99
post #69
post #44

Earlier quoted context omitted.

These would be perfect questions, if candidates didn't lie. They do. All the time. More often than you'd think about something as trivial as "can you actually write code". And so, you'll need to demonstrate your skills. Find a better way with an extremely low false positive rate, and you can make a fortune consulting and implementing that. It's not like anybody likes doing these interviews.

You don't need to ask "really hard Algorithm puzzles" to figure out whether they can actually write code. You can ask normally hard or even simple algorithm and have them implement it. If your company does object oriented, you can also ask them basic patterns. If you do functional, have them do little bit of that. It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part. That…

If you don't ask "really hard" questions[1], candidates instead complain because "any child can solve this" and feel not taken seriously. Somebody will always complain.

    "asking logical puzzles is fine"
No. NO. NO. That's the thing that isn't fine, because solving a logic puzzle relies on one critical insight. It's rolling the dice.

What you want is a question that has multiple answers, that's dirt easy, and where you can ramp up the difficulty to the moon if the candidate breezes through. These questions are hard to find, but they exist. They require investing some thought, so they're unfortunately not asked too often. But they work. (For small values of work. There is no good interview process)

[1] Somewhat hard. It's solvable in 45 minutes, it's not that hard.

Re: Organizational Skills Beat Algorithmic Wizardry (2015)

#100
post #88

Earlier quoted context omitted.

Personally, I would answer that question by telling you how the HTTP protocol works because, in my mind, that's what you're asking for. If you're going to ask that question, I think you need to be more clear about what you're looking for. I don't think there is any value in interviewers being intentionally vague in order to test if a candidate can guess what they're thinking.

Or you could just ask them to specify like, "did you mean explain x or y?".

I do. That wasn’t my point, however.
Post reply on HN