4 ms·

The solution is effective hiring. Work sample or project based hiring methods get people to demonstrate their skill-sets. I once had a candidate refer to resume

The solution is effective hiring. Work sample or project based hiring methods get people to demonstrate their skill-sets. I once had a candidate refer to resume/conversation based hiring as 'ritualized lying'. I think that's bang on. This isn't directly in response to your comment, but... There's an elitist under(over?)-tone within HackerNews that asserts any less-than-engineer technical role is inferior and attracting of undesirable character. There's a particular disdain for project managers, often for good reason. Few things are more aggravating than a poor non-technical PM. But, in many organizations they're essential and valuable members of a team. Skilled people can have an immense degree of technical talent and no interest in programming or engineering culture.

Buge 9y ago
Is the work sample done in person or take home? If it's take home, then they can just cheat on that by hiring someone else to do it.
- goodroot 9y ago
  At Compose (YC, S11) we had a two part hiring method. The first was a blind work-sample. You had unlimited time to complete it. Identifying information was obfuscated and graders would yes/no objective criteria. The best samples proceeded to the "work day". During the work day, you'd join is in Slack for 8 hours. You'd need to ask probing questions to mock-up our infrastructure and pitch a feature based on "how we work". One could try to cheat on the first part, but there is no chance one could have bamboozled us during the work day. For our technical writing positions we had some instances of outright plagiarism, but no instances of anyone trying to cheat the coding sample.
  - achievingApathy 9y ago
    Just out of curiosity, how many people applied vs. made it through the blind work-sample vs. the work day? I think this is a great system, but I'm not sure I could keep a team of engineers actively engaged in answering infrastructure questions while at the same time trying to get their own work done. Was that an issue?
  - wikibob 9y ago
    Are you still working at Compose? I'm curious how the IBM mandate of all remote workers going back to an office every day has affected Compose.
  - fragmede 9y ago
    > During the work day, you'd join is in Slack for 8 hours. That's amazing! For everybody else that shares my amazement, I found https://www.compose.com/articles/how-compose-uses-interviewed-com-and-slack-to-automate-blind-hiring/ https://www.compose.com/articles/how-compose-uses-interviewe... that touches on said hiring practice, but I'd love to hear more.
  - alasdair_ 9y ago
    How much did you pay people for the two days worth of work?
  - alasdair_ 9y ago
    How much did you pay people for the two days worth of work?
- davidbanham 9y ago
  The trick is to then talk through the code with them in the next interview. "Why did you do this part this way? Would you do it differently if requirement X were different?" It's immediately obvious if they cheated. Better yet, that's a much better, more relevant discussion than most whiteboard problems.
glangdale 9y ago
The whole "effective hiring" answer doesn't scale. I am absolutely appalled at the idea that I would have to do a 'fizzbuzz' test for a purportedly senior developer listing 'strong C/C++ skills', for example. However, that's the reality we face, and part of that reality comes from having people be comfortable with lying their way into our "profession" and us not be completely aghast when it happens. A fake doctor or accountant is a scandal. A fake programmer is business as usual. On the elitist over/under-tone stuff: I should have been clearer. I think PM roles, documentation roles, testing roles, etc are all extremely important. However, I don't think these are roles where you should stash incompetent and dishonest pseudo-developers; I think the odds are pretty good that someone who fakes their way through being a developer isn't going to be that good at anything else.
- humanrebar 9y ago
  > A fake doctor or accountant is a scandal. A fake programmer is business as usual. I generally agree with your points, but people don't die or go to jail because of bad code. With a few exceptions. And in those exceptions there are additional checks (checklists upon checklists, rigorous testing gauntlets) to prevent buggy code from causing safety issues. Technically underqualified people typically result in missed deadlines and/or poor project velocity. That can be catastrophic for a business model, but it doesn't directly result in any kids growing up without a parent.
  - salesguy222 9y ago
    As a foil to your claim that people don't die from bad code: In 1999, when the US was engaging in a bombing campaign in Serbia against "military targets" that were staffed by civilians, the US bombed the Chinese Embassy, killing several and injuring dozens of civilians. The US later "apologizied" by saying "sorry, we programmed the coordinates improperly." Now, I'm not sure if that means some CIA intern college kid task monkey supplied the wrong coordinates to the bomb programmer, or if the bomb programmer typed the (correct) coordinates improperly. But, software absolutely does kill people when wielded by lazy, incompetent, and often, diploma-holding programmers. https://en.m.wikipedia.org/wiki/United_States_bombing_of_the_Chinese_embassy_in_Belgrade https://en.m.wikipedia.org/wiki/United_States_bombing_of_the...
humanrebar 9y ago
> The solution is effective hiring. Meh. Hiring is expecting other people to train your employees for you. It's important to hire smart, driven, forthright people, but if you really want them to, say, write readable code, assign them to read Clean Code, make code clarity part of the regular performance review, add it to the code review checklist, etc. In my opinion, bigger than hiring practices is a lack of communication up and down the chain of command about the importance of good code, who is writing it, and what are the carrots and sticks involved in making sure good code happens. Most people able to hand out raises and job titles work off secondhand and hand-wavy information about technical prowess at best: "Yeah, he's really good. Fixes lots of bugs and get asked for help a lot." Of course, that could be because the code's a big mess and he wrote himself some excellent job security. A non-technical PM would know little about this very common issue.
- thegayngler 9y ago
  TBQH, Management does not care about clean code so much as getting a project out by the deadline however unrealistic it may be. Clean code is very low on their list of priorities. Even among managers who used to be engineers it's very low on the list of priorities. They say they care about it. That's not the reality though.
  - mrlyc 9y ago
    It depends on the company. One place I worked at instituted a bonus system with the result that programs were released on time, buggy or not, as releasing them late would have reduced the managers' bonuses. I raised a stink about that by repeatedly saying "We really must inspect the code before the product ships." I was sidelined and let go early when the company shrank to a shadow of its former self, infested by people who were more interested in furthering their career than doing the job. The next company I worked at was very serious about quality. When I started working there, I was told that I was allowed one bug in my code. If there were a second one, I would be fired. I'm not sure if that was true as my code didn't have any (found) bugs. It was thoroughly inspected by two senior engineers before I could even run it on the test bench. We were some months behind schedule but there was not one word about reducing the quality to catch up. The first company made communications equipment, the second one an air traffic control system.

Buge 9y ago

Is the work sample done in person or take home? If it's take home, then they can just cheat on that by hiring someone else to do it.

goodroot 9y ago
At Compose (YC, S11) we had a two part hiring method. The first was a blind work-sample. You had unlimited time to complete it. Identifying information was obfuscated and graders would yes/no objective criteria. The best samples proceeded to the "work day". During the work day, you'd join is in Slack for 8 hours. You'd need to ask probing questions to mock-up our infrastructure and pitch a feature based on "how we work". One could try to cheat on the first part, but there is no chance one could have bamboozled us during the work day. For our technical writing positions we had some instances of outright plagiarism, but no instances of anyone trying to cheat the coding sample.
- achievingApathy 9y ago
  Just out of curiosity, how many people applied vs. made it through the blind work-sample vs. the work day? I think this is a great system, but I'm not sure I could keep a team of engineers actively engaged in answering infrastructure questions while at the same time trying to get their own work done. Was that an issue?
- wikibob 9y ago
  Are you still working at Compose? I'm curious how the IBM mandate of all remote workers going back to an office every day has affected Compose.
- fragmede 9y ago
  > During the work day, you'd join is in Slack for 8 hours. That's amazing! For everybody else that shares my amazement, I found https://www.compose.com/articles/how-compose-uses-interviewed-com-and-slack-to-automate-blind-hiring/ https://www.compose.com/articles/how-compose-uses-interviewe... that touches on said hiring practice, but I'd love to hear more.
- alasdair_ 9y ago
  How much did you pay people for the two days worth of work?
- alasdair_ 9y ago
  How much did you pay people for the two days worth of work?
davidbanham 9y ago
The trick is to then talk through the code with them in the next interview. "Why did you do this part this way? Would you do it differently if requirement X were different?" It's immediately obvious if they cheated. Better yet, that's a much better, more relevant discussion than most whiteboard problems.

glangdale 9y ago

The whole "effective hiring" answer doesn't scale. I am absolutely appalled at the idea that I would have to do a 'fizzbuzz' test for a purportedly senior developer listing 'strong C/C++ skills', for example. However, that's the reality we face, and part of that reality comes from having people be comfortable with lying their way into our "profession" and us not be completely aghast when it happens. A fake doctor or accountant is a scandal. A fake programmer is business as usual. On the elitist over/under-tone stuff: I should have been clearer. I think PM roles, documentation roles, testing roles, etc are all extremely important. However, I don't think these are roles where you should stash incompetent and dishonest pseudo-developers; I think the odds are pretty good that someone who fakes their way through being a developer isn't going to be that good at anything else.

humanrebar 9y ago
> A fake doctor or accountant is a scandal. A fake programmer is business as usual. I generally agree with your points, but people don't die or go to jail because of bad code. With a few exceptions. And in those exceptions there are additional checks (checklists upon checklists, rigorous testing gauntlets) to prevent buggy code from causing safety issues. Technically underqualified people typically result in missed deadlines and/or poor project velocity. That can be catastrophic for a business model, but it doesn't directly result in any kids growing up without a parent.
- salesguy222 9y ago
  As a foil to your claim that people don't die from bad code: In 1999, when the US was engaging in a bombing campaign in Serbia against "military targets" that were staffed by civilians, the US bombed the Chinese Embassy, killing several and injuring dozens of civilians. The US later "apologizied" by saying "sorry, we programmed the coordinates improperly." Now, I'm not sure if that means some CIA intern college kid task monkey supplied the wrong coordinates to the bomb programmer, or if the bomb programmer typed the (correct) coordinates improperly. But, software absolutely does kill people when wielded by lazy, incompetent, and often, diploma-holding programmers. https://en.m.wikipedia.org/wiki/United_States_bombing_of_the_Chinese_embassy_in_Belgrade https://en.m.wikipedia.org/wiki/United_States_bombing_of_the...

humanrebar 9y ago

> The solution is effective hiring. Meh. Hiring is expecting other people to train your employees for you. It's important to hire smart, driven, forthright people, but if you really want them to, say, write readable code, assign them to read Clean Code, make code clarity part of the regular performance review, add it to the code review checklist, etc. In my opinion, bigger than hiring practices is a lack of communication up and down the chain of command about the importance of good code, who is writing it, and what are the carrots and sticks involved in making sure good code happens. Most people able to hand out raises and job titles work off secondhand and hand-wavy information about technical prowess at best: "Yeah, he's really good. Fixes lots of bugs and get asked for help a lot." Of course, that could be because the code's a big mess and he wrote himself some excellent job security. A non-technical PM would know little about this very common issue.

thegayngler 9y ago
TBQH, Management does not care about clean code so much as getting a project out by the deadline however unrealistic it may be. Clean code is very low on their list of priorities. Even among managers who used to be engineers it's very low on the list of priorities. They say they care about it. That's not the reality though.
- mrlyc 9y ago
  It depends on the company. One place I worked at instituted a bonus system with the result that programs were released on time, buggy or not, as releasing them late would have reduced the managers' bonuses. I raised a stink about that by repeatedly saying "We really must inspect the code before the product ships." I was sidelined and let go early when the company shrank to a shadow of its former self, infested by people who were more interested in furthering their career than doing the job. The next company I worked at was very serious about quality. When I started working there, I was told that I was allowed one bug in my code. If there were a second one, I would be fired. I'm not sure if that was true as my code didn't have any (found) bugs. It was thoroughly inspected by two senior engineers before I could even run it on the test bench. We were some months behind schedule but there was not one word about reducing the quality to catch up. The first company made communications equipment, the second one an air traffic control system.