Amazing article! Today hacker Robert Moore spoke up about how he pulled off his crimes (hacking into tons of VOIP serves and reselling communications services). His way in? So simple - he just used the default password for common communications devices (Cisco routers, etc.). Once in, he took control and routed traffic as he desired. URL: http://www.informationweek.com/news/showArticle.jhtml;jsessionid=WIARC3KZRXVXQQSNDLRCKHSCJUNN2JVN?articleID=202101781&pgno=2&queryText
This blog isn't about the hack. It's elegant, but in the end common petty thievery and nothing worth a bit of praise. This blog is about the quote from page two:
"Kenneth van Wyk, principal consultant with KRvW Associates, said leaving default passwords up is a widespread and dangerous problem. "It's a huge problem, but it's a problem
the IT industry has known about for at least two decades and we haven't made
much progress in fixing it," said van Wyk. "People focus on functionality when they're setting up a system. Does the thing work? Yes. Fine, move on. They don't spend the time doing the housework and cleaning things up." "
How many times have I been told in the past year "Just run through the test cases" and "just test the positive cases"? I was literally told by one employer (not my current) that SQL injection and other user-security cases were unimportant. This was from an employer going through multiple rounds of lay-offs and terrible morale.
Testing is about proving things work but it is about so much more. If a web page is served up, does it mean it 'works'? What if it takes 3 minutes to serve up the page? Is it OK then? If I can update information about an entry in my database, but I'm not monitoring for errors, can I say it works? What if, each time an update is sent, the update is 'written' but an error is thrown? If all I'm looking for is a row with the updated information, and I'm not running a negative test case to ensure the old information is gone, can I say it worked?
Now that the recruiting series is behind me, I'm going to spend some time investigating this concept. When is testing REALLY finished? (And I mean that as the verb 'testing', not the noun "Testing".)
Wednesday, September 26, 2007
Recruiting for Intellect
One other skill I am looking for during an interview is intellectual horsepower. This is probably the most controversial element of interviewing – for a kick, read How Would You Move Mount Fuji to learn more about the subject, and for a ton of great interview questions!
The basic argument against the puzzle question is that it’s generally an ah-hah question and doesn’t show whether a candidate can perform the work they’re being interviewed for. OK – I buy that… I could bring in a Nobel-winning primatologist and they’d probably crush my interview question but they’d be a terrible developer. However, when I’m hiring I’m not just interviewing for someone who can slap together a few DHTML objects… I’m looking for an engineer who can code, for sure, but who can pick apart problems and drive creative solutions to them. I’m not just looking for someone who can come in and code in Java today – I may need a low-level C++ driver written tomorrow or I may need someone who can build a replacement to a multi-million dollar line-of-business application. So you know, I agree—no problem question will allow a candidate to prove their coding ability. But I also need to see their problem-solving ability.
That having been said, there’s more than one way to evaluate what my former General Manager calls IHP. As a matter of fact, I quite often couch my question in a coding question. For instance, I may throw a quick and dirty pointer question at a candidate (to see the depth of their CS skills—and you’d be amazed at how few candidates can code with pointers… it’s a shame), and then I’ll follow it up with a question like “Design a tool which takes in two string arrays – one is a list of words, the other is a crossword puzzle—and evaluates whether all the words are in the puzzle.” That’s an engineering challenge – seems straightforward, but it’s actually a puzzle.
I am not afraid to throw the puzzle question at people either. Yes, most of them are ah-hah questions where there’s only one answer and you either get it or you don’t. I try to stay away from them, although I don’t mind them too much. Very much like my coding or testing question, I’m less concerned with candidates arriving at the answer and more concerned about them showing critical thinking abilities, the ability to step back and re-evaluate a solution, and a little bit of thinking outside of the box.
What are some sample questions? How Would You Move Mount Fuji is a great source for these. Some I like are the bridge over the chasm (four people need to get across the bridge, it’s dark, and you only have one flashlight—how fast can you get them all across?) or the miner stealing an ounce of gold for every pound. There are thousands of these questions though. And anyone who thinks they aren’t fair should know that I actually run them past my Boy Scouts and they can solve them (sometimes with a little hand-holding, I’ll admit – but these are 12-year old boys!).
In evaluating, be sure to avoid the emotional evaluation. Don’t be overjoyed or think the candidate is a hire just because she got the answer. Stop and think about HOW they got there. Did the candidate just stumble on the answer? Did they guess? Did they get there so fast that it’s obvious they knew the question in advance?
Look for critical skills. Can they break the problem down? Do they arrive at an initial answer, but then continue to probe looking for a more elegant solution? Are they organized in their approach? Are they cool under the pressure? (That’s a lot of it for me – I am looking for candidates who can tackle a tough problem—with a senior manager in the room.)
Test scores and higher ed grades are a good indicator, as well, of performance. Keep an eye out, though, for the brainiac with no common sense. You probably don’t want them unless you have some really deep experimental research type of effort (cryptography?).
In the end, I’m looking for a balanced candidate. A super-smart person with poor coding skills isn’t as helpful to me. A hard-working coder who can’t think his way out of any problem might help me short-term with the challenge I’m facing at the moment, but I’m not convinced they’re a good hire. They might make a great contractor, but I’m only looking to hire bright people who will grow with my challenges and needs.
The basic argument against the puzzle question is that it’s generally an ah-hah question and doesn’t show whether a candidate can perform the work they’re being interviewed for. OK – I buy that… I could bring in a Nobel-winning primatologist and they’d probably crush my interview question but they’d be a terrible developer. However, when I’m hiring I’m not just interviewing for someone who can slap together a few DHTML objects… I’m looking for an engineer who can code, for sure, but who can pick apart problems and drive creative solutions to them. I’m not just looking for someone who can come in and code in Java today – I may need a low-level C++ driver written tomorrow or I may need someone who can build a replacement to a multi-million dollar line-of-business application. So you know, I agree—no problem question will allow a candidate to prove their coding ability. But I also need to see their problem-solving ability.
That having been said, there’s more than one way to evaluate what my former General Manager calls IHP. As a matter of fact, I quite often couch my question in a coding question. For instance, I may throw a quick and dirty pointer question at a candidate (to see the depth of their CS skills—and you’d be amazed at how few candidates can code with pointers… it’s a shame), and then I’ll follow it up with a question like “Design a tool which takes in two string arrays – one is a list of words, the other is a crossword puzzle—and evaluates whether all the words are in the puzzle.” That’s an engineering challenge – seems straightforward, but it’s actually a puzzle.
I am not afraid to throw the puzzle question at people either. Yes, most of them are ah-hah questions where there’s only one answer and you either get it or you don’t. I try to stay away from them, although I don’t mind them too much. Very much like my coding or testing question, I’m less concerned with candidates arriving at the answer and more concerned about them showing critical thinking abilities, the ability to step back and re-evaluate a solution, and a little bit of thinking outside of the box.
What are some sample questions? How Would You Move Mount Fuji is a great source for these. Some I like are the bridge over the chasm (four people need to get across the bridge, it’s dark, and you only have one flashlight—how fast can you get them all across?) or the miner stealing an ounce of gold for every pound. There are thousands of these questions though. And anyone who thinks they aren’t fair should know that I actually run them past my Boy Scouts and they can solve them (sometimes with a little hand-holding, I’ll admit – but these are 12-year old boys!).
In evaluating, be sure to avoid the emotional evaluation. Don’t be overjoyed or think the candidate is a hire just because she got the answer. Stop and think about HOW they got there. Did the candidate just stumble on the answer? Did they guess? Did they get there so fast that it’s obvious they knew the question in advance?
Look for critical skills. Can they break the problem down? Do they arrive at an initial answer, but then continue to probe looking for a more elegant solution? Are they organized in their approach? Are they cool under the pressure? (That’s a lot of it for me – I am looking for candidates who can tackle a tough problem—with a senior manager in the room.)
Test scores and higher ed grades are a good indicator, as well, of performance. Keep an eye out, though, for the brainiac with no common sense. You probably don’t want them unless you have some really deep experimental research type of effort (cryptography?).
In the end, I’m looking for a balanced candidate. A super-smart person with poor coding skills isn’t as helpful to me. A hard-working coder who can’t think his way out of any problem might help me short-term with the challenge I’m facing at the moment, but I’m not convinced they’re a good hire. They might make a great contractor, but I’m only looking to hire bright people who will grow with my challenges and needs.
Wednesday, September 5, 2007
Recruiting for Potential
Potential. OK I admit it, I left potential out as one of the hard characteristics to probe for. What is potential, anyhow? Well, one definition is that it’s the ability for a candidate to progress to higher levels of contribution within your organization. If hired in as an entry-level test engineer, could the candidate progress to a technical lead? Can she become a test lead, test manager, or even an engineering director?
So how do you gauge this? It’s not as straightforward as measuring, say, technical skills or the ability to tear apart an application into test questions. But there are some guidelines I like to use in my recruiting which might help you.
First of all, I’m looking for a level of maturity about career opportunity. I don’t expect a college candidate to be as realistic or mature about where they want their career to go as I would, say, a five-year veteran. However, I’m still looking for a candidate who wants to progress and who wants to make a difference. I’m looking for a candidate who’s evaluating my opportunity on the basis of where she can go next and what skills she can gain. I’m also looking for a candidate who’s thinking about how they can contribute. A campus hire isn’t necessarily going to change the way my department does everything, but they may well come in with new coding skills or a process improvement they picked up during an internship.
Next thing to think about is what have they demonstrated in the past in the area of improving their abilities? I will ask things like “What technologies have you learned recently?” or “What have you had to come up to speed on in your workplace?” For me, I’m always needing to learn something. After 11 years at Microsoft , I am facing a huge wall of IT skills now that I’m in an Oracle and IBM heavy environment (more on that someday…). So I’m learning all about open source test tools, getting up to speed on Oracle SQL and I’ll probably have to jump into Java programming (sigh). But I do what it takes to keep on top of the technologies behind my projects—I’m a professional.
There’s something next which is really tough to describe, let alone measure in a candidate. Put simply, does the candidate ‘get it’? Do they understand the role of IT in the org they’re interviewing for? Do they understand issues or challenges they may have faced (or that they face) in previous positions? Are they all blame and no responsibility? Are they open and introspective about their failures, or do they continue to point the finger at outside influences? Do they show the mental maturity to make decisions on a team or group-wide level?
As not all candidates want management to be in their future, you also need to probe for deeper technical skills. Do they have any experience in distributed programming environments? Do they understand that their projects have broad impact? Can they see, for example, how an automation framework they worked on in a previous team could have been used across their entire organization?
It’s a challenge to measure a candidate’s ability to grow, but hopefully each candidate is going to be with your group for a very long time, so you want to be sure you’re hiring people who can grow over the long term and won’t just consume oxygen.
So how do you gauge this? It’s not as straightforward as measuring, say, technical skills or the ability to tear apart an application into test questions. But there are some guidelines I like to use in my recruiting which might help you.
First of all, I’m looking for a level of maturity about career opportunity. I don’t expect a college candidate to be as realistic or mature about where they want their career to go as I would, say, a five-year veteran. However, I’m still looking for a candidate who wants to progress and who wants to make a difference. I’m looking for a candidate who’s evaluating my opportunity on the basis of where she can go next and what skills she can gain. I’m also looking for a candidate who’s thinking about how they can contribute. A campus hire isn’t necessarily going to change the way my department does everything, but they may well come in with new coding skills or a process improvement they picked up during an internship.
Next thing to think about is what have they demonstrated in the past in the area of improving their abilities? I will ask things like “What technologies have you learned recently?” or “What have you had to come up to speed on in your workplace?” For me, I’m always needing to learn something. After 11 years at Microsoft , I am facing a huge wall of IT skills now that I’m in an Oracle and IBM heavy environment (more on that someday…). So I’m learning all about open source test tools, getting up to speed on Oracle SQL and I’ll probably have to jump into Java programming (sigh). But I do what it takes to keep on top of the technologies behind my projects—I’m a professional.
There’s something next which is really tough to describe, let alone measure in a candidate. Put simply, does the candidate ‘get it’? Do they understand the role of IT in the org they’re interviewing for? Do they understand issues or challenges they may have faced (or that they face) in previous positions? Are they all blame and no responsibility? Are they open and introspective about their failures, or do they continue to point the finger at outside influences? Do they show the mental maturity to make decisions on a team or group-wide level?
As not all candidates want management to be in their future, you also need to probe for deeper technical skills. Do they have any experience in distributed programming environments? Do they understand that their projects have broad impact? Can they see, for example, how an automation framework they worked on in a previous team could have been used across their entire organization?
It’s a challenge to measure a candidate’s ability to grow, but hopefully each candidate is going to be with your group for a very long time, so you want to be sure you’re hiring people who can grow over the long term and won’t just consume oxygen.
Recruiting for Testing Skills
I’m a test manager, so ultimately my interviewing is to find candidates who can test – who can find bugs, prevent bugs, and write tools to help in those processes. Testers have a special mentality—seriously, I’ve interviewed (and worked with) plenty of solid development engineers who couldn’t test their way out of a paper bag. It’s a special person who can code AND test. The good news is, finding a person with a ‘break it’ mentality is pretty easy. Probably the easiest of all the characteristics I interview for.
The best tool I’ve found for this is to simply throw the candidate a test question. It can be something theoretical, or it can have a real-world application. One of my favorites is to test a function which receives three integers representing the three sides of a triangle, and returns whether the triangle is equilateral, isosceles, a triangle, or invalid. This question works really well; it presents the candidate with a real world situation (who remembers what an isosceles triangle is anymore?), it has a ton of effective cases, and it can be easily moved into additional problems such as becoming a web service or the likes.
What’s the right answer? Well obviously candidates are going to have to catch the positive cases of each type. But from there the sky’s the limit—I’m not going to list all the cases here but suffice it to say that I was once interviewed by a test manager and given this question. We went on for a good 30 minutes and could have continued. And that’s one of the key points I’m looking for – does the candidate throw out a series of cases over a few minutes and give up, or does she keep going? A real tester should be able to run on and on and on with new cases, if your question lends itself to this. That’s why the question is so important.
So I’m looking for my candidates to just keep generating test cases. I’m looking to make sure they cover the basics – positive cases, boundary cases, etc. I’m going to keep an eye out for candidates who aren’t equivalence-classing their cases. A candidate who tells me 1,1,1 2,2,2 3,3,3 and 5,5,5 isn’t getting anywhere; there’s no difference in any of these cases (well, maybe 1,1,1). So rambling along with repetitive cases is no help. But going on and on and on with cases is definitely a key.
Another thing to look for – is the candidate organized? I’ve interviewed with a number of leads and managers who claim no candidate is sufficient who isn’t organized in their approach. I disagree with this somewhat—a candidate who, through free associate of thought, jumps from performance to security to positive test cases isn’t necessarily incompetent. As long as candidates 1) cover all those case types and 2) make sure they get the required coverage, that’s all I’m looking for. I happen to be rather random in my own test case generation. I may use an outline, but I’m plugging cases in all over the outline rather than working top to bottom. It’s simply how I think. Don’t mistake the trigger of association for disorganization.
Another thing I’m looking for is the candidate’s ability to think like a user. In testing a problem like the triangle evaluation, are they coming up with good use cases and showing customer empathy? I consider myself a technical guy and I’m always looking for good perf bugs or bad data manipulation or the likes. But the most recent bug I wrote up (just yesterday) had to do with how difficult it is to perform a certain workflow procedure in our line of business application. Nah—it’s not engineering. It’s about solving the problem the right way for the customer. In our organization, the IT department has made huge progress but still has room to go in winning over customers. Many groups are still working their own solutions rather than using our expertise. Fixing weird useage scenario bugs like this has an amazing positive effect on the department’s reputation for being client-centric.
So don’t just focus on whether the candidate got the obvious cases. Look deeper and evaluation for thoroughness, for customer empathy, and for the ability to derive great cases out of what seems like a straightforward and obvious tool. Your department will benefit greatly from this kind of test resource!
The best tool I’ve found for this is to simply throw the candidate a test question. It can be something theoretical, or it can have a real-world application. One of my favorites is to test a function which receives three integers representing the three sides of a triangle, and returns whether the triangle is equilateral, isosceles, a triangle, or invalid. This question works really well; it presents the candidate with a real world situation (who remembers what an isosceles triangle is anymore?), it has a ton of effective cases, and it can be easily moved into additional problems such as becoming a web service or the likes.
What’s the right answer? Well obviously candidates are going to have to catch the positive cases of each type. But from there the sky’s the limit—I’m not going to list all the cases here but suffice it to say that I was once interviewed by a test manager and given this question. We went on for a good 30 minutes and could have continued. And that’s one of the key points I’m looking for – does the candidate throw out a series of cases over a few minutes and give up, or does she keep going? A real tester should be able to run on and on and on with new cases, if your question lends itself to this. That’s why the question is so important.
So I’m looking for my candidates to just keep generating test cases. I’m looking to make sure they cover the basics – positive cases, boundary cases, etc. I’m going to keep an eye out for candidates who aren’t equivalence-classing their cases. A candidate who tells me 1,1,1 2,2,2 3,3,3 and 5,5,5 isn’t getting anywhere; there’s no difference in any of these cases (well, maybe 1,1,1). So rambling along with repetitive cases is no help. But going on and on and on with cases is definitely a key.
Another thing to look for – is the candidate organized? I’ve interviewed with a number of leads and managers who claim no candidate is sufficient who isn’t organized in their approach. I disagree with this somewhat—a candidate who, through free associate of thought, jumps from performance to security to positive test cases isn’t necessarily incompetent. As long as candidates 1) cover all those case types and 2) make sure they get the required coverage, that’s all I’m looking for. I happen to be rather random in my own test case generation. I may use an outline, but I’m plugging cases in all over the outline rather than working top to bottom. It’s simply how I think. Don’t mistake the trigger of association for disorganization.
Another thing I’m looking for is the candidate’s ability to think like a user. In testing a problem like the triangle evaluation, are they coming up with good use cases and showing customer empathy? I consider myself a technical guy and I’m always looking for good perf bugs or bad data manipulation or the likes. But the most recent bug I wrote up (just yesterday) had to do with how difficult it is to perform a certain workflow procedure in our line of business application. Nah—it’s not engineering. It’s about solving the problem the right way for the customer. In our organization, the IT department has made huge progress but still has room to go in winning over customers. Many groups are still working their own solutions rather than using our expertise. Fixing weird useage scenario bugs like this has an amazing positive effect on the department’s reputation for being client-centric.
So don’t just focus on whether the candidate got the obvious cases. Look deeper and evaluation for thoroughness, for customer empathy, and for the ability to derive great cases out of what seems like a straightforward and obvious tool. Your department will benefit greatly from this kind of test resource!
Tuesday, September 4, 2007
Recruiting for Skills
One of the easiest characteristics to recruit for is hard skills. At the end of the day, I need a person to code or test—since that’s what they’ll be doing all day, there’s no better way to probe than to have candidates actually code. I was a bit surprised during my recruiting in India to see how many companies administer a coding question in the form of a seated, written test—there’s probably some value in that, because it does allow the candidate to prove their skills but a written test is such a sterile environment. When I probe for coding, I’m looking for a couple of things at once: can a candidate break the problem down appropriate, can they get the right logic, are they looking to refactor or improve their code, and are they thinking about performance or scalability. In a written test, the candidate does all that thought in a vacuum – all I get is the final code. So a written test can be used as an initial weeding out, but don’t rely on it as the sole measuring stick.
In an interview, I’m dealing with limited time—usually 30 to 60 minutes. Because I don’t have all day to get through a question, I need to pick something that will let candidates demonstrate as many skills as possible. I have, therefore, developed a few standard requirements. First, if I’m interviewing for C or C++ developers, my questions do not allow candidates to use outside libraries. I once had a candidate yell at me – literally – about that restriction, but I don’t care. Anyone can consume a library – but can they write clean, elegant code on their own? I often ask them to implement a library—for instance, one question I like to ask is reversing the characters in a string (I usually throw a twist in that, such as reversing the characters in each word while preserving word order). There are some very simple bars to measure by – does the candidate use pointers or temp arrays? Memory isn’t constrained any longer, but a clean coder is still concerned. How complex are their logic statements? Are they nesting double and triple negatives together? Do they over-complicate things? Are they getting lost in their own algorithms? How confident do they appear? Do they tackle the problem without thinking, or do they put together an approach in their mind.
I really don’t care about the solution they ultimately arrive at (for the most part). I’m mostly concerned that they write clean code, the solve the problem, and they do it with quality. I’ll take a conscientious coder who returns to his algorithm one, twice, even thrice during an interview over the cocky application who codes quickly and sloppily and just leaves the code when it’s ‘finished’.
In an interview, I’m dealing with limited time—usually 30 to 60 minutes. Because I don’t have all day to get through a question, I need to pick something that will let candidates demonstrate as many skills as possible. I have, therefore, developed a few standard requirements. First, if I’m interviewing for C or C++ developers, my questions do not allow candidates to use outside libraries. I once had a candidate yell at me – literally – about that restriction, but I don’t care. Anyone can consume a library – but can they write clean, elegant code on their own? I often ask them to implement a library—for instance, one question I like to ask is reversing the characters in a string (I usually throw a twist in that, such as reversing the characters in each word while preserving word order). There are some very simple bars to measure by – does the candidate use pointers or temp arrays? Memory isn’t constrained any longer, but a clean coder is still concerned. How complex are their logic statements? Are they nesting double and triple negatives together? Do they over-complicate things? Are they getting lost in their own algorithms? How confident do they appear? Do they tackle the problem without thinking, or do they put together an approach in their mind.
I really don’t care about the solution they ultimately arrive at (for the most part). I’m mostly concerned that they write clean code, the solve the problem, and they do it with quality. I’ll take a conscientious coder who returns to his algorithm one, twice, even thrice during an interview over the cocky application who codes quickly and sloppily and just leaves the code when it’s ‘finished’.
Saturday, September 1, 2007
Recruiting for Passion
As I mentioned, in my recruiting I’m looking for six key characteristics: passion for quality, skills, break-it mentality, potential, fit, and intellectual horsepower. How can you tell if a candidate has these traits, for sure?'
I think of the six attributes, passion and fit are the toughest to measure—they are soft skills and thus they’re challenging to measure. I can gauge a candidate’s coding skills by having them write code. I can probe for IHP with a few challenging puzzle questions. I can count the test cases a candidate comes up with, and I can see how far a candidate will go in their career. But knowing their true passion and measuring how well they’ll fit into my organization are much more difficult to determine. But there are a few keys I use in my interviews, and I feel I’ve been right many, many more times than I’ve been wrong.
When I look for passion, I’m looking for a candidate who’s thrilled about technology. As my current CIO pointed out recently, a passion for quality isn’t necessary a good thing – it’s putting the passion in the right place. Engineers are geeks – we get into weird things. We like to program to relax; need I say more? We’ll spend an hour arguing over the purest object-oriented method to serialize an object! That’s passion, but it doesn’t necessarily make for a good tester.
The passion I’m looking for is applied technology. Great candidates are just as excited about pure object-oriented code or simple implementations, but they want to see them put to use in a setting where technology is solving a problem. That’s the key to me – can the candidate recognize the value of technology in a given situation. I once had an acquaintance who took time from his family to head into the mountains and write haikus—then burn them. Poetry that’s never shared is a waste, and technology that has no purpose is a poor use of a department’s time and money.
Questions I like to use to probe for this passion give candidates an opportunity to talk about a problem they see and how technology can solve it. Some questions I use to get candidates talking include “What’s your favorite software product?” or “If I gave you a million dollars (or a blank check) to form a team and build a software product, what would it be?”. I’m going to pay particular attention to the problem they set out to solve, and less about how they’ll solve it.
For instance, my favorite application is Microsoft Visual Studio 2005. Look, I’m not the greatest coder in the world—I’ll admit it. But VS 2005 gets even someone like me moving quickly. The IDE environment helps me get everything done quickly – I get squigglies when I mess up, I get F1 help on pretty much any code snippet I highlight. And finally (finally!!!) I get help lining up my curly braces. The productivity contained within that application is amazing—it is to development what Word was to document processing. My productivity increases hundredfold (literally…). Pure coders will scoff at me, and that’s fine. There are a ton of engineers in this world who are highly productive with a bare bones coding environment – more power to them! But when it comes to getting the masses to get their work done, nothing can compete with VS.
Now, you can take issue with my passion for Visual Studio. But hopefully it’s a great example for passion for technology. The problem? It takes a long time to code up applications. The solution? Visual Studio, .NET frameworks, and all the other productivity tools that come with the application. There’s a clear problem and a clear solution.
What if someone offered me a blank check and told me to build any product I wanted to? It’d be a dream! The biggest opportunity (which is a key word for problem) I see for technology is small business. Enterprises have a ton of great software out there, but small business owners suffer terribly. Most solutions for their business are garage-built one-off applications which have been distributed widely. Applications are characterized as procedural spaghetti code built on proprietary technologies with little or no ability to adapt to modern technologies such as Internet technologies or handheld devices. The company that comes up with a method to apply common code and technologies to various small-biz verticals will have really solved a major problem. (BTW: if you want to talk further about this opportunity, contact me via e-mail and let’s chat – I have some answers…).
Hopefully I’m making my point clear. A candidate who goes on and on about the latest extreme programming examples or who talks about the purest object-oriented code might be a brilliant developer, but can they actually contribute in the real world? There’s no telling. But a candidate who can see how technology can be applied to day-to-day business problems is someone I want on my team.
I’ll give you a couple real world examples. I don’t remember the problem I presented him with, but I hired a tester in India for an engineering team I ran. This guy is a super-geek! I once asked him if he had any hobbies, things he does outside of work… His answer was “Yeah, I like to read up on coding on the Internet.” To be frank, I think he can code circles around most of the developers on our team, and I’m sure glad he chose test because he single-handedly took us from 15% to 90% automation on our test cases in a matter of weeks. He has a code answer for every problem we faced in testing. He’s passionate about applying his coding skills.
Another example is my SDET lead on Education Products. She is a brainiac—one of those people you’re afraid of because she’s so smart. I could hit her up with a problem we faced with testing and she’d literally build a solution in a matter of hours. It doesn’t hurt that her code looks like poetry in C#, either. She is methodical and organized in her coding and produced consistent, reliable solutions.
So the best candidates out there combine hard skills with a real-world application. Finding candidates like this to join your team makes a world of difference because they’re using their skills to solve problems – whether you’re out to make money in product software or cut costs and increased efficiency in a business, you’ll only benefit from applied technology—and hiring people with a vision for applying technology to solve real problems.
I think of the six attributes, passion and fit are the toughest to measure—they are soft skills and thus they’re challenging to measure. I can gauge a candidate’s coding skills by having them write code. I can probe for IHP with a few challenging puzzle questions. I can count the test cases a candidate comes up with, and I can see how far a candidate will go in their career. But knowing their true passion and measuring how well they’ll fit into my organization are much more difficult to determine. But there are a few keys I use in my interviews, and I feel I’ve been right many, many more times than I’ve been wrong.
When I look for passion, I’m looking for a candidate who’s thrilled about technology. As my current CIO pointed out recently, a passion for quality isn’t necessary a good thing – it’s putting the passion in the right place. Engineers are geeks – we get into weird things. We like to program to relax; need I say more? We’ll spend an hour arguing over the purest object-oriented method to serialize an object! That’s passion, but it doesn’t necessarily make for a good tester.
The passion I’m looking for is applied technology. Great candidates are just as excited about pure object-oriented code or simple implementations, but they want to see them put to use in a setting where technology is solving a problem. That’s the key to me – can the candidate recognize the value of technology in a given situation. I once had an acquaintance who took time from his family to head into the mountains and write haikus—then burn them. Poetry that’s never shared is a waste, and technology that has no purpose is a poor use of a department’s time and money.
Questions I like to use to probe for this passion give candidates an opportunity to talk about a problem they see and how technology can solve it. Some questions I use to get candidates talking include “What’s your favorite software product?” or “If I gave you a million dollars (or a blank check) to form a team and build a software product, what would it be?”. I’m going to pay particular attention to the problem they set out to solve, and less about how they’ll solve it.
For instance, my favorite application is Microsoft Visual Studio 2005. Look, I’m not the greatest coder in the world—I’ll admit it. But VS 2005 gets even someone like me moving quickly. The IDE environment helps me get everything done quickly – I get squigglies when I mess up, I get F1 help on pretty much any code snippet I highlight. And finally (finally!!!) I get help lining up my curly braces. The productivity contained within that application is amazing—it is to development what Word was to document processing. My productivity increases hundredfold (literally…). Pure coders will scoff at me, and that’s fine. There are a ton of engineers in this world who are highly productive with a bare bones coding environment – more power to them! But when it comes to getting the masses to get their work done, nothing can compete with VS.
Now, you can take issue with my passion for Visual Studio. But hopefully it’s a great example for passion for technology. The problem? It takes a long time to code up applications. The solution? Visual Studio, .NET frameworks, and all the other productivity tools that come with the application. There’s a clear problem and a clear solution.
What if someone offered me a blank check and told me to build any product I wanted to? It’d be a dream! The biggest opportunity (which is a key word for problem) I see for technology is small business. Enterprises have a ton of great software out there, but small business owners suffer terribly. Most solutions for their business are garage-built one-off applications which have been distributed widely. Applications are characterized as procedural spaghetti code built on proprietary technologies with little or no ability to adapt to modern technologies such as Internet technologies or handheld devices. The company that comes up with a method to apply common code and technologies to various small-biz verticals will have really solved a major problem. (BTW: if you want to talk further about this opportunity, contact me via e-mail and let’s chat – I have some answers…).
Hopefully I’m making my point clear. A candidate who goes on and on about the latest extreme programming examples or who talks about the purest object-oriented code might be a brilliant developer, but can they actually contribute in the real world? There’s no telling. But a candidate who can see how technology can be applied to day-to-day business problems is someone I want on my team.
I’ll give you a couple real world examples. I don’t remember the problem I presented him with, but I hired a tester in India for an engineering team I ran. This guy is a super-geek! I once asked him if he had any hobbies, things he does outside of work… His answer was “Yeah, I like to read up on coding on the Internet.” To be frank, I think he can code circles around most of the developers on our team, and I’m sure glad he chose test because he single-handedly took us from 15% to 90% automation on our test cases in a matter of weeks. He has a code answer for every problem we faced in testing. He’s passionate about applying his coding skills.
Another example is my SDET lead on Education Products. She is a brainiac—one of those people you’re afraid of because she’s so smart. I could hit her up with a problem we faced with testing and she’d literally build a solution in a matter of hours. It doesn’t hurt that her code looks like poetry in C#, either. She is methodical and organized in her coding and produced consistent, reliable solutions.
So the best candidates out there combine hard skills with a real-world application. Finding candidates like this to join your team makes a world of difference because they’re using their skills to solve problems – whether you’re out to make money in product software or cut costs and increased efficiency in a business, you’ll only benefit from applied technology—and hiring people with a vision for applying technology to solve real problems.
Subscribe to:
Posts (Atom)
