If Carpenters Were Hired Like Programmers | Hacker News Reader

If Carpenters Were Hired Like Programmers

dawood.in

265 pointsadwn154 comments

Original discussion to the original article posted by Jason Bock (which was merely copied by Dawood Sangameshwari without proper attribution [1]):

https://news.ycombinator.com/item?id=7819413

[1] There is some attribution a the bottom of the page, but it isn't proper. It contains neither the original author's name, nor is it a clickable link. It's just a plain text URL. Better than nothing, but still the most shabby way of "attribution" I've ever seen.

At the top of http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650... Bock says I didn't write this, so I can't take credit for it so I'm not sure failing to include his name or clickable link really qualifies as "shabby" attribution.

At least James Bock added a (clickable) link to the closest source he could find. Dawood Sangameshwari could have taken at least that one.

Man this is the strangest thing to me. I used to be a carpenter. I would show up at your job site with my tools, you might ask me a couple questions, I've had guys ask me to lay out a wall or two off the prints. Call a reference to see if I show up to work. Then I get the job. Usually, doing something myself or my boss never had done before, and we would figure it out off the prints, and build it.

I just go turned down for a job I was perfectly qualified for because I 'didn't seem eager enough.' Other notes from the interviewer said 'I'd be ready to go day one' and 'seems easy going and easy to get along with'

What the fuck is wrong with people? When did working at your shit company have to be my passion instead of my job?

And the real kicker is that no company really gives a shit about anyone. The expect complete loyalty, but they have none in return.

Yeah, that kinda bums me out.

> Usually, doing something myself or my boss never had done before, and we would figure it out off the prints, and build it.

Yes, of course. That's been my entire career in software as well. And I'd suggest that's what people should be looking for: the ability to build something they've never built before.

If someone's already built it, I'm not that interested in it.

In fairness, the analogy would be:

carpentering job = 2 week programming contract job

and in that case the expectations in the programming job would be more lax, and few people would care about your "passion for the company."

Even controlling for that difference, I still think you make a good point. Though it's probably true for modern corporate business culture in general, and not specific to programming.

No. These are companies that I worked for for years at a time. That is not a correct analogy. I have been hired, and worked for 4 years based on a 10 minute conversation.

Imagine that instead of your competent self, you were an incompetent carpenter. How long would it have taken, on the job, for your boss to figure out you were incompetent? How hard would it have been to fire you?

Because that's the big issue with programming jobs: Many places hate firing, and it sure takes a while before we separate whether someone doesn't understand the tools that are currently being used, and will learn, or he's hapless.

So in fact then fear has become the biggest motivator for both hiring and firing... no wonder the industry is in a mess.

Also in the building industry, the foreman may not be a carpenter by trade but at least he has some carpentry experience; in my time in the trenches too many project managers / bosses don't even have sysadmin experience let alone programming experience. Buzz word bingo, vague hunches, me too'ism, and voodoo psychology are used as yard sticks in the hiring process instead.

Your passionate, hand-crafted response gives me an indefinable but good feeling about you, tankenmate, and I'm on board with your approach! Also, I've learned from experience that people who use the phrase "voodoo psychology" are deeply analytical as well as trustworthy.

The page won't load for me so I haven't been able to read the article yet, but I am a construction worker turned programmer as well. I have found myself in the same boat a number of times. I have been turned down for a couple of jobs due to not being enthusiastic enough or because I couldn't come up with a good enough reason for wanting to work at that particular company. Recently I was turned down for a job because I have a side hobby that might distract me from my main job. sux.

Oh yeah, side work. I forgot about that.

To boss: "No we can't come in on Saturday because 4 out of 5 of use will be pouring my neighbors driveway"

Boss: "Oh, Do you guys need to borrow the concrete tools?"

Edit: This was actually a repost without attribution. Here is the real link: http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...

My explanation:

The people making the hiring decisions have two problems: (1) Ignorance about software, programming, and the associated technology and (2) resentment for the compensation level of good software developers.

So, who are these hiring people? People from CEO to HR to middle managers who know less about the work than the candidate employees do. This fact is like a chicken bone stuck in their throat because it is totally against the 100 year old norm, back to Henry Ford's factory, of an hierarchical organization where the supervisor knew more and the subordinate knew less and was there to add routine labor to the goals of the supervisor.

So, with the resentment of (2), the hiring people expect and very much want any candidates to know basically everything, including absurd details no one should bother to remember. Or the candidate needed five years of experience with Java when the language had been out for only three years and likely only James Gosling had that much experience with Java. Or the hiring people want five years of experience with MySQL and experience with DB/2 and SQL Server don't count. Or they want C# and Visual Basic .NET (different from C# essentially only in syntactic sugar) doesn't count. Or they want C Python and Algol, Fortran, PL/I, C, and assembler for several processors don't count.

And with the ignorance of (1), the hiring people don't know what's important and what's trivial.

So, for

> When did working at your shit company have to be my passion instead of my job?

the hiring people, lacking any better criteria for not making a hiring mistake, basically want the candidate to grab their ankles and swear everlasting, life long fealty and commitment to their six month project.

Moreover, such interview questions are obviously a really bad joke for someone with a lot of significant software experience and/or a good college degree in computing; that is, the hiring people, based on near total ignorance and incompetence, are trying to give oral exams in computer science, to someone obviously long since highly qualified.

Any competent professional or worker of any kind needs to keep in mind that it's super tough to build a good career working for ignorant, resentful people. So, try not to do that.

Keep in mind that only a tiny fraction of jobs provide a stable career with compensation sufficient for a three bedroom, two bath house, wife, kids, college for the kids, and retirement for the parents.

Broadly the solution for someone in computing is just to see the bright side -- how much hard/software can be had for $2000 -- and use that to start and run a successful business.

A good example is the Canadian romantic matchmaking service Plenty of Fish, long just one guy, two old Dell servers, ads just via Google, and $10 million a year in revenue.

Other fields of high specialization have seen and responded to much the same problem: So, they have a profession with, maybe government licensing, legal liability, professional peer-review, meaningful, challenging certification, code of ethics, etc. And, e.g., as I understand, the legal profession says that in a business, a working lawyer can report only to another lawyer, never to a generalist, line manager.

Really, old-line businesses, or any business with old-line attitudes, can be just terrified of software developers and work hard trying to minimize the power of the developers, e.g., use divide and conquer by making sure no one programmer is essential and, instead, the organization has various cases of back-ups.

But the ignorance (1) and resentment (2) go a long way to explain the nonsense.

Finally many VCs like to see technical CEOs -- good.

>the hiring people, lacking any better criteria for not making a hiring mistake, basically want the candidate to grab their ankles and swear everlasting, life long fealty and commitment to their six month project.

That right there should be a sign that the candidate is getting a really good deal out of this offer, which means it's out of his/her league or you're paying way too much.

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 trading systems) with one of each of those, I would more or less believe they could do it with any of the others, with a bit of time to get used to things (particularly c++).

But if you don't believe that, ie if you decide the person must have a specific combination, then you've just shattered the potential pool of applicants into 256 little pieces.

The other thing that annoys me is the pettiness of the interview questions. So many things that you could easily google can be used to stump anyone. What's the default implementation of GetHash() in c#? I actually got asked this once.

Then there's the other way to do things, which is to do an online coding assessment. I guess this gets rid of the FizzBuzz failures, but it tends to be a problem that's too small to see if you're about to dig a hole.

What's the default implementation of GetHash() in c#?

I actually like this question (not that I've ever asked it before), because it teases out how well someone knows .net and C#.

The specific implementation of GetHashCode isn't what's interesting. It's whether you know that .net implements reference vs value equality by default, whether you know you really do need to override GetHashCode if you override Equals, testing if you know the fundamental requirements for objects you might use as keys in a Dictionary.

The specific number returned and its relationship with the identity of the object - that's not important, and is truly not something you could be expected to know. But you're ability to think things through, and know the environment - yes.

Bull. It teases out if someone happens to know the GetHash() implementation in C#. Their knowledge of .NET and C# can, in no way, be determined by one stupid question about the implementation of a specific function in C#. Evidence of that fact is in your actual response: I could now answer that question, having never used .NET or C#.

I would go so far as to say someone with that kind of encyclopedic understanding of a language is a negative indicator. People with an 'deep' understanding of a language like to use said knowledge to create 'Clever' code. 'Clever' code is generally more buggy, harder to maintain, and basically never needed.

PS: And yes, I have been burned by this in the past often enough so I will now pass on a few marginal people that happen to know a language 'deeply'.

Here's my exact train of thought while reading that:

GetHash? What the frack? Isn't that on object somewhere? Right, object handles all the common copy semantics and so forth. Use the hash to check for equality; things on the stack instead of the heap, yadda yadda..

Dang, here the guy is going into detail why this is so important. Ah yes, value versus reference semantics. Boxing and so forth. Tiny trivia around how the CLR works. I remember those days well. Would make for a great Nerd Jeopardy question.

But who cares about all of that? I'll look it up if I need it. As far as memory usage, I worry about that by using pure FP and being careful what kinds of data structures I use. Problem solved.

Encyclopedic knowledge is great, but the real trick is dumping everything possible offline and then knowing how and when you should get back to looking at it.

While in the general case I would agree with you and I try very hard to dump as much stuff offline as possible, I would argue that this is one of those things you cannot look up "if you need it", similar to the difference between 'class' and 'struct' in C# or the difference between 'class' and 'case class' in Scala (the C# one being a runtime implementation difference, the latter being a fairly large OO design difference). It's something you need to internalize to do well in the language and the environment.

C# (and similarly Java) are so tightly coupled to their runtime languages that, personally, I do feel like I need to understand stuff like this at an intuitive, not-even-thinking-about-it level to be able to write good, fast, clean code.

I do not think we disagree.

My point was understanding the stack and heap, boxing and unboxing, were great to know general purpose knowledge about how type systems are created and used in modern languages, whether Java or .NET

If you know what it is, and you know why it is important and when it is used, then any detail you might miss or mangle really isn't that important.

In a similar fashion, I can describe in general terms how a virtual lookup table is fashioned, and how method signatures work in OO linkers. I'd probably miss 90% of the details, but I retain enough of an overview to correct myself when required. I can know something in general terms well enough to know where to go when I dive deep. That's the goal.

You have to internalize struct and class. Not so much on the relationship between the built-in hash function and the rest of it. You start using structs and classes, you start extending the type system, badda boom, badda bing -- you end up in the same place. No need to be able to give a lecture on it. Just be able to do the work :)

You need to know the contract of GetHashCode to use a custom type as a key in a dictionary. It's as simple as that. This isn't encyclopedic understanding; it's one level above novice.

That's not the question being asked.

"What's the default implementation of GetHash() in c#?"

As in if you call get hash code on a custom class name {public sting first ="A", public string last = "B"}; what happens and or what's it going to return.

> It teases out if someone happens to know the GetHash() implementation in C#.

Even if that's all it teases out, that alone can make the mark between a solid programmer and someone whose "been doing .NET since it came out".

In Ruby-land, I might ask "what's the difference between extending and including a module?" If you've only ever done Rails apps, you'll never have any reason to have to figure out the difference. But the second you write anything non-trivial in Ruby itself, you'll inevitably run into it when you start refactoring and extracting. Hell, a core Ruby module (Forwardable) wants you to extend it rather than include it when you use it, the curious will want to find out why.

If I'm interviewing 10 guys for a Rails position, I'd ask all of them that question and rate more highly the guys know their basic Ruby better. Maybe none of them could answer it. Fine, no big deal. But the one's who can demonstrate immediate, real value to me. Even if all you have is a "yeah, I had to look that up a few months ago, what kind of project was that again...", is better than nothing. Hell, even a "I actually don't know that offhand, what is it?" with followup questions to my explanation, sort of curiosity will really impress me.

Yes, I know you could look it up if and when you need to. But the fact that I'm asking the question means I've used it somewhat recently, which means my new hire is going to be reading that code eventually. If you're already familiar with code that uses those sorts of patterns, I'm going to have to do a lot less explaining to you and you won't have to spend half as much time extending it.

I don't know whether GetHash() in C# is as useful a knowledge filter as extend/include in Ruby, doesn't sound like it to me, but I do think that a carefully selected question like that can separate the men from the boys, so to speak. Do you love the little details as much as I do? Then we're going to get along just fine. If you can even just, with no guilt or worry whatsoever, just state confidently that you don't know that particular detail, will say to me that your confidence lies elsewhere and prompt me to draw you out.

When I was taking screen acting classes a few years ago, something our teacher said to us stuck with me. Everything in the class is geared towards auditions, since that's pretty much all you'll be doing for at least the first few years of your career, while you're holding down a waiting gig. He said, "have fun auditioning, because it's pretty much the only time you'll get to really display your personality and skills, for a long time." Even once you start getting gigs, they won't be like the glamorous TV or movie roles, they'll be for commercials. The interview/audition is your chance to shine, milk that opportunity.

Senior programmer would know that he needs to check hashing mechanism when his custom dictionary keys were not working right.

Everything eventually boils down to the bunch of algorithms Knuth so carefully documented for us. Learning a new language is just learning the syntax and semantics for it's mapping to those algorithms.

Stop holding languages in so high regard, jeez. IT is held back by this so much it hurts. Let's just describe some sensible high-level evaluation semantics and start all compiling into that already!

Never heard of GetHash. I've got 5000+ Web pages of documentation mostly just on the .NET Framework, am betting my start up on .NET, ASP.NET, ADO.NET, and Visual Basic .NET, and have yet to encounter GetHash.

From the mnemonics of the naming, a guess is that GetHash has to do with hashing. Well, mostly I don't like hashing and prefer extendible hashing, AVL trees, red-black trees, B-trees, heaps, etc.

Typically, for a class in the .NET Framework, to use it for the first time have to find a dozen or so Web pages at MSDN and learn them: For me that means download, index, abstract, and read the pages, look at the sample code, and maybe write some minimal code to exercise the class.

Yes, being clear on call by reference versus call by value is important but also quite elementary. Basically, all aggregates are to be call by reference; simple numeric constancts are commonly call by value.

I've been writing apps in C# for about 5 years, and not once have I needed to know how GetHashCode works.

I have looked at it at some point (don't remember why, I think it had to do with an entity's identity for NHibernate) but I would fail this question even though most people I've worked with would rate me as a very effective (and efficient) programmer.

This is why I feel I would do badly in these kinds of trivia-like interviews (once since I put linux administration on my resume, I was asked how to delimit lines in bash scripting).

My dream interview, one where I'd shine, is where I'm given a problem, and I have to go through designing solutions and discussing tradeoffs. I don't mind writing code either, but I would not know the answer to this kind of very specific question, I'd just know how to solve problems.

Have you never written a class that you wanted to use as a key in a dictionary?

You need to know the contract of GetHashCode to do this properly. If you don't know the contract of GetHashCode, well, you simply don't know .NET very well. That's my professional opinion.

I don't know much C#, but can't one understand the contract without knowing the default implementation? I would agree understanding the contract is probably essential, but the implementation is not.

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.

Do you think someone who is familiar with git wouldn't be able to be productive with svn in more than one day (while doing other tasks of course)?

Getting familiar with the code base takes much longer than picking up C# if you have a Java background.

Why are you arguing with me? I agree with you, and said so. I was trying to explain the thought processes of those who don't.

Basically, managers get burned repeatedly trying to hire people who aren't productive. And the reasons they aren't productive ultimately do end up being "So and so has been here for six months and still doesn't know subversion [or C#, or whatever]". So... the logic goes that if you hired for that skill in the first place you wouldn't have this problem.

A lot of programming nowadays is not as much about writing primitives, but knowing ins and outs of specific frameworks and libraries.

How reasonable would it be to expect an Objective C / Swift guy to write high-quality C++ Boost code and vice versa?

In every company there's some amount of code that's written in X but definitely looks like the person writing it was more experienced in Y and just dragged Y idioms into his new project.

Yes, this is true, but also misses the point. You might be looking for a C++ programmer, but because of the way the add is written, your HR is going to skip over the guy who didn't write git on his resume.

There are different paradigms even within one and the same language. Eg. Android apps written by Enterprise Java guys are just awful.

If they are a really good programmer, they most probably have touched pretty much every popular language and paradigm. Give them one to two weeks to get used to the language and another couple of weeks to get used to the frameworks.

It's worse than that.

The CHAOS study, among others, shows that 80%+ of all software projects are viewed as failures by the people who pay for them.

Meanwhile you come onto boards like HN or reddit and instead of talking about how to establish and keep trust with the folks writing the checks, everybody's talking frameworks and tools.

So picture a subdivision where 80% of the houses are broken down, priced too high, incomplete, or put together haphazardly. Now stop at one of the houses where the building crew is still there and watch them spend all day talking about the nail-o-matic 200psi nailgun or the robot auto-roofer that the carpenters in the next town are using.

The situation is sad from every angle.

> So picture a subdivision where 80% of the houses are broken down, priced too high, incomplete, or put together haphazardly.

Well, in a typical subdivision, this is actually the case. Construction quality for housing in the US and Canada is woeful, though a lot of it isn't the carpenters' fault (but some of it is).

Yes, but unsurprisingly so.

It is much easier to think that the project was a failure because tool choice instead of the actual reasons projects fail; of people who are not good enough to complete the project (junior carpenters put in charge of a skyscraper), management who wants people to build some impossible project on a tiny deadline (carpenter contracted to build stairway to heaven by October), or one of the other reasons software projects fail.

All of those problems require people and process work, not just technology, but as one of the biggest problems of tech is that we often see it as a panacea, we just think the new framework will somehow gloss over these major deficiencies.

It's easier to blame a heap of software than yourself.

I've worked with really horrible frameworks in the past and most devs were like "well I wrote a wrapper to get the ugly stuff out of the way and then build it the right way", most of the time they didn't even bother to learn how things work.

A: "Dude, have you seen this Nail-o-Matic 2000 nailgun?"

B: "No. It looks totally awesome, it's so shiny and chrome..."

A: "Yeah, it's the latest thing, I picked it up last night. Let's see how it does on this roof..."

A puts a shingle down and shoots a nail in. The nail rips through the shingle, blasts a 2-inch diameter hole in the roof and embeds itself firmly into the floor of the second story.

B: "Whoa, that's AWESOME! Can I try?"

BLAM! BLAM! BLAM! BLAM!

A: "Dude, this ROCKS! Hey, boss!"

C: "Yeah?"

A: "Good news, we're going to finish this job in record time!"

C: "Whoa! Where'd you score a Nail-o-Matic 2000!?! That's awesome! I've heard all sorts of great things about how powerful it is!"

Nail-o-Matic 2000: Because More Power Is Always Better. Always.

A. You know? What we really should do is get that new Blast-O-Matic bulldozer I have parked outside and tear all this crap down and start over! I saw a video on YouTube last night that said if we built houses using silly putty that they were impermeable to weather!

B. That's a great idea. Does it work with the Nail-o-Matic?

A. I don't see why not. They are both made of atoms.

C. Hang on guys. That's not going to work. What am I thinking?

A. What do you mean?

C. Dude. We have to draw pictures of the house first! I mean without pictures? We're just throwing stuff together. Our problem all along is that we haven't drawn enough pictures.

B. So if we draw enough pictures, then can we use the Blast-O-Matic, the Nail-O-Matic, and the silly putty?

C. Sure! I don't see why not. If we spend enough time drawing diagrams, dang near anything should be possible. At least on the diagram. Let me just pull out this circuit diagram for the Pentium CPU and we'll see how it relates to the average density of silly putty over time...

(B runs out and begins bulldozing house while A and C huddle over a blueprint with their slide rules)

B. Hey guys! You're doing a great job! Let me know when you're ready. I'll just go ahead and get started with the bulldozing.

So do I understand correctly that in this metaphor the poor quality of software is mostly because the practitioners are morons? I need to revisit the creeping complexity in my own projects and try to understand where I used the wrong nailgun, because this seems like a super productive analogy.

The joke is that nowhere in this picture is the actual guy who is receiving value from the work, the guy who keeps saying in survey after survey that our work sucks -- the guy paying for the house. We distract ourselves by everything under the sun from the continuous conversation and relationship management with the value receiver necessary to make sure we're doing something that the guy writing the check likes.

Sometimes we're distracted in an angry way "Guys! We need to straighten up and do X!" Sometimes we distract ourselves just because of bright and shiny objects "Wow! Take a look at that!" Sometimes we quibble over seemingly insignificant items. Sometimes we take things that should be important and elevate them to the highest level possible.

But the overall pattern is clear. We want to do anything and everything -- except be joined at the hip into the value stream, which is exactly what our job is.

This was the hard lesson that startups taught me: lots of stuff can be neat, valuable, or worth consideration. But a true professional knows that whatever he is doing, he is doing for another human being - and so he seeks to befriend that person, have a trustworthy relationship, and look out after that person's best interests.

That's not nearly as much fun as flipping bits, and it deals with a lot of messy social and human things.

There's also the issue of people being familiar with houses and their limitations, and not asking for a 5 storey house in a 10m x 10m terrain, or that the house automatically lets them in without using keys, or that they want a mansion for 10x less the needed budget

I wrote about the different worlds of people that form the bulk of the CHAOS study and what seemingly is the crowd on HN and Reddit at https://blog.ukigumo.eu/3-types-of-company/

In short, most projects fail because many companies either don't understand IT well enough to take advantage of it or are too focused on IT to understand business.

Also:

A) Phew, almost done with this roof.

MANAGER) Hey, Mr A! When you're done with the roof, can you build another one on top of it? So we can pick it off and use in our next project?

A) But... is it built using same blueprints as this one?

MANAGER) Of course not. Just make to roof so we can fit it on another building. That way we will save time.

A) But that does not make sense. I can build the other roof much faster than we will spend time transporting and adapting this one -

MANAGER) Of course we will save time. You used nail-o-matic 2000 didn't you?

A) Yes, but that doen't have anything to do with who long...

MANAGER) Good, good, now get going, build me another, reusable roof.

MANAGER: (Gets out brochure from a construction firm) See this Whiz-O-Matic armor-plated flying roof with squirrel attack system? Just make it like it looks in this picture. Come on, guys. You're professionals, right? This kind of thing must be trivial for you.

"Well, I’m a carpenter, so I’ve worked with all kinds of wood, you know, and there are some differences, but I think if you’re a good carpenter …"

In my experience, a good programmer in one language is very likely a good programmer in another language as well. There are a lot more commonalities than some people realize. That's the reason why I'm sceptical of claims such as "the programmer knowledge half-life is X years".

More in "Programmer Knowledge" http://henrikwarne.com/2014/12/15/programmer-knowledge/

I'd rather hire a programmer that knew many languages than one who only knew one language really well though. Once you've learned a few frameworks and languages, you get much better at picking up new ones quickly because you've seen the same concepts somewhere else already.

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 what they don't know, and require much more guidance as a result.

So my reasoning is that if you know some Java you can pick up C# easily, if you know some JavaScript you can pick up Python easily etc. If you've stuck to a single language, it's going to take you much longer as you're having to learn new concepts and it's also rare I work on projects where only a single language is being used. Everyone should aim to learn enough languages that they have at least some experience of OOP, functional programming, dynamic types, strong types and SQL in my opinion.

Do you REALLY care if someone knows how to make the PHP interpreter segfault? How to create garbage collection cycles in the JS interpretter? etc.

What does knowing a language inside and out really gain? "Oh yeah, Java totally does covariance in generics by default, but not contravariance" Is this really useful knowledge?

I don't agree with that. If you understand the mathematics and computational foundations, then you already have the depth of programming languages in an abstract form. You might choose to pick up new languages because you want to learn how others elegantly can solve the same problem on a different level of the machine.

Then you can apply similar techniques in whatever language paradigm you have to work in, while also understanding the pros and cons of such a thing (are you just mimicking the paradigm or on what gradient is the implementation correct? What can you assume now from tweaking the language?)

A programming language is not really a separate thing from the machine. It's useful to think about them in this way because it makes the knowledge simple and easier to make fast assumptions given some 'correct usage' of the language with regard to the specification and design of it.

It's just different stuff that each programmer has to pick up as they go. Everyone who is building anything has to do some thinking while they are building and do some remembering while they are building.

I find when you reduce all technology to this level, it becomes very hard to determine what proficiency is. Every bit of knowledge and piece of experience is potentially valuable at the same level.

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 I did in a week. That something involved web pages, polling data through a restful interface, projecting coordinates, tweeting, and a few other moving parts.

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.

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 languages and what it tries to solve. The experience makes me more aware of the problems that Ruby tries to solve so that I can use it better.

I see a lot of people who know three or four languages, but don't understand any of them really well or the underlying concepts. Or they'll focus over-heavily on the algorithmic side of the craft and neglect maintainability and readability. I see a lot of Ruby that looks like C.

When I finally do start branching out and learning new languages, it will be on a totally different level. I'll be diving into the entire ecosystem of the language and not just struggling at the surface.

But before that, I want to learn how Rails really works. I think I understand the difference between a library and an application, now I want to understand what a framework is and how one is built and maintained.

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.

So is jQuery a library or a framework? I've seen it called, and used, both ways. It's not a hard and fast definition, and that's what I mean by "really understanding" something. I want the things I build to be able to be used in any way that it would be useful. It's the fractal landscape at the boundary between the definitions that I'm interested in.

I find myself refactoring code a lot, pulling pieces out and putting them elsewhere. Sometimes I think, "this piece would be better as a gem", or that "this gem needs to be its own application.

When I think about the overall thrust of what I'm doing, I get the sense that I'm building a framework. I need to be able to work web applications into the framework, and the only framework worth really using in this fashion is Rails. But Rails isn't intended to be included as you would a library. I need to understand it better if I'm going to be able to work it into my own framework.

I believe that jQuery is neither - it's a collection of tools to assist with programming webpages in whichever paradigm is appropriate for that particular task.

This approach gives the advantage of ceding ultimate control back to the programmer, at the cost of some internal inconsistency.

That's an interesting view. I can't think of jQuery as a tool. I have a collection of tools I use, I find a tool to be quite different from an application, a library, or a framework. Sublime Text is one of my tools. So is git. I also consider Ruby a tool. My laptop is a tool. I have some git-x commands that I've been slowly building on that I use collectively as a tool.

To me a tool is an extension of one's mind or body that goes into all projects that you work on. I can give away an application or a library. I can't give away a tool, or at least, it wouldn't really make sense to. I want to use all my tools to build a project, all my projects to use the same tools. That's why I stick to Ruby rather than bouncing around. I use Coffeescript/jQuery on web projects but I consider it a kludge, though not as much of a kludge as using Opal would be. I'd want Ruby integrated tightly into the browser before I'd prefer it over Javascript. I don't mind Coffeescript because I find that if you stick to a certain convention, Coffeescript is as easy to maintain as Javascript and I prefer the terser syntax.

My ultimate goal would be to be able to hack on all my tools like I hack applications. For example, I'd love to be able to replace Sublime Text with redcar, an editor written in Ruby, I've taken baby steps in that direction with my git scripts. I haven't decided if it would be better to write my own editor though. I'm probably at least a few years from that being able to integrate that into my workflow.

I'll expand on this with my understanding.

Library - a collection of useful things. Framework - a collection of things, and a methodology, used to structure your application.

In general, a lot of new, modern frameworks do 'call you' (Inversion of Control). Exmaple: Most PHP frameworks are setup so that you put all your models in one folder, your routes in another, etc. Then the framework itself accepts requests and determines which parts of your code to pass it through, and in what order.

However, you can also have frameworks that don't do IoC. You setup the framework, tell it what to do, tell it how to do it. But you still structure your code around that specific framework's methodology (which is why it's hard to mix 'n' match).

jQuery is an odd thing, because it's not really either of these. It provides lots of useful functions, but it also does so in a way that it replaces a lot of the 'core language features', and causes you to use it across most of your code.

However, I'd still say it's a library (with a very nice syntax) - since it doesn't tell you 'this is how you structure your application'. You can use jQuery how ever you like, and it imposes almost no constraints. Therefore it's not a framework.

jQuery is a library. Rails is a framework, but many of the components of Rails are libraries.

I think that programmer knowledge has a short half-life, but not so much programmer skill. I agree that programming well in language X and programming well in language Y are very similar (unless perhaps X and Y use radically different paradigms), because programming well is a skill. But there is language specific knowledge you need to pick up; it's just relatively fast to learn and you can bridge the gap with references.

I think this is generally true, although I think there are a couple of languages that are exceptions just because they're so ridiculously complicated. C++, for example. A very practical language, but there are so many gotchas and traps in that language that most people learn the hard way, when they're debugging a corrupt virtual table jumping into god knows what. The thing is, there's probably like 5 people on the planet that actually completely understand all of C++.

Anyway I think most programming language knowledge transfers well, but for some languages years of expertise actually means a lot.

Stolen from http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...

The source is listed at the end of the joke so at least there was some attribution.

I find that in this age of no one reading past the inferred end of the article, it's best to put attribution at the top so as to avoid this very confusion. Just my two pennies.

Anyone who provides a reference on a web page to another web page without making it a clickable link is doing the internet wrong.

Accurate, but missed the part where the carpenter is asked to build a cabinet by drawing it on the whiteboard.

Yeah exactly, was once given pencil and paper and asked to write some code. That was early on in my career, so even though i knew it was ridiculous, i didnt have enough confidence to tell them they're being idiots. At this point in my career however, i'm far more jaded about stupid interview techniques like that and will refuse to do them unless provided with a computer.

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 function outside of the current abstraction level without writing it as long as they say what they're doing.

If you can't write out an algorithm or some classes that work together without a compiler/interpreter, then you're just guess and checking as you work and not thinking through what you do ahead of time. I can't program without google, but I can write out my implementation just fine -- that's what people are interested in.

I don't really get how I'm being an idiot wanting to explore how someone solves a problem in the medium they work (code) -- I'm not a human compiler so I obviously don't care if their program compiles or is even in a real language, as long as it gets across what they are trying to do and how they would do it.

Also -- you'll need to deal with stupid people forever, the way your comment is worded it sounds like you think you're smarter and better than everyone else and are "above this silliness". When interviewing I'm jaded about people who can't interact with people who they view as "below them" -- you'd hopefully not even make it in the door for an interview if you can't politely answer a question you think is dumb. Like 90% of interactions for software developers outside of their dept are answering dumb questions...

I may need to add dumb questions to my interviews to catch this...

Edit: Also -- can you explain the code you've written/your implementation? How do you include me in your problem solving? What type of questions do you or don't you ask while doing it? Where do you start/how do you start? If the HR person is there, can you explain what you're doing to them? How do you take suggestions? How do you break down your objects (this gives soooo much information about background, I can tell a lot about a developer based on how they name their classes, like people who have worked with only activerecord style classes). I can follow up with a refactoring change (substitute this for that in this situation, decide based on a configuration file - does this require a significant redesign?)

I mean come on... it gives so much information about how someone works, I think its dumber not to ask some type of question with writing "code" - it just gives so much information about a candidate that would be hard to get one question at a time. This one question can infinitely expand and lets them interact about something they know/are comfortable with (the solution to their problem).

Don't be silly.

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 for you since you may be avoiding some false positives, but that doesn't mean your particular method is "the only way."

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.

For people early in their career, a job interview can be one of the most stressful experiences in their entire life. I still remember every interview I've had. Writing code on a whiteboard with "everyone's eyes on you" can be extremely stressful for some people. I know brilliant coders who get absolutely paralyzed at the thought of having to present to an audience. (which is what whiteboarding during a job interview is, the social dynamics are entirely different when you're working with a co-worker on a problem)

If 99% of a coders job will be sitting at their desk cranking out code, why put some much emphasis in the hiring process on how they perform in extremely high stress social situations? The skills that make someone a great interviewee do not necessarily line up to being a great coder. If someone wants to up open their favorite IDE or VIM and show you how they code, why not let them? Personally, having dysgraphia, I would offer to open a text editor to write psuedocode rather than use a writing utensil.

Of course, every hiring situation is unique. If your developers are regularly required to present to clients, investors, or inside management stakeholders, then whiteboarding could be a valid hiring test.

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

If someone can't interact with colleagues to solve problems, and can only work when alone with the computer, it greatly limits the ability to work as part of a team.

Collaborative white board discussions are a pretty common part of many software development teams.

I'm not a pro at hiring, but I have a very different approach based on what ultimately ends up being useful in an employee over the longer term for us.

If you're building a garbage collector, or a high performance graph database, then by all means, ask your candidates to whiteboard algorithms for you. Fizz buzz the crap out of them. In fact hiring for that type of position must be ridiculously hard and I'm not qualified to address it.

If however you're building CRUD apps in Rails or SPAs in React, you may want to take a different approach. One that prefers maturity, discipline, and self-motivation over pure intelligence or proficiency with Haskell.

This comes from personal experience hiring very smart people who lack some of these other values. It's never worked out well in the long haul.

I also think that there are a lot of really smart people who will just suck at those algo type interview questions because it can be a bit nerveracking and as you can already see from some replies to this thread, it can be taken as offensive (even if you don't think it is). Making your candidate (more) nervous and / or defensive and you're limiting your ability to find out about their other virtues.

I agree but usually the type of questions I asked are geared towards what I'm interviewing for. Whiteboard problems are just jumping off points, from there the problem can go so many directions based off of that person, their experience, what's important to them, etc.

For a CRUD full stack app, you're right I really don't care about your ability to write a search function since SQL will do that for you just fine - in fact, for the most part algorithms are probably not even part of the interview. I may ask them to still start solving a really simple problem -- it may or may not make it all the way to code. If someone starts writing/mapping out their database first that tells me something, I can ask why they are breaking their objects where they are, etc.

I like to ask "what's important" in the context of components - I use the example of a bunch of HTML documents to frame the context. If I'm looking at 10 similar HTML documents, what can I do to find important information? (Strip out things that are the same). So if I'm doing 10 interviews, what do you think is going to be the same (user/session management if there are accounts would be an example) and what do you think will allow you to differentiate yourself? For some people, they'll think about what they're strong in and how it applies to the problem, for others they'll focus on the problem space.

At this point you've spent 15-25 minutes talking if they're a good candidate and written no code by starting with the "write code" question -- I think you could get a great 60m interview without writing any code even though you started with a "write code" problem.

My opinion on interview questions is they're just conversation starters -- if you just go down a list of questions I just don't think its a successful interview. I really like VERY open ended questions where the candidate can have a chance to tell me why they're great. I really try to only have 3 or 4 questions for the interview and hope to only get to 1 or 2.

This is sensible. I tend to do a similar approach based on going over some code they have written and their decisions with them.

The point of whiteboarding isn't to "build" correct/functional code - it's to get an idea of your thought process and how you go about solving a problem.

It's not perfect (and there are both advantages and disadvantages to using a computer instead of a whiteboard) but when done correctly it gives a lot more useful insight than sitting there asking questions about their past the whole time.

Which would be perfectly valid if software developers spent their entire day solving problems on the whiteboard. But we don't.

At my first job this was very common. Usually it was more related to schema design and class hierarchies. But there were always white boards full of diagrams of whatever we worked on. We had folders full of digital photos of white boards as reference material.

I'll never forget how excited the lead dev was one day when he got some markers that would automatically make a digital file from whatever he drew on the white board.

Whoa, something like this? https://www.schoolsin.com/qrt-kapture-digital-flipchart-pen/...

I did not realize accelerometers/gyroscopes/whatever were capable of that.

Imagine you were in charge of casting for your community theater's production of Hamlet. How would you decide who to cast?

I'm guessing you would find it sensible to hold auditions. Does an audition perfectly mimic what they would actually spend their time doing come showtime? No. There isn't an audience, the lighting and acoustics are different, nobody is wearing costumes, everyone is standing in the same place instead of moving around, people are reading from scripts instead of having lines memorized, etc.

The audition isn't intended to mirror a performance - it's intended to give some insight into how someone may perform. Likewise, whiteboarding isn't intended to replicate a typical day in the life of a software developer. It's intended to give a glimpse into how you solve problems.

As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises and basing your decision just on how well they answer questions or what their background is. In fact the whole point of the post you're commenting on is to point out the foolishness of basing hiring decisions solely on having X years of experience in Y technology.

>As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises

Whiteboarding vs no coding exercises is a false dichotomy. There are ways to test coding in a 45 minute interview that don't involve standing in front of a whiteboard, writing with a marker.

> Whiteboarding vs no coding exercises is a false dichotomy.

Sorry, it wasn't my intention to suggest those were the only two options (I was attempting to comment on the benefits of coding exercises, regardless of method).

Using a computer is certainly as good or better than a whiteboard. Though one of the bigger downsides to using a computer is there's generally this expectation you need to write "real" code that actually compiles and runs and so the focus becomes as much on writing syntactically correct code as about how you solve the problem (when only the latter has value).

In the jobs I've liked, I do. To be more precise, I solve the problem on a whiteboard, and then type out the solution at the computer. The more experience I have, the less often I encounter gotchas while typing that I missed at the whiteboard.

The distinction matters. Are you an engineer or a tech? An architect or a laborer? Often, software developers end up being both (just as carpenters often end up designing and building). In particular, if you want your developers to be both, then you should make sure they can.

Why is thought process relevant? Different people have different thought processes. I would estimate that recruiters would bias to hire candidates that have similar thought processes to themselves, even if that doesn't correlate well with actual work performance.

> Different people have different thought processes.

Nobody is saying otherwise. The point isn't to make sure your thought process is identical to the interviewers (good interviewers will be more impressed if it isn't), it's to make sure you have one.

That may sound silly but read Jeff Atwood's thoughts on FizzBuzz[1] to realize how many "programmers can't program." Coding exercises are used to make sure you know how to think through a problem and solve it.

> I would estimate that recruiters would bias to hire candidates...

I'm not sure if you used the wrong word or not, but technical interviews are usually done by engineers or engineering managers, not recruiters. But yes, if I were interviewing somewhere and I sufficiently solved a problem but they didn't like it just because my thought process was different I would consider that a red flag.

[1] http://blog.codinghorror.com/why-cant-programmers-program/

Even when I'm in a discussion using the whiteboard at my current job its not like I'm up there verbalizing every thought that comes to mind as I write. And typically in these sessions I'll be completely silent for a majority of the time.

What you get isn't useful insight. It is the appearance of useful insight.

Not a great analogy though, since the programmer output is text, not a physical object.

Actually, a carpenter who is asked to build a cabinet will start by asking you about what kind of cabinet you want, and a sketch on a whiteboard will work as well as anything else.

Where is it going to go? How big should it be? What's the purpose? Is it going to be built-in, or standalone? What's your budget? Do you want doors, and if so do you want glass in them? Shelves? Drawers? Some combination?

Are there exsting cabinets or furniture in the room? Do you want the style matched, or the woods matched, or both?

All of this stuff goes into the specs for the whiteboard... oh, and you don't know enough about this that "cabinetmaker" is a serious specialization, you should really have put that down as the job title and you should be looking at a portfolio of their work.

So not so far off, really.

Two points:

First, nobody expects a cabinetmaker to draw a to-scale, installation-quality blueprint on a whiteboard like many companies expect out of whiteboard coding exercises.

Second, a cabinetmaker's portfolio will consist of multiple photographs of completed jobs. It will likely not include detailed specifications of the jobs or records indicating what specific parts of the jobs this cabinetmaker was responsible for and what other carpenters did. It certainly will not include the ability to inspect the actual work done. This industry expects candidates to have a portfolio such that this level of inspection is possible.

Regarding your first point it's extremely rare in my experience to have an interviewer expect perfect/compiable code when whiteboarding (nearly every whiteboarding exercise I've ever done has been prefaced with the interviewer explicitly stating this). They're looking for how you go about solving a problem, they don't care about missing semicolons.

As for your second point, just because the ability to easily "inspect the actual work done" is not practical in one profession doesn't mean it shouldn't be considered in a completely different profession where it is practical.

> Regarding your first point it's extremely rare in my experience to have an interviewer expect perfect/compiable code when whiteboarding (nearly every whiteboarding exercise I've ever done has been prefaced with the interviewer explicitly stating this). They're looking for how you go about solving a problem, they don't care about missing semicolons.

The interview instructions Amazon gave me prior to my in-person interviews specifically said my whiteboard code would be judged on syntax and that I was expected to produce working code, not pseudocode. They are not the only company that has said this to me, so I do not think it is "extremely rare".

> As for your second point, just because the ability to easily "inspect the actual work done" is not practical in one profession doesn't mean it shouldn't be considered in a completely different profession where it is practical.

For a large portion of programmers, it is impractical. The only way most programmers have representative examples they can show that level of detail in is to do professional-quality work outside of their day job. Expecting them to do so is unreasonable.

This.

A better analogy of what Whiteboarding can effectively used for: "On this job, you'll have to apply varnish in these certain places with very low ventilation, directly above a daycare, what techniques could you use to minimize fumes?"

(problem solving...)

I like the metaphor and style, but I think he left some good parts out. Such as (and yes I was asked these):

- The ridiculously broad yes or no honor question (e.g. "So are you familiar with data structures and design patterns?”)

- The ridiculously specific-to-the-company question (e.g. " Here is a batch of the data our systems generate. How would you process it for triggering of requests to our api?")

- The vaguely worded trick question: "OK that looks good... But how would you do it if you didn't have all these nice Java objects and methods?")

- The Prove-it Take-home that doesn't change anything. "We use ruby and you've mostly used Java, do this ruby take home assignment." Two days later. "Your assignment looks great but we're really looking for someone with more Ruby experience."

- The post-coding interview, resume-based rejection AKA "why the fuck did you ask me to come in in the first place?" rejection. (E.g. "Your coding interview went well but you've jumped around to different projects and we're not sure you wouldn't leave us if given the chance.")

- The didn't drink enough kool-aid rejection. "Don't know the CEO's full bio? Don't know the intricate details of our public API? Didn't read our blog post from this morning? For shame."

This answer on Programmers Stack Exchange sums the problem up very nicely:

http://programmers.stackexchange.com/a/1847

> A common HR thing that drives me nuts when I'm job hunting: the implicit assumption that all coding skills are language-specific, that there is no software engineering expertise that transcends command sets. That ten years experience in Java and another five in Perl mean you'd be completely useless on a project that uses, say, C#.

> "Yes, there's a learning curve. But I've made harder transitions than this. I'll make you a deal, pay me 80% for the first month and at the end of that time if I'm not ... oh, wait, we're not actually having this conversation, because your HR monkey simply deleted my application."

I think that's why a lot of companies are now doing contract-to-hire. First they let the contracting agency do the pre-screening, and if the employee doesn't work out the contract just doesn't get renewed.

Only problem is for the employee -- it is difficult during the contract phase, if they don't get any feedback if they will be converted to an FTE, and the lack of benefits. So for the hiring company, they will no be able to steal away any good developers who are currently fully employed.

This actually will happen if you speak with an HR rep for insurance predictive modelling:

-So do you have experience with SAS?

-Yes, but mostly I model in R. They are sister languages.

-So how much SAS, how much R?

-Mostly R as it is widely held to be a superior language

-But SAS you can do more with!

-Ahh, if Big-Famous-Tech-Company-X wanted to do stat modelling they use R, not SAS. Again, anyone who does statistical modelling knows this.

-But we pay for SAS

-Yeah, sorry about that...

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.

No, it is not like that at all. It is like asking a Carpenter to build a cupboard and thinking he's unqualified for the job if he's only ever used Craftsman screwdrivers because that means he can't use Husky screwdrivers.

Its also like deciding to hire an HR guy based on what brands of keyboards or pens he's used.

> It is like asking a Carpenter to build a cupboard and thinking he's unqualified for the job if he's only ever used Craftsman screwdrivers because that means he can't use Husky screwdrivers.

I get what you're trying to say and I agree 100% it's foolish to make hiring decisions primarily on having X years experience with Y technology but let's not pretend all technologies are as interchangeable as a Craftsman screwdriver vs a Husky one.

Just because someone has a lot of experience working with wood doesn't mean they can do anything with wood well (at least not without sufficient time). You probably wouldn't want Antonio Stradivari to build you a house or Bob Vila to make you a violin.

Are interview questions this irrelevant? Because there are relevant questions you could ask a carpenter in an interview, like if they've worked with I-joists, whether they know what a nailing schedule is, whether they're familiar with a "California corner", their health and safety knowledge, etc.

It is obviously an exaggeration, but Java/Javascript confusion is a real thing.

As you can tell, this article was not written by somebody who knows carpentry. It's also supposed to be funny.

But yes and no, interview questions can be this irrelevant. This is a litmus test. It tells you that you should treat this company as a client, not as an employer, play the expert card, and charge 3x your normal rate. Because they don't know what they're doing, and will likely gladly pay somebody who does know and can explain it to "the suits".

I would say that passing interviews is a separate skill, different than doing actual work. They are not completely different, of course, but different. This implies that the irrelevance is pretty high, otherwise you would not need to prepare specifically for interviews.

That is a serious flaw in the typical interview process. An interview is supposed to screen people based on whether or not they can do actual work. If you are really screening for some parallel skill, then your hires are going to be a crapshoot.

This is true of any job though.

Even though there is a difference between "interview coding" and "real life coding" an advantage of our profession is that we can have interviews that can give more insight into how someone will do their job than just asking them questions. Imagine hiring a manager - you can't "whiteboard" management.

I was interviewing for a webdev position and they had me solve some kind of a crossword puzzle interview question. Clearly if I just practiced messing around with double indexed arrays I would have passed it. But seriously, webdev is mostly about making controllers and interfacing the database. NOTHING to do with how fast I can implement some algorithm.

If you did ask about I-joists, there'd be a series of articles on Carpentry News complaining about how you ask overly academic interview questions. Carpenters with "fifteen years of experience" would talk about how they haven't made a single I-joist since they were an apprentice. If they ever needed to make a "California Corner", they'd just look it up on YouTube and it's pointless to expect them to know it off the top of their head.

They'd then explain that what you really should be asking in the interview is a series of questions about the specific wavelengths of light reflected by different brands of brown paint, because painting things brown is 95% of what a carpenter does and the rest is just wood-gluing together prefab parts from the factory.

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.

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

I think this is true, but it raises a question about "hiring for a specific role."

I find that when companies do this, they're in a reactive mode. Which of course is going to happen from time to time, but the reason memes like the OP get born is because many companies are habitually reactive when it comes to hiring.

I don't follow a lot of sports, but I follow NFL football. Each year, the teams get to "draft" (a/k/a hire) incoming players from college. When it comes to the NFL draft, there are two prevailing philosophies: "Draft for Need" and "Draft Best Player Available". Without question, teams that stick to more of a BPA approach tend to have longer term success. Teams that draft for need sometimes get that player that helps them get over the hump and win a championship, but more often they're trading away long-term greatness for some short-term pain relief.

I think hiring for software teams (and just about anything where there is a lot of variance in depth and breadth of skill) follows the same pattern. Hiring for a specific role is an antipattern (albeit sometimes a necessary one). If you have a very specific role to fill, perhaps a freelancer or a consultant might be a better fit for easing the short-term pain. Then you let them go as soon as they're no longer needed.

This is a really, really cool idea. I think the danger with BPA is that if you're hiring them way too early (like... a year before they'd be firing on all cylinders), then you risk them disengaging and churning out. NFL teams have a constant amount and kind of work that's predictable every season that prevents them from misallocating investments like this - and prevents players from misallocating their labour. Software teams, on the other hand, risk building the wrong thing, and hiring people for problems that won't come about until they build the right thing. Which usually means that those people get antsy (I definitely had this experience, but in a marketing role, which is even more stage-dependent than working dev positions, so I'm probably a little more sensitive to the chance and impact of being hired too early).

This sounds reasonable, though if you hire the Best-Programmer-Available regardless of the presence of a specific technical skill, I'd be surprised if they really take a year to get firing on all cylinders. Maybe a month or two at most would be what I would expect in the sorts of places I've worked.

Sure, some places (especially in startup land) can't even afford to wait even a month, but that doesn't make the dynamic any less of an antipattern. Instead it's just one of the painful tradeoffs people make while they need to manage their runway extra closely.

Then it means that you are applying to a wrong company (already consumed by bureaucracy, with little tech value or understanding)...

I remember my programming interviews as the most meritocratic ones (much more than e.g. in academia, where there is a problem that one is have too low high, or different official credentials).

To all my friends here on Hacker News: Over a few years, I prepared a FAQ document on company hiring procedures for questions that come up here on Hacker News all the time about legal and effective hiring procedures. Most companies use lousy procedures for hiring workers, and that throws away competitive advantage. There is an optimal way to hire, and a century of research on what it is. Rather than repeat all my previous keystrokes here, I'll just link[1] to an earlier version of the FAQ. If you don't want even to follow a link to a very popular comment, let me just pass on here the summary of the FAQ:

EXECUTIVE SUMMARY: If you are hiring for any kind of job in the United States, prefer a work-sample test as your hiring procedure. If you are hiring in most other parts of the world, use a work-sample test in combination with a general mental ability test.

[1] https://news.ycombinator.com/item?id=4613543

I'm happy to answer follow-up questions about this. It's better for companies and it's better for capable workers for companies to learn how to hire smarter.

Last June I started work with a software engineering company that was using meteorjs heavily for their new product and php and java for their main product. Front end was standard jquery. At the time of joining, I had only ever used java, and that too in university for a project on multi threading/parallel processing. In about half a month I was acquainted with the basics of meteor and node js, and within a month I was completely up to speed with the intricacies of the development enivronment. (not all of them. By up to speed I mean, I had figured out where to look when I hit a gotcha). This included mongo db which I had never used till I joined.

I then shifted time to working both on the new product and the backend of their old product. I was using PHP and a framework (I can't remember which one) that I had never touched before. Took me about a week and a half to get up to speed before starting to work on the actual product.

This isn't some display of talent. I believe that any engineer who understands the fundamentals would do exactly what I did. (Provided they are willing to read documentation without skimming through it).

The point here is, I left that company in October. And they've just reopened the position I left vacant. Looking at the list of qualifications and experience required on that list, I couldn't help but think, I would have never thought myself adequate for the job if I had looked at the ad posted since I had never touched any of the stuff they required. Turned out, when it actually comes down to it, it really doesn't matter.

This analogy is actually spot on. Languages really do become another shade of paint at some point. And I never really believed in that till a couple of weeks ago when I saw that job posting. Pretty crazy that as an industry we still believe in this kind of hiring process.

I think you have a great point, although some people are able to do what you did and some are not. Even if some people can do fast just-in-time learning there is value in expertise of the sort described in [0].

[0] http://norvig.com/21-days.html

A clear difference between a carpenter and a programmer is the liability inherent in the work. A carpenter can't just produce a minimum viable product that just happens to break down as soon as a bird land on it, or leaks water as if it was constructed like a sieve. Hiring a carpenter is a comparable safe thing to do, as the worst thing a lawful carpenter can do is overcharge his clients/employer.

A programmer on other hand is not liable for anything. If it breaks or leaks information at the easiest provocation, then its not the programmer who might loose money. All risk is put on the employer or customer, and as such, it becomes their responsibility to identify and test a programmer before spending money. As a result, you get questions which are mostly irrelevant to the task at hand, but which might sorts out high risk vs low risk.

If I hired a carpenter under those conditions, I would ask what brand of paint they buy. If its an expensive one, it might hint towards a professional.

Your logic makes sense, but it seems like every high school I've ever been in or heard about that had just recently been built leaked rain like a sieve.

That's because of flawed design usually. Architects cook up these lovely stylish renderings that the school boards find inspiring (particularly since it isn't their cash), which often involve flat or complex roofs.

Fast forward to the post-construction era, and that inspiring building now has 10 inches of water or ice on the roof. Water being water, it eventually gets in, usually around flashing.

So if a salaried carpenter does a shoddy work, does the employer get reimbursed? I find that very hard to believe.

I really enjoyed the post. I reminded me a lot of this Youtube video(http://youtu.be/BKorP55Aqvg).

I understand this is a comical post but as the son of a carpenter and understanding the profession decently well I would say these are none of the questions that would be asked of a carpenter.

There are however many important questions a person would need to answer to be hired as a carpenter or more likely be able to join a union. There they would be able to get experience and training. Then the company the union carpenter work for already knows the skills and abilities they have and there is really no need for any interview. Any GC or sub asks for guys to do a job. The local sends them the qualified guys. Pretty simple actually.

> I really enjoyed the post. I reminded me a lot of this Youtube video(http://youtu.be/BKorP55Aqvg).

Jesus, that's painfully real.

"...these are none of the questions that would be asked of a carpenter."

That's exactly the point. But it parallels the useless questions so often asked of the general computer programmer by the Corporate HR Recruiter Drone .

They forgot to ask about the deeply theoretical questions that the carpenter wouldn't actually use at the job.

"Now could you whiteboard for me how a table saw is built?"

"I've never had to build a table saw."

"I just want to see how you think."

...and architects sometimes have to go to great lengths before they are allowed to work on your castle:

http://www.fotolibra.com/gallery/698061/hiorne-tower-nr-arun...

...and for sci fi fans who think the Tower looks familiar:

http://www.doctorwholocations.net/locations/arundelparktower

I came across this [1] job posting last week. Made me realize how ridiculous the knowledge and experience expected of a web developer has become. I particularly like bullet 6, "Team-oriented, flexible, and able to work in an ambiguous and/or changing work environment." Really?

[1] http://jobs.hbispace.com/web/95148/job_2-15.html?cacheBuster...

That's a good example of outright incompetence; the author clearly has no idea what they're talking about.

DHTML? I haven't heard that term used in a while. I think can translate that job posting as such: "In order to save costs, we've trimmed all developer positions except one. You will be the sole developer responsible for everything we do. You will always need to be on-call to work, even if it's formatting a Wordpress post for an editor on a Saturday night. You will work long hours but we'll only pay for 40/week, no overtime. Your salary will be peanuts and will not cover the cost of living in Washington, DC. Be a team player and join us."

I have read this before, and I see the source is attributed. If so, why is this link on HN and not the original. Seems a way to gather some page hits.

I think it's a really compelling and quite funny article but to actually make a difference you need the translation. You need the side-by-side comparison and I think people would sit up and go 'ah' and it will change hiring for them.

Can someone write this with the real-world situation so 'brown' isn't a guess at [framework/language/methodology]

Depending on the job; i find the deeper somebody knows his/her special field the better he/she can adapt to another field.

I.e. if you really know the ins/outs of the Java, the VM, changes of the language over time. You will be able to pick up C#, python f.e.

Love it :) Sad thing is that it hit the nail on the head so accurately (pardon the pun)

You really rocked it there.

Very piercing commentary.

Seems like this is the original: http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037...

How can it be "the original" when it states in the opening paragraph I didn't write this, so I can't take credit for it?

Given that both articles on that site were swiped from elsewhere without attribution, perhaps that particular "carpenter" should be asked about theft.

(well ok, one does mention a link to a 404 error)

of course, this happens, but when it happens just end the interview.

would you like to work in such a place?

ouch! As someone who's been on an 8-month long job hunt, this hits too close to home.

No mention of H1Bs in this hiring related post?

I will attach this to my resume.

Just great!

Gold.

I find it a bit less shiny every time I see it.

Reply on news.ycombinator.com