13 ms·

Yeah, never heard anything about a "knowledge economy". Must be made up. > I don't like to yell, but here it is plainly: YES. Really? I must have went to the

by jshowa 14y ago

Yeah, never heard anything about a "knowledge economy". Must be made up. > I don't like to yell, but here it is plainly: YES. Really? I must have went to the wrong college then or you're interviewing the wrong people. Yes, there is a reason UML is used. Its used because its a standard. Its used because its unambiguous if you know it. Its used to identify relationships, areas of repeated code, state of objects in your code, and it can easily be used to generate code, if it is learned and used properly. I have yet to see any software development book or methodology that doesn't use some form of UML knowledge. Unless you code with no design. > Your school projects do not in any meaningful way approximate a real software project in the real world. Your design docs are held to a completely different standard than real design docs, and the process by which they are synthesized, iterated upon, and approved is also either completely absent in academia or heavily bastardized. Likewise, programming exercises you see your typical CS or engineering program are incredibly simplistic compared to what you would run into the real-world once you're hacking on production systems at-scale. This is why open source experience is valuable, but class projects are not. Here is what I've done as part of my CS degree: - Wrote linked lists, binary search trees, graphs, stacks/queues, and most of the well know sorting and searching algorithms used everyday by programmers FROM SCRATCH. - Wrote my own linux shell, complete with scripting interpretation, variable substitution, I/O redirection, and most of the features you find a normal bash shell. - Wrote several built-in linux commands and other commands (i.e. tail, ps, pstree, etc.) from scratch using only the linux kernel and system calls. - Designed a new calendar system for my university using the agile development methodology with all documentation produced (i.e. SRS, UML documents, requirements etc.) - Wrote a lexer and compiler, with a partner, for a made up language. - Experience implementing RDMS in mySQL and constructed tables and views for it. - Wrote a SMS text messaging system using uC/OS-II using a motorola HCS12 microcontroller complete with ring tone, memory management, clock, and serial communication. - Designed and implemented a solar charging station with COTS parts and arduinos to measure charge voltage and current (meter essentially) - Designed and implemented an RC tank, controlled via Wifi with a webcam and some small autonomous functionality - In the process of designing, implementing, and documenting a airborne particle counting network that uses rs-485 as a backbone and a control program written in C# If this isn't enough experience, then I must be living in a fantasy land. By the way, I've done no open source, but many of these projects (ones with arduino and linux) could qualify. > They can talk a lot of shop about algorithms, but to get them to implement their own algorithms (and do it well) is nigh impossible. Code quality is on the whole probably worse than fresh undergrads. Go figure, they know a lot about algorithms that the programmers probably just use API calls to do. Also, implementing complex algorithms in an interview isn't exactly easy or time conducive. All I know is, I've seen some crap code from programmers (with no CS degrees) that were commercially certified in the language they were running in. I mean I'm talking extreme no-no's (i.e. magic numbers, lack of enum use, lack of comments, no early exiting loops, god objects etc.) stuff that I actually got marked down for in my college assignments.

potatolicious 14y ago
> "Here is what I've done as part of my CS degree: - Wrote linked lists, binary search trees, graphs, stacks/queues, and most of the well know sorting and searching algorithms used everyday by programmers FROM SCRATCH" None of which you will ever be called upon to do during your career. You are paid to judiciously use all of the above, not regurgitate the standard implementation. Which is not to say that your efforts are entirely wasted - there is value in deep understanding of the fundamentals, but it is an insufficient parameter for employment. > "Wrote several built-in linux commands and other commands (i.e. tail, ps, pstree, etc.) from scratch using only the linux kernel and system calls." See above. Rewriting shell commands is really, really, really far from, say, engineering a highly scalable e-commerce platform that can take literally millions of hits per minute. The problems we work on in private industry is way harder, way bigger, and way more involved than reimplementing select, discrete pieces of Linux. We also do it in teams, so your lone gunman bit won't exactly work out. This is the problem we run into when interviewing hardcore academics - so many John Wayne-types who have never worked at production-scale, who have never experienced the full breadth of building a product (as opposed to simply write working code), who trivialize the endeavor, and then find themselves overwhelmed. Computer science is only a tiny sliver of what a software engineer has to do in his day to day. > "If this isn't enough experience, then I must be living in a fantasy land." Welp, sorry to burst your bubble. It's insufficient. You could've spent all of that time interning for software companies and your odds will be much, much better. To be fair though, there are a lot of your peers who don't even have said projects under their belts, so you're far from scraping the bottom of your peers. Experience, experience, experience, this is mantra we need to repeat at every new CS student. Code is only a tiny part of your day in the private sector, your mastery of the full scope of being a software engineer is far more important. > "but many of these projects (ones with arduino and linux) could qualify." Unless these projects were shipped to users (whether it's the public or a client), and unless these were done as part of a team, they really won't. The benefit of open source experience is less about the open source part, and more about having been exposed to how a real, product-shipping team operates. Lone-wolf open source projects are, of course, of some value, since it serves as a reasonable work sample, but it does not eliminate the need for team software experience, which is the real benefit of joining an active open source project. > "Go figure, they know a lot about algorithms that the programmers probably just use API calls to do." They know a lot about the algorithms, but they have no fucking clue when it comes to implementing and applying this in a real-world context. And sadly, shipping product is what makes money, knowledge of algorithms is not an end, it is a means. > " I mean I'm talking extreme no-no's (i.e. magic numbers, lack of enum use, lack of comments, no early exiting loops, god objects etc.) stuff that I actually got marked down for in my college assignments." Here's the trick: these are minor problems in the grand scheme of things. Which is to say, you can fix a programmer that has bad style, but you cannot fix one that just doesn't know WTF is up. I will hire an excellent engineer with mediocre code style over a mediocre engineer with excellent style. One helps ship a product, the other will write perfect code that has trouble proving relevant IRL.

by jshowa 14y ago

potatolicious 14y ago

> "Here is what I've done as part of my CS degree: - Wrote linked lists, binary search trees, graphs, stacks/queues, and most of the well know sorting and searching algorithms used everyday by programmers FROM SCRATCH" None of which you will ever be called upon to do during your career. You are paid to judiciously use all of the above, not regurgitate the standard implementation. Which is not to say that your efforts are entirely wasted - there is value in deep understanding of the fundamentals, but it is an insufficient parameter for employment. > "Wrote several built-in linux commands and other commands (i.e. tail, ps, pstree, etc.) from scratch using only the linux kernel and system calls." See above. Rewriting shell commands is really, really, really far from, say, engineering a highly scalable e-commerce platform that can take literally millions of hits per minute. The problems we work on in private industry is way harder, way bigger, and way more involved than reimplementing select, discrete pieces of Linux. We also do it in teams, so your lone gunman bit won't exactly work out. This is the problem we run into when interviewing hardcore academics - so many John Wayne-types who have never worked at production-scale, who have never experienced the full breadth of building a product (as opposed to simply write working code), who trivialize the endeavor, and then find themselves overwhelmed. Computer science is only a tiny sliver of what a software engineer has to do in his day to day. > "If this isn't enough experience, then I must be living in a fantasy land." Welp, sorry to burst your bubble. It's insufficient. You could've spent all of that time interning for software companies and your odds will be much, much better. To be fair though, there are a lot of your peers who don't even have said projects under their belts, so you're far from scraping the bottom of your peers. Experience, experience, experience, this is mantra we need to repeat at every new CS student. Code is only a tiny part of your day in the private sector, your mastery of the full scope of being a software engineer is far more important. > "but many of these projects (ones with arduino and linux) could qualify." Unless these projects were shipped to users (whether it's the public or a client), and unless these were done as part of a team, they really won't. The benefit of open source experience is less about the open source part, and more about having been exposed to how a real, product-shipping team operates. Lone-wolf open source projects are, of course, of some value, since it serves as a reasonable work sample, but it does not eliminate the need for team software experience, which is the real benefit of joining an active open source project. > "Go figure, they know a lot about algorithms that the programmers probably just use API calls to do." They know a lot about the algorithms, but they have no fucking clue when it comes to implementing and applying this in a real-world context. And sadly, shipping product is what makes money, knowledge of algorithms is not an end, it is a means. > " I mean I'm talking extreme no-no's (i.e. magic numbers, lack of enum use, lack of comments, no early exiting loops, god objects etc.) stuff that I actually got marked down for in my college assignments." Here's the trick: these are minor problems in the grand scheme of things. Which is to say, you can fix a programmer that has bad style, but you cannot fix one that just doesn't know WTF is up. I will hire an excellent engineer with mediocre code style over a mediocre engineer with excellent style. One helps ship a product, the other will write perfect code that has trouble proving relevant IRL.