4 ms·

Here is what I love to see: 1. An understanding of the fields of work and of their evolution. Don't look for candidates based on languages and libraries -- tho

by alxlaz 8y ago

Here is what I love to see: 1. An understanding of the fields of work and of their evolution. Don't look for candidates based on languages and libraries -- those might be OK to get an initial shortlist, but: a) Any programmer past junior level should be able to pick up a library (from a field he understands) in ~1 week and become minimally productive with a language in 2-3 weeks. b) It's the idioms of each field that are difficult to teach, not the tech tools. Someone who did Java ME programming back in 2003 is probably better suited for an embedded software engineering position than someone who has 5 years of writing C++ code in the banking industry. 2. Erring on the side of inclusiveness. If you have doubts about whether I should see a candidate or not, send me the resume and we'll figure it out. 3. Valuing listening over "established patterns". Case in point: short job tenures. I've given favourable feedback for kids who, early in their careers, hand changed two or three jobs in a row. They were brilliant programmers who ended up in large companies, where managers many layers above them assigned them tasks way below their skill level, based on their title of "Junior Software Engineers" rather than on reading their CVs. They did the smart thing and left jobs that hampered their professional development. So far, I have not been wrong about this a single time. That's not to say short job tenures are always something to ignore. Some people have them because they're assholes -- but okay, we won't hire them because they're assholes, not because they spent less than an year in two places. 4. Valuing honesty over "right" answers. I know people who left their jobs because their boss was a dick, HR wouldn't handle it, their boss's boss was an even bigger dick and they had no access to that boss's boss. These people should be able to say why they're leaving their jobs, not invent reasons about company culture and looking for new challenges and self-deprecating comments about how they just don't think they belong in that team. 5. Appreciating competence, thoroughness and professionalism, not things like enthusiasm. Some of the best engineers I know work on a strictly 9-5 basis and go home to their kids and don't touch computers by choice because their kids are the world to them. Professionalism and competence are hard to fake. Enthusiasm isn't. If you want to appreciate enthusiasm, take real, falsifiable cues. Don't look for broad smiles and "I'm so super enthusiastic about <this company culture item>". For example, look for relevant hobbies, like ham radio or restoring old computers. Any idiot can fake being enthusiastic about programming in an interview, but faking it by writing m68k on a Friday evening for fun is above and beyond what most people would do in order to look like they love their profession.

sanderjd 8y ago
I'm surprised I didn't find this higher up the thread: I'm soooooo sick of people hiring based on languages. It's right there in the first response in this article: "make sure you’ve included the same language as the job description if at all possible". This is so ridiculous. Either you're hiring a junior person and you're going to have to invest in ramping them up anyway, or you're hiring a senior person who will quickly figure out whatever language you use. The exception to this is if you're hiring the lead for a project, who will be setting the idioms and mentoring the rest of the team. But even then, why are you dictating technology to that person rather than letting them choose? It is worth asking people whether they are interested / willing to learn the tools you're building on, but it doesn't make sense as a filter.
- dragonwriter 8y ago
  > The exception to this is if you're hiring the lead for a project, who will be setting the idioms and mentoring the rest of the team. But even then, why are you dictating technology to that person rather than letting them choose? Just because you are hiring a lead doesn't mean it's a greenfield project with nothing established; even if the lead has freedom to migrate over time, that doesn't mean that it isn't important for them to be able to guide and mentor on the existing stack very quickly. I generally agree the I industry overemphasized experience in using particular tools rather than skill in engineering systems, but it is not the case that specific tool (including language) skill is completely irrelevant.
  - sanderjd 8y ago
    I see that what I said wasn't clear at all: I meant the specific kind of lead who will be setting everything up, ie. on a greenfield project. I think a lead on an established project falls into the camp of experienced people who can figure things out. Another exception: contractors. In this case, you do want someone who is immediately productive in the language you're using because you do not reap any of the benefits of them ramping up like you do with permanent employees. For contractors, familiarity with the language and ecosystem is the more important part of their job; for employees, familiarity with the business is more important and the language stuff can be picked up.

by alxlaz 8y ago

sanderjd 8y ago

I'm surprised I didn't find this higher up the thread: I'm soooooo sick of people hiring based on languages. It's right there in the first response in this article: "make sure you’ve included the same language as the job description if at all possible". This is so ridiculous. Either you're hiring a junior person and you're going to have to invest in ramping them up anyway, or you're hiring a senior person who will quickly figure out whatever language you use. The exception to this is if you're hiring the lead for a project, who will be setting the idioms and mentoring the rest of the team. But even then, why are you dictating technology to that person rather than letting them choose? It is worth asking people whether they are interested / willing to learn the tools you're building on, but it doesn't make sense as a filter.

dragonwriter 8y ago
> The exception to this is if you're hiring the lead for a project, who will be setting the idioms and mentoring the rest of the team. But even then, why are you dictating technology to that person rather than letting them choose? Just because you are hiring a lead doesn't mean it's a greenfield project with nothing established; even if the lead has freedom to migrate over time, that doesn't mean that it isn't important for them to be able to guide and mentor on the existing stack very quickly. I generally agree the I industry overemphasized experience in using particular tools rather than skill in engineering systems, but it is not the case that specific tool (including language) skill is completely irrelevant.
- sanderjd 8y ago
  I see that what I said wasn't clear at all: I meant the specific kind of lead who will be setting everything up, ie. on a greenfield project. I think a lead on an established project falls into the camp of experienced people who can figure things out. Another exception: contractors. In this case, you do want someone who is immediately productive in the language you're using because you do not reap any of the benefits of them ramping up like you do with permanent employees. For contractors, familiarity with the language and ecosystem is the more important part of their job; for employees, familiarity with the business is more important and the language stuff can be picked up.