Mudshark

I don't know. I think that a general CS or CE degree from a good university will give you the foundation you need to go down just about any career path you might want to pursue later.

It's just that when you go to get an actual job, they are almost certainly going to want to see that you have at least some experience in the specific technology you will be working with. If you have the right foundation, some things you can pick up in a couple of days before the interview (new languages and the like) but other things simply require experience to really 'get'. For example, I wouldn't expect a guy who specializes in embedded systems to pick up a book on database design and really know all the well known pitfalls and best practices in a couple days. And I wouldn't expect a database guy to really grok real-time programming in a constrained environment like the embedded systems guy. But if both had a solid CS background, I'd expect them to be competent in each others specialty given enough time investment.

I guess what I'm saying is, if you don't know exactly where you want to be when you graduate, get a general CS or CE degree and use the time to work on projects that interest you. By the time you are done you should have explored all the different facets of the field and (if you weren't slacking) you should have a diverse stable of projects behind you that you can use as evidence of your competency.

Bisclaveret

As someone who's dabbled in the older languages for a while (FORTRAN, COBOL, and the old BASICS like GW-BASIC/IBM BASIC) I'm finding it really hard to understand the logic of OOP programming like C, because everything I've worked with before is intensivly structured, and well, old. In my EE classes so far i've taken a 12 week intro to VB6 course (that was a while ago, i dropped out because of RL issues and have to start over) and that went pretty well, but still, it was only an intro. My major problem in that class was REM'ing each line of code so that when I could look at it 2 months later I would know what the hell I was doing

I suppose one of my problems is not having enough examples of work and not having experience in just making things in that language. Most people I've talked to say, "oh, just get some well documented C/C++ code and you can understand it right off the bat and you'l be programming in no time" which I'm finding is quite a load of bunk, because I've had no theory in how the languages work or even how they're structured.

__________________

ScratchMonkey

If old compilers were reliable, we'd just all stay with Visual Studio 6. Or go back to Turbo C 1.0.

When I pursue a problem, I don't want to just pick a path through the tool chain that doesn't cause problems. That just means I don't really understand the problem, and it's going to arise again, likely when I can least afford it. I chase the problem down to root cause, into the bowels of the tools, so that it gets fixed and I never see it again.

I've yet to find a framework that doesn't bite me at some point because the documentation doesn't match the implementation. Sometimes the developer blogs enough additional information that one can figure out what's really happening. But I usually prefer getting full source so I can see for myself what it really does.

__________________
Sig

=Sarc=

It gets easier with more experience. I work with a lot of Java code that isn't commented and it isn't hard to understand what the code does. It is a drawback though because I would like to know what a method does without having to read through the code.

You'll find that a lot of difference languages are quite similar. A program is just a sequence of logical statements. Once you understand the syntax, it's quite easy to read. Also, syntax between different languages may be different but it's logical enough that you'll understand what is going on.

__________________
JO Guides & Tutorials
Team Element - It's who you game with.

ScratchMonkey

The purpose of comments is not to explain how code works. Well-written code should be easily understood for function. The purpose of comments is to explain why code was written that way. It explains the constraints outside the system, such as bugs in OS APIs and strange hardware with unusual requirements, or UI design considerations.

For a good source of code to study, just grab any Linux distro. Source is available, so you can see how everything in the system works. And because it's open source, the authors have their ego invested in making the source look good. To some extent it's their resume, and future employers need only download that code and inspect it to decide whether to hire them.

__________________
Sig

=Sarc=

That's a very good point. I don't complain much about code that isn't commented because I can just read it to know what it does. I complain about code that doesn't have comments that state if arguments can be null or if return values may be null.

__________________
JO Guides & Tutorials
Team Element - It's who you game with.

ScratchMonkey

As a rule, I use C++ pointers for "possibly null" and references for "must not be null". I also use const whenever possible to clarify what may be modified. Let the compiler do its job in finding bugs, and give it as much information as possible so that it can do it effectively.

__________________
Sig

El_Gringo_Grande

Having some projects that you can actually show is always a good thing.

I have been making the technical decision for hiring for about 6 years and I never ask specific technical questions. They just are not that important.

Well, in the beginning I took that approach because that is all that I knew at the time. I wrote small quizzes and had a crap load of specific technical questions and would only hire the people that could answer them very specifically.

And I couldn't understand why I didn't get the quality of employee I wanted. The code they wrote was technically sound but over all it simply sucked. They didn't take directions well and often insisted on doing it the "right" way.

Firing those punks was fun!

Now I ask very general questions like "what are the benefits of a RDBMS?" or "Explain the shortcomings of OOP". If they get pass those I will go a bit deeper and possibly ask them some simple questions about a couple of patterns.

But really what I am looking for is somebody that seems to have a passion for the work. And the one thing that will seal the deal in most cases is the candidate that will come out and say "my code sucks, but not as bad as it used to". Because, quite frankly, 80% of all code sucks. And only those willing to admit it can improve their craft.

There are a couple exceptions to the above. If I am looking for a junior level positions for a specific job (like report writer) then I will ask very specific technical questions. Or if I am hiring a person to maintain old code/systems.

But for new development? Could care less what the person specifically knows because, more than likely, the technology is going to change during the development. Then all that matters is passion, the ability to learn and the acceptance of change.

__________________
Sen. John McCain (AZ) For President '08
---
I’m not racists, I have republican friends. Radio show host.
- "The essence of tyranny is the denial of complexity". -Jacob Burkhardt
- "A foolish consistency is the hobgoblin of little minds" - Emerson
- "People should not be afraid of it's government, government should be afraid of it's People." - Line from V for Vendetta
- If software were as unreliable as economic theory, there wouldn't be a plane made of anything other than paper that could get off the ground. Jim Fawcette

Mudshark

This is a good post for soon to be graduating students. My company hires along similar lines. The interview is usually a 3+ hour deal (if you make it that far [most don't]) and you get questions from various managers and leads (for dev positions anyway). Generally, we give a few specific technical questions. Usually these are probing questions and they are often covered on the phone screen. You are expected to have the answers because they are integral to specific to the job you will be doing every day. Once we are convinced you are an actual professional, we invite you in for an interview and the questions move heavily toward the abstract. Such as:

'Here's a problem scenario, how would you go about approaching a solution?', or
'What's your take on XXX technology for YYY application?'.
or
'suppose you have XXX technical situation, point out any risks or potential problems'

Often, these 'scenarios' are modeled after spicific issues we've had to deal with. Often we will start small scale and add on extra complexities such as environmental or business constraints as we go. The purpose of these questions is many-fold.

We want to see that you are not BSing us. If you've never used the XXX technology that we ask about, DON'T PRETEND! That's an immediate 'no thanks, good luck.' It's perfectly acceptable to say you've never worked with it and you would have to do some research before giving an answer you were confidant with.

We want to see how your mind works. Maybe you don't come up with the same answer for a problem that everyone else does, or maybe it's even wrong. As long as we can see you thinking about the 'right' things...

We want to see how you work in a team. This one is HUGE for us. We work heavily in teams and if you can't get along and contribute to a group, you're out. We try to turn your solutions of the the big abstract questions into discussions. Maybe we suggest an alternative solution of our own design and see how you react. Do you courteously point out some of the solution's weaknesses (+not a yes man+)? Do you ask us questions about the problem space surrounding the problem (+big picture thinker+)? Or, do you vehemently defend your solution defiantly ignoring it's warts? (-Stubborn- -egotistical-).

We try to make these discussions simulate the type of team meetings and discussions we have all the time, every day. We want to see you argue with us, in a professional way. We want smart people who can get a job done on their own and point out any potential problems to the team before they become major disasters.

Still, many people come in thinking there's just going to be some basic programming questions or a written test or something. These folks are shocked to come in and find us wanting to sit in a room and just generally talk about software development.