In theory, practice and theory are the same thing, in practice they aren't
This is true 90% of the time, but in Engineering it isn't always the case. I was speaking to someone a day or so ago about interviews and they were nervous as the job they were applying for required a specific programming skill and they had only done "a bit" of it.
What I told this poor young fool was that as they had talent (and they do) this lack of experience was just a minor element. Could they learn more in the week before the interview? I asked. "Sure" came the reply.
Well there you go. Any if they ask questions about threading and deadlocks can you answer them.
"Well I know the theory but not the syntax"
And it was here than I imparted the knowledge... Its actually the theory that counts not the syntax. To this end I'll tell two tales.
My first job interview was for a start-up company. They had some interesting bits around Eiffel and were trying to create a meta-language on Eiffel that enabled multiple different GUIs and Databases from a single code base. Part of this would require me to know C. I was asked
"Do you know C"
"Sure" I said.
"You'll have to take a coding test next week to check" they said
This gave me 7 days to learn C, a language I'd never coded in before. By the end of that week I was coding with pointers to functions which took pointers to arrays of functions as arguments. The reason was I understood the theory and could quickly apply it to the new syntax.
I got the job..... but they went bust 6 months later owing me 2 months wages so it wasn't the best story.
Now for another story, a good friend wanted to shift out of his current IT job which didn't do coding into a coding job. He had a bunch of theory and brains but no experience. I boldly said that I could coach him through a C++ interview in a couple of weeks. For 2 weeks we talked about classes, STL, friends and lots of other things.
He got to the interview, chatted for 30 minutes about computing in general and was asked the killer question
"So you know C++"
To which he quickly replied "Yes".... and the interview was over. He got the job and was pretty bloody good at it, despite the level of bluffing (although the single word "Yes" isn't the strongest bluff in the world).
The point is that if you understand the theory of programming languages and computing then individual languages are just a set of syntax that implements that theory in a specific context. Unfortunately in IT very few people understand the theory and are therefore condemned to badly implement software in the manner of an orang-outang who doesn't understand English but has a dictionary of English words to point at.
Lots of times Theory is less important than practice, but in IT if you don't know the theory then the odds are you'll be rubbish at the practice.
Technorati Tags: SOA, Service Architecture
5 comments:
In the second example; if you had applied at the company I work for you would have stood ZERO chance of success.
IMHO: A company that doesn't ask you any "core" in-depth questions regarding the skills you advertise in your resume isn't worth working for (because they haven't worked out how to hire good developers).
And indeed I interview a fair bit more in-depth than "do you know X". My point is that he succeeded in the job because of his theoretical background. I'll take a fiver that even if they'd asked detailed questions he'd have got through.
On the 2nd point, if you are after experience on your CV then don't be overly fussy about where you get your first 24 months. After then its great but lots of great companies want that magic 2 years experience.
Such a strategy is potentially dangerous when hiring software developers. While I dont dispute the fact that a strong grounding in theory is essential to do be a decent programmer, the converse is not necessarily true. I have seen people with master degree in computer science fail miserably when it comes to delivering working sofware. I would go for some one with someone with a proven track record anyday.
I think I would go with Steve on this one but I'd formulate it differently: if you CAN program in one language, you COULD program in any language. Meaning, if you know enough theory and have practiced long time enough to produce good code in one language, you would need only the shortest of time to adapt to another language.
As a corrollary, I tend to think that no amount of practice is going to make up for lack of theory: I can sit my son in front of Eclipse for an infinite amount of time, he surely won't produce the next Oracle competitor! :)
I think honesty is the best policy.
I went for a job were I didn't know the specific programming language but I knew how to program. Instead of waiting for the dreaded question "Do you know programming language X?" I started off with my emphasis on skill and theory and after they were nodding their heads I told them I don't know the specific language in question.
I made my case for the job by describing myself as understanding the theory and having the experience applying it, albeit in a difference language. So I got them to reframe their requirements; do you want a walking textbook or someone with knowledge and skill at applying their knowledge? I can pick up the specifics of a language in a week while I'm settling in.
If the company is worth working for then a broad view is required on their part too.
Post a Comment