4 ms·

This is targeted toward students who could benefit from someone hand-holding them through the design of an algorithm, but anyone can learn something. It's alway

This is targeted toward students who could benefit from someone hand-holding them through the design of an algorithm, but anyone can learn something. It's always good to have another potential interview question in your repertoire.

starmole 12y ago
In case you did not know: This is closely related to an s-buffer (s for span) in graphics. And the first approach (height map) is pretty much a z-buffer. Your silhouette there is eye distance (z) across a single scan line. One difference of how it is approached in graphics is that usually not all spans are an input array but inserted one at a time.
sdrothrock 12y ago
> This is targeted toward students who could benefit from someone hand-holding them through the design of an algorithm I enjoyed the article and then came back to read the comments and found this sort of insulting. Just because something is detailed doesn't mean that it's hand-holding. It's interesting to see how other people think.
- brianpgordon 12y ago
  I'm sorry, I didn't mean to be insulting. I thought this was a little basic for the HN crowd so I wanted to make sure I left a disclaimer to that effect so people didn't think I was being condescending by explaining every little detail. I guess it backfired.
optimusclimb 12y ago
Yup. I sure solve THAT problem every day. My boss comes in and is like, "well, we have the bugs from that security audit, we need to come up with a design for the feature we want to try and roll out in two quarters so we can agree on it and cut tasks/divy up work, and then we're using two many boxes for the Foo processor. I think you've never optmized that right? Why don't you have a look at that. Also, don't use any standard library functions or look anything up. When you're done with that, I have a question for you about manhole covers." Yup, another great interview question for your repertoire to weed people out and talk about the kinds of things that come up in the day to day of being a modern software engineer.
- legutierr 12y ago
  Does a modern software engineer not need to demonstrate an ability to design efficient algorithms that solve problems that haven't been encountered before? Or, in your mind, is the solution to every problem that a modern software engineer might encounter already found in some stackoverflow post?
  - peeters 12y ago
    > Does a modern software engineer not need to demonstrate an ability to design efficient algorithms that solve problems that haven't been encountered before? On the job? Sure they do. In an interview room? That's not an adequate replication of the job environment. I am not asked to design an algorithm for a problem introduced to me 17 seconds ago and have 5 minutes to do it. Plus, you're committing the #1 sin of interviews; that many of the people that can answer the question in an interview setting have encountered the problem before, and that's why they can answer it.
    - JoeAltmaier 12y ago
      That answers something that's been bothering me about interview coding. The ones who pass, are the ones who've seen the problem before. So its not a coding test nor a creativity test; its an experience test only.
      - cousin_it 12y ago
        I've passed many algorithm interviews without knowing the answer beforehand. It's very possible, people just don't bother to learn. Any good textbook on algorithms will give you the tools to create new ones. Mostly it's application of a few basic concepts, like big-O complexity, divide and conquer, or dynamic programming. Go through 100 problems on Project Euler and this stuff will become second nature.
  - btilly 12y ago
    It all depends on the job. Most people with the title "software engineer" are day in, day out, faced with random debugging, tinkering with code and keeping the code-base organized as they go. Clever algorithms are not needed. Solid development skills are. Furthermore when you do run into occasional algorithm problems, it is enough for there to be people in your environment that you can turn to for that. This is an accurate description of most of the productive colleagues that I've known over the years. I've known a lot of people who do not do well on algorithm challenges, but who I'd like to work with again because I know that they can consistently pull their weight. But doesn't someone need to know algorithms? Well, yes. I certainly do. But it doesn't need to be everyone. In a good team, people naturally turn to the most appropriate teammate for help when they need it. So they might turn to me for algorithm questions, someone else for weird git problems, and yet another person for networking expertise. Algorithms are just one component. But, I can see you say, all else being equal, wouldn't you prefer someone who knows algorithms? Obviously so. But algorithms are only one component of what we do. And is not always strongly correlated with everything else that we need to know, such as unit testing and writing modular code. And here we get to the real problem. When our interview tests test something different than what we actually need, then we don't know whether we're getting the skills we need. Furthermore when that different thing is something that every other organization is also testing for (like algorithms), then we wind up both not being interested in people who have the skills we need, but we wind up in direct competition with everyone and his dog. Therefore interviews should try to test the skills that we actually need people to use day to day. If your job does not require people to regularly write clever data structures, don't test for that. If your job requires people to lay out and modify class hierarchies for new business requirements, test for that instead.
praptak 12y ago
> It's always good to have another potential interview question in your repertoire. It is a widely known "good interview question" which means it is a bad interview question.

starmole 12y ago

In case you did not know: This is closely related to an s-buffer (s for span) in graphics. And the first approach (height map) is pretty much a z-buffer. Your silhouette there is eye distance (z) across a single scan line. One difference of how it is approached in graphics is that usually not all spans are an input array but inserted one at a time.

sdrothrock 12y ago

> This is targeted toward students who could benefit from someone hand-holding them through the design of an algorithm I enjoyed the article and then came back to read the comments and found this sort of insulting. Just because something is detailed doesn't mean that it's hand-holding. It's interesting to see how other people think.

brianpgordon 12y ago
I'm sorry, I didn't mean to be insulting. I thought this was a little basic for the HN crowd so I wanted to make sure I left a disclaimer to that effect so people didn't think I was being condescending by explaining every little detail. I guess it backfired.

optimusclimb 12y ago

Yup. I sure solve THAT problem every day. My boss comes in and is like, "well, we have the bugs from that security audit, we need to come up with a design for the feature we want to try and roll out in two quarters so we can agree on it and cut tasks/divy up work, and then we're using two many boxes for the Foo processor. I think you've never optmized that right? Why don't you have a look at that. Also, don't use any standard library functions or look anything up. When you're done with that, I have a question for you about manhole covers." Yup, another great interview question for your repertoire to weed people out and talk about the kinds of things that come up in the day to day of being a modern software engineer.

legutierr 12y ago
Does a modern software engineer not need to demonstrate an ability to design efficient algorithms that solve problems that haven't been encountered before? Or, in your mind, is the solution to every problem that a modern software engineer might encounter already found in some stackoverflow post?
- peeters 12y ago
  > Does a modern software engineer not need to demonstrate an ability to design efficient algorithms that solve problems that haven't been encountered before? On the job? Sure they do. In an interview room? That's not an adequate replication of the job environment. I am not asked to design an algorithm for a problem introduced to me 17 seconds ago and have 5 minutes to do it. Plus, you're committing the #1 sin of interviews; that many of the people that can answer the question in an interview setting have encountered the problem before, and that's why they can answer it.
  - JoeAltmaier 12y ago
    That answers something that's been bothering me about interview coding. The ones who pass, are the ones who've seen the problem before. So its not a coding test nor a creativity test; its an experience test only.
    - cousin_it 12y ago
      I've passed many algorithm interviews without knowing the answer beforehand. It's very possible, people just don't bother to learn. Any good textbook on algorithms will give you the tools to create new ones. Mostly it's application of a few basic concepts, like big-O complexity, divide and conquer, or dynamic programming. Go through 100 problems on Project Euler and this stuff will become second nature.
- btilly 12y ago
  It all depends on the job. Most people with the title "software engineer" are day in, day out, faced with random debugging, tinkering with code and keeping the code-base organized as they go. Clever algorithms are not needed. Solid development skills are. Furthermore when you do run into occasional algorithm problems, it is enough for there to be people in your environment that you can turn to for that. This is an accurate description of most of the productive colleagues that I've known over the years. I've known a lot of people who do not do well on algorithm challenges, but who I'd like to work with again because I know that they can consistently pull their weight. But doesn't someone need to know algorithms? Well, yes. I certainly do. But it doesn't need to be everyone. In a good team, people naturally turn to the most appropriate teammate for help when they need it. So they might turn to me for algorithm questions, someone else for weird git problems, and yet another person for networking expertise. Algorithms are just one component. But, I can see you say, all else being equal, wouldn't you prefer someone who knows algorithms? Obviously so. But algorithms are only one component of what we do. And is not always strongly correlated with everything else that we need to know, such as unit testing and writing modular code. And here we get to the real problem. When our interview tests test something different than what we actually need, then we don't know whether we're getting the skills we need. Furthermore when that different thing is something that every other organization is also testing for (like algorithms), then we wind up both not being interested in people who have the skills we need, but we wind up in direct competition with everyone and his dog. Therefore interviews should try to test the skills that we actually need people to use day to day. If your job does not require people to regularly write clever data structures, don't test for that. If your job requires people to lay out and modify class hierarchies for new business requirements, test for that instead.

praptak 12y ago

> It's always good to have another potential interview question in your repertoire. It is a widely known "good interview question" which means it is a bad interview question.