4 ms·

I am on the other side of the table too. I also design the interview process. The things I look in an interview - the ability to code with quality - the abili

by a_c 5y ago

I am on the other side of the table too. I also design the interview process. The things I look in an interview - the ability to code with quality - the ability to learn and grow - track record to deliver business value In my experience, people are wasting too much resources on interviewing. And the process is never meant for more senior positions. Engineers don't like it, and the outcome cannot be falsified (what if we hire someone with a light weight process, would it turn out worse?) I am saying specifically about interviewing, as opposed to hiring in broader sense. What you want is a process that evolve with your demand/available resource, not hardcoding of 2 sessions of coding (oh and with shadowing, so to grow interview skills of the team, of course!), 1 session of architectural design, 1 experience deep dive, whatever. Is this topic something people are interested in though? I might try to write up the thinking behind our process

CraigJPerry 5y ago
These are just 3 arbitrary points. E.g. I’m pretty certain you’re not advocating for hiring developers who can’t have a civilised disagreement, yet you don’t list anything about collaboration or communication or ability to put team before self in pursuit of a common goal. Hiring well is hard to do fairly and accurately. There’s no pithy shortcut that can be wrapped up in a blog post. About the best I’ve managed to go in 15 years of hiring is recognise that i have biases and recognise that I’m not always that good at seeing my biases.
- a_c 5y ago
  Agreed those are arbitrary point. And so is every hiring process. Pick some attributes that helps you define good people, good business, good tech and that's it. At the end of the day, it is a subjective process. I bet whatever "objective metrics" we come up at the end has some "rating" element in it which is subjective. Acknowledge the arbitrariness within the team and to the candidate in my opinion helps bring more fairness to the table. And also why I think it is worth less to overly religious over the hiring process
loup-vaillant 5y ago
> track record to deliver business value A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line. That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.
- jonfw 5y ago
  If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that allows a company to explore an idea before being thrown in the bin is still business value. This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.
  - loup-vaillant 5y ago
    My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces. For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant. Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]). [1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s
    - TheOtherHobbes 5y ago
      It shouldn't be "Delivered business value and here's exactly how much to the cent." It's more "Did something a manager considered useful." Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare. Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed. Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.

by a_c 5y ago

CraigJPerry 5y ago

These are just 3 arbitrary points. E.g. I’m pretty certain you’re not advocating for hiring developers who can’t have a civilised disagreement, yet you don’t list anything about collaboration or communication or ability to put team before self in pursuit of a common goal. Hiring well is hard to do fairly and accurately. There’s no pithy shortcut that can be wrapped up in a blog post. About the best I’ve managed to go in 15 years of hiring is recognise that i have biases and recognise that I’m not always that good at seeing my biases.

a_c 5y ago
Agreed those are arbitrary point. And so is every hiring process. Pick some attributes that helps you define good people, good business, good tech and that's it. At the end of the day, it is a subjective process. I bet whatever "objective metrics" we come up at the end has some "rating" element in it which is subjective. Acknowledge the arbitrariness within the team and to the candidate in my opinion helps bring more fairness to the table. And also why I think it is worth less to overly religious over the hiring process

loup-vaillant 5y ago

> track record to deliver business value A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line. That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.

jonfw 5y ago
If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that allows a company to explore an idea before being thrown in the bin is still business value. This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.
- loup-vaillant 5y ago
  My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces. For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant. Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]). [1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s
  - TheOtherHobbes 5y ago
    It shouldn't be "Delivered business value and here's exactly how much to the cent." It's more "Did something a manager considered useful." Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare. Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed. Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.