With the beta launch of www.numeroom.com just over a month ago, I've been inundated by the requirements of the next stage of business. Acquiring users (to convert to customers hopefully at some time in the future), tenuously looking to acquire angel and VC funding, crafting my marketing and sales plans and networking, networking and networking. This part of running a business is the most arduous for a technical minded person who would much rather play around with algorithms than work on contacting potential users, however the usefulness of a product or service won't immediately present itself to those who might find it most useful and the leg work is required. That is the road I am on and it is at times a frustrating one, but with each new user one that gets closer to the magic critical mass of users where the unique utility of the numeroom.com collaboration ecosystem is harnessed. That said the rate at which new users are acquired has necessitated my investigation of available consulting assignments in information technology in order to fund all the necessary operations to keep numeroom.com growing until that critical mass is achieved.
It has been quite a few years since I've been looking for a gig, so all the trusted recruiting contacts I had built up over a decade ago when I last put myself on the market have moved on. Thus, I've had to attempt new relationships with recruiters in IT, the recent interaction with a few shows me that for the most part recruiters are still asking all the wrong questions of their potential candidates.
In illustration, few people stand out as giants of the art like Norman Rockwell. A native New Yorker, Rockwell showed an aptitude for drawing before he was a teen. By the time he was in his late teens he was already doing advertisement illustrations and other early covers for various magazines and publications. Norman Rockwell's talent was immediately on display the seconds a person saw his work. The question of what brushes he used for painting , or what type of pencils he used for sketching was a distant one on the minds of any one that saw what he could do with whatever he did use. Rockwell , and the talent of all great illustrators is on display in the work itself and more importantly, viewers of that work ascribe the ability to the person and not the tools that the person employs to create the work. A similar thing is true of masons, outstanding masons are skilled in the art of mixing cement, leveling walls, crafting unique designs from the components of brick, stone, and metal that are part of modern day masonry. As a result, when a mason is attempting to secure new work, he does not list in his advertisements all the models of his best trowels, or the type of his shovels, or the make of his levels, saws, or the maker of his cement. These are all irrelevant to the end result of a stable, level and excellently constructed work of masonry, be it in a porch, stone work on the front of a home or a stylized brick perimeter wall. The work speaks for the skill of he mason, not the tools that the mason uses. Making the statement "Great work you did on that wall, what level do you use?" immediately underscores the ignorance of the person asking the question, and the fact that they have no idea that skill in masonry lies not in tools , it lies in knowing how to use what ever tools are available to create consistently functional and beautiful masonry for their customer needs. It is true that most masons, and most illustrators for that matter have a set of preferred tools but the best are not tied to those tools. They are simply an end to a means, which the artists experience allows them the flexibility of achieving even if some or all of the tools are replaced. In illustration and in masonry, the potential customer realizes this intrinsically and does not ask such foolish questions about the tools used to perform the work. However, this is not the case in information technology.
My recent experience with recruiters, (it may bare on this subject that most recruiters tend to be males in their mid 20's fresh out of college) indicates how clueless many are with regard to what to look for in a competent software engineer. In my recent experience, the first question usually out of their mouths has to do with what specific components I have experience using, this is identical to the "tools" question posed to illustrators and masons as hypothesized above, and just as foolish. The mark of a great software engineer lies not in the tools (technologies) he or she has used. Even in the extreme cases, great skill with engineering can enable the individual possessing it the ability to pick up and go on any technology from zero in a time frame that will not impact the operations of the most demanding businesses. As it stands, the implementation time given even to crack consultants ranges on the order of weeks to months, enabling opportunity for the technologist to train up on the nuances of the new technology. True, there are situations where the implementation time does require an individual with more specific and detailed understanding of the underlying technology but this becomes more irrelevant the longer the time to launch period is for the project. The modern technological landscape has mostly standardized to one major type of design, object oriented design. (A philosophy that can be applied without requirement of an explicit object oriented language I might add.) The major platforms of development on which object oriented design are performed are extremely similar in overall philosophy but differ mostly in syntax. The differences between coding in java , c++ and c# are far fewer than many coders not familiar with the would realize, no wonder that recruiters are completely baffled given their relatively low level of experience in the technologies and most importantly, not realizing that the programming language and platform is but a tool. The true skill of an engineer lies not in which language he knows but rather in if he knows the most efficient collection to use in a code problem regardless of platform. Arrays? Trees? Maps? It is in knowing when a problem would be readily and efficiently solved using recursion as opposed to linear execution, it is in knowing if a design should write to files on a file system or write to a database table depending on the architecture of the software being designed? Stand alone, mobile device? Distributed web application??. These grains of knowledge are only acquired one way, experience, and they are applicable to any platform consistently because they are engineering and thus architecture related , not platform/language or library related.
I have a personal anecdote of the truth of this statement. The last time I was actively job hunting (as a full time worker and not as a consultant) I ended up interviewing at TheStreet.com, during my interview my interviewer asked all the right questions. My specific lack of experience on the platforms in use at the time on their system, my lack of knowledge of the very language I'd be programming in was irrelevant because he saw in my answers to his engineering questions, an ability to cut through the fat of inefficient design that constitutes the work of the bulk of "professional programmers". He hired me on the spot and within the next few weeks he saw his bet pay off in my rapid assimilation of the processes, tools, applications and languages required to perform my job. Despite tight deadlines I was able to become competent and skilled in my position and serve beyond the needs of the business. I've found that only engineers are able to sniff out other engineers, as they know what questions to ask and they understand the depth of the answers returned by engineers versus the shallow, responses returned by programmers that can rattle off facts but lack the wisdom to engineer efficient solutions with those facts. So recruiters need to probe the type of questions concerning the engineering competence of candidates and then let the hiring managers determine if that talent is sufficient for the implementation needs of the new position. When the opportunity is presented to view or use the finished work of an engineers efforts in any technology it should be taken, I've had two recent interviews where I suggested the recruiter look at the numeroom.com website to understand the scope of my ability only to have them indicate that they would rather I talk about it. This type of bone headed response is just like asking Ansel Adams to betray his 'secret' camera technology that made all his photographs of Yosemite so stunning. Now, I could only hope to exhibit a fraction of the talent that Ansel Adams had in my engineering work but the point is made, if you want to know how good some one is at something you ask for an example of their work, you don't ask for a list of the raw materials they use to build it. The talent for most every technical subject is not in the materials, it is in the builder.
So with that said, I resolve to perform the following the next time I get asked by a bone headed recruiter, what languages or IDE's or libraries I've used to build my software and refuses to simply look at the working examples I have online to judge the quality of the end result. "My competence in engineering is on display in the finished work, not in the tools I used to build it." and get up and leave. ;)
It has been quite a few years since I've been looking for a gig, so all the trusted recruiting contacts I had built up over a decade ago when I last put myself on the market have moved on. Thus, I've had to attempt new relationships with recruiters in IT, the recent interaction with a few shows me that for the most part recruiters are still asking all the wrong questions of their potential candidates.
In illustration, few people stand out as giants of the art like Norman Rockwell. A native New Yorker, Rockwell showed an aptitude for drawing before he was a teen. By the time he was in his late teens he was already doing advertisement illustrations and other early covers for various magazines and publications. Norman Rockwell's talent was immediately on display the seconds a person saw his work. The question of what brushes he used for painting , or what type of pencils he used for sketching was a distant one on the minds of any one that saw what he could do with whatever he did use. Rockwell , and the talent of all great illustrators is on display in the work itself and more importantly, viewers of that work ascribe the ability to the person and not the tools that the person employs to create the work. A similar thing is true of masons, outstanding masons are skilled in the art of mixing cement, leveling walls, crafting unique designs from the components of brick, stone, and metal that are part of modern day masonry. As a result, when a mason is attempting to secure new work, he does not list in his advertisements all the models of his best trowels, or the type of his shovels, or the make of his levels, saws, or the maker of his cement. These are all irrelevant to the end result of a stable, level and excellently constructed work of masonry, be it in a porch, stone work on the front of a home or a stylized brick perimeter wall. The work speaks for the skill of he mason, not the tools that the mason uses. Making the statement "Great work you did on that wall, what level do you use?" immediately underscores the ignorance of the person asking the question, and the fact that they have no idea that skill in masonry lies not in tools , it lies in knowing how to use what ever tools are available to create consistently functional and beautiful masonry for their customer needs. It is true that most masons, and most illustrators for that matter have a set of preferred tools but the best are not tied to those tools. They are simply an end to a means, which the artists experience allows them the flexibility of achieving even if some or all of the tools are replaced. In illustration and in masonry, the potential customer realizes this intrinsically and does not ask such foolish questions about the tools used to perform the work. However, this is not the case in information technology.
My recent experience with recruiters, (it may bare on this subject that most recruiters tend to be males in their mid 20's fresh out of college) indicates how clueless many are with regard to what to look for in a competent software engineer. In my recent experience, the first question usually out of their mouths has to do with what specific components I have experience using, this is identical to the "tools" question posed to illustrators and masons as hypothesized above, and just as foolish. The mark of a great software engineer lies not in the tools (technologies) he or she has used. Even in the extreme cases, great skill with engineering can enable the individual possessing it the ability to pick up and go on any technology from zero in a time frame that will not impact the operations of the most demanding businesses. As it stands, the implementation time given even to crack consultants ranges on the order of weeks to months, enabling opportunity for the technologist to train up on the nuances of the new technology. True, there are situations where the implementation time does require an individual with more specific and detailed understanding of the underlying technology but this becomes more irrelevant the longer the time to launch period is for the project. The modern technological landscape has mostly standardized to one major type of design, object oriented design. (A philosophy that can be applied without requirement of an explicit object oriented language I might add.) The major platforms of development on which object oriented design are performed are extremely similar in overall philosophy but differ mostly in syntax. The differences between coding in java , c++ and c# are far fewer than many coders not familiar with the would realize, no wonder that recruiters are completely baffled given their relatively low level of experience in the technologies and most importantly, not realizing that the programming language and platform is but a tool. The true skill of an engineer lies not in which language he knows but rather in if he knows the most efficient collection to use in a code problem regardless of platform. Arrays? Trees? Maps? It is in knowing when a problem would be readily and efficiently solved using recursion as opposed to linear execution, it is in knowing if a design should write to files on a file system or write to a database table depending on the architecture of the software being designed? Stand alone, mobile device? Distributed web application??. These grains of knowledge are only acquired one way, experience, and they are applicable to any platform consistently because they are engineering and thus architecture related , not platform/language or library related.
I have a personal anecdote of the truth of this statement. The last time I was actively job hunting (as a full time worker and not as a consultant) I ended up interviewing at TheStreet.com, during my interview my interviewer asked all the right questions. My specific lack of experience on the platforms in use at the time on their system, my lack of knowledge of the very language I'd be programming in was irrelevant because he saw in my answers to his engineering questions, an ability to cut through the fat of inefficient design that constitutes the work of the bulk of "professional programmers". He hired me on the spot and within the next few weeks he saw his bet pay off in my rapid assimilation of the processes, tools, applications and languages required to perform my job. Despite tight deadlines I was able to become competent and skilled in my position and serve beyond the needs of the business. I've found that only engineers are able to sniff out other engineers, as they know what questions to ask and they understand the depth of the answers returned by engineers versus the shallow, responses returned by programmers that can rattle off facts but lack the wisdom to engineer efficient solutions with those facts. So recruiters need to probe the type of questions concerning the engineering competence of candidates and then let the hiring managers determine if that talent is sufficient for the implementation needs of the new position. When the opportunity is presented to view or use the finished work of an engineers efforts in any technology it should be taken, I've had two recent interviews where I suggested the recruiter look at the numeroom.com website to understand the scope of my ability only to have them indicate that they would rather I talk about it. This type of bone headed response is just like asking Ansel Adams to betray his 'secret' camera technology that made all his photographs of Yosemite so stunning. Now, I could only hope to exhibit a fraction of the talent that Ansel Adams had in my engineering work but the point is made, if you want to know how good some one is at something you ask for an example of their work, you don't ask for a list of the raw materials they use to build it. The talent for most every technical subject is not in the materials, it is in the builder.
So with that said, I resolve to perform the following the next time I get asked by a bone headed recruiter, what languages or IDE's or libraries I've used to build my software and refuses to simply look at the working examples I have online to judge the quality of the end result. "My competence in engineering is on display in the finished work, not in the tools I used to build it." and get up and leave. ;)
Comments