Just got my ass totally kicked during a phone interview. The guy asked a bunch of very specific technical questions that I had absolutely no answer for. Ouch. Embarrassing!
And if that wasn't bad enough, after leading me to think that the job was going to be a lot of new development, he gets me to give my opinion on new development (love it) vs maintaining old code (do not love it). But this is the wrong opinion, of course (though I bet nine out of ten developers share it). So I spend the next 20 minutes hopelessly trying to defend my opinion while he makes it clear that having such an opinion is a problem for this job which, actually, will involve a lot of old code, and that getting into old code can be a great thing, and a way to prove yourself, and don't all companies have a lot of old code, and ... ugh. All good points! Valid points! Indisputable points! Points I should've never given him the opportunity to make, however.
Oh well. Can't win 'em all.
I think the secret to maintaining old code is to tear out large chunks and rebuild them. Then you get the fun of new development, while performing the necessity of maintaining existing routines. You just call it “refactoring” to cover for the fact that you’re doing extra, but more satisfying, work.
This happened to me a while ago — I had represented myself to the recruiter as a C++ expert — which I am, pretty much — but the company’s definition of C++ expert included a fair amount of stuff that I had heard of, would be able to figure out when I needed to, but had not yet done so… Next time I have a phone interview, I´m going to do a little reading beforehand to make sure all my memories are up-to-date.
I share your opinions vis-a-vis maintaining old code vs. writing new. I particularly don’t like the mix: if I’m going to be spending more than say 50% of my development time on maintaining old code, I wish that would be the complete job.
I think the secret to maintaining old code is to tear out large chunks and rebuild them.
yup. if time allows.
my problem with old code is that you never know exactly what kind of side-effects your change is going to have across the entire project. for example, you’re a week from release and you get a bug report in a section of code you’ve never seen before. so you get in there, find the problem, patch it up and move on. well, there’s a good chance you’ve just opened a can of worms: the testers are going to start focusing on that area while testing your fix and they’ll probably start turning up bugs that have been there forever, which now become your bugs; and you might have just broken something somewhere else because you didn’t know about this undocumented dependency or side effect, or whatever – old code invites cascades of problems. and when the clock is ticking, that can get tough.
new development, where you are in there from the very beginning, where you own the code, and you can visualize the whole system, and know exactly which parts are doing what without even looking at the code – that’s much more satisfying. sure, you can get to that state with old code, but it takes time and a lot of work.
Do you have any examples of the questions they asked or is it still too painful? :)
As someone who has interviewed candidates for C++ roles (both on the phone and in person) I think very specific questions are a bit pointless when even guru’s would just Google for the answer anyway. People aren’t encyclopaedia’s. Specific language questions are fair game I guess but if you’re being asked questions about specific Win32 API calls or STL algorithms, well, that’s not really fair. I always have reference material around, as even after coding in C++ for 15 years, I FORGET STUFF! (especially STL).
I’m quite easy with candidates on the phone because for the roles I’ve been recruiting for we were after graduates who are usually young, inexperienced and as nervous as hell. I don’t actually like interviewing over the phone, but it does sort out the dross and is less hassle for all involved.
For face-to-face interviews we always make the candidate write some code (on paper, so we’re not going to get anal about syntax, etc.) We usually set a couple of simple tasks to solve – FizzBuzz type exercises – nothing too taxing but enough to see if the user actually has a clue. We also show code examples – good and bad – and ask them to pick it apart. There are 20 or so specific C++ language questions asked but again, it’s nothing strenuous – why use const? How does a class differ from a struct? etc.
The main thing I look for is passion.
As for maintenance old code vs. writing new, there isn’t a programmer on the planet who would prefer the former. I refactor old code when I have time and only if the code is backed with decent unit tests. In fact, unit testing is only worth doing for this reason alone – so you can improve the code later without breaking anything. Hot topic though, and adding unit tests to old code is a career in itself (and has led to some good books on the subject). If there aren’t any tests then, yeh, changing that code could bite you very hard on the arse.
I couldn’t imagine a job that involved 100% maintenance of somebody else’s code. That would suck.
I am very lucky – I have worked for the same company for 20 years now (!) and 99% of the code I maintain I wrote in the first place. This makes it much easier to change as I have a pretty good idea of the repercussions…
Do you have any examples of the questions they asked or is it still too painful?
here’s one: how is STL’s map implemented, and what is its performance ?
i think it’s a tree of some kind, but i’m not sure which flavor. (red-black, binary?) performance? beats me! slower than a vector if you’re iterating through the whole collection, faster than a vector if you need a particular item.
there were some about C# Grids which i probably should have known, but just don’t have enough experience to know off the top of my head.
not saying they were unfair… but, damn, i got crushed :)
I’ve been through a lot of tech interviews, both as an interviewer and interviewee, and the maint vs. new code question is a pretty common trap. I’ve been the new person enough times to know that the new person almost always gets the crappy maint work to start.
“Gotcha!” interviewing sucks and to me it indicates there’s some macho, cowboy oneupmanship stuff going on in that environment, or that the interviewer is reading the questions off a list and doesn’t really understand the answers. In either case, blech. It’s obvious when someone’s not an idiot. A smart person is one who knows when to hit Google.
No sane developer wants to maintain old code that they didn’t write. But it’s almost always your first assignment, under the guise of “learning the code”. But that’s an evil question: if you say you like new code, then you get burned like you did, and if you say you like old code, then they know you’re lying…
Understanding the basics, like class vs struct is good, but anything specific like STL implementation: who remembers that when the answer is a Google search (or thick book in your desk) away?
Ouch. Well, it sounds like you avoided a job that would have been plein du suck.
My falling-down place in the C++ tech interview was questions about overloading the placement new operator. I mean I know what it is, and could figure out how to do it pretty easily, but why the hell would I ever want to? The interviewer asked me what would be a situation where you’d want to do that, I flailed around a bit and basically said, well, all the C++ programming I’ve done, I’ve never had occasion to. Seems like a bizarrely complex and non-OO way of getting around the nature of C++…
why the hell would I ever want to?
because you need that data aligned on 16-byte boundaries in order to use it in SSE2 instructions! duh! i mean, how else are you going to do a 4-way parallel multiply on your single-precision data if it isn’t aligned properly? sheesh.
i do this all the time.
{where “all” = once in my 25 years of programming. last month. and i didn’t know it had a special name. and honestly, i ended up using alligned_malloc instead because these were just floats, not classes. screw arcana.}