22 ms·

It's not the question itself with which I have a problem; it's the whole approach. Let me explain... 1. Every programmer I have ever worked with (except for a

by edw519 16y ago

It's not the question itself with which I have a problem; it's the whole approach. Let me explain... 1. Every programmer I have ever worked with (except for an inept few) knew something that I didn't. They could show me a piece of their code and say, "When you do <a>, it causes <b>, the compiler does <c>, the operating system does <d>, which results in <e>." To which I think, "Great. Who cares. I would have just done <x> and been done with it." 2. Looking at someone else's code and asking what it does is great: if you have to maintain that code. Otherwise, who cares? If I want to build something, I build it with what I know. What I know may or may not include the best tool in the tool box, but again, who cares? Something built 90% optimally today always defeats something built 100% optimally tomorrow. 3. Describing what some preexisting code does is a good academic exercise, but that's all it is. In my experience, I have observed zero correlation between programmers who would have done well on this question and those who could build and deploy great stuff quickly. 4. For some things, it's absolutely critical to know what goes on under the hood. For others, it's a waste of time. Something than improves performance 1000x or improves up time to five nines is the former. Something that's slick is probably (but not always) the latter. I think this question is probably the latter. If I have 15 to 30 minutes with someone and want to find out how well they'll be able to build something, I'll have them build something and ask questions about what they just wrote. I have always learned more about them this way than by looking at 3rd party code.

bcrescimanno 16y ago
I don't completely disagree with you; but I do have some comments (numbered per your items): 2. In a lot of jobs, the ability to read, maintain, update, and extend existing code is considered far more valuable than "building it yourself in your own way." While it's true that there's "more than one way to skin a cat," I'd rather be consistent within a single codebase about how we're skinning that cat. If you can't read and understand code that came before you, you're going to limit your career options to doing nothing but one-off client work. 3. Depends on what you believe "very quickly" means; I would argue that someone who can read and extend preexisting code can work faster than an engineer who wants to build everything him-or-herself. 4. This question isn't a case of performance optimization (though it certainly can be seen that way if you want to talk about the memory and cpu implications of creating tons of functions). This question exposes whether a candidate has an understanding of some pretty fundamental concepts of using closures within javascript and how they impact scoping. I totally agree that you also want to get a candidate to build something; but this question is very useful at exposing their understanding of how javascript truly works.
axod 16y ago
2. If you can't read code well, how the hell are you going to be able to write code well? Too many programmers are terrible at reading code and that correlates IMHO with being terrible at writing it. If you're planning on being an author, it's useful to first be able to read, and to read loads. That's how you learn. The interview question is a simple rookie js question that basically asks "Do you know javascript to any degree".
tocomment 16y ago
I think you have a very enlightened approach, Edw519. I actually take it one step further and ask candidates to work on problems or portions of problems the company actually has. E.g., how would you approach fixing this bug. It also has the side benefit of letting candidates see our codebase, bug tracking, etc. As far as asking how technologies work under the hood. I really don't care if a web developer knows how pointers work, etc. If they can consistently get challenging problems done, that's all I need to know.

by edw519 16y ago

bcrescimanno 16y ago

I don't completely disagree with you; but I do have some comments (numbered per your items): 2. In a lot of jobs, the ability to read, maintain, update, and extend existing code is considered far more valuable than "building it yourself in your own way." While it's true that there's "more than one way to skin a cat," I'd rather be consistent within a single codebase about how we're skinning that cat. If you can't read and understand code that came before you, you're going to limit your career options to doing nothing but one-off client work. 3. Depends on what you believe "very quickly" means; I would argue that someone who can read and extend preexisting code can work faster than an engineer who wants to build everything him-or-herself. 4. This question isn't a case of performance optimization (though it certainly can be seen that way if you want to talk about the memory and cpu implications of creating tons of functions). This question exposes whether a candidate has an understanding of some pretty fundamental concepts of using closures within javascript and how they impact scoping. I totally agree that you also want to get a candidate to build something; but this question is very useful at exposing their understanding of how javascript truly works.

axod 16y ago

2. If you can't read code well, how the hell are you going to be able to write code well? Too many programmers are terrible at reading code and that correlates IMHO with being terrible at writing it. If you're planning on being an author, it's useful to first be able to read, and to read loads. That's how you learn. The interview question is a simple rookie js question that basically asks "Do you know javascript to any degree".

tocomment 16y ago

I think you have a very enlightened approach, Edw519. I actually take it one step further and ask candidates to work on problems or portions of problems the company actually has. E.g., how would you approach fixing this bug. It also has the side benefit of letting candidates see our codebase, bug tracking, etc. As far as asking how technologies work under the hood. I really don't care if a web developer knows how pointers work, etc. If they can consistently get challenging problems done, that's all I need to know.