Interviewing programmers

Riffing on Dispose:

a) Why would you implement IDispose?

b) What's a finalizer?

c) What should you clean up (or not) when Dispose is called?

d) What should you clean up (or not) when the finalizer is called?

e) What's the function that I always forget to call when I implement Dispose? (Interpret as "What's the function you should call when you implement Dispose?")


How many people do you suppose get c) and d) correct?

amotif wrote:



Massif wrote: why "this " + someint.ToString() + " is stupid" is a bad idea

Ooh, good. Are you asking because of the use of ToString() here or because you think there's an inefficinet concat happening--because it's really not. C# 2 will use String.Concat(string,string,string) here. It's probably not any worse than using String.Format.

Even so, String.Format("this {0} is stupid", someint); is preferable because it is shorter, easier to read and easier to localize.

Mark Brown wrote:

I'm with Mr. Awesome here. I much prefer asking programmers questions around, "How would you design or program something" rather than really specific nit-pick topics.

There's so much an engineer has to know that it's impossible (for me at least) to keep it all in my head. I'd want to see creativity, how they approach the problem. Who cares what the enums for some specific API are, that's what MSDN is for.

Generally too I find that even just having a casual conversation about software and programming has been enough for me in the past to weed genuine candidates from BS'ers.

I find that good programmers tend to do coding outside of the office, and are often really enthusiastic about these apps, which can be surprisingly relevant.

If you ask a programmer what they think the best app they've ever created on their own was, and discuss that, and then ask later what the best app they've created as a group was, what their involvement was and what position/responsibilities they had in that environment were, and discuss what mistakes and lessons learned from these experiences were.

Mark Brown wrote:

I'm with Mr. Awesome here. I much prefer asking programmers questions around, "How would you design or program something" rather than really specific nit-pick topics.

There's so much an engineer has to know that it's impossible (for me at least) to keep it all in my head. I'd want to see creativity, how they approach the problem. Who cares what the enums for some specific API are, that's what MSDN is for.

Generally too I find that even just having a casual conversation about software and programming has been enough for me in the past to weed genuine candidates from BS'ers.

I too prefer this sort of direction when interviewing potential candidates.

Tell you what, as sad as it seems, I went to bed thinking about this thread last night. I was just about to shut the PC down for the night and thought I'd catch up on the evenings Coffeehouse postings and read this one. Do people really go this nasty and technical in interviews? I think I'd sooner be interigated by Jack Bauer than attend some peoples interviews in this thread

Actually, I'll go through those common question regarding OOP concepts. And then limit my question to those related to the job function.

Say that I'm hiring a Web Programmer knowing C#, it may not be so important to the interviewee whether he/she knows about IDispose/Finalization or not if our pages don't really touch them, however I'll want to make sure that know something about difference between Profile, Session and Viewstate, and of course, the events and their usage in Page Lifecycle.

If you're hiring Winform programmer for Database related programs, you'll probably want to ask them if they know anything about how to get things done in commonly used 3rd party tools like Crystal Report, as well as the ability to write SQL statements, or even stored procedures.

The ideas of best fit questions in interviews come from your currently working projects. Maybe pulling out helper functions that you think you'll able to finish in 5 minutes and ask them to implement in 15 minutes will be good enough.

andy_hanger18 wrote:

Do people really go this nasty and technical in interviews? I think I'd sooner be interigated by Jack Bauer than attend some peoples interviews in this thread

I don't remember all the details for all the .NET framework object, and I don't expect candidates to either. The reason I ask 'nasty' questions is not so much for the answer the candidate gives, but for how they react and handle a question that they don't know.
If they just answer 'I don't know', or 'I'd have to Google that', then I take that as a positive.  If they bluster and bullsh*t, then I take that as a negative.  If they ask for the correct answer then that's a gold star.

I prefer not to ask simple answer questions, but questions that could lead to a brief discussion so I can gauge the intellect of the candidate.

We use sneaky non-technical questions too:

Recently we've been interviewing for a graduate tester position.  We ask 'Where do you see yourself in three to five years time?'
If they say something like 'I don't plan that far ahead.' or 'I don't mind as long as I'm learning' then that's fine.  If they say 'Running my own software firm' or (the classic) 'I plan to become a Developer' then that's a bad sign (we're going to train them as testers and they're just intending to use us as a leg up into a different career, thus wasting our efforts).

It's a bit of a game/battle : we are trying to sell our company to the top candidates because we want good employees while the candidates are trying to sell themselves to us because they want the job.  The interview is where the interviewer and the candidates try and find the complete truth (Does the interviewer have any frustrations about the job? Does the candidate plan to stay for at least three years?  How much overtime does the interviewer really do?  Is the candidate really as smart as they appear in their CV?)

As an interviewer I try to be open, friendly, and honest, but you can't badmouth company culture/coworkers/bosses/customers/whatever in front of a candidate as it's not professional. At the same time you want the candidate to have a clear picture of what the job is like because there's no point in hiring them only to have them leave after a month when they realise the job is not what was outlined in the interview. So the interview (for me) becomes a subtle game of psychology to try and get/give the truth. Nasty technical questions are a part of that.



Herbie

evildictaitor wrote:

Even so, String.Format("this {0} is stupid", someint); is preferable because it is shorter, easier to read and easier to localize.

But Format strings are slower than simple concats because it has to parse the format string first. I wouldn't use this in a high-perf app.

W3bbo wrote:



evildictaitor wrote: Even so, String.Format("this {0} is stupid", someint); is preferable because it is shorter, easier to read and easier to localize.

But Format strings are slower than simple concats because it has to parse the format string first. I wouldn't use this in a high-perf app.

I wouldn't use .NET in a high-perf system ...


Herbie

evildictaitor wrote:


Even so, String.Format("this {0} is stupid", someint); is preferable because it is shorter, easier to read and easier to localize.

I don't know. I find "this followed by this followed by this" easier to read than "this, now remember these values, and read the first string again and replace the accolades bits with them."

The fact that it's shorter shouldn't matter. Maximum readability wins from minimum use of characters.

Localization, you have a point.

Anyone has an opinion on multi-on-one vs. one-on-one interviews? Personally, I think being interviewed by  many people is fun, but I hear it could be stressful, too.

Ion Todirel wrote:



evildictaitor wrote:  *void.

good answer, you're hired

Not really, delegates are more than just function pointers. They offer type safety and security as they always point to a method, which a *void may well not do.

Minh wrote:

Anyone has an opinion on multi-on-one vs. one-on-one interviews? Personally, I think being interviewed by  many people is fun, but I hear it could be stressful, too.

Be especially mindful not to arrange everything to be intimidating. Unless you're interviewing for a position where coping with initimidating situations is important. (Avoid the classic, interviewers on one side of a long desk, and interviewee isolated on their own little chair in front of them.)

As someone who doesn't like interviews at all, more than a couple of people could be terrifying.

Then again, fitting in with the team is critical in most situations, perhaps "interview" by testing people out in a mock-working environment. (Perhaps something like a brainstorming session with the team, see how they fit in.)

Massif wrote:



Dr Herbie wrote:  I wouldn't use .NET in a high-perf system ... Herbie

You wouldn't?

I know there's high-performance and there's high-performance but .NET performs pretty well under most conditions, and I'd opt for managed code in really all situations over unmanaged.

Besides, this guy is running a .NET application that's performing pretty nicely.

Dr Herbie wrote:



I wouldn't use .NET in a high-perf system ...

Herbie

You wouldn't?

I know there's high-performance and there's high-performance but .NET performs pretty well under most conditions, and I'd opt for managed code in nearly all situations over unmanaged.

Reason being, unmanaged code has the ability to be made fast, but it's hard to make it so (when we're talking really fast.) Whereas .NET is easy to make fast. (But the top speed is slightly lower.)

If you're opting for unmanaged you'd have to justify it to me (and if you're not profiling your code for performance you'll get shot.) Many people seem to think C++ is an optimisation step in and of itself over .NET, but the truth is that it's quite easy to make a horrendously slow C++ app if you're not careful.

However, I'm just a lackey, and not in a position to be making these decisions.

Bas wrote:



Massif wrote:  Dr Herbie wrote:  I wouldn't use .NET in a high-perf system ... Herbie You wouldn't? I know there's high-performance and there's high-performance but .NET performs pretty well under most conditions, and I'd opt for managed code in really all situations over unmanaged.

Besides, this guy is running a .NET application that's performing pretty nicely.

To me high performance is high performance: counting the cycles, unrolling loops, using your own memory management for speed, using assembly where it really matters, you know, all the optimization tricks turned up to 11.

I should point out I don't do the high performance stuff. I'm not smart enough to do it, only smart enough to understand how it can get done.


Herbie

evildictaitor wrote:



amotif wrote:  Massif wrote: why "this " + someint.ToString() + " is stupid" is a bad idea Ooh, good. Are you asking because of the use of ToString() here or because you think there's an inefficinet concat happening--because it's really not. C# 2 will use String.Concat(string,string,string) here. It's probably not any worse than using String.Format.

Even so, String.Format("this {0} is stupid", someint); is preferable because it is shorter, easier to read and easier to localize.

"Easier to read" is rather subjective, but I would suggest that

  "this " + someint + " is stupid"

is certainly shorter and easier to read than

    String.Format("this {0} is stupid", someint)

Localization is a weenie argument  but a valid point if you're hiring someone to write localizable UI code. I've written written localizable UI but haven't met many other people who have. It's certainly a different level of understanding than knowing what the compiler might do with string + string + string.

AndyC wrote:



Ion Todirel wrote:  evildictaitor wrote:  *void. good answer, you're hired

Not really, delegates are more than just function pointers. They offer type safety and security as they always point to a method, which a *void may well not do.

The type-safety is only at compile time (for non .NET languages), so actually what a delegate is is a *void.

Even in .NET it's just a typedef wrapper on a System.IntPtr.