I'm not even going to use my stock rebuttal of "correlation != causation" because in the case of #1 through #5, I doubt if we even have correlation. For every example of a good programmer for any of these 5 that OP can provide, I can provide multiple counter-examples. None of these is much of an indicator of anything.
1. How opinionated are they?
Everyone has an opinion, assholes included.
2. How much do they contribute to open source projects?
Many of the best programmers I know contribute nothing to open source because of confidentiality agreements.
3. How much do they enjoy programming?
You mean when it's fun specing something out or at 4 in the morning when everything is down?
4. Do they actually ship?
And what does it cost to maintain or fix it? There are 2 ways to find out. a. Read the source. b. Wait a year. Which would you prefer?
5. What have they mastered?
Who cares? What they do on their own time is their own business. This is an indicator of nothing.
6. How well do they communicate?
This is important for all people, for all things, so it doesn't even need to be on this list.
So, how should a non-programmer hire a programmer?
I have to say I disagree; their list provides some good, sufficient indicators of a good programmer. You appear to have read an assertion that these are necessary qualities into the article, but I'm not seeing that anywhere.
> Everyone has an opinion, assholes included.
Not true in my experience; there are plenty of apathetic floaters who don't care enough to form an opinion about anything. They use what they're told to use, don't look around at anything, don't form comparative opinions, and don't care. They all produced terrible work, because they didn't care enough to form opinions, or look around for better tools and techniques, and so never learned anything
> Many of the best programmers I know contribute nothing to open source because of confidentiality agreements.
Absolutely. But again, it's a good sufficient tell, not a necessary quality.
> You mean when it's fun specing something out or at 4 in the morning when everything is down?
Yes. You want them to fundamentally enjoy what they do. Dispassionate automatons may exist who nonetheless churn out solid work, but in my experience there are far fewer passionate, horrible developers than uncaring horrible developers, so it is again a good sufficient distinguisher to help find a good developer.
> And what does it cost to maintain or fix it? There are 2 ways to find out. a. Read the source. b. Wait a year. Which would you prefer?
c. Contact previous employers/coworkers, see what their reputation for shipping (and shipping quality) is.
> Who cares? What they do on their own time is their own business. This is an indicator of nothing.
It's an indicator of intellectual curiosity. Again, intellectually incurious developers who nonetheless do solid work and stay up to date may exist out there, somewhere, but I've never met one, so it's yet another good sufficient identifier.
> This is important for all people, for all things, so it doesn't even need to be on this list.
If you really believe that, you haven't met a lot of hiring managers who completely and utterly forget about it or think it is unimportant for technical positions. There are people who absolutely need this reminder.
The only way one can hire a programmer is to be a programmer.
That's a awfully large sense of entitlement there, one that is very, very difficult to support. I'm surprised such a comment is coming from you.
While I don't excuse idiot HR recruiters and headhunting firms on quotas, there is a level between clueless and mastery that a person can attain that allows them to make the comparative judgement required in the hiring process.
I know little about law, but enough to hire a semi competent lawyer, I know little about masonry, but have successfully hired a firm to rebuild a chimney. They are probably not the absolute best at their professions. They probably take shortcuts that purists wouldn't like. So be it. They get the job done and that's good enough for me.
There is really no reason that someone with little knowledge of programming cannot properly hire or outsource a competent developer for work that they need to get done.
To suggest otherwise is only to worry about which way the mortar is spread in between the brick, when it all boils down.
That's a awfully large sense of entitlement there, one that is very, very difficult to support. I'm surprised such a comment is coming from you.
Sorry if that's how it sounded; that's not what I intended.
A little background...
I have worked for about 100 managers over the years, and with few exceptions, here's my experience:
- Those who were programmers were able to understand, examine, critique, question, and drive almost anything I worked on.
- Those who were not programmers were able to fit whatever I was doing into their project plan and evaluate it only through the eyes of other programmers (who may or may not have done a very good job of it).
I have also maintained hundreds of thousands of lines of code and I can predict with uncanny accuracy that which was written for a programmer boss and that which wasn't. There is a difference.
There are probably billions (or trillions) of lines of shit code out there that never would have made it through peer review of almost any programmer here at hn. But no one had to worry about that; they were written by programmers working for non-technical bosses.
Hope that paints a better picture of my skepticism :-)
I can certainly attest to shit code getting through non-tech bosses.
It's not just a matter of 'getting away with something' either. A badly managed programmer won't know the larger scope of what they are doing, or even worse be doing something the wrong way because they 'have to', and the code inevitably becomes a series of hacks fixing whatever the latest requirement or problem is.
I enjoy programming both when specing it out AND when things are down at 4am. I would prefer it not be 4am that they be down, but I still enjoy the challenge and feeling of accomplishment when I fix it.
How much do they contribute to open source projects?
I always take issue with this one. Not all good developers are commiters to open source projects and not all commiters are good developers. While I personally would love to contribute to some open source project I use, the area of work I am in makes it difficult to do so. When you freelance it is an additional burden to try to explain to customers that portions of the code you develop on their dime will get contributed to an open source project. Even if they are generic routines that have no direct benefit to the company other than getting the project done. Also given the fact that some of my clients are blue chip tech companies jumping through the legal hoops is a royal PITA. So in the end it is just easier for me to not be a contributor. I submit bug's, test cases, and suggestions but the requirement of my time to CYA myself so that I can contribute some code back kills my ability to do so. I have to imagine that their are a good deal of top caliber developers in the same boat. I think the point of whether someone contributes to an open source project is moot at best.
I wouldn't consider it moot, but I wouldn't necessarily deduct points either. Open-source contribution is a good bonus in a developer; it shows that they have been able to cooperate others (among a group of people that are often unpleasant, ornery, or crotchety) and adhere to the requirements of the BFDLs, which shows adaptability. The big benefit of course if that you can go back and look up their interactions and the code they submitted and how they went about the whole thing, which is definitely useful in determining if the person would be a good hire. It also demonstrates a level of conscientiousness about their place in the community.
So, all that said, there are good reasons a developer may not have many open-source contributions, as you stated. So while I don't think it's good to necessarily detract from developers without that, I wouldn't exactly consider it moot, either; open-source dev is a very useful reference and a good demonstration of the candidate. If you can't contribute, you will miss out on some of those good vibe points, but that's the way things go sometimes I guess.
Sure, I don't believe that it deducts points, I just think that there are so many good developers that don't contribute, that using it, as even the slightest filter of applicants, is going to do more harm than good.
Am I the only one who thinks that the first one is a terrible heuristic? In my experience, people who don't have a lot of experience tend to be the most opinionated. I may just be thinking of the wrong kind of opinionated, but as far as I can tell any programming language's biggest fans tend to be the programmers who only know one language.
I was really opinionated ten years ago, before I had tried to build anything serious. These days, I think every choice is a trade-off. I wonder if I'll ever be opinionated again.
I'm the same way, but I'm going to expand on that a bit.
It's not that I'm no longer opinionated, but I've matured as a programmer. I no longer view any solution as the only/best solution to any given problem. So rather than being so opinionated that you don't concede, I find myself listening to other possible solutions with an open mind and admitting that I'm wrong.
I feel that people who are overly opinionated just haven't matured to the point where they can comfortably say that they're wrong or that another solution exists that performs just as well.
Not only that, but the specific example they gave is even worse.
Ruby vs Python? My only opinion on Ruby vs Python is that I wish one would die so that we don't have two utterly similar languages fragmenting the same niche and causing lots of duplicated effort (e.g., ruby oauth and python-oauth2). Does that make me a bad programmer?
I think you're right in thinking the "wrong kind of opinionated".
I'm pretty f'ing opinionated about certain things and those are not trivial things - testing for instance.
I'm also opinionated about languages but I can clearly articulate why I would choose python over ruby and vice versa in any given situation. Same goes for rdbms vs. schemaless data stores.
Some of my favorite and best interviews have been geeking out discussing technology with a potential employeer.
What was really left out was "make friends with a trusted geek". Have someone you can call on to perform the interview on your behalf. I have pretty solid bullshit detector and have frequently helped out friends who couldn't find a technical resource to perform a phone screen.
Maybe they should have drawn a distinction between "Opinionated because they're ignorant" and "Appears opinionated because they're committed to principles which may be inconvenient."
I agree with you. I almost stopped reading the article at that point, because it will tend to get you clueless zealots rather than competent engineers.
Like religious fanatics very opinionated programmers will argue endlessly over trivial matters that in the end make no difference, wasting valuable time, all because they can't just let their arbitrary preferences go and are obsessed with winning every argument due to their autism.
2. How much do they contribute to open source projects?
Those who contribute a lot of free work without compensation don't have much business sense. You also have to worry they will contaminate your code with GPLd code that they have secretly reattributed.
3. How much do they enjoy programming?
Those who are very enthusiastic about something are usually very new to it and don't have much experience. If your oncologist was jumping up and down and clapping when discussing your tumor because he is so excited to see this form of tumor, would you want to use him, or assume he is either insane or fresh out of med school and has not seen many tumors yet.
> Those who contribute a lot of free work without compensation don't have much business sense.
Yeah, just like a writer who blogs, a soccer-mom who drives all the neighbourhood kids to practice and basically anyone who ever volunteered their time or resources for anything have no business sense. It feel like 1999 all over again, but here goes: Rewards comes in other forms than money.
> You also have to worry they will contaminate your code with GPLd code that they have secretly reattributed.
Frankly, I'd be more worried that a person not familiar with the workings of the open source community would be more at risk for making this kind of mistake. Why would copy-pasting this method I found in the open on teh interwebs not be OK? And who's ever gonna find out?
Not so much that they'll secretly take GPL'd code, but they'll just dump it in without telling you and then 2 years later when somebody finds it in your widget, it's a major pita figuring out what's happening.
This is far likely to be done by someone with little or no open source experience. Anybody who has worked with open source code knows the basic difference between GPL, LGPL and MIT/BSD and what you can and can't do with the code. Someone who hasn't worked with open source software is far more likely to go blindly assume that "open source" means I can copy and paste this any way I want.
Some of the "soft" questions I've recently started asking interview candidates:
What computing blogs / magazines do you read? - To see if he keeps up-to-date on trends in technology.
What are some of your favourite languages? What do you code with in your free time? - Not just to gauge passion, but also to see how diverse his toolset is. Someone who knows Java, Clojure and Matlab is well-rounded. Someone who knows only Java, C++ and C# is not.
What do you dislike about your favourite language? - To make sure the guy isn't a religious nut, since we probably don't use his favourite.
Who are the key people in your field? - For a given topic the developer is passionate about, there should be someone whose papers he's read plenty of times.
Why did you leave your last job? - Pretty standard one, but always key.
I also require a cover letter of everyone who applies, plus I tell recruiters that I want the resume in LaTeX. In addition to gauging writing skills and technical adeptness, those two requirements are a pretty good filter against spray-and-pray applicants.
Someone asked me this fairly recently, but he said "what technical stuff do you read?", which I had a pretty hard time answering because I think my definition of technical was much stricter than his. He mentioned that I had written about Joel Spolsky, for instance, but Joel is not really a technical writer -- he writes about business, etc. within his technical company.
I ended up just saying "whatever's on Hacker News, basically", because I don't really follow any blogs regularly any more. I should have said Lambda the Ultimate, I guess; that used to be on my feed reader (still is, but I never use feed reader anymore).
Or you can just learn a simple programming question or two that you can ask them to write the answer to. Example:
string itoa(int i)
{
//convert integer to its string representation
}
In my experience this will tell you enough about the person's proficiency to make a decision. I've seen so many people fall apart on this question in so many different ways it's not even funny. The ones who get it have all been pretty good hires.
The glibc implementation of atoi basically just offloads to strtol, which just offloads to strtol_l.c, which is pretty complex at first glance.
You're basically testing to see if people know about casts, right? I'm not a big C developer and most of the languages I spend most of my time in have much less onerous typing systems than C, but if you gave me this question I would probably just write something like:
return (int) char;
perhaps including a loop to read to the end of char*. Would I pass or not? I don't think I'm that bad of a programmer, just don't have a lot of direct experience with C.
1) In this scenario you are implementing that mechanism. Casts don't work via magic.
2.) C isn't required. The functions use the C conventions for naming. That's all.
3.) That solution would never work because it would return the ASCII value for the character.
The solution requires that you go through the string multiplying the value you get by the next power of ten and adding it to what you had before. You work from the 1 position back to the front of the string. You also need to ignore non numerical characters.
Can I see a functional implementation just for educational purposes here? I don't understand really because I have casted things in C like that before (not in lieu of atoi() with (int) char as shown, but other datatypes) and because in my experience, when I have a read out a string, I have not gotten an ASCII keycode, but the inputted character. Most of my C experience has been on existing open-source projects, so maybe they'd already implemented stuff that glossed over all this.
That said, I don't really understand why this should be a consideration for the programmer at all. C's type system seems to get in the way and slow things down almost as much as it helps (again, limited C experience here) and I don't think that's how these things should work.
Castings in c doesn't perform type conversion, regarding the implementation just consider that every ascii char has a numerical code (it's int value) and that in the ascii table the numbers are adjacent.
I think that might work. My method makes more sense to me but that's because it's just the first thing that came to mind when thinking about the problem.
Your method means you only need to walk the string once which is better. Either way 9/10 interview candidates can't even get that far.
as jswinghammer says you have to implement the mechanism that does this. when you do, don't forget negatives, trailing and leading spaces, and non-base-10 numbers (last one is not a requirement).
Learn the answer. It's not very long. You can have some followup questions like "How would you test this?" or "What range of values would this work for?". Most of the time people don't even know what range of values can be stored in a 32 bit integer (or even in the general area). It's pretty easy to learn 3-4 facts to know more than the people you don't want to hire.
What's that have to do with anything? In my example the function returns a type of string which doesn't exist in C.
The simplest version of the function is one that takes an integer and returns a string. This isn't a trick question and it's not difficult to answer or judge the answer if you take the time to learn it. Assuming that you're going to be hiring a programmer without one handy to help you then you need to read a few books and learn a few things. It's not that hard if you're sufficiently motivated to learn.
I was illustrating the point that even the most minor of things can have many completely different looking but acceptable solutions.
There's way way more than "one or two" ways to solve it if a non-programmer is judging. Non-programmers won't have a command of the language necessary to parse uncommon syntax and idioms.
If you define the parameters correctly there are really only two ways to solve itoa that I know of. Problems like this always have rules and boundaries.
Besides the people who this question would screen could not tell you what an allocator might even be.
I've asked this question 100-150 times now and I think I've seen everything at this point. The working solutions all look the same or pretty darn close.
Yea but there may be an unbounded number of approximation methods that aren't the textbook answer but still diagnostic of competence on behalf of the answerer.
I want a solution to the problem on the terms I defined or they have to give me a pretty good reason why they can't solve it. I usually give tons of hints and let them ask many questions. This never helps those who can't program.
For a non-programming recruiter it is way to easy to get impressed by a good talker who knows how to throw in appropriate buzzwords in a conversation. You can judge communication skills, but how on earth would you judge whether the prospective hire can code correctly if you cannot code yourself? IMHO the best way to go is to find a fried of a friend who is a programmer and get an opinion from him/her. It would also not hurt to run a candidate through 3rd-party test that require actual programming (my favorite is codility.com, but there are several other websites that provide similar services).
A novice programmer probably doesn't have enough experience to create any informed opinion.
A slightly experienced programmer is probably very opinionated about his tools.
A very experienced programmer knows there are trade-offs in every choice and isn't so passionate about voicing his specific opinions on the choice between 2 similar duck-typed programming languages.
37Signals is so overrated. I hope more articles like this help change the general perception about them.
It's not that I don't appreciate their contributions or think they're a fine/nice shop or whatever, but the hype that goes into their stuff is a little ridiculous for serious developers I think.
1. How opinionated are they?
Everyone has an opinion, assholes included.
2. How much do they contribute to open source projects?
Many of the best programmers I know contribute nothing to open source because of confidentiality agreements.
3. How much do they enjoy programming?
You mean when it's fun specing something out or at 4 in the morning when everything is down?
4. Do they actually ship?
And what does it cost to maintain or fix it? There are 2 ways to find out. a. Read the source. b. Wait a year. Which would you prefer?
5. What have they mastered?
Who cares? What they do on their own time is their own business. This is an indicator of nothing.
6. How well do they communicate?
This is important for all people, for all things, so it doesn't even need to be on this list.
So, how should a non-programmer hire a programmer?
a. Become a programmer.
b. Hire a programmer to hire a programmer.
c. Punt.