[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.
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 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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).
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.
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.
"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".
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'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 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.
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.
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.
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.
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?"
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."
> 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.
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.
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.
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.
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.
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.
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.
[+] [-] vog|11 years ago|reply
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.
[+] [-] frostmatthew|11 years ago|reply
[+] [-] jethro_tell|11 years ago|reply
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?
[+] [-] freshyill|11 years ago|reply
[+] [-] jonahx|11 years ago|reply
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.
[+] [-] dwc|11 years ago|reply
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.
[+] [-] robotkilla|11 years ago|reply
[+] [-] graycat|11 years ago|reply
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.
[+] [-] lordnacho|11 years ago|reply
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.
[+] [-] prostoalex|11 years ago|reply
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.
[+] [-] barrkel|11 years ago|reply
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.
[+] [-] ajross|11 years ago|reply
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.
[+] [-] DanielBMarkham|11 years ago|reply
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.
[+] [-] jerf|11 years ago|reply
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.
[+] [-] hobs|11 years ago|reply
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.
[+] [-] alricb|11 years ago|reply
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).
[+] [-] fsloth|11 years ago|reply
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.
[+] [-] raverbashing|11 years ago|reply
[+] [-] ukigumo|11 years ago|reply
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.
[+] [-] k__|11 years ago|reply
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.
[+] [-] henrik_w|11 years ago|reply
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/
[+] [-] alexbecker|11 years ago|reply
[+] [-] seanwilson|11 years ago|reply
[+] [-] overgard|11 years ago|reply
Anyway I think most programming language knowledge transfers well, but for some languages years of expertise actually means a lot.
[+] [-] aw3c2|11 years ago|reply
[+] [-] mtmail|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] spiralpolitik|11 years ago|reply
[+] [-] frostmatthew|11 years ago|reply
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.
[+] [-] dsr_|11 years ago|reply
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.
[+] [-] TamDenholm|11 years ago|reply
[+] [-] atonse|11 years ago|reply
(problem solving...)
[+] [-] henrik_w|11 years ago|reply
[+] [-] cpursley|11 years ago|reply
[+] [-] fivedogit|11 years ago|reply
- 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."
[+] [-] V-2|11 years ago|reply
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."
[+] [-] derekp7|11 years ago|reply
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.
[+] [-] stillsut|11 years ago|reply
-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...
[+] [-] alricb|11 years ago|reply
[+] [-] sjclemmy|11 years ago|reply
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.
[+] [-] stared|11 years ago|reply
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).
[+] [-] tokenadult|11 years ago|reply
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.
[+] [-] nstart|11 years ago|reply
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.
[+] [-] belorn|11 years ago|reply
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.
[+] [-] bmoresbest55|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] pargon|11 years ago|reply
"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."