Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Carpenters Were Hired Like Programmers

dawood.in

Post reply on HN
Print view View original

61–70 of 164 posts

Re: If Carpenters Were Hired Like Programmers

#61

Post by barrkel »

vinceguidry wrote: post #58
weixiyen wrote: post #37

Earlier quoted context omitted.

I've always gone for the ones who really knew one language inside and out. The reason is actually very simple, they have demonstrated exceptional skill to dive deep into one language, so they should be able to do the same in another language. The jack-of-all-trades people usually are much riskier hires as they don't always understand how deep they can go in any particular language, thus are unable to fully assess wha…

That's how I find myself conducting my own personal development. The deeper I dive into Ruby, the more I find myself able to hold my own in conversation with my friend the graybeard C++ guy whose been doing it longer than I've been alive. He'll describe something he's trying to do and I'll be able to immediately find an analogue in Ruby. I'll get a sense for how Ruby exists in the general evolution of programming lan…

now I want to understand what a framework is

I'll short-circuit that one for you right now: you call a library, a framework calls you - it figures out how by some combination of convention and configuration. Libraries put you in control, frameworks make you cede control. You can usually mix and match libraries, whereas you can only use one framework at a time comfortably.

Re: If Carpenters Were Hired Like Programmers

#62

Post by [deleted] »

wtbob wrote: post #48
italophil wrote: post #38

Earlier quoted context omitted.

If they want SAS that is their choice. It's like asking a carpenter to built a cupboard and he answers: "I'd rather build a shelf, it will hold your dishes just as well."

No, it's more like asking a carpenter to build a cupboard, but when he brings a hammer to the worksite you ask him to use a rubber mallet instead. Sure, one could drive nails with a rubber mallet—but who'd want to? Likewise, who would want to use an inferior language or library when superior ones exist?

[deleted]

Re: If Carpenters Were Hired Like Programmers

#63

Post by ajross »

lordnacho wrote: post #44

This is so true. I see a lot of job ads that seem to require very specific experience, but where anyone in that field could do the job. If you just make up eg 4 different types of technology, and put a few things in each bracket: [SVN, Git, Mercurial, CVS] [MySQL, PostgreSQL, Oracle, MSSQL] [AMQP, MQTT, STOMP, RabbitMQ] [Java, C#, C++, ObjC] Now if someone came along and said they'd solved a domain problem (eg tradin…

Here's the thing though: the reason people hiring get so hung up on specifics is because they get burned repeatedly. Coding is just hard. Learning it is hard, doing it is hard, and there aren't enough people who can do it well to go around.

So if you're a manager and need to "build a team", you can either play that needle in the haystack game (which you will always lose, because the needles generally don't even show up on your list of resumes) or you can try to cheat: find someone who has done exactly what you are doing in the past.

Obviously that doesn't work either, but it's not irrational to believe it might.

Re: If Carpenters Were Hired Like Programmers

#64

Post by seanwilson »

autokad wrote: post #56
weixiyen wrote: post #37

Earlier quoted context omitted.

I've always gone for the ones who really knew one language inside and out. The reason is actually very simple, they have demonstrated exceptional skill to dive deep into one language, so they should be able to do the same in another language. The jack-of-all-trades people usually are much riskier hires as they don't always understand how deep they can go in any particular language, thus are unable to fully assess wha…

In my experience, although not very large, people who only know one language do so because they stick to things in their comfort level. they are also disadvantaged in environments where projects vary quite a deal. certain environments have different communities supporting them, making them better for certain tasks. an example, a ASP/ASP.NET developer (only thing) of 10+ years couldn't do something over 6 months that…

That's why I prefer a so called jack of all trades to a one tricky pony. I've worked on mobile projects where I've had to switch between Java, Objective-C, JavaScript, Bash, SQL and Python in a single day to add new features. Knowing, for example, obscure details about Java you rarely need and could Google for anyway isn't as useful as being flexible.

Re: If Carpenters Were Hired Like Programmers

#66

Post by thomaskcr »

jhall1468 wrote: post #59
thomaskcr wrote: post #50

Earlier quoted context omitted.

Why wouldn't you just do it? I can understand if they're nit-picking syntax but I personally ask people to write out algorithms/code on the board all the time in interviews. I don't care about the code, I want to see them think through a problem. They can use any for syntax they want, even mix and match things like brackets and indentation or how control structures are defined (for i = 1 to 10 { .. } ), or use a func…

It's a contrived situation that involves significantly more nerves than any real life situation will. I've known more than a few programmers that were perfectly capable of doing their work, but struggled through interviews because they got nervous during the coding phase. The reality of the situation is that contrived problems in stressful situations are going to result in a lot of false negatives. That may be fine f…

But its not contrived -- its like your entire job. You're literally saying "I can't perform my primary job function when there is any pressure whatsoever". That MIGHT be acceptable if you're interviewing for an entry level job.

The only other reason I can think for being unwilling to do this is if you're incapable of working with other people - because whiteboarding out solutions with other devs is super common. Even "where do you think I should start, I'm a bit nervous and an idea to get me going would be great" is a perfectly acceptable question. The best interviews are a conversation -- if you turn it into a conversation where we're working together on the problem, it shows a lot about you still. If you take someone else's idea and run with it I think that's really cool, obviously if you need hand-holding it's suboptimal, but there is still a very positive possible outcome from saying "I have no idea where to start" if you're actually nervous.

The only ways I can think of to fail writing out code is people skills or being completely unable to program. It's not like I expect a perfect solution in the 30-60 minutes we have, analysis paralysis is just as bad as no-knock raiding the problem. There is some type of middle ground that involves a good solution that had to be done quickly -- maybe you even mention some other avenues to explore.

What if you ever have to represent my department in any capacity and someone asks you what your ideas for a problem and you just say "no, I don't do that" -- that doesn't really represent me well. I would be very surprised if being uppity about a question being "below you" ever works, you might as well just walk out the door if you're going to refuse to answer a question on "philosophical principle".

The question is just a jumping off point -- its up to you to turn it into a conversation that shows me how great of a programmer you are. If your answer is telling me how dumb my interview is, then that doesn't show me how great a programmer you are at all -- it shows me you have an attitude problem.

Re: If Carpenters Were Hired Like Programmers

#68

Post by frostmatthew »

jhall1468 wrote: post #59
thomaskcr wrote: post #50

Earlier quoted context omitted.

Why wouldn't you just do it? I can understand if they're nit-picking syntax but I personally ask people to write out algorithms/code on the board all the time in interviews. I don't care about the code, I want to see them think through a problem. They can use any for syntax they want, even mix and match things like brackets and indentation or how control structures are defined (for i = 1 to 10 { .. } ), or use a func…

It's a contrived situation that involves significantly more nerves than any real life situation will. I've known more than a few programmers that were perfectly capable of doing their work, but struggled through interviews because they got nervous during the coding phase. The reality of the situation is that contrived problems in stressful situations are going to result in a lot of false negatives. That may be fine f…

> contrived problems in stressful situations are going to result in a lot of false negatives

I don't understand the concern with a "contrived" problem. You think it is better with a random spontaneous problem the interviewer thinks up on the spot?

Interviews are stressful for most people; good interviewers will take that into consideration.

Re: If Carpenters Were Hired Like Programmers

#69

Post by omegaham »

wtbob wrote: post #48
italophil wrote: post #38

Earlier quoted context omitted.

If they want SAS that is their choice. It's like asking a carpenter to built a cupboard and he answers: "I'd rather build a shelf, it will hold your dishes just as well."

No, it's more like asking a carpenter to build a cupboard, but when he brings a hammer to the worksite you ask him to use a rubber mallet instead. Sure, one could drive nails with a rubber mallet—but who'd want to? Likewise, who would want to use an inferior language or library when superior ones exist?

> Likewise, who would want to use an inferior language or library when superior ones exist?

My guess is that the existing codebase is in inferiorLanguage, and it would be a massive pain in the ass to rewrite it in superiorLanguage.

The carpentry analogy doesn't really work here because you can stop using the rubber mallet at any time. You can't just switch frameworks or languages when you feel like it.

Re: If Carpenters Were Hired Like Programmers

#70

Post by sjclemmy »

As someone who occasionally has hiring responsibility I sympathise with both interviewer and interviewee. It is extremely tricky to determine if the person you have interviewed is going to fit the bill. I've hired people who I thought would be a great fit for permanent roles but turned out to be the worst kind of procrastinating, one trick ponies who caused more problems than they fixed.

In a recent situation I had a very specific set of requirements for very specific reasons. The company is .net all the way and has a couple of permanent developers who know only VB and have no C# experience. Because of a large influx of work, these developers needed some additional resource for a short period of time. I wanted to try and increase the skill level of the permanent developers as they are not very familiar with design patterns and 'modern' techniques. To this end, I wanted C# developers with familiarity with design patterns and modern best practice to come in and develop in VB. I didn't care if they hadn't used VB recently at all. But I did care that they knew .net. I don't have time for them to learn .net. So I can't have someone from the Java world, it would just take too long. But at the same time, I'd rather not have a VB only person, as they tend (and I am generalising, I know) to not understand much about design patterns and they don't tend to have broad programming knowledge.

When interviewing for a specific role, you have to think very hard about what it is you are trying to do - and don't just fall back on generic cut and paste questions.

Post reply on HN