3 ms·

> So your argument that what makes a person a good software engineer is the whiteboard coding algorithms? No, his argument is that what makes a person a good s

> So your argument that what makes a person a good software engineer is the whiteboard coding algorithms? No, his argument is that what makes a person a good software engineer is the ability to think about an abstract problem and come up with a solution to it.

sidlls 9y ago
That may be his argument, but his example is exactly the kind of "whiteboard coding algorithms" trivia that people mistake for engineering in this industry. I'd agree with his argument if that's what it is, just not his example.
- randomdrake 9y ago
  > I'd agree with his argument if that's what it is, just not his example. I guess I wasn't very clear, then. The parent is correct, my argument did include: "ability to think about an abstract problem and come up with a solution to it." I was trying to use a bit of brevity in my example but these responses make me believe I oversimplified an actual recent problem I had in mind (which is what I believe make the best interview questions). I do try to attach more business needs to the questions I've asked during interviews. Instead of: "how would you store 1 million strings, search through them while caching results, and make sure only certain individuals can access certain strings" What I really had in my head was: "We have tens of thousands of PDFs that we need to extract text from to make available. That text needs to be normalized. Only certain members of certain teams should have access to different types of text. Additionally, this is going to produce millions of strings. How would you get the PDFs to a place you could use them, extract the necessary text, normalize it, store it, utilize caching to make retrieving it snappy, and ensure correct access?" Technical interviews should be more full of questions that spark conversations where additional inquiries come naturally. What kind of software? What version? What framework? Could you do that faster? And so on. Rattling off whiteboard questions is definitely what I was trying to make an example of avoiding.
blain_the_train 9y ago
I think you mean, think about a problem abstractly. However, a good abstraction is context specific, which is why it's often hard to deliver one in a interview, because the interviewer is both biased and a working against you.

sidlls 9y ago

That may be his argument, but his example is exactly the kind of "whiteboard coding algorithms" trivia that people mistake for engineering in this industry. I'd agree with his argument if that's what it is, just not his example.

randomdrake 9y ago
> I'd agree with his argument if that's what it is, just not his example. I guess I wasn't very clear, then. The parent is correct, my argument did include: "ability to think about an abstract problem and come up with a solution to it." I was trying to use a bit of brevity in my example but these responses make me believe I oversimplified an actual recent problem I had in mind (which is what I believe make the best interview questions). I do try to attach more business needs to the questions I've asked during interviews. Instead of: "how would you store 1 million strings, search through them while caching results, and make sure only certain individuals can access certain strings" What I really had in my head was: "We have tens of thousands of PDFs that we need to extract text from to make available. That text needs to be normalized. Only certain members of certain teams should have access to different types of text. Additionally, this is going to produce millions of strings. How would you get the PDFs to a place you could use them, extract the necessary text, normalize it, store it, utilize caching to make retrieving it snappy, and ensure correct access?" Technical interviews should be more full of questions that spark conversations where additional inquiries come naturally. What kind of software? What version? What framework? Could you do that faster? And so on. Rattling off whiteboard questions is definitely what I was trying to make an example of avoiding.

blain_the_train 9y ago

I think you mean, think about a problem abstractly. However, a good abstraction is context specific, which is why it's often hard to deliver one in a interview, because the interviewer is both biased and a working against you.