I'm interested in how would you hire a developer?(not necessarily Delphi developer) or highly skilled one.
I'm interested in how would you hire a developer?(not necessarily Delphi developer) or highly skilled one.
Personally, I'm interested in people that think for themselves, i.e.:
Here's what we wanna do __, thoughts? <- if this doesn't start a stream of thoughts on which we can build and make progress, that person is not really interesting any time soon.
If possible, I'd like everyone to join, from novice to experienced people and everything in between.
Personally, I'm interested in people that think for themselves, i.e.:
Here's what we wanna do __, thoughts? <- if this doesn't start a stream of thoughts on which we can build and make progress, that person is not really interesting any time soon.
If possible, I'd like everyone to join, from novice to experienced people and everything in between.
Not sure where you want to start in the process, but there are some key factors you need to consider from the start for picking who to interview: Skills, Experience, and Fit for role.
ReplyDeleteSkill set required - Do you need them to know, or is it OK if they learn as they go? If you urgently need help, they need as much of your desired skill set as possible. If you are just expanding the team, you have may have time to allow for a longer learning period.
Level of experience required - Slave Code Monkey, or Lead Code Architect? Will they be working from specifications, or creating the specifications? If the latter - they do need actual experience.
Fit for role - Everyone is looking for a job that fits them. Do you think they have the room to grow in the role and will they be willing to move outside their comfort zone? Will they feel constrained and have no view of where to move on? This is a risk factor for losing people. If they feel stuck in a rut, you risk losing them later.
The actual interview is a whole different ballpark!
How do you probe skill sets and experience? If you want to compare candidates, you really need to put some effort into designing the problems you want them to analyze. Do you offer parameters to work within, or do you allow them to redesign from scratch?
When you create the questions, they will say a lot about you and your product, so you most likely need to limit the scope, line up the ball park, and be prepared to be answer questions that the candidates have.
Thinking for yourself is great if you need a lead coder, but if you need a code monkey, you have to make sure that he doesn't find that role limiting. Thinking programmers also have a tendency of creating frameworks for everything (at least I do :P), whereas the code monkey might just brute force their way through.
When asking questions on skills and probing their ability to reason, use open questions that prevents yes/no replies.
- "How would you design it?"
- "How would you solve it, given that it has ?"
- "If you have to pick between A, B and C - which one would you chose, and why?"
- "This is how we did it. What other methods would be applicable?"
Make sure your questions don't require business knowledge which is not technically a developer skill, or define the business rules (but don't overdo it) before opening the question.
Other drills...
- Describing a solution - Can they model it in their head and present an understandable description verbally and/or in writing?
- Broken code analysis - Spot the logic error.
- Broken data analysis - Preventing garbage in, garbage out.
- From symptom to cause - Work through a bug report, what to check next.
- Asking the right questions - This is really difficult to quantify - but if you present a frame of reference, you prolly also have an idea about what would be good questions. Were they asked?
Social and organisational fit
- Do they fit in? Age and interests, maturity, hobbies, social skills?
- Group chemistry? Introverts vs Extroverts, able to take criticism and offer it in a civil way, giving and receiving praise?
- How do are they motivated? That's an entire other encyclopedia of leadership skills! Cash, Praise, Peer recognition, Job satisfaction, and so on...
- Can you meet their expectations for stuff to do, benefits, and salary - without compromising your current staff, both now and in 2-5 years?
Dig for facts
I've been burned by focusing too much on one aspect of a candidate fitting the "specs", and forgetting to probe properly, just because the candidate had excellent social skills, and appeared to ask the right questions - but turned out to be severely lacking in the skills area.
ReplyDeleteSo, always probe for examples of actual use: "Have you used it?", "When, why and how?", "How did you solve it?", "What did it do", "Is it in use?", "Was there any problems?" and ask them to exemplify and be concrete if they appear vague.
The challenge is getting through the above without leaving the candidate shell shocked or feeling like they have been exposed to a third degree interrogation.
What ever you do - Take interest in them. Be patient and don't be on the clock. They are there because you asked them to. You are the buyer. Make sure you get the quality you need.
Now - read the above paragraph as if you were applying for the job.
Lars Fosdal thank you for your post, I acknowledge that it took a bit of effort.
ReplyDeleteIt's interesting how many things one must keep in mind when hiring, one of the things that really blows my mind is that we seem to fail when hiring quite a lot, i.e.:
- requirements: language A, B, C, ..., Z.
- pluses: frameworks A, B, C, ..., Z.
- buzzwords: as many as possible
- as many years of experience as possible
...
then, at the end of the day, we end up with rolling devs at each 2-3 years.
I'm a simple guy that like simple things, so here are a few of my thoughts -- criticism is very welcomed!
- is s/he a "free thinker"?
- is s/he the person that not only gives solutions, but also recognizes flaws within solution(s) and/or other issues that were left out(for whatever reason)?
- is s/he not only showing interest in giving a good solution but also fine tune it in order to achieve a better polish?
~~~
if all of the above applies => hired!
Also, I believe that if you let people grow within your company and with company's "attitude", that dev will have quite a hard time changing the company, especially when they have something to say and can bring ideas that are taken into consideration and even applied.
This is my current view, pretty hardcoded into my brain, but I'm interested in fine tuning it, so feel free to add/remove/modify the list as you see fit or argue against.
I really hope that this discussion will bring a new insight into people, especially the people that just started in this field.
Designing for change is desirable, but not always a requirement. Sometimes you just need this one solution to solve this one problem.
ReplyDeleteOverdesigning and creating frameworks can be a massive waste of time, if it get's out of hand. On the other hand - failing to plan for change in a design can be very costly later.
The ability to correctly select whether to "sketch, code and go" vs "design, plan, code and go" - is very much a matter of experience.
Free thinkers are good as long as they don't suffer from the "Not Invented Here" syndrome and insist on writing everything from scratch.
Recognizing flaws is again dependent on the requirements for the solution. If it is well described and the biz.logic well known, it is easier to find them. Again - a matter of business knowledge and experience as much as it is a matter of skill.
My personal mantra: There are no stupid questions. Always ask if you are in doubt. You might want to ask to make sure everybody is on the same page, if you already know the answer.
All programming is an exercise in "What if..." - and so is design. But - sometimes the right answer to "What if" is "We Don't Care" or "We'll deal with that when we get there".
I like "lazy" programmers. The kind that will go to lengths to avoid repeating a tedious task. They tend to plan for the future.
Good people are hard to find. Personally, we've gone through 5 non-Delphi developers in the past 3 years. Granted, these were remote, freelancer/contractor positions, so the mindset requirement is different than that of an employee.
ReplyDeleteOne thing I never used to do, but have now found useful, is basic testing. Not to see how well a candidate knows esoteric language features or can solve complex problems under time pressure, but to see if they have good fundamentals and how they approach even simple problems. A fun, yet remarkable example is the Fizz/Buzz test:
Using your language of choice, print the integers from 1 to 100, but for multiples of three print "Fizz" instead of the integer. For multiples of five, print "Buzz". For integers which are both multiples of three and five, print "Fizz/Buzz".
It is stunning how many "developers" cannot do this without making a mistake.
I've also been unhappily surprised by developers that seem incapable of recognizing bad output. How one could create a report and not see that 50 + 2789 does not equal 612 billion is beyond me. Personally, I would feel like an idiot creating a report that doesn't at least add up. Sure, the data and calcs might be in error (it happens) but the damn thing should at least total correctly.
Dany Marmur I don't get it.
ReplyDeleteKevin Powick yeah, the simple and small things usually show the reality clearer, as stated above, I really like the simple things, sure one can take quite a few things and weight them, but at the end of the day, you have way too many variables and you're only human...
Text copy paste, Dany Marmur?
ReplyDeleteKevin Powick - Don't they teach mod anymore?
Lars Fosdal it's not that they don't teach operators, but the guys are thinking to complex to solve a simple problem.
ReplyDeleteI've been given a similar problem in the past at an interview...
Lars Fosdal They don't get it wrong because they don't know a particular language feature. It's due to more subtle, yet important, reasons such as weak comprehension, carelessness, inability to transform a problem solution to an algorithm, and the inability to recognize bad output; I've seen people fail this even with the benefit of having a computer to test their work. By "fail", I don't mean that they can't get a result, it's that they fail to recognize the result as incorrect.
ReplyDeleteMaybe it's an attitude of current developers, but in my mind, the first line of QA should be that of the developer themselves.
Numerical methods and discrete math and logic does have an important place in the life of a developer, but I've screwed up my fair share of algorithm implementations, so I think it is a little more complex than carelessness and weak comprehension, Kevin Powick.
ReplyDeleteAgain - experience with this kind of analysis helps.
One of the things that I've gotten better at over the years, is isolating tasks. Treat each link in the solution chain as one small problem and you get manageable code with plenty of room for asserting or inspecting the data. Divide and conquer, so to speak.
What you sacrifice in performance, very often is negligible compared to the time you end up wasting debugging, retesting or even refactoring your code numerous times - with the attached loss of client confidence when you just can't get it right.
If you absolutely need top notch performance, you can still rewrite and use the first implementation as your reference test code.
Then again - spaghetti developers will write spaghetti code in any language. I'm more of a Lasagna coder. Layer upon layer upon layer :P
Lars Fosdal There are also issues of domain knowledge. Many (most?) Delphi jobs are likely to involve database operations, but most of my working life has been spent on near-real-time applications, and relatively few developers have a significant appreciation of the impact that has on design. In most of those applications, I would have said that the database activity was little more than rudimentary. Management of events, and response to external triggers, on the other hand, was cause for a good deal of thought, and often, for significant experimentation.
ReplyDeleteI spent a couple of years working on a medical office practice app. Completely different requirements, and a tremendous need for knowledge of HIPAA documents, as well things like HL7 messaging. In this context, a skilled developer still needed months to gain sufficient comprehension of the domain specialization issues.
Indeed, Bill Meyer. In my experience, it is unusual to have people getting a solid grasp of the code base and the business logic in less than 10-15 months, unless they are familiar with the business up front. Good documentation really helps. You guys do documentation, right? Right?
ReplyDeleteWe've have become very fond of , but even to this day - I see that doing proper documentation very often is left as a to-do item. There just is so many other tasks in line...
Lars Fosdal I have been working now for about 18 months on a single project. It involves bringing forward functionality from an old (non-Delphi) app, as well as adding new functionality. It is database intensive, and monitors compliance with Federal requirements in certain areas of education, which is to say that there are innumerable complexities and quirks which must be accommodated. After all that time, I still--often--encounter surprises which require me to discuss with my client, who is the architect for the app. And it is not uncommon that he must in turn discuss with the agency using the app, as the (need I say it) Federal documents are (cough) less than clear.
ReplyDeleteLars Fosdal your previous comment.
ReplyDeleteI find myself in similar situations regarding code documentation, even when I have time to document, it seems like time wasting when I can bring value to the table(reports, better UI, better flow, etc.) -- yes bad practice, but what I think I do right is: write simple to understand code, even if I feel clever, tomorrow might be a bad day to understand the "clever" code.
As a result of above practice, everything is small, easy and can be picked up by almost every developer out there with average and below average Delphi knowledge(OK, there are a few things here and there that will bring a huge WTF on your face, but nothing earth shattering (: )
Dorin Duminica I have found that "clever" code is often the enemy of maintainability. For my part, I have no wish to be tied to any particular application to the end of time. In fact, from some, I want to run at the first opportunity! ;)
ReplyDeleteBill Meyer even tho' I'm far behind your experience, I have experienced quite a few times this sentiment (: the only thing keeping me from running is the awesome people I work for -- they worth every effort.
ReplyDeleteClever code always comes back to bite you. Simplicity rocks. So many proverbs in this area. Quick and Dirty Code - When Quick is forgotten, Dirty remains.
ReplyDeleteDorin Duminica Awesome people make a huge difference. My client is terrific, and we get along without any difficulties between us. We may both have difficulties with some aspects of what needs to be built and delivered, but never an argument over how to implement. It's always a discussion of what is needed, and how best to make it accessible to users who may not be very adept at the niceties of the system.
ReplyDeleteLars Fosdal yeah, I tend to leave "clever" for researching into ways of doing things.
ReplyDeleteBill Meyer same here, I usually fight over simplicity, one of the people I work for wants a lot of flexibility for the user <- this brings a lot of issues for the user(which in most cases is PC "illiterate"), oh boy, the discussions this brings (:
P.S. Bill Meyer can you share you thoughts on how would you hire a developer please?
ReplyDeleteDorin Duminica In my own experience, "flexibility for the user" quickly moves us into YAGNI (You Ain't Gonna Need It) territory. A more logical arrangement of user access usually trumps the flexibility.
ReplyDeleteSpecialist apps usually don't do beginner friendly. Being both beginner friendly and super user friendly and effective, is really hard to accomplish.
ReplyDeleteLars Fosdal It varies. I designed a video server app for broadcast television that I think was user friendly and very effecxtive, while being pretty simple for new users to comprehend. Bear in mind, though, that I had 25+ years of experience in broadcast television when I sat down to design it, and unhappy experience with a few other approaches from various vendors. Domain knowledge gave me an edge.
ReplyDeleteLars Fosdal I think this is the 80-20 rule, right?
ReplyDeleteif the target audience is super user, then you make it best for that type, and the reverse is true for simple users. So, I think it all goes down to testing the flow back and fourth many times and figuring out how you can simplify it as much as possible.
IMHO PC's and software and everything related exists to SOLVE problems, if it creates more problems than it solves, then not only are you left with more problems than before having the software, but you've also wasted money, effort and time.
I once delivered a release version that frozen everything when it was deployed -- worked on my PC -- the business using it was devastated for an entire day <= this brought in an entirely new POV in my mind: don't release stuff that's not tested enough and deployed on clean VM.
And no, I did not have to pay anything on that, someone else took the fall for me which is worst that if I had to pay the price...
Dorin Duminica My own experience in hiring developers is spotty, at best. I would endorse what Lars has already said, but add that as most of my work has been in or for small companies, the personality of the developer is a large factor. He can be highly skilled, but if he has a bad attitude, or a huge ego, I'll pass. On the other hand, someone with a real desire to become a member of a productive team but has gaps in his experience, may be more attractive. In difficult cases, I may propose a trial period. As I am often talking to people who have done contract work, it's usually an option. A few months--or in a bad case, possibly much less--will let me see how they work out. The problem of domain knowledge is always a factor, and many people have a horrible time at interviews. Seeing how they work on a real task resolves the things an interview can't. Not usually practical, though, if the company is large.
ReplyDeleteDorin Duminica - I wrote software for the financial business for many years. I learned a lot about the importance of testing while sitting with the traders, and seeing and hearing the quite graphic response of my users when my app didn't show them the right figures :)
ReplyDeleteIsn't the 80-20 rule in software that 80% of the features take 80% of the time, and the remaining 20% of the features, also take 80% of the time? ;)
Lars Fosdal Broadcast operators are pretty colorfully expressive, too!
ReplyDeleteI bet :D
ReplyDeleteBill Meyer I happen to share the same thoughts, don't really like big companies they make one feel insignificant...
ReplyDeleteLars Fosdal ((: ah the memories in a software dev's life, maybe we should do a hangout and tell our various code horror stories?
I am trying to forget those ... ;)
ReplyDeleteDorin Duminica If feeling insignificant had been the worst of it, I'd have been laughing. Two years in hell is what it was.
ReplyDeleteLars Fosdal NFW was a popular acronym...
ReplyDeleteLars Fosdal we all do, but the thing is:
ReplyDelete- when I started coding, I would have rather thrown acid in your face than let you see what I do because I was afraid of being judge -- that was then...
If new devs can have an idea of how things happen, I think they can be less stressed and focus more and better on the things that really matter and learn from our experiences.
It is not the size of the company, it is the size of your little corner, and how that corner interacts with the rest of the company. Are you viewed as an asset or a liability?
ReplyDeleteBeing a development manager in Reuters was hard. A lot of politics and lobbying, and always having to defend your priorities to people that appeared to think that the software created itself while they were brainstorming new features to sell.
When I got the chance to decide if I wanted to go all pointy haired boss or The Way of The Geek - I ended up going back to doing what I love most. Write code and solve challenges.
Fortunately, I've always had the privilege of working with skilled people that love their work.
Dorin Duminica - Fortunately, open source drives more developers to show their stuff these days. I also was pretty secretive when I was fresh, but since I usually wasn't the only developer on the project - I had to. In a way, that improved my code too.
ReplyDeleteLars Fosdal Fair summary. In my case, the corner was small, very, and those of us working in the code were hugely undervalued. Moreover, lack of domain knowledge was held against you, but knowledge gained somehow never became an asset.
ReplyDeleteI had previously spent decades working almost exclusively with skilled people who valued their coworkers, and where egos were rarely a factor, except in respect to the desire to deliver clean solutions.
"I think it is a little more complex than carelessness and weak comprehension" Lars Fosdal
ReplyDeleteNot when the problem tests basic principles as simply as Fizz/Buzz and you're applying for a job, where one would think you would be taking the most care to be accurate. Of course, an application doesn't hinge on just one test; I was just giving a single example.
It is a very good example.
ReplyDelete