Tests are useless. Why test someone on a tricky bit of source code, or make someone think stuff up from scratch. When I hire someone, I want someone who knows how to design. A proper design is far more valuable than a piece of code -- coding is the easy part! If someone forgets how to implement a particular function, there's always MSDN and CP. I look for people who are eager and willing to learn new techniques, and also know exactly where to go if they forgot some details. I look for resourceful people. I like to give a standardized "behavioral interview", where I ask the candidate to describe a situation, state his actions, and tell me the outcome. These questions are designed around a set of core competencies that I find are of most value to the position. I look for thought patterns and elegant solutions to his/her situations. I also look for outcomes that were less than desirable, or complete failures. I feel a failure is worth far more knowledge than a series of simple successes. I also like the fact that they encountered the failures on someone else's nickel That tells me they are ess likeley to make that same mistake with me. And all the while during the interview, I am assessing their personality. I look for confidence without arrogance, and persuasion without manipulation. I also look for what i call "the fire", that intangible quality that tells you a person really loves what they do.
All and all, one could always hire a monkey to write code; I'd prefer a true developer.
People who were eager to call themselves "developers" five years ago are now calling themselves "architects". Those calling themselves "developers" are mostly just too stupid to realize they needed to make the switch. They like to prattle on about adding value, etc. I can spot a faker like this within five minutes.
Just like with anything else, in this business one achieves mastery in the doing. Someone that has much experience finding out (through a combination of study, playing around in their spare time, etc.) the best ways to do things will have knowledge ready to hand in a discussion of these topics. People that always prefer to steer the conversation away from technical things don't know what they're doing.
Just keep looking for your failures... you're bound to find them. I'll keep putting together clean, scalable programs (not "developing value added solutions") in the meantime. And if anyone asks, I'll have plenty of specific things to say on everything I've touched, and high-level things as well.
Jeff Varszegi wrote: People who were eager to call themselves "developers" five years ago are now calling themselves "architects". Those calling themselves "developers" are mostly just too stupid to realize they needed to make the switch.
See, I could care less what they want to call themselves; as long as they can design high-quality software. I'd even put "yoda" or Grandmaster on their business cards if they'd like.
Okay, so it'd be okay with you if you hired a "developer" who called him/herself a "programmer". It's your statement that you don't care whether someone can write decent code that I find ridiculous. You'd rather hire someone who can see the big picture but can't correctly solve the problem; you say that's just make-work. I submit that only after developing low-level skills does a person correctly develop high-level ones.
What's wrong with the title "programmer"? I'm a programmer. I'm also a developer and an architect. I take pride in my ability to design well, but I also take pride in my ability to code well. A wonderful design combined with poor coding techniques still results in a poor quality product.
That's all well and good if everyone you interview has an intrinsic ability to code well, but most do not. In my (albeit limited) experience, few people produce truly high quality code. I believe neglecting to test for coding competence is a major oversight.
I agree with you, but I still think that temp-to-perm is the best way to go, no matter what you're looking for. I think it's pretty easy for a lazy jerk to camouflage their behavior for a short amount of time, even several months. If I ever have my own company, I'm going to hire temp-to-perm with the initial contract being not less than one year.
Hiring based on "attitude" can sometimes lead to only hiring a certain type of person. It would be a shame hire "all mouth no trousers" types exclusively. Diversity is important. I think a common mistake is people hiring others who are like them in terms of personality.
Please clarify what you mean by "attitude". If you are referring to a good work ethic then I agree with your policy However if you are referring to less tangible and/or subjective qualities I strongly disagree.
(PS. Always remember that candidates who stuck to and finished a 3 or 4 year degree are demonstrating commitment and responsibility.)
My view of 'attitude' involves a person's work ethic, their approach to customers, their willingness (or lack thereof) to go the whiole 9 yards, their commitment to self-improvement, their ability to thinkon their feet without jumping in feet first without thinking.
I manage a helpdesk for a large multinational. The last thing I want is for an employee to treat customers (ie anyone seeking our assistance) as though the customer was there to provide the helpdesk with work. I don't want our customers feeling that we are doing them a favour. Rather they should be provided with a prompt, efficient, courteous service.
Hiring some based on their finishing a 3 or 4 year degree most defintiely does not guarantee that they have the right characteristics to work on a busy helpdesk. I have learned that the hard way.
Completing a 3 or 4 year degree shows commitment to completing a 3 or 4 year degree and not to our customers. Nor does it demonstrate that the person has a responsible attitude. It does suggest commitment and responsibility and that the person MAY be suitable but it is most definitely no guarantee.
I always remember that the degree demonstrates a level of commitment and responsibility. But I also take into account the fact that the degree is no guarantee.
The approach my employees take towards their customers is extremely important. A degree is no guarantee that they will have the correct approach.
In the beautiful city of
Adelaide, South Australia
A employee to do a helpdesk or to do a client confrontation can be different from the "usual" coder.
In that part i agree that a person with good verbal skills (mouth) can be enough, no code knowledge may be necessary - no diploma also, they can be tought to speak the speech.
As for a coder - that atrib alone is not enough. Trainning for a coder can be a very high-cust solution.
Edmund . C . Prakash wrote: 2 very good qualities everyone looks for in employees.
I'd prefer people who are smart and ones who aren't cheap. Paying somebody a low wage, is a guarantee of low productivity, bad feeling and a whole host of other negative attitudes.
Paying a reasonable rate, is the only way to do it. Anybody willing to settle for less, is probably not worth employing - as they can't be that smart.
Edmund . C . Prakash wrote: My company only hires the best of the best. They also have to be indian.
Interesting. Over here in the UK, we could get into trouble for that kind of discrimination. You give the job to the best suited candidate, regardless of race or colour.
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
Last Visit: 31-Dec-99 19:00 Last Update: 20-Feb-24 11:35