4 ms·

Sounds like she's still perpetuating the problem: Software Engineering interviews will focus on your standard coding, algorithm, and system design questions...

by asnyder 13y ago

Sounds like she's still perpetuating the problem: Software Engineering interviews will focus on your standard coding, algorithm, and system design questions... Why are algorithm questions still being asked in a high-pressure environment? Very few people actually work on algorithms once hired and never in my experience has it actually been a good indicator of actual development competency. As DHH states: http://37signals.com/svn/posts/3071-why-we-dont-hire-programmers-based-on-puzzles-api-quizzes-math-riddles-or-other-parlor-tricks http://37signals.com/svn/posts/3071-why-we-dont-hire-program..., unless you're hiring someone to code algorithms it's not useful. As a Director at AppNexus I've done my best to reverse this trend by asking what I consider competency questions. Such as "On a scale of 1-10, 1 being novice, 10 being creator of said technology, how would you rate yourself?" Then based on this answer I'll ask a question at that level. I find that most people screened don't actually know the basic fundamentals of the technologies they list. After you've gotten the basics down you can then get into system-design, or thinking questions. In the case code analysis is necessary I think it's much better to present a sub-optimal pre-written function and ask the candidate what the function does, and whether and how it can be improved. In this way I know whether they understand code, and whether they're competent enough to improve. The faster we move away from these algorithmic questions the better.

morpher 13y ago
How do you account for the Dunning-Kruger[1] effect when asking your "How do you rate yourself?" question? I would guess that answers in the range "6 or 7" could span a really wide range of actual knowledge. Does that agree with your experience? [1]http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
- pisarzp 13y ago
  I understand that he just asks real question on that level to calibrate your answer. It's just faster to start from some reference point.
  - asnyder 13y ago
    Right, even if someone miscalibrated we can quickly get to the proper calibration. Though, I stress ten as being the creator of said technology. For example, in the case of PHP ten would entail actually being able extend PHP via C/C++. In my experience most people calibrate pretty well initially or after an initial miscalibration.
- drivebyacct2 13y ago
  Ask for code. TALK about algorithms at a high level. I have an aptitude for reading people, but my day two impressions of coding with a new person tend to lead to valid assumptions about them months later.
gaylemcd 13y ago
I don't see how I'm perpetuating the problem. I'm just explaining what Google actually does and what they don't do.
gaylemcd 13y ago
"Such as "On a scale of 1-10, 1 being novice, 10 being creator of said technology, how would you rate yourself?" Then based on this answer I'll ask a question at that level. I find that most people screened don't actually know the basic fundamentals of the technologies they list." See, and I hate questions like that. If you're going to ask candidates to rate themselves in a technology, don't ask for a number. What I think a 7 is might be different from what you think it is. Just ask the candidate how comfortable they feel in a language. Words work better than numbers. Also, you should know that many candidates are really scared by someone asking them to rate themselves on a scale from 1 to 10. You're kicking off an interview with a degree of intimidation that's probably unnecessary. You're right though that many people don't know the fundamentals of the technologies they list. This doesn't mean that they're bad engineers; there's just a lot of confusion around at what point you should list a technology on your resume. Remember that a lot of companies aren't particularly looking for competency in a particular language. Thus, drilling into the specifics of a technology doesn't assess much for them.
- sigsergv 13y ago
  I'm always answering “7” or “4”.
nostrademons 13y ago
I've found that algorithms are one of those things that doesn't come up often in your daily work, but when you need them, you really need them, and otherwise you'll end up delivering a substandard product. It's very much like Joel Spolsky article on hitting the high notes: http://www.joelonsoftware.com/articles/HighNotes.html http://www.joelonsoftware.com/articles/HighNotes.html I've found that in my work, a tricky algorithmic problem comes up on average about once a month. It's a tiny fraction of the total work I do - but if I couldn't solve algorithmic problems, then there are whole projects that I simply couldn't tackle. We'd either do something substandard for users, or we'd throw bodies at the problem (which still happens a lot, unfortunately), or they'd need to bring in someone else to do my job. Moreover, I've found that there's a cultural shift that happens when enough people are familiar with algorithm design within a company. A lot of other places I've worked are basically "Make the user fill out a form, dump it in a database, format it for display." When a significant fraction of your employees are capable of hitting the high notes, this becomes "Make the user interact with your system in the manner they're most comfortable with, extract meaning out of their ordinary behavior, compute interesting results, and show it to them." The complexity moves from the user to the software, and as a result, users would rather use your software. There are whole subsystems within Google Search - synonyms, spelling, refinements, authorship, snippets, ranking, translate, voice search, etc. - that would never have happened if there weren't a critical mass of people willing to dive into difficult problems.

by asnyder 13y ago

morpher 13y ago

How do you account for the Dunning-Kruger[1] effect when asking your "How do you rate yourself?" question? I would guess that answers in the range "6 or 7" could span a really wide range of actual knowledge. Does that agree with your experience? [1]http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

pisarzp 13y ago
I understand that he just asks real question on that level to calibrate your answer. It's just faster to start from some reference point.
- asnyder 13y ago
  Right, even if someone miscalibrated we can quickly get to the proper calibration. Though, I stress ten as being the creator of said technology. For example, in the case of PHP ten would entail actually being able extend PHP via C/C++. In my experience most people calibrate pretty well initially or after an initial miscalibration.
drivebyacct2 13y ago
Ask for code. TALK about algorithms at a high level. I have an aptitude for reading people, but my day two impressions of coding with a new person tend to lead to valid assumptions about them months later.

gaylemcd 13y ago

I don't see how I'm perpetuating the problem. I'm just explaining what Google actually does and what they don't do.

gaylemcd 13y ago

"Such as "On a scale of 1-10, 1 being novice, 10 being creator of said technology, how would you rate yourself?" Then based on this answer I'll ask a question at that level. I find that most people screened don't actually know the basic fundamentals of the technologies they list." See, and I hate questions like that. If you're going to ask candidates to rate themselves in a technology, don't ask for a number. What I think a 7 is might be different from what you think it is. Just ask the candidate how comfortable they feel in a language. Words work better than numbers. Also, you should know that many candidates are really scared by someone asking them to rate themselves on a scale from 1 to 10. You're kicking off an interview with a degree of intimidation that's probably unnecessary. You're right though that many people don't know the fundamentals of the technologies they list. This doesn't mean that they're bad engineers; there's just a lot of confusion around at what point you should list a technology on your resume. Remember that a lot of companies aren't particularly looking for competency in a particular language. Thus, drilling into the specifics of a technology doesn't assess much for them.

sigsergv 13y ago
I'm always answering “7” or “4”.

nostrademons 13y ago

I've found that algorithms are one of those things that doesn't come up often in your daily work, but when you need them, you really need them, and otherwise you'll end up delivering a substandard product. It's very much like Joel Spolsky article on hitting the high notes: http://www.joelonsoftware.com/articles/HighNotes.html http://www.joelonsoftware.com/articles/HighNotes.html I've found that in my work, a tricky algorithmic problem comes up on average about once a month. It's a tiny fraction of the total work I do - but if I couldn't solve algorithmic problems, then there are whole projects that I simply couldn't tackle. We'd either do something substandard for users, or we'd throw bodies at the problem (which still happens a lot, unfortunately), or they'd need to bring in someone else to do my job. Moreover, I've found that there's a cultural shift that happens when enough people are familiar with algorithm design within a company. A lot of other places I've worked are basically "Make the user fill out a form, dump it in a database, format it for display." When a significant fraction of your employees are capable of hitting the high notes, this becomes "Make the user interact with your system in the manner they're most comfortable with, extract meaning out of their ordinary behavior, compute interesting results, and show it to them." The complexity moves from the user to the software, and as a result, users would rather use your software. There are whole subsystems within Google Search - synonyms, spelling, refinements, authorship, snippets, ranking, translate, voice search, etc. - that would never have happened if there weren't a critical mass of people willing to dive into difficult problems.