4 ms·
If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone
by 0x20cowboy 2y ago
If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.
- tedunangst 2y agoIf all I needed to do was express my thoughts out loud, I wouldn't need to hire anyone. I can do that myself.
- cheeze 2y agoOn the flipside, I've spent an hour with a candidate who seemed great, but could hardly _actually program_. It was a bizarre dichotomy. Dude was clearly smart as hell but was so caught up in building perfect abstractions in parts of our software that _didn't matter all that much_ using languages that nobody else knew or wanted to use. I get it, your fun language is fun. But if the dev shop is 60% one language and 39% another, I don't really care about the small improvements. You need a strong reason that it actually _helps the business_
- caseyy 2y agoAsk them to explain what 4-5 different bits of code do. When they do, ask them to explain it like they would to a junior and to a senior/principal/fellow. It works very well and takes only an extra 10 minutes on top of the conversation.
- marcinzm 2y agoThat biases heavily to candidates with good people skills and the skill to take over a conversation. Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous.
- 0x20cowboy 2y agoI disagree. That would indicate conversations skills equate to knowing what you are talking about. "Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous." I think that I am. I'll think about that a bit more. I don't care for popular people so, in fact, my bias might be the other direction. However, I don't think I have ever met a person who I thought was technical and proficient, but turned out not to be. I have been forced to hire people I knew were not proficient because they passed a test, but not the other way around.
- marcinzm 2y ago> I don't care for popular people so, in fact, my bias might be the other direction It's not about someone being popular and you saying it just makes me more certain you don't realize the trap. People can have well honed social skills and not act like your standard popularity contest wining politician.
- kmoser 2y agoThe most carefully honed social skills in the world won't help somebody plausibly answer a question like "What is the data type of this variable?" or "Show me the line where the null pointer dereference is happening." They can add all the smiles and chuckles and other social niceties they want, but at the end of the day, whether they come up with the right answer or not, their logic will tell you pretty clearly whether they know what they're talking about. That's the point of a technical interview: to distinguish those who think (or pretend) they can code sufficiently well to do the job, from those who can't.
- noisy_boy 2y agoaka Talk is cheap, show me the code.
- caseyy 2y agoSo true. A test will only measure its set of criteria. What is a test for drive — desire to understand and learn? What is a test for how a person will respond to challenging and overwhelming prod scenarios? What is a test for if they will burn out in a month because they want to prove how rockstar of a programmer they are? My most successful hiring has always been based on a conversation with 3-4 practical questions. I even worked in a company that had testing down to a science with all the psychometric nonsense and in the end, it just hired many sociopath-adjacents.
- kenschu 2y agoThere's both culture and technical elements to consider in a potential hire. I don't think anyone would contest that vetting for the culture/drive of a candidate is important. But I do think the demonstration of skills is a necessary part of technical hiring, at least for non-senior positions.
- caseyy 2y agoI agree with that to some degree. But I do lean more into hiring on potential though, it has worked out for me. Skills can be learned. Tools can be provided. But the employee’s personal values are very hard to change. These are core components of performance in some perf management theories. I think context is important. If a company can hire on potential, I would say it will be a better hire in the long-term. But if employee turnover is high and tenures short, and you need work done now and not 6 months from now, I agree with you more.
- throwaway215234 2y agoWhat you're describing is a low hiring bar. Low hiring bars make sense for companies that pay low to average salaries, or don't require particularly deep technical skills. But it's an awful strategy if you're trying to filter for exceptional talent and willing to pay top dollar.
- BurningFrog 2y agoStrong disagreement! Sure, there is some correlation between talking and doing, but I've worked with people who talk like geniuses and code like crap. And also the opposite. For some skills, there is just no substitute for actually have people actually demonstrate using them.
- Pikamander2 2y agoThat sounds like a great way to end up with a dev team full of smooth talkers who you then later discover can't code their way out of a paper bag.
- mikeocool 2y agoI agree — this is very much the type of interview I like to give. However it took me a while to get good at steering the conversation and digging for details. It’s really easy to let the interviewee talk through talk through all of the great things they built from a product and business perspective — and assume they understand the technical perspective. There are candidates who are really good at talking in an impressive way, but manage to talk around any true implementation details or deep technical understanding. It’s also really easy to come away with a bad impression of someone who has a tendency to give short answers and not elaborate on things, even when it turns out that person is really skilled when you dig in. I imagine a big part of the reason for the test-style interviews we have today is that it’s easier to train an interviewer on how to give them.
- sethammons 2y agoWe tried this approach. It did not work. Source: SendGrid while ramping up to become a public company. The interviewing experience involved was fairly extensive; I had probably given a couple hundred interviews in my career by then and I was not the most experienced by a long shot. We tried to have a zero coding interview. All behavioral and experiences questions followed up by "how would you design a system to do blah." Got a candidate that did well. Hired. Turned out they could talk the talk but not walk the walk. It was wildly unexpected. They simply couldn't code well. Too long to deliver, too poorly written, usually didn't work right. We insisted on _some_ coding in interviews going forward