Ask Slashdot: Are General Engineering Skills Undervalued In Web Development?
nerdyalien writes After reading a recent post about developer competence, I can't help but to ask the question, "Are general engineering skills undervalued in web development?" I am an EE major. The course I completed, and the professors who taught it; mainly emphasized on developing skills rather memorizing reams of facts and figures. As a result, I have acquired a multitude of skills such as analytical, research, programming, communication, project management, planning, self-learning, etc.
A little over 3 years ago, I made the fateful decision to become a web developer in a small SME in SEA. Admittedly, I have an unstructured knowledge about CS theory. Still, within a short period of time I picked up the essentials of web development craft, and delivered reliable web applications. Most of all, I made good use of my existing technical/soft skills, despite the lack of my CS pedigree.
Recently I went through a couple of job interviews in MNCs, SMEs and start-ups alike. All of them grilled my CS theory or Java knowledge. Almost no interviewer asked me about my other skills (or past experiences) that could be helpful in the developer position. In my experience, web development is a cocktail of competing programming languages, frameworks and standards. Rarely a developer gets exposed to a single technology for a substantial period to learn it inside-out. Even still, in web development world, deep in-depth knowledge in anything will be outdated in few years' time as new technologies roll out. So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?
A little over 3 years ago, I made the fateful decision to become a web developer in a small SME in SEA. Admittedly, I have an unstructured knowledge about CS theory. Still, within a short period of time I picked up the essentials of web development craft, and delivered reliable web applications. Most of all, I made good use of my existing technical/soft skills, despite the lack of my CS pedigree.
Recently I went through a couple of job interviews in MNCs, SMEs and start-ups alike. All of them grilled my CS theory or Java knowledge. Almost no interviewer asked me about my other skills (or past experiences) that could be helpful in the developer position. In my experience, web development is a cocktail of competing programming languages, frameworks and standards. Rarely a developer gets exposed to a single technology for a substantial period to learn it inside-out. Even still, in web development world, deep in-depth knowledge in anything will be outdated in few years' time as new technologies roll out. So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?
Most web sites seems to have far more engineering and art than they need, and far less UX that they should. I don't care how pretty and dynamic a site is if the user experience sucks.
and can not produce a decent web page to save my life.
I am very small, utmostly microscopic.
Yeah, they were probably all sitting there, reading through your resume, trying to figure out just what the fuck all of the acronyms you used in it actually mean.
I mean, in a fairly short Slashdot submission summary you managed to work in these:
I'm sure that you're dropping obscure acronyms in everything else you write, in some vain attempt to seem more important than perhaps you really are.
Like most such things, it depends on who you talk to, and also your specific situation. I've had bosses that valued general skills and bosses that looked for specific toolsets. The good ones value what the job requires.
Unless you are going to be developing a site that is directly related to an EE field (mathematics/signal analysis/electronic parts etc), why would you expect your knowledge to be any more use than say someone else's knowledge of law ? If you want topics that would be useful but aren't directly related, art/art history/graphic design/advertising all come to mind.
I know from experience my undergrad was EE and I have Professional Engineering license and it really doesn't overlap much except for problem solving skills and logical thought.
If you are ever in a position to hire people, you will find it is the hardest business skill to acquire. HR people don't understand the types of skills technical jobs require, and hiring managers don't understand how to evaluate applicants on anything except technical skills.
The result is hiring on trivial but easily tested skills. I was just turned down for a job because, after 20 years of delivering successful projects, which I had documented, they wanted me to take a basic coding test, and I refused.
I'm not usually that ornery, but at some point I want the people I might be working with to show some common sense.
All I can suggest is you are going to run into this over and over, and the only thing you can do about it, especially early in your career, is learn CSS, JavaScript and JavaScript frameworks, and HTML5. You are going to need to learn them anyway.
As for Java, that's a big one, but you could get started. All of the tools you need are free and are available for both Windows and Linux.
As previously discussed, it is essential that you know how to send any type of document securely to your manager. :-P
No, but seriously, I agree with you (and I conduct interviews and hiring) that meta-skills (the abililty to learn, to problem solve, to communicate, to function on a team, and being passionate and driven) are more important than acronyms. Such jobs are out there. I'm surprised all of your interviews have only grilled you on domain specifics. That should be a portion of the interview, but only a portion. And more to assess your overall skills match with the job, which will never be 100%.
> So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?
Well- knowledge of what's relevant today AND the ability to pick up new tech / tools fast for what's relevant tomorrow. Most of the tools all follow the same patterns at the end of the day:
e.g.
- Piping output / chaining commands (streams in js are hot right now- gulp.js for instance)
- Not repeating your self (polymorphism / extensibility) as a broad pattern
So if anything, the most important thing is the ability to teach yourself and keep up with what's changing. And sometimes that doesn't mean using it- for example, understanding why React JS and a virtual DOM may or may not be a better solution to what's going on with Angular / Ember / Backbone etc.
What's really going to be necessary is to once again establish a boundary between graphical artistry (in an automated, fitted per instance by code way) and /information systems/ design, where in complicated systems (the back end and interface for the front end) are built and maintained.
Job interviews for coders are usually for "code monkey" positions unless company is small and you need to wear multiple hats.
but what you are really criticizing is the mediocrity of the hiring process
hiring a good team is perhaps the most vital function of a company, and so many get it wrong, in terms of who and what kind of skills they should be looking for
they'll hire the guy who knows the buzzwords of the moment, and ignore the guy who doesn't know the buzzwords, but could learn them in half a day and, most importantly, apply them with the requisite scalability, maintainability, versioning, testing, etc. that means the difference between a world class site and a brittle piece of shit
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
The most important knowledge is understanding of the customer's business. That is not likely to be engineering, and most web applications and sites are not developed to serve an engineering need, but rather a marketing, communications, financial, or business process need. Industrial engineering might be useful generically, and general systems engineering uses requirements management techniques that are valuable no matter what you do.
You have a good start sprinkling in the three letter acronyms into your question. Be sure to learn a few more. I admit it don't recognize the ones you used, and can't be bothered to Google them. :-)
In a more serious vein, in my experience, all software related development could stand to use strong skills in the areas you listed. You should be able to evaluate the suitability of each part of the "cocktail' of tools to the task at hand, and to deliver well crafted and tested solutions, or to be able to point out the deficiencies of the proposed tools. Too much code has been written by persons sorely lacking in those skills, and the poor quality that results is evident. Not even big corporations are immune. One of my pet peeves: why do users have to enter in phone numbers or card numbers in web forms with out spaces or other punctuation? So simple to strip them out in the validation step.
I'm guilty of interviewing by asking (almost exclusively) language questions, CS theory, and programming small functions.
Knowing any language well correlates with a person who hones their craft and continually improves.
Solving problems with optimal algorithms correlates with with someone who can think through complex problems.
For me, asking about previous experience isn't as valuable because it can't be verified on the spot. So it boils down to: "show me your skills" vs "tell me about your skills".
Agree. Interviewers have no clue what they are doing. But I have had some interviewers that ask useful questions on your full abilities and not just programming know-how on specific platforms. Platforms are changing constantly, and your Engineering background will make you capable through all future changes, but unfortunately, most interviewers think the technology is key and not the approach to using the technology and other skills.
Re-usable engineering skills is what you need to succeed. Knowledge of these transient platforms and outdated simple algorithms is what you will need to get hired. That is life in the present job market.
I moved from Engineering to programming back in 1998 because I love computers.
The internet grew because of the guys that dug the trenches for the optic fibers. They also had to negotiate other utility services as they dug. Like to see a sys admin cope with that - after all, he would have to get his hands dirty and be will to give up on finding a an effective underarm deodorant.
Being in Webdev for 15 years I can say that getting the job done quick is all that counts. Most of the web is run by the bizarest of contraptions in software you can imagine - but they get the job done. Take for instance Wordpress: It's a prime example for bad software architecture and the inner platform antipattern.
But it works. It delivers, Any idiot can download and install WP, pop in a theme and start fiddling. The webev gets called in when the system is all gummed up and feature x,y or z has to be added with magic programming trick (i.e. dirty hacks) quickly.
Same goes for PHP as a PL. Strange, bizar and hilarious, but it get's the job done.
That's what counts.
All that been said, it's precisely because of this that your skills as a webdev determine wether you'll have some freedom to pick your job and a fair salary or if you'll be treaded badly. I've been through so many projects that I can tell you even the crappy devs don't mean it. If there's a crew of 5 coding without versioning, that's because their to dumb to know any better and they won't listen to you if you're not ready to walk out of a job that only pays you a McDs salary.
If however, you've got the skills and the tools, most people will think you're a demi-god. Use whatever technology you want, but be able to deliver. I've started building my own toolkit a while ago - it involves bash-cli snippets and PHP code - and dive into any mess my client/boss requires me to work with, be it Wordpress, Drupal, Joomla or whatever. I've since become good enough that I can make some demands, but I have no illusions about my outlook in the webdev world. It is a volatile occupation and unless you move into Java/Oralce, SAP or MS territory, it will stay that way.
The upside is the freedom we have. We get to use FOSS most of the time as primary tools of trade and get to try out new things 5 times a week - neat. You can't have it both ways.
In a nutshell: If you want to stand your ground, you have to be good at both: Overall problem solving experience and proficient expert knowledge in the current tools of your trade. If you stick to building those mostly from tried-and-true FOSS technologies, you'll keep pointless learning to a minimum. For instance, I make a point of using grep to search for snippets of code in a project. My IDE may be dead 3 years from now, as may be the system I'm using. grep will be around until I die.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
If I was the hiring manager, the interview wouldn't just be about programming, but what people are up against is the problem where they need people who can understand the libraries, the language, and able to work with it. Eventually it boils down to short listing candidates who have already used whatever buzzwords they're using. A conundrum, since the chicken and egg problem translates into hires that should and can have made it, but are not given a chance. I'm always surprised that something like Web Development, perhaps a new thing in the nineties hasn't progressed into a drag and drop paradigm, instead it had expanded sideways by adding more to the jargon soup and browser differences.
Engineering knowledge and skill is way undervalued in the current development climate. It is more about get it done fast, get it out the door. Don't make the code pretty, don't make it reusable, fix it later attitude. Patch it up, put a bandaid on it and move on to the next fire.
The only place I have seen where engineering skills are valued is where lives are at stake (nuclear reactor code, Space Shuttle) or enterprise software that has to be up 24/7 or the business fails.
Welcome to the real world.
Oh dude, you're so overqualified for anything in Web Development.
CS, CS is bogus and only really quantifies anything if you're working in Artificial intelligence or Security. The rest of the time, a CS degree is just acts as a warranty for the interviewer that you supposedly knew enough book facts to pass an exam.
Like, I kid you not, most of the crap people work on in Web Development are bloated Javascript frameworks, or bloated Ruby/PHP/Perl backends, and very few people actually know how to make efficient use of the hardware because none of them know exactly how hardware works. Hence we keep seeing further inefficiency by switches to virtual machines and "cloud" virtualize-everything.
I'll give you a very-obvious example. Lots of sites like to use WordPress. If you compare Wordpress to a flat-file (using only javascript, what was formerly known as AJAX (eg Web 2.0) using only flat files, you have 1000X the capacity on the machine with the flat files. The solution that everyone uses? Throw more hardware at it. So instead of optimizing the CMS so it generates cacheable flat files requiring 10 times less hardware, they instead buy 10 times as much hardware and virtualize it on demand.
Like I see so much waste "cloud" setups it's no wonder that cloud providers are making money hand over fist.
In my experience, web development is a cocktail of....
Big project with complex database bindings and backends are usually written in Java. They may not make up most of the web (if counted as pages) or accesses (since facebook etc is highly optimized), but if you need to get a real medium sized project out of hte door in a controllable fashion (and not-perfomance optimized), Java is your friend.
Forget interpreted loose-typing languages. Forget OO by instance copy shit. Take a decent EE and refactor if something is wrong. Use XML bindings where you see fit (without additional cost). And so much more. I know many programming languages, but Java is my favourite from the vievpoint of controlled delivery and SW Quality tools.
That being said yes, i believe that general engineering skills are undervalued, but i have the serious feeling that the original poter understands something different than I do, which is the mindset to dissect problems in systems, where each system prevents imperfections of other systems to pass trough.
The thing is, most CS types that I come across have a really poor grasp of how to configure and get the best out of operating systems. In my first job, I saw very poor examples of JCL written by talented programmers. Today I see programmers with a really basic grasp of bash scripting. Building, configuring and using a virtual machine: that's like deep magic to them.
So, yes, there are lots of people who can write excellent C and C++, but they should not be let anywhere near the act of deploying that code on a real system.
I am also an EE by training, but now write software exclusively, mostly embedded software, and I also dabble in some web development on the side. To me, the general value of any kind of engineering education is that it trains you extensively in problem solving. Although I learned a lot of specific things that I use on the job, the general thing I learned was how to solve problems. I also gained the confidence that problems which seem unsolvable at first could always be solved with a systematic approach and persistence.
I'm not claiming that learning problem solving skills is exclusive to an engineering education, but just that it's a particular emphasis of that. It's a very general and valuable skill that's applicable to many fields. In this example, perhaps you "solved the problem" of doing web development by taking a systematic approach to acquiring the skills needed, and persisting until you mastered them. Of course, anyone can do that, and there are plenty of capable self-taught web developers who aren't engineers, but your EE training certainly doesn't hurt.
You can't even understand what a post title is supposed to be used for, so we believe you.
I've spent about 20 years refining my programming stereotypes. I think they fit the data pretty well now. Here's my take on you, simply because you're an EE:
* You're smart enough to pick up pretty much any CS concept, from the simple to the arcane. For the most part, only physics majors will simply be smarter than you.
* Your code will look like crap, until you put effort into writing more idiomatically and until you learn the design patterns that help programmers use to tame complexity. Your code will, generally speaking, be harder to read than that produced by CS and physics majors, until you put some work into it.
* You mentioned having only a fragmented understanding of CS theory. I think that's true for most of us (I have a PhD in CS). There's just so much of programming for which good theory has been developed: type systems, parallelism (concurrent sequential processes, deadlock rules), user interfaces (kind of), system complexity, static / dynamic analysis of code, relational algebras, parsing, the expressive power of various languages in the Chomsky hierarchy, graph theory, complexity classes, etc. A lot of these theories can be useful for solving problems, but most programmers muddle by without putting them all together and remembering their implications. Heck, most programmers probably don't know about half of the things I listed.
So I wouldn't feel too anxious about that, especially w.r.t. web programming. But it can be very satisfying to to learn more about them, and may in some cases let you solve some problems that other's can't. If you want to get better at some of the brainier stuff, I'd suggest getting a master's degree in CS from a decent school. But that my be overkill for bog-standard web development, I'm not sure.
You should learn a language properly before you start insulting others.
Why the hell would you want to do web development?
Web and other programming is just that and is not engineering.
I saw this happening in the mid 90s - programmers insisting on calling themselves engineers.
I do not know why this happened other than the pathetic egos of our profession and engineering envy - like economists have physics envy. Somehow, programmers got it in their heads that being called an engineer is better than being a programmer or software developer. Why? I have known plenty of engineers who couldn't lay down a decent program. Spaghetti city!
Me, I'm just a programmer - thank you very much. I am not an engineer because I do not have an engineering degree, the experience or the exams that says I am.
"I made the fateful decision to become a web developer in a small SME in SEA"
I do not know what your acronyms are and damn you for expecting me, the reader, to google them. Next skill? Learn to write.
I object to power without constructive purpose. --Spock
If you have options, exit.
I've seen some nasty trends and the industry has changed a lot in 20 years. The only money I made was running my own shop - not working for others. The early 90's was the best; it's been a steady run downhill from there.
If you have options to move into entrepreneurship, business, finance, government - consider them, and use the tech as an ancillary skill you can leverage.
You'd have to be a sucker to be chasing tech as an employee these days.
Proof: Not a single web page in the world is able to remove spaces or hyphens from a credit card number when accepting a payment. Proof that not a single web developer in the world can do simple character extraction from a string.
HR wants 10 years experience in something that was invented 5 years ago.
If you have bigger-picture skills, you might be tempted to think for yourself.
Sheesh, evil *and* a jerk. -- Jade
Like most engineers, you're under the impression that your "magic ring" should automatically be given respect. Your whole post just screams "prima donna", and THAT'S your problem in interviews.
I do not fail; I succeed at finding out what does not work.
Because web development isn't engineering. It's more like graphic arts, writing ad copy, or such-like. It's not like you're calculating finite element models of structures, or developing efficient database structures.
Within the web development industry, which the submitter is referring to, "CS" is often taken to refer to "Adobe Creative Suite". You know, it included Photoshop, Dreamweaver, and lots of other tools that are popular within the web design and development industry. Even since the switch to Create Cloud, a lot of people still refer to it as "CS" out of habit. Computer science isn't their first thought when hearing or seeing that acronym.
Again, within the web development industry, "EE" is first and foremost known to refer to the "Experts-Exchange" website. Electrical engineering isn't the first thought when hearing or seeing that acronym.
So the submitter probably is using acronyms that he thinks mean one thing, but the audience he's expressing them to takes them as having a totally different meaning. Then he wonders why they don't value him. It's because as far as they're concerned, he's talking gibberish to them.
The companies are probably looking for the cheapest code monkeys they can find and thus don't want to pay for any other skills.
I'm a consultant - I convert gibberish into cash-flow.
I'm the head of software engineering at a small company and was a technical director at an MNC previously. I've hired hundreds of programmers.
I regularly hire EEs as programmers, but not for web development. Web development is mostly the bastion of very nimble, hacky types. As others have said, it's frequently more about putting together a reasonably elegant hack in a short period of time.
I hire EEs for board support and other embedded development. Those are the places where real engineering skills are the most useful. I don't want my BSP full of dirty hacks or hard to find/duplicate bugs. I want code that is planned, organized and well executed. That's exactly (in my experience), what I get from engineer coders.
The exception to my above generalization about web development is Java. Java backed websites (JSP and the like) are mostly developed by engineers and are used by large companies. If you want to maintain your engineering mindset and build websites, Java dev as a nameless drone at a big company is the way to do it.
Otherwise, I'd suggest boning up on your C and getting into embedded stuff. I personally find embedded work much more satisfying. It's also much easier to stay relevant without knowing the ins and outs of the latest NoSQL db or javascript library.
Since I don't know much more about IT than the average human resources guy, maybe my experience can be useful.
I taught myself how to write spreadsheets, and wrote a lot of them for my own personal use.
Then I talked to a guy who had been an engineer and programmer, and came into corporations to teach other people how to use spreadsheets.
He made the point that, when he wrote a spreadsheet, he included error-checking routines, such as calculating things in different ways, that would catch obvious mistakes in the spreadsheet.
For example, in a checkbook program, he would calculate the balance on each line by adding the debits or subtracting the credits from the previous line, as I did, and get a running balance.
Then he would separately total the columns and get the balance by taking the difference between the totals.
They should be the same. But if you made a mistake, they might not be.
People have made a lot of expensive mistakes by calculating the total of a bid but getting the range wrong.
This is a deliberately stupid example, but it's stupid enough that it was news to me (because I was self-taught), and it's stupid enough for an HR guy to understand.
I would suggest that you think up a few examples of how your general engineering and EE skills gave you insights that helped you write a better program, examples with obvious utility, examples that are simple enough for an HR guy to understand.
Since the HR guy may not even understand programming, you can give him a quick course in programming, which will demonstrate your educational skills as well.
I'm an embedded developer. I wanted to prove I could do both so I made this HTML5 simulator for a microcontroller.
www.microcontrollerjs.com
(shameless plug :-)
If you can show you have a deeper knowledge of computing than just the latest fluffy buzz words, I think you'll find the decent employers will be quite interested, and it will filter out those who just want a code monkey.
It used to be that you'd go in and you'd be asked to talk about the projects that are on your CV, talk about what challenges you faced and how you solved them, and you'd be asked some basic technical questions to confirm that you hadn't completely made it all up.
Now, nobody gives a crap about your CV. The last time I went through it, to be a PHP/MySQL developer, the tech lead or whatever came in without my resume in hand, gave a curt look and a limp handshake, and launched into it:
"I have 3 questions."
First off:
"Design a game of blackjack." with no further explanation. A silent stare as I asked for clarification. Okay you want me to give you an object model. Doing that.
Much pain later and condescension and derision later (yet in my opinion done well enough to be functional,) comes the second question with only 10 minutes in the hour remaining:
"Design an algorithm to efficiently sort a list of trillions of elements."
And I barely got off the ground on that one. Bounced some thoughts at him with the same derision and impatience in return. Needless to say I never got to hear what the third question was.
His colleagues were not much nicer. I didn't get the job, but fuck them. I wouldn't want to work with these miserable assholes anyway. As I was walked out I saw their big developer pit or whatever they call it, this nightmarish contraption with no privacy and all this agile frenzy going on. No windows, all artificial light in the middle of the day, these giant monitors mounted on walls showing the build status or whatever the fuck, this cheap synthetic carpet, not a single person smiling. I'm sure they are very productive and God bless em.
OTOH, yup, I'm still looking for full time work.
bsf,bcf? What is the "f" supposed to mean? Flag?
Get free satoshi (Bitcoin) and Dogecoins
For instance, I make a point of using grep to search for snippets of code in a project. My IDE may be dead 3 years from now, as may be the system I'm using. grep will be around until I die.
Okay. We'd better fix this mortality thing.
It's PIC assembly. BSF == BIt Set in File, BCF == Bit Clear in File.
My blog, if you're interested: http://www.purp
Recently I went through a couple of job interviews in MNCs, SMEs and start-ups alike. All of them grilled my CS theory or Java knowledge. Almost no interviewer asked me about my other skills (or past experiences) that could be helpful in the developer position
nerdyalien,
The secret of job interviewing is telling the interviewer about your skills and past experiences -- and explaining how relevant those are to the position you are interviewing for --without sounding like a self-centered jerk.
I think instead of asking if it is really necessary to know CS theory and/or Java, you should just learn them for your next interview. Too many people have this "I can learn it easily" attitude and think it is enough, but that does not mean shit to an interviewer. Companies want people who can hit the ground running (i.e. people who already know their shit). You might as well prove that you "can learn it easily" by actually learning it.
Even still, in web development world, deep in-depth knowledge in anything will be outdated in few years' time as new technologies roll out
This just is not true. What new technologies are you expecting? Yes there is a lot of noise about Javascript frameworks, but they're all just Javascript (20 years old). Server side languages haven't shifted much. Most websites are database driven, so in depth knowledge of databases and SQL is unlikely to ever be outdated. Many of the problems to solve server side are concurrency related, hardly new.
Asking a prospective employee about the detail it is really important thing for a couple of reasons. First it obviously gives you an idea about how quickly the candidate is likely to take to come up to speed with the work that you might actually have for them. Secondly, and more importantly, it lets you know that they have the ability and aptitude to actually learn this type of stuff to the detail that's required at least once. It doesn't matter that the technologies in question might be dead, dying or changed in the future, this is better, more tangible evidence than "general" or "life" experience of the capability of the individual to cope with similar new technology in the future.
I'm just guessing here, but isn't setting/clearing a bit supposed to be used with memory, registers or ports? Why is it called a file?
Get free satoshi (Bitcoin) and Dogecoins
Software is not engineering, and web design isn't even software.
From the original post:
In my experience, web development is a cocktail of competing programming languages, frameworks and standards. Rarely a developer gets exposed to a single technology for a substantial period to learn it inside-out. Even still, in web development world, deep in-depth knowledge in anything will be outdated in few years' time as new technologies roll out. So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?
Yes, even in Web development, you can spend years using the same stuff. Many developers do, especially those writing in-house web apps at big companies. I've spent ten years in the IT department for a hospital group, and I've been slowly refining my skills with the same everyday tools since Day 1: Linux, PostgreSQL, Apache, PHP, HTML 4, CSS, and JavaScript. SQL gives me the most mileage, and it's the oldest. As I move what code I can from PHP to SQL, it shrinks, speeds up, and covers more situations.
I've never taken any classes in engineering or computer science. I've heard mixed opinions on their usefulness. My background in English, especially composition, helps me everyday. I recommend The Elements of Style, On Writing Well, and The Mac Is Not a Typewriter.
If you claim java and a formal programming background, expect to be asked about it.
When interviewing at a small company, it is entirely possible that nobody there actually knows the technology you are expected to be using.
So they'll find something else on your resume that they do know and ask about that. If you can't prove that you know it as well as they think you should, they'll assume that you lied about knowing the relevant technology too.
Or perhaps they want to see how you react to being asked to do something you aren't 100% comfortable with. Web technologies are a fast moving target. Whatever you know today may be irrelevant tomorrow. So your comfort in taking what you do know and applying it to what you don't is the most important skill they are interviewing for.
Small companies also tend to have everyone in everything. If a priority bug comes in and you are the only one in the office at the time, you'll be expected to look into it. Normal development will have you doing your specialty, but at times, you'll have to do other things.
It could also be a personality fit type interview. You are expected to admit when you don't know and show an eagerness to learn.
Speaking as a generalist and fast learner, it is not an attribute that is easy to interview for, just something that builds success over time. I have been mis-led by plenty of people I have hired over the years that are clearly smart, grounded, and can pick up and apply an abstract concept in the course of an interview. I have decided they (we) are all con men; I usually have to fire them after 6 months.
It is the actual, concrete skills that tell an employer how quickly you can come up to speed, which is generally why they are more highly valued in an interview phase. If you have that foundation, the other skills are what make you stand out and succeed.
My advice is to be able to speak to the specifics, but also explain how deeper skills apply them; that highlights the best of both.
It is memory, registers and ports, e.g. BSF STATUS,5 would mean set bit 5 in the STATUS register. The reason why it is called 'File' is for historical reasons from terminology such as the 'register file'. This is apparent in other instructions such as FSR (File Select Register). The 'register file' is an array of the processor registers.
My blog, if you're interested: http://www.purp
Almost no interviewer asked me about my other skills (or past experiences) that could be helpful in the developer position.
Did they ask you why you are applying for that position, what makes you think you are qualified? Did you bring up your other skills and past experiences in your response? Did you put your lack of formal training in a positive light without insulting people who have formal training? Do you have a well practiced sales pitch tailored for 30, 60 and 120 seconds?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I have a degree in Physics (and not an "easy" one) and I have found that my extensive math is usually a significant advantage over CS guys. So I could see how some things from EE could be useful, especially if you were doing much in the telecom/signal processing etc type of EE stuff. Then again I also have a Master's in CS (good US Uni), so I guess it is different. You can brag if you know more than other people in a field, but you can't do it if you are at least as good in the basics... ;)
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
No. they are not.
> Even still, in web development world, deep in-depth knowledge in anything will be outdated in few years' time as new technologies roll out. So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?
Neither. Knowledge and learned skill should not make you desirable to an experienced engineering manager. The key is hobby-style interest (or ambition) in the tools, languages, and practices used in that field. You said it yourself, "deep in-depth knowledge in anything will be outdated in few years," meaning that if the applicant is not deeply invested in the field that you are interviewing for, they will allow themselves to be less useful in only a few years.
If you got your PE, you'd notice that a large part of it is "continuing education", and for good reason. The engineers that are consistently valuable in today's technology-based industries are the ones who *both* do their job and advance in their field at the same time.
http://www.dawood.in/if-carpen...
Cuts to the core of the major problem I have with most tech interviews.
The reason the Engineering + Computer Science guys will kick your ... well ... is because engineering programs have very specific goals and are accredited. It also doesn't hurt that engineering profession is supposed to be based on apprenticeship At least North of the border.
My biggest contribution to my employer is that I have been around the block a bit and the software engineers (yah - the ones that can legally claim the title) and the software developers get mentoring assistance so they don't need to make the same mistakes others have already made. The new developers are way smarter than I am and have much more pertinent subject training but that is a minor thing if they can be made useful in a year instead of three or five.
It doesn't hurt that engineers get engineering training .. think medical school or law - instead of just a course load. They come out of school knowing the customer doesn't know what they want, what professional ethics look like, what problem solving in several different contexts looks like, what technical writing means. Some even grasp the concept of resource constraint vs cost. At least they get taught these things ... even if they are too hotshot to remember for a year or two if you don't tune them in fast.
Now I know that some CS schools have actually figured this out and somewhat merged their programs with engineering schools so CS people can actually have a hope of doing the jobs most of them will end up doing - so if you are one of the happy few I salute you, but recognize you are the minority.
Google it, because that the way shit works in the real world.
If you're getting CS confused in the context of Java, and Creative suite, you're on the wrong forum.
And by web development community you must be referring to php and UX peeps, because nobody I know has mentioned ExpertSexChange in years. A more valid context for EE would be Java EE, but nobody gets a degree in Java EE, and nobody has a major in ExpertSexChange either.
> All of them grilled my CS theory or Java knowledge. Almost no interviewer asked me about my other skills (or past experiences)
Can you go to the board and write code to find a loop linked list?
I'm not sure what exactly interviewers think they are getting out of such questions, but in my experience, almost nothing
I would not hire you simply for using so many acronyms.
Who does that, especially posting to a public website? ASSHOLES! That's who!
If you're an electrical engineer, why the hell are you wasting time doing web development?
Its seems to me that you have a point and yet you do not get your own point. In technology our skills have a half life of five years. You sound like you know that part. You got grilled on 'CS theory' because 'in web development world, deep in-depth knowledge in anything will be outdated in few years' time'. The point is that we continually have to learn new skills that are of value in the market. The current market skills will be valued first as they are most relevant to the task at hand. All the other elements play a supporting and enhancing role to your job application. This does not mean that the best Java programmer will get that Java job. It will go to the best Java job candidate. If your general background compliments your Java skill set then you will shine brighter.
When applying to a Java job without / with less Java skills than the position requires I feel that person should earn less to compensate for the risk of the project's failure due to incompetence. In my opinion in 2015, if your applying to a Java job it will be by definition a job for a specialized niche work requiring advanced skill.
Engineering is applied science. Electrical engineering, chemical engineering, and running a train are true engineering pursuits.
Computer "science" is not a science---it is an arbitrary paradigm beyond the electrical engineering and physics required to construct physical computers.
Since there is no "science" in computer science, calling a programmer an "engineer" makes no sense.
Web Developers are craftsmen not engineers and generally know little about what it means to be an engineer, despite all the automated tools they have at their disposal.
Really?
The most important Engineering Principle is to measure everything using metrics to guide the process, in a word continuously testing your assumptions and decisions.
This IS applicable to software engineering through the application of test driven development, to ensure the component meets the requirements and continues to do throughout the development process.
Because PHP is going to be reaming your asshole all the time. Seriously, if you can't gape at least six inches in diameter (that's 29cm in radius for our European friends), then you may as well just quit now. Try something with Java, were all you have to do is suck Larry Ellison off.
CAPTCHA: buttfuck, seriously, how odd is that. Wow, fuck you Timothy.
Are we channeling Timothy now? Maybe we could try posting "Ask Slashdot" stories in the "Ask Slashdot" section? It's there for a reason you know.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
But, seriously, the problem is that the people interviewing are only looking to fill a square hole with a square peg. Asking how well rounded you are isn't germane to the discussion, because it's not in the list of requirements. By the way, those same skills are stressed in any good CS program.
My engineering degree has prepared my for a job in IT in 2 main areas. First, critical thinking, and second, envisioning/building systems with many moving parts. Basic concepts like UID/GID, and file permissions may seem core to IT Skills, but are the last thing that seem to be foundational to many SW developers. Also the ability to think on ones feet, to build a system of moving parts, into a system of many more moving parts. So many of my Graduating class have switched to IT jobs. Civil, Mechanical, chemical, even Electrical gearheads have made the jump. Reason? We are trained to think and consider all the details. Why, its where the money is. Want a foundationally sound system? Pair a software/Visionary with an Engineer and you will get solid/durable results. Be sure to spec out the requirements, the expectations, and the succcess criteria.
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
That is why you were not asked about them. In most cases, web-developers are the bottom of the barrel, spotty CS skills at best, no other engineering skills at all. The interview process you experiences tries to make sure the people interviewed are not completely incompetent, nothing more. You are vastly overqualified.
And no, this is not prejudice. I did run into really badly done mission-critical web-applications repeatedly and in different places and tried to find out why they were made so badly. Turns out this is standard. Best so far I found are a couple of web-developers that cannot manage to read and understand the teo content pages of an RFC, where half of the pages are pictures. The one using a self-written bubble-sort to sort an arbitrary large array in Java was also nice.
Also relevant: http://blog.codinghorror.com/t...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
How about you go and read the damn PIC datasheets? Who the hell cares why they call it a file? It's their device, they can call it Bob if they want to.
As much as I hate to put people in boxes, I suspect you are correct in your guess. If the OP wants to get any web development job and they have reasonable programming chops, then there are any number of opportunities. The bar isn't set particularly high for the most part. Many employers have realized, though, that developers are not all equal and there is a huge difference between the bottom performers and the top performers. I've spent over 20 years in a mixture of embedded and application development. I've spent the last 2 years in web development. There is a lot of looking down on web developers by application developers, but I have to say that the job isn't so different. The main difference is the size of the code bases (10's of thousands of lines for web apps vs 100's of thousands of lines for application development). This difference in scope allows you to get away with crappier code, but basically good programmers with a solid foundation in the basics will still handily outperform cowboy coders.
I think my main advice for the OP is that if you are asking the question, then there are probably a lot of things that have escaped your notice due to lack of experience. Employers armed with very good programmers will notice it and may decide not to hire you. This is just an indication that you still have a lot to learn. If you can communicate that you understand your gap, you are likely to have more success. Good teams hire good juniors too. But if you go in with a handful of years of experience thinking that there isn't much more to learn then you will probably only be able to find work with lower performing teams.
The OP didn't say this, but I have to say that my biggest complaint with people I'm interviewing is the attitude that 1-3 years of experience is particularly significant. I can't tell you the number of applicants we've had with that much experience expecting to technically lead the team. When I tell them that I have worked as a professional programmer for 25 years and ask them what they intend to learn for the next 22 years, it usually leads to a blank stare. Such a thing has not crossed their minds. That's not to say that I wouldn't consider it for the occasional very rare talent, but I can tell you that in hundreds of people I've met, I've only really encountered 1 or 2 that were really capable of doing it.
Memory was used to be called file, before a file was called something that is on disk, in fact there were no disks.
Web developers have engineering skills? Stop the presses!
Scruting the inscrutable for over 50 years.
The reason someone recruiting you is less likely to ask you about other experiences and training you had that YOU feel relate to the job is that he doesn't know what you know.
How the heck is John McGee, with his Comp. Lit. Masters and 5 years of HR experience, supposed to see for himself that 4 years of general engineering gave you a methodology to apprehend complex system, which makes you a fast and good learner. How is he supposed to know that because you've spend so much time learning so many different yet relatable fields (EE, thermodynamics, mecanical, etc..) you've gotten very good at extracting general information and synthetyzing which will empower you to switch from Node.js to Go much faster than Jimmy over there who did 5 years of node.js since highschool and never learned anything else ?
Yes, technically it is his job to know that, but then again it is YOUR job as a potential employee to formulate and back with facts these claims that you make.
The guy interviewing you isn't supposed to help you sell yourself. He is trying to gauge you. Selling yourself, being coherent and expressive about your strenghs and skills is an excellent indicator that you can explain a problem and communicate efficiently which are valuable in your future work.
Software engineering is much harder to keep up with. Other engineers get to keep using the same solutions. We have to keep inventing new ones.
Speaking as one of those "other engineers" I can safely say that is complete nonsense. You think engineers in other fields do nothing but solve the same problem over and over using nothing but the same tools? If that were true then there wouldn't be much need for engineers at all. I have a job precisely because I have to continually find new solutions and invent new tools to solve problems. If you seriously think that software engineers are forced to be more inventive than other types of engineers then you very clearly have no idea what other types of engineers actually do.
Which is why in many places it is illegal to call yourself an engineer unless you licensed to be one.
Not anywhere in the US. Just because you don't have a license doesn't mean you are not an engineer. To be an engineer you have to do engineering work. That's it. Doesn't mean you are a competent one, but you can describe yourself as one. While the term does get used inappropriately sometimes it's perfectly fine to call yourself an engineer if you are applying science to practical problems because that is what engineers do. It also doesn't truly matter if you have an engineering degree or not. Some of the best engineers I know don't have a college degree.
There are jobs you cannot get without a certification like a PE (civil engineers and a few others) because of liability concerns but that doesn't mean the people who lack such licensing (including myself) are not engineers.
The other applicants will have you beat on direct experience, looks like. I don't think any employers are looking for people with 'general engineering principles' at the expense of direct applicable experience. That's why you don't get the job.
Study up on relevant technologies and coding style so you can break through by submitting a killer coding test or nailing it on the specifics in an interview.
HR wants 10 years experience in something that was invented 5 years ago.
Yeah we've all see that but HR usually just parrots what the hiring manager tells them.
If you have bigger-picture skills, you might be tempted to think for yourself.
The problem with having a generalist skill set is that no one at a large enterprise will know what to do with you. Generally a large enterprise will want someone with deep domain expertise in a narrow field. And that makes sense because they have a specific task and it is comparatively easy to evaluate experience versus ability.
I have the skill set of a generalist. I'm have an engineering degree and a business degree and I'm also a certified accountant. I'm rather competent in a variety of skills though if you look hard enough you can usually find someone marginally better at any one of them if you don't need the other talents I possess. I have worked in diverse industries, everything from manufacturing to health care to auctions to retail. I've consulted, owned several businesses and spent many years doing hard core engineering analytics (statistical stuff mostly) for big manufacturing companies. I'm competent in process engineering, product design, production management, statistics, accounting, finance, HR and some areas of IT. When I apply for jobs I generally have little problem convincing the interviewer that I'm pretty smart but they then usually become concerned that I'm either overqualified OR that I will get bored and leave OR they think that I don't have enough experience in the little niche they are hiring for even though I generally could handle it pretty easily.
Generalist skill sets are usually most valuable in smaller companies which cannot afford to have specialists. That's why I run a small manufacturing company rather than working as a minion in a much larger one.
No, Bob is the name of New Earth.
Get free satoshi (Bitcoin) and Dogecoins
I can't comment on why or why not you've been able to land a web developer job, but I'll pop in with a bit of related but unsolicited career advice: Look for a job where someone is building devices for the "Internet of Things." There are plenty of embedded systems companies which value the type of skills which came with your EE degree, but have no staff with a background in web development. As they look to get their devices on the internet, someone well versed in the mix of technologies involved - and can build a usable web UI - will be in demand there.
Computer "science" is not a science---it is an arbitrary paradigm beyond the electrical engineering and physics required to construct physical computers.
First off, your premise is wrong. Computer science is very much a science, specifically one devoted to the study of information, algorithms, storage and other aspects of information processing. Do not confuse the field of computer science with what most people who have computer science degrees actually do to earn a living which is more fairly described as engineering. The mere fact that much of the field (though not all) is abstract in nature does not in any way mean that it is not a scientific pursuit. By your definition chemical engineering is "an arbitrary paradigm" beyond the chemistry and physics required to build processing plants. If you can apply the scientific method to a problem then you are doing science. The level of abstraction is irrelevant to the discussion.
Since there is no "science" in computer science, calling a programmer an "engineer" makes no sense.
Second, a programmer absolutely can be an engineer as long as he/she fits the definition of doing engineering work. Engineering is the application of science, technology, economics and other practical knowledge to solving problems. Most programmers are involved in engineering work at some level. While it might be socially pretentious to call some of them engineers, strictly speaking it is technically correct if you do.
The general idea behind good engineering. Sit down do all the work and build your product. With Web Development or any software development with a lot of end user interactions. The engineering methodology towards development is doomed to failure, unless you happen to have a large marketing engine behind you to push your product.
The first mistake: Collecting your requirements. In development this is an iterative task. As the end users really do not know what they wan't have of them aren't even sure what advantage your product will have to bring.
The second mistake: Prototype. The idea of a prototype is a functional equipment made before mass production. In software Mass Production is not the issue. So you are actually just making an equivalent of a Clay model. for your prototype. This will at least start to spark their imagination so you can actually collect real requirements, however you get stuck in a lot of complaining, how the colors are off, or you are using the wrong logo, or the fact the data is not saving. You get a bunch of non-requirements from it. As a side note. I once released a prototype software back in the 1990's we just recently got a CD Burner, and a CD Labels that we can print too. So when we distributed the prototype, I printed a label with some fancy graphics, and put it in a jewel case. Some bonehead got his hand on the prototype system, impressed by the graphics on the CD and Jewel case. and Installed it over his version of the software and wrote a nasty level on how horrible the new version of the software was, how half of the screens didn't work, and how he deleted all his existing data. Needless the CEO of the company blasted him back and told him how much of an idiot he was, for installing a software labeled in big writing "PROTOTYPE" and expecting it to work like production software, and also for Installing software he wasn't suppose to install on his system anyways.
The third mistake: Requirements and spec signoff. The requirements and specs are not done until the product is done. Any assumption made early on may be a major issue later. You decided to use HTML Tables and you found out they were slow for large data sets so you needed to switch to divs. Or you were suppose to use divs but getting the CSS just right on the required browsers is near impossible, so you need to switch to tables. The original data format took hours to process, while a different format takes seconds.
In general with modern software development engineering principles don't work too well, as the IDE and coding is the design process, and the steps of making a formal design with a bunch of flow charts etc... Is for a large part just redundant.
This is for software that is intended to end user interaction (Web development). These engineering skills are much more useful for back end type of work. Where there is a fixed process and you just need to have the computer do the work and you really don't care about making it look nice to the end user.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I have been a professional developer for almost 20 years and I have never been a manager by choice, but I conduct lots of interviews where I get to make the "no go" decision on applicants. In other words, I am never the final say whether you do get hired but if I tell a manager, I don't think you should get hired, you won't.
I would never hire you for a senior developer position.
1. Your communication skills suck. A good developer should be able to describe the problem and the solution in an easily understandable manner. You use way too many acronyms.
2. You admit that your knowledge of CS is "unstructured". If you think you have picked up the "craft" in a short period of time, you are not self-aware enough to know what you don't know. When I interview a "web developer". I want someone who knows front-end, web services or the server side framework in question, how to properly layer the stack, unit testing, databases, etc. Do you know that?
3. Why would I hire you if you don't know the language you are being hired for? Java is not a new flash in the pan language. It's been around and popular for 20 years.
4. " Rarely a developer gets exposed to a single technology for a substantial period to learn it inside-out. " This very statement shows an extreme lack of technical maturity. I know plenty of developers that know their chosen stack inside and out. If you have been jumping around from technology to technology every six months it shows a lack of focus.
4. Of course I am going to "grill you on CS theory". If you understand CS theory well, I would have more confidence that you could pick up a language/technology fast. Theory doesn't change that often. If I can ask you about MVC and you know the theory behind it in Java well, I would expect you to pick up Angular fast.
5. " So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?" Both. I want you to be able to demonstrate that you have used the latest technologies either in your job or side projects and that you have spent time studying language agnostic concepts like project management, design patterns, etc. I want to make sure that I am working with someone that is an aggressive learner.
I see that there are lots of silos within the SW profession. The 2 biggest camps are MS dotNet and Java EE based tech. Then there are lots of sub types. At one time, I use to be a Jovial programmer working on big DoD projects until I got laid off. Most of the interviews questioned lots of language specific stuff. However, I felt that my biggest strength was in SW design and analysis, and SDLC. No one asked me questions about that, as I suppose they thought it was hard to evaluate an answer.
Lately, I have become a Java programmer and had a C++ interview. I use to know C++ quite well, but after being away from it for a while, I even forgot a lot of that. My first observation was that if you don't keep up, you fall behind quite rapidly. On top of that, it is easy to juxtapose knowledge between the two. For example, while working on Generics in Java, I could not keep my syntax straight and used patterns from C++ templates.
... aptitude.
We've all met and worked with coders who seem to have an IQ lower than asphalt and we've met and worked with brilliant coders.
While it's rather easy to judge their level of competency, it's near impossible to determine if they can play the guitar, and who gives a shit anyway?
How many great coders are self-taught? Not many, but one is enough for my team.
It little behooves the best of us to comment on the rest of us.
The poster has a degree in Electronic Engineering, but his skill list does not including designing, building, and repairing electrical apparatuses.
It turns out that the University of Illinois actually teaches a course in General Engineering. It mostly prepares students for managerial roles.
Web design has become as non-technical as a secretary using a PC. The only place you can have value form a techie view is in the back-end but that's generally NOT EE. You are wasting your degree.
The title "Web developer" gets thrown around to much. We can be talking about Facebook and Google or site that gets 20 request per second. The required skillset is entirely different. A Masters in CS is wasted in typical web development they should be building tools and platforms eg databases, languages etc.
In a regular web dev role a Master in CS / EE is a burden. I worked in the later scenario as a developer / lead developer / director roles, for more than 10 years. I can say EE or CS developers rarely workout. The fact is the Web Development is just not that hard, experience counts more than college. My best engineers have MIS, History, Journalism etc degrees. They learned everything on their own or worked their way up. I am not say that you don't need to understand what algorithms you should use, how to implement security, Optimize DBs etc, but if you are passionate you will study those fields as you work your way up. My degree gave me a good start on concepts, but i learned on the job.
Typical EE / CS employees:
1, Spend Ton of hours finding an "ideal solution" that have no bearing on requirements or the constraints of budgets.
1 a, Said ideal solutions is always broken then the next CS guys pisses over it and rewrites it. Then we have web developer make it work and of story.
2, Have no hands on training in both Databases and Web Development, while MIS students do.
3, Generally don't fit the culture.
Well, if it is on Wikipedia it must be true. Such a great defense to your argument!
You can build an industry around anything. It still doesn't make it a science.
In the meantime some may wait for you to actually "discover" an algorithm. Perhaps some will call this activity "angel'o'sphere's folly".
It depends...
Keep in mind that a lot of companies rely on HR people to do the hiring. And they have no idea at all, what characteristics make a good developer.
In those cases, comfort yourself with the idea that you probably "dodged a bullet", you would not have liked the job. In fact, remember that the interview is for You to evaluate Them, not so much the other way.
The best thing that helped me with this problem, was a couple of Psychology courses that I took.
Also note my sig line, for the result for those companies...
The skills are so different they don't benefit from each other. Front End Devs need UI and ascetics as well as general programming skills. Back end Devs need business logic, database, and general programming skills. Knowledge of the elemental composition of plastics, or knowledge of resistor band codes won't come in handy in either.
(If at first you don't succeed, do it different next time!)