Ok, so I'm being "re-deployed" - a fancy term for I'm looking for another position before I get asked to leave. As part of this journey I've gone through a couple of "Technical Interviews". And while I did not get the positions, I always try to come away with learning something. You know the "how can I do better", "how can I correct the errors or problems I had during the interview" kind of introspection.
So, some observations. Basically, it boils down to the questions that get asked. Some are very general like "give me your impression of what it takes to work on a team of developers". Well, since I have worked on a number of such teams, giving a professional answer to this question is not really a stretch for me. But then comes some "odd" questions (or at least what I felt were a bit odd). "How does the memory manager work?" or "why would create your own 'dispose' method"- Interesting questions that leave me with the reaction of 'well, do you have a day or two while I give you my understanding of how a heap works in relation to memory management' or 'shall I give a three hour lecture on how you can cause memory leaks and performance issues when you do not take time to clean-up by making sure you dispose of the resources that your code grabbed'. My goodness! I thought this was a job interview? But maybe the point of those questions was to determine how well I could pull text book answer out of my backside in 200 words or less?
Then there are the questions that you don't know the answers to cold. One comes to mind- "What is the purpose of the "Using" statement and why would you use it?"- Gee to encapsulate a class or a namespace into your class so that you don't have to fully qualify a namespace reference? That's the answer I gave...but come to find out (after a 2 sec search and read on the C# using statement) Using is also a statement that allows for "the correct" usage of IDisposable objects. Yeah, I knew that because I use 'Using' that way all of the time...It's actually kind of a cool statement which basically is a odd-ball try-catch that allows you to instantiate a resource object that is guaranteed to be disposed of if an exception occurs (say that five times really fast- I wonder if it's really a guarantee?). So, was I turned down because I didn't know that about the "Using" statement? Well, I don't think it was because of how I answered the question on "variables passed by reference as compared to variables passed by value" - maybe I should have shown off more when I was asked about how the heap was organized in relation to how variables function given how they are passed (the by ref or by value question)?
Another odd question was "what is IME Invoke"- well to be honest I drew a blank on this one. But after another 2 sec search I found what I had forgotten about IME- in case you get asked IME is the "Input Method Editor". Basically IME is about how to handle the input of Internal Data. Like a Natural Language data handler. Yeah, I use that all of the time. But actually, I do know about it- just never use it.
So, coming out of these interviews...I was left with the impression that I was "lacking" in the ability to code with the best of them (which is actually not true). I know how to find the answer and I know how to understand what the answer means...no really I do! The sad part is that the interviewers never got close to asking questions that revealed my skills. Like- I know where to start, I know where to go, and I know how to solve problems. I can even find problems that are hard to see...such skills have come with experience and by the fact that I can code well above the average....
Oh, well....I can't wait for someone to ask me questions about OOP! Polymorphism- how do you spell that? And what's the difference between Polymorphism and Inheritance? I mean that's important to a true blue OOP programmer!
Maybe, someone needs to develop a class on how to do a technical interview?
~cse
cse
Subscribe