We are a commune of inquiring, skeptical, politically centrist, capitalist, anglophile, traditionalist New England Yankee humans, humanoids, and animals with many interests beyond and above politics. Each of us has had a high-school education (or GED), but all had ADD so didn't pay attention very well, especially the dogs. Each one of us does "try my best to be just like I am," and none of us enjoys working for others, including for Maggie, from whom we receive neither a nickel nor a dime. Freedom from nags, cranks, government, do-gooders, control-freaks and idiots is all that we ask for.
There are three things you need to determine about a candidate: talent, judgement, and personality. Think of hiring an engineer as if you're buying a race car. The first thing you must look for in a race car is horsepower, because without horsepower the car is useless for racing. The horsepower of engineers is talent. Without talent, engineers are useless for building products, so it's the first thing you must look for in a candidate. It doesn't matter how nice the person is, or how hard-working. No horsepower, no race.
Talent alone is insufficient. The world is filled with talented people who never get anywhere for a myriad reasons. Laziness, anxiety, fragility, impulsivity, egotism, victimhood, just to list a few. So once you've identified talent, you have to determine the shape and quality of its vessel. Where will the person direct their talent? And are they well-adapted to the demands of the external world?
I am reminded of a lunch interview I had years ago. I had worked for a startup for 3 years, starting at a lower position and salary and with OJT, worked myself into a better compensated and more responsible job in creating databases. All OJT- had never done any DB stuff before. The owner decided to liquidate his assets, and sold them for a nice profit.
Thus my need for a job. My interview was with a small company in the same field. I was initially nervous about the interview, but after going the night before to the restaurant where I would be interviewing, I decided to simply treat the interview as talking shop, and my nervousness disappeared.
At the interview we compared notes on where to to get the data necessary for the job. Similar experiences and conclusions. They asked me, "Can you do such and such with the data?" I had and could [self-taught], so replied , "Yes." I then explained how to do it and some things to look out for.
Several hours after the interview, I got an e-mail with a job offer. They talked about my "can-do attitude." It wasn't bravado- I had done it.
Engineers, we be strange beasts. Very strange. Which side of the table are you sitting on? That makes a huge difference. One side you're selling yourself, the other trying to figure out if you're being lied to.
The original article is good for one side of the table, Gringo's comment is perfect for the other.
Also be aware of the level you are looking for. If the interview is about a Principal or above engineer, don't make them write a recursive algorithm on the white board. Just assume they know how to google stackoverflow for a bunch of answers.
All interviews with engineers need to take place in a room with at least one whiteboard that can be erased and a full complement of working markers.
When I am interviewing someone for a programming spot, my checklist looks like this:
1) Can they do the job? (or learn to do the job if it is a junior position)
2) Are they going to cause me more problems than they solve?
Are they going to be fun to work with? This is more important than it sounds, given that there are a lot of really, really bright people who do not work and play well with others.
Best interview I ever had was at a seismic data acquisition company. I was expecting hard-core technical questions, but my manager-to-be and I basically ended up talking about tools - source code management, GUI builders, editors, etc - things we had used, and what we liked or didn't like about them. I think we both learned a lot about each other.
I don't really have an argument with what was expressed in the article. I 'guess' under ideal conditions it would 'probably' work. But it has been my experience that for every 20 software engineers you get one (maybe out of every 30-50) guy who can do it all and is more productive than the other 20 put together. You will also get about 5 that can't do shit and maybe another 5 or so that can kinda do it mostly somewhat. But you will get the best interview responses and good feeling from the least talented candidates and that one genius that you interview will be less verbal, less attractive (I mean general appearance and how they fit into the interview situation) and less likely to feel like "wow'ing' you. You will probably pass on him and take the slick guy with the nice degree and it will take you two years to figure out you made a mistake and fire him (and another two years to find and fix all his mistakes).
I have seen the fireballs who program faster than they think and appear to be geniuses and they need someone to monitor them 24/7. Someone to interpret what they do/say, someone to fix what they overlook (because to them once they figure out the problem and take a crack it it they're done).
So how do you interview for a software engineer and not reject the genius and hire the flamboyant problem child?
1. Don't let the non-professionals (HR, admin staff, etc.) have any say in the interviews and decisions.
2. Use your best programmers/engineers to do the interview or at least sit in on it and then listen to what they say. Watch for personality or technical disagreements that might indicate your 'experts' bias towards any candidate.
3. If your company is big enough 'temp' hire the top two or three or four and then over the next six months figure out which one is the right one.
4. If you are a government agency; forget all of that stuff because your red tape and hiring delays and higher level interference will guaranty that you won't get the right guy so just do what you are told and let HR pick their candidate.
Is it common practice to refer to programmers as engineers? I'd call someone who writes code as a programmer or maybe software developer. When I hear the word 'engineer' I think of someone with a degree in engineering. Those guys can barely reboot their computer without tech support. There's no way they'd know how to write code. I'd say lots of talent, poor judgement, and no personality.
That jumped out at me, too. This guy is hiring programmers not engineers. We can certainly write code and even be fairly competent out of at it but it's not engineering. It's a problem I see in industry where programmers feel they can step into an engineering or research role. It never works out. Generally a programmers idea of solving a problem is to just sit and try things out in code. And they approach most problems the same way. It's not engineering.
I'm not sure if you are simply unaware that the title "software engineer" is real or you are engineers who resent anyone stepping on your turf. "Usually" software engineers deal with much larger and more complex problems than "programmers" do. Usually software engineers deal with much larger and more complex problems than engineers do too. Most engineering today is NOT dramatic new problems requiring difficult problem solving. Most engineering is cut and dry and more about rubber stamping a solution that was developed centuries ago and applied hundreds of times since.
You don't. You need it to assess the skills of the software engineer you are about to hire. How quickly can he see the solution and frame it as a mathematical model he con convert to code? How quickly can he write the code and find and eliminate the bugs? How accurate are the results? What is his level of competence and attitude while dealing with the problem? Even in failure, much can be learned about the applicants skills and thought process. And if the problem is too complex you will be sitting there for hours to days waiting for a result. The problem/test must be something that can be completed in 15 minutes or so.