Engineers are almost like lawyers. A senior lawyer is still doing pretty much the same thing as a junior one, just that he has more experience. Same goes for engineers, except that eventually things degenerate into high management where people think they are absolved from thinking (apparently). In the end you still solve problems, and you need all the tools in your toolbox. If you've forgotten basic CS, there's no way you can properly evaluate code, system design, or even properly chose tools for the job (hint: MS research has developed F# for a reason). The proof is in the pudding: people who are bad at the basics will do things in the most awkward way possible, no matter how high on the ladder they are.
You must understand that I'm talking about things that you actually need day-in, day-out in your job. Sure a pharmacist may not need much undergrad chemistry or biology, it's pretty useless in their job at any level, no matter if you're just starting out or not! A pharmacist is not a drug developer, where you need more of biochemistry. In case of a lawyer, there's specialization, but still the basics apply in their job even when they are senior, so you're quite wrong there. Laywers learn a lot of useless crap like legal system history, various disciplines of law that they won't practice, etc. Same as an electrical engineer may not be up to snuff on, say, basic mechanics (statics and dynamics), or chemistry, or some niche stuff like IC design -- it's simply not his area. But an EE needs to be pretty damn well up to snuff on basic circuit analysis, because that's what he'll need in any area of EE. He'll need understanding of statistics and probability if he does QA/testing. And so on. An effective guy with lots of experience, I'd expect, will be so much "beyond" the basics, that he should be able to do the basic calculations as a back-of-the-envelope or mental exercise. He should have a feel for orders of magnitude, and how simple systems scale (you increase x 10 times, but y shrinks only 3 times, etc).
Brainteasers are pointless, but only if they are the common sort that relies on preconceived notions. A good brainteaser clearly defines the problem space, and doesn't have you jogging your memory for similar ones in search for a solution. It's self-contained and doesn't involve trickery.
Removing a node from a tree in software engineering is akin to putting together a low-spec current source with an op-amp in electrical engineering. You may not have it in your head, but you pretty damn well should derive it from whatever basic principles, given a couple of minutes of time. You should also be able to reason about the limitations and pitfalls of whatever approach you've taken. I'm not asking for exact code to anything, you miss my point completely. I agree about the cache in your head, but again, it's beside the point.
I wouldn't recall a quicksort either (I don't have a name to algorithm link in my head), but that's besides the point. Given an algorithm, show me the code, or show me how you analyze the algorithm. For fizzbuzz, the algorithm is pretty much there in the problem description, you can't get more obvious than that.
Computer science offers us a bunch of wonderful mathematical frameworks that aid in analysis of stuff we do every day. If you actually use this skill and keep it current, you should, given your experience, pretty much look at the code/algorithm and tell in a minute or two how computationally expensive it is, what constant factors might be important given some alternatives, etc. You don't learn it in school to promptly forget it. If you have a PhD in software engineering or computer science, you better knew that stuff very damn well. Anyone advocating 50 XML roundtrips for a simple web-based transaction obviously forgot everything they learned in school. And then your employees hate such a system, your customers hate it, your support people hate it, and your IT costs go through the roof as you have to throw servers at a problem that would run fine on a PC from 15 years ago.
That's why, when I design new products, I sit next to our technician who puts them together. Sometimes I even put together a prototype myself. Just so that I have instant feedback as to design-for-manufacturability. It stupidly easy to draw stuff on paper, even if it's just wiring control panels, where it takes 2-3x as long, with much higher aggravation for the technician.
Besides, just like in software you're no engineer if you can't put a fizzbuzz together in a minute or two, in electrical engineering it's a bit backwards if you can't hold a soldering iron properly or wire a panel together up to relevant standards (depending on what your specialty is, of course).
I don't know what tests you're alluding to, but man, if you can't do fizzbuzz-style exercise without breaking a sweat, you're useless, okay? I don't even think there's any argument to that. When you're designing large systems, you must have demonstrable working knowledge of the basics. Otherwise your designs will be bloated monsters where anyone who knows their basics will look at and say: it took you HOW LONG and HOW MUCH MAN-YEARS?!
Fact of life: if you don't have a decent grasp of basics of computer science, including algorithms and algorithmic complexity, you'll be useless at designing anything big. You'll make it too big, it'll unnecessarily underperform, and people who know their shit will laugh all the way to the bank as they overtake your employer's bloated product. It's like claiming to be a great architect without having working knowledge of the basics of structural engineering. Just as you need a feel for strength of structures and their scaling behavior in architecture, you need to know your algorithms and data structures in designing large systems. Software design and architecture are both engineering disciplines -- there's always a bit of art to them, of course.
Maybe you never had to do such a thing because you don't have a clue about theroetical underpinnings of computer science, lack mathematical skills, and simply can't apply what you don't know about! Counting set bits in a bit array is a task that has real life applications outside of signal/image processing, you know.
I don't think anyone senior is really capable of anything if they can't, in fact, promptly deal with simple problems. I've seen lot of code that was "designed" by senior people where the bloat was 10:1. They'll overdesign everything, and you end up with monster frameworks to do the most menial of things that should be almost an afterthought when you have access to modern libraries. Yeah, it's good to be able to solve problems that can't be figured out in under an hour, but it's not good if it can't be figured out under an hour because you're overcomplicating things.
I completely agree that the art of designing a large system on solid principles (cohesion, decoupling, yada yada) is another matter. The point of fizzbuzz-style exercises is not to waste valuable time of interviewers on dealing with people who can't code a hello world, much less design anything that's not a spaghetti monster.
It can be fun to throw some simple stuff in there to break up the bigger stuff.
A.K.A. the simple pleasures of life. Sometimes it's good to feel good about something simple -- the equivalent of hanging a picture on the wall. People who don't dig this, I'm afraid, are unsocial.
If I were a BOFH asked to "help out" with such a test, I'd talk about my pet peeve: transitive closure in SQL. Comes real handy in anything that deals with bills of material.
Yep. Their teams end up wasting man years doing simple shit that can be done in a week, and can be thrown away and redone when needs change drastically enough to warrant it.
I don't care how senior you are. It's like saying that an experienced transplant surgeon doesn't need to know how to make an injection. Yeah, in their job probably they'll never inject anyone, but still, you need to know it just in case. Shit sometimes goes wrong. It's a wrong analogy! As for a senior software engineer: how on earth can you pretend to be able to design, you know, software, if you don't demonstrably have a clue how to, you know, make software for a very simple task? Such "senior engineers" will proceed to design a 100kloc framework for a fizzbuzz. Because, you know, it needs to fulfill whatever buzzword quota they came up with.
Have you ever done a lot of "programmer" hiring? Such a test is valuable to both the employer and the employee. The employer won't waste time talking to clueless idiots. The employee will know that the employer is serious about weeding out idiots and thus having resources left to talk to people who know what the fuck they are doing. Such tests have not much to do with what most of your job is. Software engineering is a lot about design, testing, etc., but if you can't code your way out of a fizzbuzz, it doesn't matter what else you pretend to know.
The problem is: in most cases, 90%+ of applicants are useless and will fail such a test. It's crazy how many people apply to programming jobs without knowing anything about programming. Apparently, they themselves are OK with such a waste of time. Idiots.
LOL, in 45 minutes you should do it in assembly for any architecture out there, even ones you never used before. Might take a bit longer in brainfuck, though:)
You don't need multiple lasers, just a slightly different read head. Instead of reading a single-lane track, you can be reading a track that's 4 or 8 lanes wide. It'd cost a small increment more, since the optics, mechanics and the optical chip are very similar to current technology.
I guess kids these days just don't have imagination:(
When you stream a game, it doesn't have to mean that you're streaming what's on the screen directly. In a game engine, there may well be content that's expensive to calculate, but has very relaxed latency requirements and can be essentially treated as pre-caching of sorts. What you do is look at the client and look for where it ails, and basically offload stuff that may be precomputed a bit in advance. For low-latency GUI, you still have a low-end GPU, but it can, for example, use some shadows computed elsewhere, some matte textures to approximate higher quality content, have advanced AI offload, etc. There's a lot of ways to make stuff look good even on low-end GPUs, as long as you can throw a bunch of computing power a couple of seconds ahead of the frame. It requires out-of-the-box thinking, perhaps, but it's not exactly a brand-new technique. I've seen it applied in the 90s on some flight simulators.
If emulating Apple meant replacing the shit plastic case with solid machined aluminum, I'd be all for it. It seems that nobody else is serious about unibodies and lasting design elements. Other products come and go, like the Dell Adamo, while Apple stays true to form on the unibody front.
The problem is with schools that don't let you pay using a credit card. Then, on most credit cards, cash-outs ("balance transfer" checks) have higher APR, and are usually limited to a part of your credit line. I know of at least one Big Ten school that doesn't take credit cards for tuition. They only accept bank transfers online and checks in person (perhaps maybe cash too).
Slowly?? I've just tried it, and it doesn't seem to be slow at all under OS X 10.6. I have used Illustrator CS2 since ancient times under VMWare Fusion anyway, so this was just to try out how the more native version works -- seems perfectly usable.
Slashdot Mirror
Engineers are almost like lawyers. A senior lawyer is still doing pretty much the same thing as a junior one, just that he has more experience. Same goes for engineers, except that eventually things degenerate into high management where people think they are absolved from thinking (apparently). In the end you still solve problems, and you need all the tools in your toolbox. If you've forgotten basic CS, there's no way you can properly evaluate code, system design, or even properly chose tools for the job (hint: MS research has developed F# for a reason). The proof is in the pudding: people who are bad at the basics will do things in the most awkward way possible, no matter how high on the ladder they are.
You must understand that I'm talking about things that you actually need day-in, day-out in your job. Sure a pharmacist may not need much undergrad chemistry or biology, it's pretty useless in their job at any level, no matter if you're just starting out or not! A pharmacist is not a drug developer, where you need more of biochemistry. In case of a lawyer, there's specialization, but still the basics apply in their job even when they are senior, so you're quite wrong there. Laywers learn a lot of useless crap like legal system history, various disciplines of law that they won't practice, etc. Same as an electrical engineer may not be up to snuff on, say, basic mechanics (statics and dynamics), or chemistry, or some niche stuff like IC design -- it's simply not his area. But an EE needs to be pretty damn well up to snuff on basic circuit analysis, because that's what he'll need in any area of EE. He'll need understanding of statistics and probability if he does QA/testing. And so on. An effective guy with lots of experience, I'd expect, will be so much "beyond" the basics, that he should be able to do the basic calculations as a back-of-the-envelope or mental exercise. He should have a feel for orders of magnitude, and how simple systems scale (you increase x 10 times, but y shrinks only 3 times, etc).
Brainteasers are pointless, but only if they are the common sort that relies on preconceived notions. A good brainteaser clearly defines the problem space, and doesn't have you jogging your memory for similar ones in search for a solution. It's self-contained and doesn't involve trickery.
Removing a node from a tree in software engineering is akin to putting together a low-spec current source with an op-amp in electrical engineering. You may not have it in your head, but you pretty damn well should derive it from whatever basic principles, given a couple of minutes of time. You should also be able to reason about the limitations and pitfalls of whatever approach you've taken. I'm not asking for exact code to anything, you miss my point completely. I agree about the cache in your head, but again, it's beside the point.
I wouldn't recall a quicksort either (I don't have a name to algorithm link in my head), but that's besides the point. Given an algorithm, show me the code, or show me how you analyze the algorithm. For fizzbuzz, the algorithm is pretty much there in the problem description, you can't get more obvious than that.
Computer science offers us a bunch of wonderful mathematical frameworks that aid in analysis of stuff we do every day. If you actually use this skill and keep it current, you should, given your experience, pretty much look at the code/algorithm and tell in a minute or two how computationally expensive it is, what constant factors might be important given some alternatives, etc. You don't learn it in school to promptly forget it. If you have a PhD in software engineering or computer science, you better knew that stuff very damn well. Anyone advocating 50 XML roundtrips for a simple web-based transaction obviously forgot everything they learned in school. And then your employees hate such a system, your customers hate it, your support people hate it, and your IT costs go through the roof as you have to throw servers at a problem that would run fine on a PC from 15 years ago.
That's why, when I design new products, I sit next to our technician who puts them together. Sometimes I even put together a prototype myself. Just so that I have instant feedback as to design-for-manufacturability. It stupidly easy to draw stuff on paper, even if it's just wiring control panels, where it takes 2-3x as long, with much higher aggravation for the technician.
Besides, just like in software you're no engineer if you can't put a fizzbuzz together in a minute or two, in electrical engineering it's a bit backwards if you can't hold a soldering iron properly or wire a panel together up to relevant standards (depending on what your specialty is, of course).
I don't know what tests you're alluding to, but man, if you can't do fizzbuzz-style exercise without breaking a sweat, you're useless, okay? I don't even think there's any argument to that. When you're designing large systems, you must have demonstrable working knowledge of the basics. Otherwise your designs will be bloated monsters where anyone who knows their basics will look at and say: it took you HOW LONG and HOW MUCH MAN-YEARS?!
Fact of life: if you don't have a decent grasp of basics of computer science, including algorithms and algorithmic complexity, you'll be useless at designing anything big. You'll make it too big, it'll unnecessarily underperform, and people who know their shit will laugh all the way to the bank as they overtake your employer's bloated product. It's like claiming to be a great architect without having working knowledge of the basics of structural engineering. Just as you need a feel for strength of structures and their scaling behavior in architecture, you need to know your algorithms and data structures in designing large systems. Software design and architecture are both engineering disciplines -- there's always a bit of art to them, of course.
Maybe you never had to do such a thing because you don't have a clue about theroetical underpinnings of computer science, lack mathematical skills, and simply can't apply what you don't know about! Counting set bits in a bit array is a task that has real life applications outside of signal/image processing, you know.
I don't think anyone senior is really capable of anything if they can't, in fact, promptly deal with simple problems. I've seen lot of code that was "designed" by senior people where the bloat was 10:1. They'll overdesign everything, and you end up with monster frameworks to do the most menial of things that should be almost an afterthought when you have access to modern libraries. Yeah, it's good to be able to solve problems that can't be figured out in under an hour, but it's not good if it can't be figured out under an hour because you're overcomplicating things.
I completely agree that the art of designing a large system on solid principles (cohesion, decoupling, yada yada) is another matter. The point of fizzbuzz-style exercises is not to waste valuable time of interviewers on dealing with people who can't code a hello world, much less design anything that's not a spaghetti monster.
It can be fun to throw some simple stuff in there to break up the bigger stuff.
A.K.A. the simple pleasures of life. Sometimes it's good to feel good about something simple -- the equivalent of hanging a picture on the wall. People who don't dig this, I'm afraid, are unsocial.
Yes, this a 100 times!
If I were a BOFH asked to "help out" with such a test, I'd talk about my pet peeve: transitive closure in SQL. Comes real handy in anything that deals with bills of material.
Yep. Their teams end up wasting man years doing simple shit that can be done in a week, and can be thrown away and redone when needs change drastically enough to warrant it.
I don't care how senior you are. It's like saying that an experienced transplant surgeon doesn't need to know how to make an injection. Yeah, in their job probably they'll never inject anyone, but still, you need to know it just in case. Shit sometimes goes wrong. It's a wrong analogy! As for a senior software engineer: how on earth can you pretend to be able to design, you know, software, if you don't demonstrably have a clue how to, you know, make software for a very simple task? Such "senior engineers" will proceed to design a 100kloc framework for a fizzbuzz. Because, you know, it needs to fulfill whatever buzzword quota they came up with.
Have you ever done a lot of "programmer" hiring? Such a test is valuable to both the employer and the employee. The employer won't waste time talking to clueless idiots. The employee will know that the employer is serious about weeding out idiots and thus having resources left to talk to people who know what the fuck they are doing. Such tests have not much to do with what most of your job is. Software engineering is a lot about design, testing, etc., but if you can't code your way out of a fizzbuzz, it doesn't matter what else you pretend to know.
The problem is: in most cases, 90%+ of applicants are useless and will fail such a test. It's crazy how many people apply to programming jobs without knowing anything about programming. Apparently, they themselves are OK with such a waste of time. Idiots.
LOL, in 45 minutes you should do it in assembly for any architecture out there, even ones you never used before. Might take a bit longer in brainfuck, though :)
You don't need multiple lasers, just a slightly different read head. Instead of reading a single-lane track, you can be reading a track that's 4 or 8 lanes wide. It'd cost a small increment more, since the optics, mechanics and the optical chip are very similar to current technology.
Rip it and be merry. What's the problem?
If only life was that way :)
I guess kids these days just don't have imagination :(
When you stream a game, it doesn't have to mean that you're streaming what's on the screen directly. In a game engine, there may well be content that's expensive to calculate, but has very relaxed latency requirements and can be essentially treated as pre-caching of sorts. What you do is look at the client and look for where it ails, and basically offload stuff that may be precomputed a bit in advance. For low-latency GUI, you still have a low-end GPU, but it can, for example, use some shadows computed elsewhere, some matte textures to approximate higher quality content, have advanced AI offload, etc. There's a lot of ways to make stuff look good even on low-end GPUs, as long as you can throw a bunch of computing power a couple of seconds ahead of the frame. It requires out-of-the-box thinking, perhaps, but it's not exactly a brand-new technique. I've seen it applied in the 90s on some flight simulators.
If emulating Apple meant replacing the shit plastic case with solid machined aluminum, I'd be all for it. It seems that nobody else is serious about unibodies and lasting design elements. Other products come and go, like the Dell Adamo, while Apple stays true to form on the unibody front.
for all you finish credits online for govenours college
Huh?
The problem is with schools that don't let you pay using a credit card. Then, on most credit cards, cash-outs ("balance transfer" checks) have higher APR, and are usually limited to a part of your credit line. I know of at least one Big Ten school that doesn't take credit cards for tuition. They only accept bank transfers online and checks in person (perhaps maybe cash too).
Slowly?? I've just tried it, and it doesn't seem to be slow at all under OS X 10.6. I have used Illustrator CS2 since ancient times under VMWare Fusion anyway, so this was just to try out how the more native version works -- seems perfectly usable.