These days you would be asked to draw a picture of a hammer pounding in a nail on a whiteboard. The interviewer would say, "this isn't about drawing," but if your hammer looks like a dinosaur you're not going to get the job unless you learned carpentry at Stanford.
The thing I've always found funny about job interviews is that they're always "looking for candidates who can hit the ground running," so they'll reject anyone missing one out of the ten required buzzwords. But I've rarely ever worked on the same tech stack more than once or twice per company. My job is to learn almost every day, and to perpetually be hitting the ground running...
The programmer recruiting industry is counter productive, adding less than no value to the people who need coders as well as the the programmers who want to work. Less than no value means they are a net drain on society, as worthless as hiring people to dig holes in the ocean.
These recruiter tactics would be acceptable for food service jobs though. There you would need to find a candidate with a high tolerance for complete bullshit.
The entire programming recruiter industry can be replaced by the following:
Throw a party with free drinks and food, of the people who show up, present a coding test on the board and the first 10 people to submit a correct solution gets on the short list.
And if you are so poor and can't do that (HR is vetoing), just do a basic coding test online. Of the people who submit correct answers, short list the best ones.
But perhaps I'm wrong, perhaps social skills are more important in programmers than coding skill.
I'll offer some counter points, but my view point is skewed.
- The best programmers come from all over the world. While it'd be great if they can attend these parties, it's not practical, even if they are within the same country.
- Companies do throw/host a lot of meetups to attract top coders. Top coders are usually kept very happy by their current employers and not looking to leave so they don't usually attend recruiting functions unless they are the ones recruiting.
- If you want to see parties thrown as recruiting events, go to Uncubed in SF. It's a wonderful time, but most people are just entering into the industry, so not many senior level guys.
- * Most programmers I meet at my workplace thought the interview was pretty easy, to which I say "Of course you did, you're here, but think about the 30-40 candidates before you that failed miserably." I meet a lot of skilled programmers that hate coding tests/interviews, the reason? They already know they can do the job, they know they're gonna ace the interview because they're awesome. But guess what? A lot, and I mean a lot, of people that fail thought the same.
- Don't discount social skills. Some roles are more client facing than others, or working with non-technical folks. Communication is key to projects.
I think any programmer that's been a hiring manager will agree there are many senior level people that just can't code,entry level grads with CS degrees that can't write algorithms or figure out time complexity.
This was definitely good for a laugh. And yeah there are many managers who view hiring developers like this. However, I've actually seen a number of interviews go the other way. The interviewer was looking for a developer with a track record of successful projects. The interviewee was looking for a company who used a very specific web stack.
While I agree that looking for a specific stack is dumb, I had to write an ad for a developer recently. It becomes kind of difficult to ask for anything without mentioning specific technologies 'or something similar'.
I work with a very well known Java and Spring based ecommerce platform. I find that people new to the platform, regardless of Java and Spring experience, take a while to produce really good design and code.
You might know the frameworks and languages but sometimes you need experience in the specific platform.
I work in consultancy so I rarely have time to up skill someone into the platform.
That sounds like the platform is relatively complex.
I've seen Java/JavaEE/Spring code where it was easy to get started, since the platform was built as simple as possible. I've also seen Big Balls of Mud where a developer needed months to be somewhat productive. So the question shouldn't be: "Is my platform brown?" But rather: "Have you ever worked on a freaking castle with hundreds of secret passages?".
Sometimes complexity is unavoidable. The interviewer may ask a question like: "What are your experiences with complex code/legacy code?" (If the interviewer is able to accept the reality of course)
I wouldn't say that was brown exactly, but I know exactly what you mean with big ecommerce platforms and all kinds of other vertical-market software. It can take months or even years to learn all of the tricks.
That being said, it is always a gamble. A great programmer might pay off in the long run more than a mediocre programmer who already knows the platform... or not!
I've not seen programmers hired like carpenters, but I worked briefly at a place where programmers were represented by the United Brotherhood of Carpenters.
That was Hughes Aircraft. That weird union representation came about because Hughes unionized during the construction of the Spruce Goose [1], which involved a massive amount of carpentry, so it made sense for the carpenters union to be the union that represented Hughes employees. That representation stuck long after actual carpenters became rare at Hughes.
My experience, which only covers 25 years or so, is nothing like that. It's vaguely funny, but maybe the author has applied for a lot of jobs for which he or she didn't possess qualifications.
Sure, interviewers ask irritating questions. But come on. At Google no one asks you how much Spring 4.x you've used. They ask you very difficult programming problems.
only covers 25 years? That's a long programming career! From what I can gather, the more one steps outside the silicon valley bubble the more these types of interviews are common place.
In a lot of interviews I have been asked detailed questions about tech that is not even listed on my resume. It's like asking a cabinet maker about masonry or electrical. Sure, you know something about it but, probably not as much as someone who does that all day.
Please read the resume before starting the interview.
I must admit, that one hits the nail directly on the head!
That is often times, how management sees programmers: Dudes that must have experience with rocks and brown to fit the job. And that is also the way, they want to pay them.
Wow, was that ever an old-school interview. Something from a more civilized day. Today, our tradesman, a real construction veteran, interviewing at BeigeCo ("Disrupting Subdivisions") would be asked to write the chemical constituents of walnut on a whiteboard, along with its biological lifecycle.
"Hey, thanks for coming in. We're really excited to talk to front porch specialists like you."
"What would happen if you removed all the carbon from the walnut after you built a house? Don't worry, the answer isn't important, we just want to see how you think".
"I'm sure you've done a lot with nails. We're really proud of our nails stack, and our guys do a lot of optimizations. One of our guys even bent nails recently! Steve, who's a little OCD, but a great guy, really wasn't happy with the default round nails from Home Depot so he poured his own, totally square! Now we use those everywhere. We like to see that new hires can come up to speed on that fast. So imagine you were making your own nails, what tools and materials would you use? On the whiteboard, derive the optimal chemical composition for nails you'd use if you were building a doghouse that could withstand a sixteen-ton weight dropped on it from 500 meters 100 times a second."
"Oh yeah, of course I understand this is a front porch gig. Yeah, mostly support columns and floors, we do a lot of floors and we need people like you to nail them together. But we think that cosmology is important to that. After all, all those materials had to come from somewhere! (grin)"
"Back to the nails. No, no, don't use off the shelf chemicals, again we want to see how you think. Feel free to make any alloy you want. Think also about quantum effects and the impact of international taxation. White board's there, don't stress, just give it your best shot."
Later ... (somewhat visibly disappointed)
"OK, great. Well, we like to give our interviewees a little carpentry project that they can take home and work on. We'd like you to design and build a swimming pool that will be filled with not water, but German chocolate. The 100 meter Nutella breast-stroke is going to be the next Olympic event you know! (laughs). So it should be 3m deep and 100m long and don't forget the filtration system for the chocolate. Just work this up tomorrow and leave the pool in our parking lot by 5pm. I know you've got a job and deadlines and, what's that you say, oh a mortgage payment due ... but this is a really great opportunity here. We're really disrupting beige house building. Just think, when Google buys us, you can stop worrying about that mortgage!"<smile, chuckle>."
"Hey, HR forgot to ask, but can you give us the addresses and keys for the structures you've built for free in your spare time. Oh, there's nothing? Kids, I see, they can be a challenge. You spend time at the gym too? Ha ha software projects too!? I didn't know people were still writing that stuff! Anyway that's great, but I've found that our best carpenters really like to see that you've put up some free buildings, the more the better."
"Well, thanks for coming in, and what do you think of our open-air office? We think that getting rid of ceilings and roofs really helps collaboration. We leverage the Seattle rain to get us all huddled together under umbrellas and those water fights can get crazy! The people we hire really seem to enjoy that."
Oh I liked that quite a bit. One of the things I liked about my Google interview, I tried to use this when I was interviewing there as well, was to take algorithms and express them in any programming language you are comfortable with.
Of course if it was carpentry the question would be "Hmm, everything you've made out of wood seems to look like a table, even this house over here." If you wanted to capture that "I can write Fortran in any language" feel.
Do you have any idea how hard it is to sell brown cars these days? If the salesman can sell many of them, he must have something up his sleeves. And, in the end, because of the shortsighted "vision" of whomever happens to be the CEO at the moment, all that matters is how fast and how much you can sell during the current CEO's term so the CEO can reap all the bonus and benefits. Who cares if the end product is crap?
My cousin is a carpenter in Germany, and he sure constructs a lot of houses. Often just parts, mainly the roof, but complete wooden houses are gaining popularity as well.
Ok. I extrapolated too much, and stand corrected.
Stone is used as primary material in Belgium, Luxemburg, The Netherlands, France, UK, most parts of Germany, ...
I see that you have a lot of coping saw experience, and that's great, but... well... we're looking for someone who's a better culture fit. You understand, right? I thought you might. Well, thanks so much!
There's a contradiction. It's that people that want a carpenter with brown experience will NOT usually hire the car salesman with brown experience.
Is this supposed to be about education? Hiring a non-CS major? The people that are obsessed with the keywords are also obsessed with degrees and certificates.
The people that will hire the kid who dropped out of high school are not the same kind of people that need him to have every keyword they're looking for on his resume. Those people might not even require a resume.
This is the worst analogy I've ever read about hiring.
Carpentry is much different from programming. If you're building a subdivision, you're not building 500 unique houses. You build one, then you build an almost-exact copy. But here's where it diverges from programming: you don't get to copy it, you have to follow the exact same steps again. You're not building a machine to build houses and then have it build 500 houses. You're just repeating the exact same thing 500 times.
So for hiring a carpenter, a lot of things that don't make sense when hiring programmers makes sense. For example, if you like house 1 of 500, you can probably hire the same team sight unseen to build house 2 of 500. All they're going to do is the exact same thing they did on the first house, leaving very little room to mess something up unexpectedly. They'll probably do a better job, just from having done it before.
Programming is not like that, because we can reuse code, we almost never solve the exact same problem over and over. We are always coming up with a more abstract problem to solve, because the foundation exists for doing so. (Say you're making two websites. You write the first one. What do you do for the second one? Cut-n-paste-and-modify? I hope not. What you probably end up with is a mini web framework and two things that use that. This makes website 3 even easier than website 2, and website 4 easier than that. That's why we call it engineering and not carpentry.)
Another factor that comes into play with programming is deciding when to build a machine to build houses and when to just build a house. That's "experience".
(A more appropriate analogy might be civil engineering. Civil engineers don't build machines to build bridges, they build bridges, because while a lot of things are similar between individual bridges, a lot of things are different too. Civil engineers abstract the components of the bridge, of course; they're not milling I beams or fasteners or developing new types of concretes from scratch for every bridge. That's like libraries that programmers use. But they are also doing engineering -- what's the right material and right type of structure for the given design constraints? Similarly, it would not be strange to ask a civil engineer if she's ever used concrete when you're planning on building an interstate highway. It would also not be strange to set up an example structure and do some load and material calculations on the whiteboard. While being able to do those calculations doesn't mean she's a good engineer, not being able to do those calculations would be pretty strange. I don't know much about civil engineering, but I hope this analogy at least makes a little sense to other laymen.)
I agree with what you say except that the "joke" is not about carpentry at all, instead we are transplanting some common (?) programmer occurrences into the world of carpentry. So it is not an analogy..
It's like that joke, "what if OS'es were cars?" and then in the linux car you have to bring your own seat or something. Car lovers should not be offended...
But back to agreeing with you: it seems that the world of programming is much more brittle than carpentry. Ie. it is indeed true that someone without vast experience in brown may get tripped up by some rarely seen consequence of brown-ness. Maybe it has a weird interaction with the extra warm weather that causes the wood to rot. Etc.
