Earlier quoted context omitted.
I am not arguing that programmers need to have "punchy" titles at all. However, others clearly that some sort of term beyond those you listed is necessary, and these names are evidence of that.
There is no need for those terms. They are marketing names dreamed up by people who think they can neuro-linguistically trick developers into thinking working for them (usually for less money than they are worth), then they can get over on them. Again, what is the difference between a doctor who is one of the best in the world versus a doctor who is just 'decent'? What is the term that is necessary to describe that d…
I Hate Puzzles: Am I Still a Programmer? (2011)
251–260 of 268 posts
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#252Earlier quoted context omitted.
> He would be terrible at a company like Google. I don't think you can adequately back up that statement. Google is a massive company with very broad needs in each engineering discipline they hire for. My most significant criticism of Google's hiring practices is that they feed every software engineer through the same sieve. The sieve is calibrated as you describe, and that calibration is appropriate for many of thei…
I'm sure there is periodic work that you could tear off that fits the description of tedious and simple. That doesn't mean you'd want this particular person. Are you going to have him be a traveling coder, hoping in on only the tedious boring word? Are you going to have him travel with warning that he shouldn't be trusted to have to think about a problem because he'll do poor work? I agree that Google doesn't make en…
I would reorganize work so there is full-time tedious but necessary work to be done and put him on that. I would also use him for spec work, sort of like an in-house subcontractor. It works very well with electronic and mechanical engineers. I see no reason it would not work for software engineers.
> You should also recognize that there are advantages to keeping the bar consistent. You essentially know that everyone you work with is smart and able to solve a problem well.
Consistency can be taken too far, which I think Google does. It is one thing to only hire smart problem solvers. It is another thing to only hire people who are smart problem solvers in a specific domain and in a specific way. I feel like Google is trying to diversify their line of business but not diversify the types of problem solvers they hire.
> Hiring someone fairly unintelligent without any specialist knowledge into a company too big to allocate appropriate work wouldn't be a good idea. It works better in a smaller environment where you can ensure that he's getting appropriate work.
I would think it would be the opposite. A small company is less likely to have sufficient appropriate work to allocate.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#253Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#254Earlier quoted context omitted.
In the real world, a light source has a useful radius of illumination. This could be exploited. If the useful radius is greater than half the span of the bridge, everyone can cross the bridge in exactly 10 minutes. If the useful radius of the torch is 25% the bridge length, the bridge can be crossed in 15 minutes. So the correct answer to the puzzle question is "how much of the bridge does the torch illuminate?" Then…
I don't think that would make the person who's interviewing you very happy.
I once aced an interview brainteaser, and the interviewer actually tried to derail my solution by interrupting and making misleading suggestions. When I finished, he told me that I was the only candidate so far to give the "correct" answer. He was clearly unhappy about it, which confused the heck out of me at the time.
I wasn't supposed to do that. I was supposed to give a half-assed, partially correct answer and let the other guy show off how smart and superior he was, by giving me the "real" answer.
So yes, beating the brainteaser might backfire. If it could, would you still want to work there?
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#255I don't write programs because I like solving puzzles. I write them because I like creating things, and it's a lot easier to create things with programs than with a machine shop. I also enjoy the competition with other compiler/language vendors to produce a better product.
> I write them because I like creating things, and it's a >lot easier to create things with programs than with a machine shop. Exactly. This is one of the main reasons for me as well - creating things without buying or manufacturing physical materials.
I tried again in college, with a much better design. The guy who ran the college machine shop (he built custom lab equipment for researchers) helped me a lot. It still took months. This time, it did run, but it took so much time it didn't satisfy my urge to create things - my designs ran far, far out ahead of any possibility of making them.
Not so with software!
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#256Earlier quoted context omitted.
> Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba. I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory". It it is p…
I don't get why people tend to think that computer science is something different from "actual programming". In the end everything you can program can be expressed formally and vice-versa, the only thing that changes is how much you abstract from the actual implementation, which is handy in order to catch defects in the approach you are taking to certain problem.
Computer Science is broad (even AI is different), but I'd say it's more about Turing's academic papers, and computational mathematics. Programming, and computers, aren't even needed, they're just models which either can or cannot derive solutions, or in a reasonable time. Such as the halting problem, P, NP, NP-complete.
In a way it's mathematical logic, but with more rigorous proofs.
Everybody else can learn a generic language with some external libraries and make almost anything they want. But that's not more academic than it is to do woodworking, or sewing. Comp Sci is academic, and one of the more important ones because it determines a lot of research other disciplines do. I.e physicists and mathematicians do comp sci, while the softer sciences run models without understanding why they work.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#257Earlier quoted context omitted.
I don't get why people tend to think that computer science is something different from "actual programming". In the end everything you can program can be expressed formally and vice-versa, the only thing that changes is how much you abstract from the actual implementation, which is handy in order to catch defects in the approach you are taking to certain problem.
Because everybody can do "actual progrmaming." Especially in grad school. Computer Science is broad (even AI is different), but I'd say it's more about Turing's academic papers, and computational mathematics. Programming, and computers, aren't even needed, they're just models which either can or cannot derive solutions, or in a reasonable time. Such as the halting problem, P, NP, NP-complete. In a way it's mathematic…
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#258This is what really irks me about the industry as a whole. Large companies like Facebook and Google have hiring processes in place that aim to weed out the strong from the weak by making them solve complex algorithmic puzzles and solve them on a whiteboard, and for larger companies like Facebook or Google who have massive troves of data, this kind of makes sense to me, but only if you're hiring a programmer to work w…
For the kind of frontend work you're used to doing: perhaps they won't.
For the kind of frontend work Google does -- you know, things like Gmail, Google Maps -- they most definitely will.
That's why Google asks those questions.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#259Earlier quoted context omitted.
I'm sure there is periodic work that you could tear off that fits the description of tedious and simple. That doesn't mean you'd want this particular person. Are you going to have him be a traveling coder, hoping in on only the tedious boring word? Are you going to have him travel with warning that he shouldn't be trusted to have to think about a problem because he'll do poor work? I agree that Google doesn't make en…
> I'm sure there is periodic work that you could tear off that fits the description of tedious and simple. That doesn't mean you'd want this particular person. Are you going to have him be a traveling coder, hoping in on only the tedious boring word? Are you going to have him travel with warning that he shouldn't be trusted to have to think about a problem because he'll do poor work? I would reorganize work so there…
Maybe so. But this isn't just any random small company. This is a specific 50-person company.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#260Earlier quoted context omitted.
As the author of said book who has coached MANY people, I can assure you that many - heck, most developers - could not pass a Google interview regardless of how much they prepared. They'll get better with preparation, but it doesn't just fix all issues.
Gayle, Don't get me wrong. I made it through the Amazon interviews thanks to your book. I spent a week reading through and cranking out examples before the interview. Then I spewed out all of the desirable answers at each step of the interview process. Now I'm a highly experienced developer with 15+ years experience across a variety of technologies. I contribute to open source, answer questions on Stack Overflow, pre…
You're right that the problems that some up in interviews typically aren't real life problems. But that's not necessarily an issue. Are the skills they test (developing good algorithms) important for real life?
An interviewer doesn't ask you to develop an algorithm to return a random node from a binary tree because they particularly care if you know THAT algorithm. They're asking as a way of evaluating your skills developing solutions to problems you haven't seen before.