4 ms·

Yes, the people who were still in tech were obsessed and passionate about it. And then companies like this insisted we act like trained seals, spending days wor

Yes, the people who were still in tech were obsessed and passionate about it. And then companies like this insisted we act like trained seals, spending days working on irrelevant puzzles for the honor of being maybe possibly considered for a job. And then to top off that shit sandwich, they sprinkle in these wonderful bacon bits: "When implementing the server, aim for scalability and robustness. (Many submissions fail due to lack of robustness!) Your submission should include a description of the steps you took towards those two goals. Keep in mind that the client may be buggy, or even malicious. For example, if a client connects to the server and sends an infinite stream of the byte 'X' with no line break, the server should deal with this case gracefully. Please do not use an existing networking framework (e.g., Twisted or asyncore for Python, ACE for C++, etc.) to implement the server." Not only no, but fuck no. I settled for a job in the IT section at a bank working with COBOL and EJBs because of this shit, until I'd finally had enough, co-founded a company, moved to San Francisco and implemented a SANE hiring process that treated candidates like professionals. Most of us did, so I guess in a way these horrible and misguided hiring practices were partly responsible for the next resurgence, because we'd finally had enough.

matfil 7y ago
While I wouldn't necessarily say that problems in this style are the right way to recruit in 2019, something equivalent to: Please do not use an existing networking framework (e.g., Twisted or asyncore for Python, ACE for C++, etc.) to implement the server. ...would be a massively positive signal to me as a candidate. Places that truly value "full stack" abilities like this seem to be hard to track down.
- closeparen 7y ago
  Same. I had to do this in first-year CS, and got pretty surprised to find out I'd be working with senior backend engineers who've never heard of sockets. Concerns at this layer don't come up much, but when they do, the set of people available to help gets a lot smaller.
oriolid 7y ago
Just out of curiosity, what do you think is a sensible hiring process for people expected to know how program, and why does it work?
- kstenerud 7y ago
  What I've found worked well is to have a conversation about something they've built in the past. Ask them questions about it, like why certain architectural decisions were made, what constraints they had to work under, what issues came up, and how they dealt with them. I've even hired without seeing a single line of code. You of course have to change tactics when hiring junior devs, and would probably want to see SOME code in such a case, but regardless, just talking about technical subjects they claim knowledge about is usually enough to discover how deep that knowledge goes. If they have any code at all in the wild, I'll look at it to get a fuller picture of their abilities, but I won't require it. If I want to see code, I'll tell them beforehand that I want to build a little project together with them (less than 50 LOC) that does this one trivial thing, and that they can write beforehand if they want to. Then when they come in, we either build it together if they haven't done it beforehand, or we change the specs if they did. And no, no bonus points for doing it beforehand. That's just so that they can feel more comfortable in the codebase if they feel it's necessary (being nervous in the interview and all). I'm most likely not going to compare their code to others; I'm only interested in whether their code meets the company standards. I've also fired many people. It's not hard to do, nor does it cost much. So many of these recruitment processes are predicated on the principle of "what if someone lies to us?" for fear of hiring the dud. But in reality, it's so hard to bullshit someone knowledgeable that the actual risks are tiny. Yes, I've encountered people who couldn't code. I've had such resumes passed to me by people (usually non-technical, or recruiters) telling me how awesome this person is (because they don't know enough about the subject matter to tell the difference). But it takes very little conversation about any topic one is knowledgeable in to sniff out someone's bullshit. Think of it this way: You have a leak in your house and hire a plumber. The guy comes and tells you that you need this and that. How do you know he's telling the truth? Now imagine that you're a plumber who's been asked by a friend to sit in on the conversation. How long do you think it would take before you can confidently call bullshit on what he's saying? If YOU know your shit, you can tell when other people don't. And if you DON'T know your shit, you're going to have a hard time no matter how much code they throw at you.

matfil 7y ago

While I wouldn't necessarily say that problems in this style are the right way to recruit in 2019, something equivalent to: Please do not use an existing networking framework (e.g., Twisted or asyncore for Python, ACE for C++, etc.) to implement the server. ...would be a massively positive signal to me as a candidate. Places that truly value "full stack" abilities like this seem to be hard to track down.

closeparen 7y ago
Same. I had to do this in first-year CS, and got pretty surprised to find out I'd be working with senior backend engineers who've never heard of sockets. Concerns at this layer don't come up much, but when they do, the set of people available to help gets a lot smaller.

oriolid 7y ago

Just out of curiosity, what do you think is a sensible hiring process for people expected to know how program, and why does it work?

kstenerud 7y ago
What I've found worked well is to have a conversation about something they've built in the past. Ask them questions about it, like why certain architectural decisions were made, what constraints they had to work under, what issues came up, and how they dealt with them. I've even hired without seeing a single line of code. You of course have to change tactics when hiring junior devs, and would probably want to see SOME code in such a case, but regardless, just talking about technical subjects they claim knowledge about is usually enough to discover how deep that knowledge goes. If they have any code at all in the wild, I'll look at it to get a fuller picture of their abilities, but I won't require it. If I want to see code, I'll tell them beforehand that I want to build a little project together with them (less than 50 LOC) that does this one trivial thing, and that they can write beforehand if they want to. Then when they come in, we either build it together if they haven't done it beforehand, or we change the specs if they did. And no, no bonus points for doing it beforehand. That's just so that they can feel more comfortable in the codebase if they feel it's necessary (being nervous in the interview and all). I'm most likely not going to compare their code to others; I'm only interested in whether their code meets the company standards. I've also fired many people. It's not hard to do, nor does it cost much. So many of these recruitment processes are predicated on the principle of "what if someone lies to us?" for fear of hiring the dud. But in reality, it's so hard to bullshit someone knowledgeable that the actual risks are tiny. Yes, I've encountered people who couldn't code. I've had such resumes passed to me by people (usually non-technical, or recruiters) telling me how awesome this person is (because they don't know enough about the subject matter to tell the difference). But it takes very little conversation about any topic one is knowledgeable in to sniff out someone's bullshit. Think of it this way: You have a leak in your house and hire a plumber. The guy comes and tells you that you need this and that. How do you know he's telling the truth? Now imagine that you're a plumber who's been asked by a friend to sit in on the conversation. How long do you think it would take before you can confidently call bullshit on what he's saying? If YOU know your shit, you can tell when other people don't. And if you DON'T know your shit, you're going to have a hard time no matter how much code they throw at you.