Monday, March 24, 2008

My Years of Experience - An Interview Gone Wrong

so I am just now catching up with some posting that I was fixing to do some time ago. I was reading an interesting article over at Coding Horror pertaining to the myth that when hiring someone it really matters how many years experience that they have listed on their resume. I have to say that for a variety of reasons I could not agree with the premise of this post more. Lemme provide a little background on my last search for a position:

The Setup

I was out shopping for a job and decided this time that I would give a head hunting company a try. I know, I can hear lots of people yelling "NOOOOOOOOOOOOOOOO why would you do such a stupid thing" don't worry, in this case I got one of the "good" companies (JSync). JSync in this case told me that they had several positions currently hiring - one of the opportunities was a position at the Philadelphia Stock Exchange. It seemed like it would be an interesting and challenging place to work. It also seemed as if the description of the position was exactly what I was looking for, the PSE was looking for a talented Java engineer that had X number of years experience with a smattering of other experience required (tomcat and a few other items included) I personally and reflexively skimmed over the total years required and moved right into the things that I didn't have background in to validate that I could learn them without too much effort all seemed in good order as far as I was concerned. JSync set up a PHONE SCREEN that turned out to be anything but.

The Call

The call started while I was out on lunch (specifically because I did not want to have that conversation in the same building I was working at to avoid conflict of interest and all that). The conversation start out well introductions and pleasantries aside the tech guys started their questioning. The questions started out small and my expectation was that they were going to get bigger, instead the questions dove ever increasingly into the extremely minor details of certain items. PSE was interested in the minutia and academia about java and tomcat and a whole bunch of other items. I was one the phone for over an hour. I finally had to stop the interview/phone screen and thank them for taking the time to talk to me but it did not sound like I was the person they were looking for. I interpreted that experience to say that they were interested in someone with either more experience OR someone who knew things that are easily found in a book or on the web. What they seemed not interested in was my ability to learn and self start. Rather then be interested in the process that I go through to gain knowledge in new technology and process.

Jeff states in his article:
"what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with."

This is what I think the interview, er, um, I mean phone screen at PSE should have been attempting to ferret out. Can I learn what I need to in order to do the job that the PSE would need me to do. Their screening process, I do not think, came anywhere even close and as a result left me feeling like the interview was a bust overall. I neither got the job or an offer, I just didn't measure up to their 'experience expectations'.

So if you are in a hiring mode what would you rather have - someone that has experience in software programming or someone who can pick up and use anything with ease and speed when the task at hand calls for it. Would you rather have someone stuck in their way of doing things or someone who can utilize any tool to approach and solve the problem at hand.

Jeff notes:
"No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing. This is why working programmers quickly learn to view their peers with a degree of world-weary skepticism. Perhaps it's the only rational response when the disconnect between experience and skill is so pervasive in the field of software engineering."

So like Jeff I pose the question, if you are looking for a job, why would you want to approach a company who is still using the 'years of experience myth' to do their job posting and searching. Like Jeff I find the attempt to be a simply ignorant move to weed out people that the companies think are all fluff and no stuff. Rather you should look for companies are searching for passionate people with a desire to learn. Companies should look for people that have a modicum of experience (6 months to a year) and consider their full experience as a programmer, the "learning range" of the person they are attempting to hire and search for excellence in that area.

In the end if your looking for a job, you'll be much happier and satisfied with the interview when the items above are what the company is interested in... if you are the company doing the hiring you will be much more pleased with the result of your hiring efforts when it comes down to doing actual work in new and creative ways.

Friday, March 21, 2008

To Tree or not to Tree that is the Big Co Question

I have talked about innovation on this blog before but a book that I have been reading and a recent post by Paul Graham stating You were not meant to have a boss got me to thinking about the topic of innovation as it pertains to management.

Paul says that there are consequences that happen when any company gets big. I believe he was pointing out that there may be a tipping point to the size of a company at which time the standard way of thinking about organization and management starts to break down leading to an inevitable slow down of everything that the Big Co. is attempting to do. He says the following:

"...companies will inevitably slow down as they grow larger, no matter how hard they try to keep their startup mojo. It's a consequence of the tree structure [of management] that every large organization is forced to adopt."

So my question(s) are thus: IS this tree structure, the org chart, really a necessity of getting bigger as a company? Is there really no innovation to be had in how companies organize themselves and the tasks at hand such that the 'tree' is the only way to go? My answer is NO on both counts - there is some empirical evidence for this in the world so let me see if I can back up my answer.

Ah the wizdom of crowds

Crowds as a whole are really quite something; they have a mentality all there own. One of the things about crowds is that they are really really good estimators. They are good estimators because no one person in the crowd has to be dead on they just have to be close. Taking a look across a broad range of answers to a given problem almost certainly provides a more accurate picture then having a few people (managers) making all the 'big decisions' for a company. This should be self obvious as just common place statistics yet every company I know is set up in the reverse and pays little attention to information to be 'gathered from the masses'. Provided the right information disseminated across a large group of people in an effort to estimate say growth of a sales unit within Big Co. the avg. answer has a much better chance to be closer to reality then the answer that a single smaller group of managers might be. There are a number of reasons for this, not the least of which is the pure and simple fact that the managers of a big co. by and large do not have all the information that may be needed to make an accurate estimate. You could argue that it is possible for the management folk to gather this information, my counter is that the instant it is gathered it might not be pertinent to the estimate. Only the frontline employees have a good feel for certain types of things, thus making them good estimators for a whole plethora of items. Big Co. being typical in most cases will however ignore the wisdom of the crowd in favor of a select few. This is a good case for not organizing in a tree and utilizing the information of the people to get things done. Those people however are going to need additional information that typical management holds tight to the vest.

Free and available Information

Information control is one of the ways that management types can maintain the tree structure and the management dogma. However the free and available information about all corners of Big Co. might spark a line of thinking in someone bringing about ideas that management might not other wise have thought of. Information pertaining to budgeting, staffing, pricing, sales and product can be very useful tools to the entire company. There is however an unwritten rule that this information is reserved for the management elite, those who have been shown to make good decisions in the past. What if those management types were armed with an army of people backing them up? What if that army had the same information management did and were allowed to essentially do what Paul says people (programmers in particular) do best which is invent new things rather then what is typical in Big Co. which is a stifling of what could be great new ideas:

"If you're not allowed to implement new ideas, you stop having them. And vice versa: when you can do whatever you want, you have more ideas about what to do."

All ideas should be welcome, radical ones perhaps more so. However if you lack the information about what direction you want to go in or where there have been problems in the past your new idea could meet with roadblocks and other preventative items. Information, good information is at the base of a great number of really great ideas. Share it far and wide.

Being Democratic

One of the HUGE draw backs to the way in which most large organizations is put together is the tree, the non-democratic way in which people are put into management positions. In a great number of cases people are promoted because they have pleased a singular person - their boss. In reality the person promoted might actually be a complete and total ass but that information did not weigh into the decision because only a small handful of people were involved in the promotion decision. In this particular case it might be an individual’s boss and that bosses boss who made the final call. You could argue that better managers of course might talk to people that have worked with said ass before but the tree structure of it all has the tendency to force that idea to the back burner as unnecessary. Be democratic, just like with the freedom of information and let everyone see what everyone else’s ideas are. Let everyone have a vote on what the company should be doing to increase profits, cut costs etc. Let everyone suggest what the best way to get and retain customers is. Let everyone have a vote. There is certainly no harm in letting the masses vote - you may just find that their wisdom was well worth a small effort to solicit the feed back in the first place.

Challenging Dogma

The problem with most of the items above is that they all challenge the dogma in management and organizational structure that has existed in companies now for a long time. There is some evidence in the world that this dogma can be changed (Whole foods employee based store management as an example) but there is certainly not enough of this type of trend setting work being done. Is the tree the only way? is it the case that your ability to change a company from within is limited based on where you are in the tree as Paul points out:

"...when you're part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you're going to face resistance when you do something new."

I say the tree is not the only way; the items above should point that out. There are ways to organize that allow people to feel empowered to make decisions. There are ways in which Big Co. can allow people to THINK and ACT and INNOVATE to keep the company fast. It is however going to take changes in how management thinks to get there. Go Grass roots - take the discussion to the masses let us innovate management and eliminate the 'boss' as Paul thinks of it today.

Saturday, March 8, 2008

"Here there be Dragons"

The title of this post "Here there be Dragons" is what cartographers used to put on maps to indicate a location or place that they either didn't know or had not been mapped by anyone at the date/time their map was created. This wonderful line was also used recently by a speaker that I know so I thought I would bring it up here as a way to make a posting point.

Life in general is a large and wondrous thing. The world is big and there are so many things to do and see that one might reasonably expect to only do or accomplish some percentage of 'everything' within their given life time. Life is also a very scary place, with lots of unknowns and lots of places that should be labeled "Here there be Dragons." The world of programming in a large number of ways is also big and full of unknowns and places that should be labeled "Here there be Dragons."

The title, on seeing it written on a map of old would evoke feelings of fear and apprehension in the sailors that used those maps to chart their course. However there were also that chosen few who would dare to use the map to go right to that location, the place where the dragons were, just to see what existed there. The world is full of both types of people, those who can play it safe and are ok with that and those who would rather take a leap of faith and see what can be discovered.

Fear is a natural reaction to the unknown. You know the butterflies in your gut when you do something a little outlandish or outside the norm? Human kind likes to stick to things they know or have experienced already by their very nature. People VERY much enjoy their routines. There are however a few outlying individuals who like to challenge, who like to push the envelope. A group of people that sit on the up and down slopes of the bell curve, ever dragging it in one direction or the other. A group of people who are naturally more nervous about taking chances and on the other side a group of people not as nervous about such things. Corporate world or outside world doesn't much matter in this case - routine is king for some and not for others.

A fair number of people in the world note that programming as a profession has not been around all that long. Hell computers have only really been around for ~50 or so years, a great deal shorter then some of the greatest life changing inventions in history - life altering stuff such as the wheel, the light bulb or even your avg. telephone. So it should stand to reason that a large number of things pertaining to programming have not yet been figured out. There are plenty of examples of where this bleeding edge work is being done. Arguments about static typing or dynamic. Conversations about threading models - and whether or not it is the next big frontier. Blog postings about languages (yes the many and varied) such as Python, lisp, java, ruby, haskell, OCaml, smalltalk and many more. A great many places for programmers that contain the label "Here there be Dragons."

Now alot of people look in on those conversations and ask themselves if those conversations really matter to them. A great number of people are comfortable with what they do and where they are in the programming realm so what does it matter. Those same people asking are the people who would rather fall into their routine. The people on the other side having those difficult conversations are the people who managed to get the butterflies in their stomachs to "Fly in formation" and overcome their fear of the unknown to attempt to make things better for everyone.

So in the end - maybe you are comfortable avoiding places where Dragons lurk. I for one am not - and will constantly look for where the Dragons are in an attempt to bring a new eye to those conversations. I will look for ways to help clear the Dragons out for others and for myself. I will constantly strive to get my butterflies to fly in formation so that I can make the most of my life both personally and professionally.