5 ms·

I disagree. I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding. In fact, I don't see how it is po

I disagree. I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding. In fact, I don't see how it is possible to do extremely well on the "talk like a professional" part and not be able to write basic programs, unless you and I have very different concepts of what "talk like a professional" means.

brianwawok 11y ago
I worked with a team of these before. You can rule our certain types of people with tech questions (i.e. never coded before, only coded hacked, etc.). You cannot rule out * People who read a lot of blogs so know the lingo, but never code * People who get the theory but can't actually implement something that works without bugs * People that over-engineer simple things
- dpark 11y ago
  Also: * People who have been on a team long enough to learn how things should work but lack the skills to really do the coding. I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume that someone else on his team is carrying most of the coding burden. This guy might be great at a PM-type job (or not, I don't interview for those jobs), but not as a dev.
  - vonmoltke 11y ago
    I feel like there is some detail missing here. What constituted doing "very well" on the open-ended questions? How deep into the engineering did you get? Since you mentioned he "might be great at a PM-type job" it sounds like you didn't go very deep on int.
    - dpark 11y ago
      That one was a phone screen, so no it was not the deepest technical dive ever. But in fairness a 1-hour interview is rarely the deepest technical dive possible. I normally pose some big problem like "design a system that accomplishes X at high scale" and then drill into some area iteratively until we're discussing fairly specific details. At the high level I'm looking for the candidate to recognize tradeoffs between centralized/distributed designs, sanely choose the major components, deal with stateful and stateless components, recognize security tradeoffs, etc. As we drill in we might talk about data partitioning, georeplication, or high availability and implementation tradeoffs there. We might get down to the level of something like handling out-of-order change notifications. Rarely do I drill down to the level of file I/O or memory management strategies.
- vonmoltke 11y ago
  > People who read a lot of blogs so know the lingo, but never code I think this is where my definition of "talk like a professional" may be more strict. I'm interested in understanding, in opinions, in the actual engineering. > People who get the theory but can't actually implement something that works without bugs Having spent most of my career working with PhDs trying to design and implement signal processing and NLP algorithms, I have experienced a lot of that. Given the proper attitude, it is fairly easy to correct coding deficiencies if someone really understands what they are supposed to be doing. > People that over-engineer simple things The greater offenders are fairly easy to detect in a directed technical discussion. The lesser offenders are fairly easy to correct in code review, again given the proper attitude, as they are unlikely to be doing things that require major refactoring. In short, I think I place much more emphasis on engineering as opposed to coding. My experience has been that any coding issues people with good engineering skills and an attitude worth hiring have are quickly and easily corrected. You cannot really understand the engineering of a system without being able to code it. You might not be as efficient as someone else, but you are capable.
dpark 11y ago
> I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding. Coding is a skill largely separate from other critical dev skills, e.g. design. Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill. You can study database partitioning strategies and learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code. And sure, you can try to probe deeply enough to expose where their knowledge stops, but you're still not probing for coding skill. There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter. "Oh, you don't don't know the auto-generated C++ class members? You clearly haven't actually worked in C++!" Yeah, right. Anything known broadly-enough known that it's reasonable to assume all coders would know it is broadly-enough known that non-coders could learn it, too. Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code.
- vonmoltke 11y ago
  > Coding is a skill largely separate from other critical dev skills, e.g. design. I do not believe coding is largely separate from engineering. There are, of course, other skills that are necessary or desirable. > Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill. Absolutely. It is also a level of skill I would only expect or look for in a position that was not going to be doing daily coding, such as a systems engineer. > You can ... learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code. Here I disagree. If you have never used a framework or API, you don't know it. I don't care that you can regurgitate the Javadocs; I care that you know things like its pitfalls, quirks, and runtime oddities. > There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter. To be clear, I abhor trivia-based interviewing. What I am talking about is practical engineering tradeoffs between one course of action versus another, preferably supported by direct personal experience in the past. > Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code. Exposing the level of competence a five-minute coding problem can is trivial to do in parallel with a deep engineering discussion. In fact, I think some sort of code should be part of that discussion. I just don't think it should be the "implement this" CLRS problem. It should be something two-way, more representative of what the job is like on a daily basis.

brianwawok 11y ago

I worked with a team of these before. You can rule our certain types of people with tech questions (i.e. never coded before, only coded hacked, etc.). You cannot rule out * People who read a lot of blogs so know the lingo, but never code * People who get the theory but can't actually implement something that works without bugs * People that over-engineer simple things

dpark 11y ago
Also: * People who have been on a team long enough to learn how things should work but lack the skills to really do the coding. I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume that someone else on his team is carrying most of the coding burden. This guy might be great at a PM-type job (or not, I don't interview for those jobs), but not as a dev.
- vonmoltke 11y ago
  I feel like there is some detail missing here. What constituted doing "very well" on the open-ended questions? How deep into the engineering did you get? Since you mentioned he "might be great at a PM-type job" it sounds like you didn't go very deep on int.
  - dpark 11y ago
    That one was a phone screen, so no it was not the deepest technical dive ever. But in fairness a 1-hour interview is rarely the deepest technical dive possible. I normally pose some big problem like "design a system that accomplishes X at high scale" and then drill into some area iteratively until we're discussing fairly specific details. At the high level I'm looking for the candidate to recognize tradeoffs between centralized/distributed designs, sanely choose the major components, deal with stateful and stateless components, recognize security tradeoffs, etc. As we drill in we might talk about data partitioning, georeplication, or high availability and implementation tradeoffs there. We might get down to the level of something like handling out-of-order change notifications. Rarely do I drill down to the level of file I/O or memory management strategies.
vonmoltke 11y ago
> People who read a lot of blogs so know the lingo, but never code I think this is where my definition of "talk like a professional" may be more strict. I'm interested in understanding, in opinions, in the actual engineering. > People who get the theory but can't actually implement something that works without bugs Having spent most of my career working with PhDs trying to design and implement signal processing and NLP algorithms, I have experienced a lot of that. Given the proper attitude, it is fairly easy to correct coding deficiencies if someone really understands what they are supposed to be doing. > People that over-engineer simple things The greater offenders are fairly easy to detect in a directed technical discussion. The lesser offenders are fairly easy to correct in code review, again given the proper attitude, as they are unlikely to be doing things that require major refactoring. In short, I think I place much more emphasis on engineering as opposed to coding. My experience has been that any coding issues people with good engineering skills and an attitude worth hiring have are quickly and easily corrected. You cannot really understand the engineering of a system without being able to code it. You might not be as efficient as someone else, but you are capable.

dpark 11y ago

> I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding. Coding is a skill largely separate from other critical dev skills, e.g. design. Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill. You can study database partitioning strategies and learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code. And sure, you can try to probe deeply enough to expose where their knowledge stops, but you're still not probing for coding skill. There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter. "Oh, you don't don't know the auto-generated C++ class members? You clearly haven't actually worked in C++!" Yeah, right. Anything known broadly-enough known that it's reasonable to assume all coders would know it is broadly-enough known that non-coders could learn it, too. Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code.

vonmoltke 11y ago
> Coding is a skill largely separate from other critical dev skills, e.g. design. I do not believe coding is largely separate from engineering. There are, of course, other skills that are necessary or desirable. > Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill. Absolutely. It is also a level of skill I would only expect or look for in a position that was not going to be doing daily coding, such as a systems engineer. > You can ... learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code. Here I disagree. If you have never used a framework or API, you don't know it. I don't care that you can regurgitate the Javadocs; I care that you know things like its pitfalls, quirks, and runtime oddities. > There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter. To be clear, I abhor trivia-based interviewing. What I am talking about is practical engineering tradeoffs between one course of action versus another, preferably supported by direct personal experience in the past. > Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code. Exposing the level of competence a five-minute coding problem can is trivial to do in parallel with a deep engineering discussion. In fact, I think some sort of code should be part of that discussion. I just don't think it should be the "implement this" CLRS problem. It should be something two-way, more representative of what the job is like on a daily basis.