Channel 9 Forums - Coffeehouse - Interviewing programmers

Coffeehouse - Interviewing programmers

pathfinder — Tue, 21 Aug 2007 16:15:30 GMT

I am interviewing candidates for a C#/C++ programming position and I just need some ideas for good technical questions to ask to guage someones experience. I am mostly concerned with C# experience. Does anyone have some good ideas on questions I should ask?

Questions involving using Sockets and Threading would be helpful too.

They don't have to be trick questions, but one I thought of was "Name a class that does not have the .ToString() method".

Coffeehouse - Interviewing programmers

ScanIAm — Tue, 21 Aug 2007 17:28:02 GMT

pathfinder wrote:

I am interviewing candidates for a C#/C++ programming position and I just need some ideas for good technical questions to ask to guage someones experience. I am mostly concerned with C# experience. Does anyone have some good ideas on questions I should ask?

Questions involving using Sockets and Threading would be helpful too.

They don't have to be trick questions, but one I thought of was "Name a class that does not have the .ToString() method".

Are you going to not hire someone if they don't know which class doesn't have a .ToString() method?

Hell, I don't know this off the top of my head, and I'm willing to bet I've got a pretty decent knowledge of C#.

Mostly because it isn't pertinent to the skillset.

Coffeehouse - Interviewing programmers

evildictaitor — Tue, 21 Aug 2007 17:33:00 GMT

pathfinder wrote:

I am interviewing candidates for a C#/C++ programming position and I just need some ideas for good technical questions to ask to guage someones experience. I am mostly concerned with C# experience. Does anyone have some good ideas on questions I should ask?

Questions involving using Sockets and Threading would be helpful too.

They don't have to be trick questions, but one I thought of was "Name a class that does not have the .ToString() method".

Is there one? All classes extend System.Object which provides the .ToString() method.

Coffeehouse - Interviewing programmers

Martin Carolan — Tue, 21 Aug 2007 17:36:35 GMT

As he said in his message, there isn't one, System.Object has it, so they all have it

Coffeehouse - Interviewing programmers

Herbie Smith — Tue, 21 Aug 2007 17:38:36 GMT

pathfinder wrote:

I am interviewing candidates for a C#/C++ programming position and I just need some ideas for good technical questions to ask to guage someones experience. I am mostly concerned with C# experience. Does anyone have some good ideas on questions I should ask?

Questions involving using Sockets and Threading would be helpful too.

They don't have to be trick questions, but one I thought of was "Name a class that does not have the .ToString() method".

"What is polymorphism and why is is useful?"

I was shocked at the number of candidates that couldn't separate polymorphism from class inheritance and I don't think I've met one yet who could explain why it was useful (other than inheriting functionality, which is not the correct answer).

Also, for C#, ask them to explain garbage collection.

Herbie

Coffeehouse - Interviewing programmers

Ion Todirel — Tue, 21 Aug 2007 17:42:05 GMT

well, there are so many questions you may ask, a google search will guide you

Coffeehouse - Interviewing programmers

Ion Todirel — Tue, 21 Aug 2007 17:43:44 GMT

Dr Herbie wrote:

"What is polymorphism and why is is useful?"

I was shocked at the number of candidates that couldn't separate polymorphism from class inheritance and I don't think I've met one yet who could explain why it was useful (other than inheriting functionality, which is not the correct answer).

Also, for C#, ask them to explain garbage collection.

Herbie

good questions, also you may ask when Dispose method is called

Coffeehouse - Interviewing programmers

W3bbo — Tue, 21 Aug 2007 17:43:54 GMT

Martin Carolan wrote:

As he said in his message, there isn't one, System.Object has it, so they all have it

Not necessarily.

If you compile your project with the /nostdlib you can define your own classes which don't inherit from System.Object (it's how you compile mscorlib.dll btw).

Dr Herbie wrote:

"What is polymorphism and why is is useful?"

I was shocked at the number of candidates that couldn't separate polymorphism from class inheritance and I don't think I've met one yet who could explain why it was useful (other than inheriting functionality, which is not the correct answer).

It's useful because it enables code-reuse and overriding older/irrelevant methods.

But they're not so much separate as they are dependent. Polymorphism depends on inheritance. That's why VB6 isn't a true OOP language.

Dr Herbie wrote:

Also, for C#, ask them to explain garbage collection.

"See Sharp Garbage Collection you say? Well I know the city santiation guys use thick gloves when dealing with the bins in the public loos"

Coffeehouse - Interviewing programmers

W3bbo — Tue, 21 Aug 2007 17:45:08 GMT

Duplicate post of evilness.

Coffeehouse - Interviewing programmers

pathfinder — Tue, 21 Aug 2007 17:47:48 GMT

ScanIAm wrote:

Are you going to not hire someone if they don't know which class doesn't have a .ToString() method?

If I had a candidate that could answer the question and one that couldn't and everything else was equal, then probably yes.

Coffeehouse - Interviewing programmers

pathfinder — Tue, 21 Aug 2007 17:52:06 GMT

W3bbo wrote:

Martin Carolan wrote:
As he said in his message, there isn't one, System.Object has it, so they all have it

Not necessarily.

If you compile your project with the /nostdlib you can define your own classes which don't inherit from System.Object (it's how you compile mscorlib.dll btw).

Good point. What about P/Invoke? I like the suggestion about GC. These are good .NET questions, how about any questions that are specific to C# language structure?

Coffeehouse - Interviewing programmers

mstefan — Tue, 21 Aug 2007 17:52:23 GMT

Dr Herbie wrote:

Also, for C#, ask them to explain garbage collection.

That's easy. Every Wednesday morning, this large truck with robotic arms roams the neighborhood, lifts up our trash bins (which we've placed at the curb on the previous evening) and deposits the contents into the back of the truck. Sometimes, it must shake the bin a few times to extract all of the refuse. It then places the bin back down on the ground, near its original position at the curb. Thusly, the garbage has been collected.

Am I hired?

Coffeehouse - Interviewing programmers

Massif — Tue, 21 Aug 2007 17:58:32 GMT

As I've been interviewed recently you'd think I'd be able to help, but I got asked a bunch of really annoying "what does X keyword mean" questions.

I suggest asking them about C# strings, (like why "this " + someint.ToString() + " is stupid" is a bad idea)

Also you could ask them how they'd marshall a pointer by p/invoke. That'd be tricky methinks.

But definitely ask them about garbage collection, and if they know about generations and what is the best amount of time to retain objects etc...)

But mainly I'd ask them about OO principles, design patterns and stuff like that. Picking up C# is a week or so's work for a programmer who understands the principles.

Coffeehouse - Interviewing programmers

bbrewder — Tue, 21 Aug 2007 18:09:24 GMT

pathfinder wrote:

I am interviewing candidates for a C#/C++ programming position and I just need some ideas for good technical questions to ask to guage someones experience. I am mostly concerned with C# experience. Does anyone have some good ideas on questions I should ask?

Questions involving using Sockets and Threading would be helpful too.

They don't have to be trick questions, but one I thought of was "Name a class that does not have the .ToString() method".

Check out this blog entry on Coding Horror: Why Can't Programmers.. Program?. It outlines some basic questions that have proven remarkably useful at weeding out the truly incompetent.

You should just stick to very basic questions when it comes to programming, such as write a for loop. If you need somebody that can design a multi-process communication system, ask them basic questions about remoting, such as, pick your favorite remoting technique and establish a connection. For threading, ask them to establish a thread.

I don't think that more complicated questions will prove anything one way or another (not everybody performs at their best during an interview).

Obviously these questions won't tell you if the person is truly competent or not, but they will tell you if they are incompetent. To judge further, just ask them about their experience with the things you are interested in. Try to get them to go deep and explain any complex/tricky parts as best they can (but don't make them write the code).

Don't bother asking trivial or very technical questions. Trivia might be fun, but it's not a very good indicator of competence.

Coffeehouse - Interviewing programmers

W3bbo — Tue, 21 Aug 2007 18:11:08 GMT

bbrewder wrote:

For threading, ask them to establish a thread.

What if they give you an example back which just uses BackgroundWorker.

Is that a partial-credit?

Coffeehouse - Interviewing programmers

Yggdrasil — Tue, 21 Aug 2007 18:13:35 GMT

Some questions I'ved asked, to get a feel for how much the person understands the technology he's using:

1) What are the primary differences between developing in a managed environment (C#, Java, etc) and an unmanaged one (C/C++ etc).

Some people stammer and go all glassy eyed. ("Because it's newer"). Some have some half-remembered or non-specific answers. ("Because it's safer" or "Because we get to take advantage of the .NET framework"). With others, you can see straight away that they have experience with unmanaged code and the advantages of managed code - less worries about memory management, having runtime checks to prevent access violations and overflows, and so forth.

2) Strings. Ask people how strings are implemented in .NET, why we need the StringBuilder class and, as an extra bonus, what all these interned immutable strings are good for.

3) XML. Ask about the different ways of working with XML files in .NET. Assuming they pass the first stage, ask them when would an XmlDocument be appropriate and when an XmlReader.

All this assumes that these are even in your area of interest. Don't bother asking them about things that they don't need in their daily work.

Coffeehouse - Interviewing programmers

Herbie Smith — Tue, 21 Aug 2007 19:32:56 GMT

W3bbo wrote:

Dr Herbie wrote:
"What is polymorphism and why is is useful?"

I was shocked at the number of candidates that couldn't separate polymorphism from class inheritance and I don't think I've met one yet who could explain why it was useful (other than inheriting functionality, which is not the correct answer).

It's useful because it enables code-reuse and overriding older/irrelevant methods.

But they're not so much separate as they are dependent. Polymorphism depends on inheritance. That's why VB6 isn't a true OOP language.

OK, firstly polymorphism has nothing to do with code-reuse. That's where you're confusing class inheritance with polymorphism (although you're right, polymorphism does depend on inheritance). Polymorphism can also be done through pure interface inheritance.
Polymorphism is where different classes can be made to appear the same through casting to a base class/interface. This allows all the references to be treated the same, thereby simplifying code that uses those objects.

The classic example is a vector drawing program there all the shapes derive from the base 'BaseShape'. The specific instances of shapes that the user creates (Like CircleShape, TriangleShape and RectangleShape) are stored in a collection of BaseShape instances and the picture is drawn by iterating through all the BaseShape instances and caling the 'Draw' method. The main program has no knowledge of which shape it is drawing and it treats them all the same.
The contents of the 'BaseShape' class are irrelevant to the technique of polymorphism; BaseShape may containa lot of shared code, or it may be an interface with no shared code. Polymorphism and code-reuse are two separate aspects of inheritance.

I had been doing OOP for nearly 10 years before I realised this distinction.

The next question would be:
Other than inheritance, how else can you re-use code in an OOP fashion?

Herbie

Coffeehouse - Interviewing programmers

Maddus Mattus — Tue, 21 Aug 2007 19:46:39 GMT

When testing knowlidge you should ask questions like:

"How would you do ...?"

When testing experience you should ask questions like:

"Can you give me a concrete example how you dealt with ... in project .... ?"

If the candidate answers in plural form, "we did this", "we did that", ask him what his/her contribution was.

I tend to ask questions like:
"Can you explain to me how events work?"
"What is a delegate?"

Coffeehouse - Interviewing programmers

thumbtacks2 — Tue, 21 Aug 2007 19:47:56 GMT

Dr Herbie wrote:

W3bbo wrote:

Dr Herbie wrote:
"What is polymorphism and why is is useful?"

I was shocked at the number of candidates that couldn't separate polymorphism from class inheritance and I don't think I've met one yet who could explain why it was useful (other than inheriting functionality, which is not the correct answer).

It's useful because it enables code-reuse and overriding older/irrelevant methods.

But they're not so much separate as they are dependent. Polymorphism depends on inheritance. That's why VB6 isn't a true OOP language.

OK, firstly polymorphism has nothing to do with code-reuse. That's where you're confusing class inheritance with polymorphism (although you're right, polymorphism does depend on inheritance). Polymorphism can also be done through pure interface inheritance.
Polymorphism is where different classes can be made to appear the same through casting to a base class/interface. This allows all the references to be treated the same, thereby simplifying code that uses those objects.

The classic example is a vector drawing program there all the shapes derive from the base 'BaseShape'. The specific instances of shapes that the user creates (Like CircleShape, TriangleShape and RectangleShape) are stored in a collection of BaseShape instances and the picture is drawn by iterating through all the BaseShape instances and caling the 'Draw' method. The main program has no knowledge of which shape it is drawing and it treats them all the same.
The contents of the 'BaseShape' class are irrelevant to the technique of polymorphism; BaseShape may containa lot of shared code, or it may be an interface with no shared code. Polymorphism and code-reuse are two separate aspects of inheritance.

I had been doing OOP for nearly 10 years before I realised this distinction.

For those of us out there who are self-taught programmers, this is a definite hurdle. For me the real difficulty was not the concepts behind polymorphism, but rather the lack of decent textbooks describing the concept. I can't count the number of textbooks that did not use any type of visual diagram when explaining these concepts...for me it would have been so much easier.

Coffeehouse - Interviewing programmers

Charles — Tue, 21 Aug 2007 19:58:48 GMT

What does the keyword virtual mean? When would you use it?

When would you use an abstract class over using an interface?

What can you do to ensure that your objects are properly disposed of by GC?

What happens when you call GC.Collect()? Why would you call it? What's the cost? What happens?

Implement ToString()

C

Coffeehouse - Interviewing programmers

bgmacaw — Tue, 21 Aug 2007 20:01:36 GMT

My approach

Start off by asking a few softball programming trivia questions that anyone with any experience should be able to answer. If they fail these simple questions, it's obviously time to say "Next!".

Then follow up by asking them to describe the project they're currently working on and some of the specific techniques they're using. Ask them specific, open ended, questions about it like, "Why did you use generic List rather than an array?" or "How did you decide that XML serialization was the best approach?" The idea is to get a taste of how they organize their thoughts on familiar ground.

The last part, if they've done well so far, is to present them with a sample problem that fits within your domain. For example, let's say you load a lot of oddly formatted raw data files into database tables. Ask them how they would approach the problem and have them pseudo-code out their solution. This will give you an idea of how they think when presented with something new.

You can also ask off-beat thinking questions like "Everybody knows why manhole covers are round but why are septic tank covers square?"

Coffeehouse - Interviewing programmers

Christian Liensberger — Tue, 21 Aug 2007 20:24:22 GMT

Mine does not have one

public class LittleguruFoo
{
    public new bool ToString
    {
        get { throw new NotImplementedException("I don't have a ToString method!"); }
    }
}

Hehe

Foo f = new Foo();
f.ToString(); // Compiler error.

object f2 = new Foo();
f2.ToString(); // Now I have one again. Holy cow, I can't escape.

Coffeehouse - Interviewing programmers

evildictaitor — Tue, 21 Aug 2007 20:32:16 GMT

pathfinder wrote:

Good point. What about P/Invoke? I like the suggestion about GC. These are good .NET questions, how about any questions that are specific to C# language structure?

When you use P/Invoke the result is always pseudo-typed into the correct struct / primative.

E.g. if a P/Invoke signature returns an int, you get something which can be conceptually thought of as a System.Int32 which extends System.Object.

Maddus Mattus wrote:

"What is a delegate?"

*void.

Coffeehouse - Interviewing programmers

evildictaitor — Tue, 21 Aug 2007 20:34:38 GMT

Double posty post post.

Coffeehouse - Interviewing programmers

Maddus Mattus — Tue, 21 Aug 2007 21:09:58 GMT

evildictaitor wrote:

Maddus Mattus wrote:

"What is a delegate?"

*void.

I'm hoping that's a c++ question,...

Because I would fail miserably

Coffeehouse - Interviewing programmers

JeremyJ — Tue, 21 Aug 2007 21:22:11 GMT

Maddus Mattus wrote:

evildictaitor wrote:

Maddus Mattus wrote:

"What is a delegate?"

*void.

I'm hoping that's a c++ question,...

Because I would fail miserably

I think what he is getting as is that at the root of it, a delegate is a function pointer.

Coffeehouse - Interviewing programmers

blowdart — Tue, 21 Aug 2007 21:24:13 GMT

Ion Todirel wrote:

Dr Herbie wrote:
"What is polymorphism and why is is useful?"

I was shocked at the number of candidates that couldn't separate polymorphism from class inheritance and I don't think I've met one yet who could explain why it was useful (other than inheriting functionality, which is not the correct answer).

Also, for C#, ask them to explain garbage collection.

Herbie

good questions, also you may ask when Dispose method is called

And if that supports deterministic finalisation. Then ask about the Dispose pattern. (which is what i do, and did today)

Coffeehouse - Interviewing programmers

blowdart — Tue, 21 Aug 2007 21:26:05 GMT

Charles wrote:

What does the keyword virtual mean? When would you use it?

How does new differ from override; best illustrated by a piece of sample code; where each class has a Message method printing the class name; then declare all 3 classes as the base type.

In the last 3 months only 1 person has gotten the final output right.

Coffeehouse - Interviewing programmers

W3bbo — Tue, 21 Aug 2007 21:45:09 GMT

blowdart wrote:

Charles wrote:
What does the keyword virtual mean? When would you use it?

How does new differ from override; best illustrated by a piece of sample code; where each class has a Message method printing the class name; then declare all 3 classes as the base type.

In the last 3 months only 1 person has gotten the final output right.

Well you haven't phrased your question properly. Write it out fully and I'll give it a stab.

Coffeehouse - Interviewing programmers

pathfinder — Tue, 21 Aug 2007 21:49:15 GMT

Dr Herbie wrote:

OK, firstly polymorphism has nothing to do with code-reuse. That's where you're confusing class inheritance with polymorphism (although you're right, polymorphism does depend on inheritance). Polymorphism can also be done through pure interface inheritance.
Polymorphism is where different classes can be made to appear the same through casting to a base class/interface. This allows all the references to be treated the same, thereby simplifying code that uses those objects.

The classic example is a vector drawing program there all the shapes derive from the base 'BaseShape'. The specific instances of shapes that the user creates (Like CircleShape, TriangleShape and RectangleShape) are stored in a collection of BaseShape instances and the picture is drawn by iterating through all the BaseShape instances and caling the 'Draw' method. The main program has no knowledge of which shape it is drawing and it treats them all the same.
The contents of the 'BaseShape' class are irrelevant to the technique of polymorphism; BaseShape may containa lot of shared code, or it may be an interface with no shared code. Polymorphism and code-reuse are two separate aspects of inheritance.

I had been doing OOP for nearly 10 years before I realised this distinction.

The next question would be:
Other than inheritance, how else can you re-use code in an OOP fashion?

Herbie

Good points!
We use polymorphism when we are passing objects between the different tiers in our application. Any object that is exposed on the web tier and is passed back to the business tier MUST inherit off of an interface. The business tier and data access tier MUST use the same interface. In this case polymorphism is not used for code reuse but instead to keep our heads on straight. Especially since there are different programmers working in the different tiers.

Coffeehouse - Interviewing programmers

blowdart — Tue, 21 Aug 2007 21:52:45 GMT

W3bbo wrote:

Well you haven't phrased your question properly. Write it out fully and I'll give it a stab.

I'll do it in the morning; if someone else hasn't done it.

Basically in BaseClass have a vitual method Message which prints "BaseClass". In SubClass1, derived from BaseClass override that method and print SubClass1, in SubClass2 new the method and print SubClass2. Now declare 3 variables of class BaseClass, one an instance of BaseClass, one an instance of SubClass1, one an instance of SubClass2. Call Message on each. What gets printed.

Coffeehouse - Interviewing programmers

blowdart — Tue, 21 Aug 2007 21:55:25 GMT

pathfinder wrote:

In this case polymorphism is not used for code reuse but instead to keep our heads on straight. Especially since there are different programmers working in the different tiers.

Pah, shift to late bound duck typed objects and remove that dependancy on a base object

Coffeehouse - Interviewing programmers

Ion Todirel — Tue, 21 Aug 2007 22:48:02 GMT

W3bbo wrote:

blowdart wrote:

Charles wrote:
What does the keyword virtual mean? When would you use it?

How does new differ from override; best illustrated by a piece of sample code; where each class has a Message method printing the class name; then declare all 3 classes as the base type.

In the last 3 months only 1 person has gotten the final output right.

Well you haven't phrased your question properly. Write it out fully and I'll give it a stab.

i don't know, sounds very clear to me...

Coffeehouse - Interviewing programmers

JohnnyAwesome — Tue, 21 Aug 2007 23:17:20 GMT

I like questions that let the candidate and interviewer to run with them. It puts people at ease and it only gets as complicated as you want/need it to. So, in their basic form if the candidate can't even answer it to begin with then you do not have to go farther. But as they progress take them down a path and let the conversation kind of build on itself.

You could white board or on paper (which I hate personally) offer several items and start simple and ask to see them related programmatically. Just a half-dozen objects should be good. Just make sure they are different. So maybe some would be properties like type or color and some are obviously extended from other base classes to anyone who has actually written code. Make sure it's something simple and could go different directions:

1. Helicopter
2. Bird
3. Operator
4. Dump Truck
5. Seagull
6. Green

If they can't see a seagull and extending bird its over. Maybe they pose a question "Is an operator a person? Can they drive and fly?" Whatever. You should be looking intelligence and problem solving abilities. Posing the right questions and then constucting the answers in C#.

You could draw out a scenario all the way to building a small app on a white board. What methods would these objects have? How would they work? When?

Coffeehouse - Interviewing programmers

Mark Brown — Wed, 22 Aug 2007 00:25:12 GMT

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.

Coffeehouse - Interviewing programmers

amotif — Wed, 22 Aug 2007 01:43:31 GMT

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.

Coffeehouse - Interviewing programmers

amotif — Wed, 22 Aug 2007 01:47:23 GMT

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?

Coffeehouse - Interviewing programmers

evildictaitor — Wed, 22 Aug 2007 02:37:07 GMT

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.

Coffeehouse - Interviewing programmers

evildictaitor — Wed, 22 Aug 2007 02:39:49 GMT

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.

Coffeehouse - Interviewing programmers

andy_hanger18 — Wed, 22 Aug 2007 07:08:47 GMT

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

Coffeehouse - Interviewing programmers

cheong — Wed, 22 Aug 2007 07:58:29 GMT

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.

Coffeehouse - Interviewing programmers

Herbie Smith — Wed, 22 Aug 2007 08:16:21 GMT

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

Coffeehouse - Interviewing programmers

Ion Todirel — Wed, 22 Aug 2007 10:52:31 GMT

evildictaitor wrote:

Maddus Mattus wrote:

"What is a delegate?"

*void.

good answer, you're hired

Coffeehouse - Interviewing programmers

W3bbo — Wed, 22 Aug 2007 11:09:33 GMT

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.

Coffeehouse - Interviewing programmers

Herbie Smith — Wed, 22 Aug 2007 11:24:14 GMT

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

Coffeehouse - Interviewing programmers

Bas — Wed, 22 Aug 2007 11:24:33 GMT

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.

Coffeehouse - Interviewing programmers

Minh — Wed, 22 Aug 2007 12:53:20 GMT

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.

Coffeehouse - Interviewing programmers

AndyC — Wed, 22 Aug 2007 13:01:39 GMT

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.

Coffeehouse - Interviewing programmers

Massif — Wed, 22 Aug 2007 13:12:11 GMT

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.)

Coffeehouse - Interviewing programmers

Bas — Wed, 22 Aug 2007 13:42:57 GMT

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.

Coffeehouse - Interviewing programmers

Massif — Wed, 22 Aug 2007 13:43:46 GMT

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.

Coffeehouse - Interviewing programmers

Herbie Smith — Wed, 22 Aug 2007 14:01:53 GMT

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

Coffeehouse - Interviewing programmers

amotif — Wed, 22 Aug 2007 14:37:41 GMT

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.

Coffeehouse - Interviewing programmers

evildictaitor — Wed, 22 Aug 2007 14:39:57 GMT

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.

Coffeehouse - Interviewing programmers

evildictaitor — Wed, 22 Aug 2007 14:41:24 GMT

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.

One has to ask why you are doing string formatting operations in a critical loop. Not that they arn't great and all, but when you get to high speed optimisations, you switch away from a string and go to a char[] because then it becomes mutable.

Coffeehouse - Interviewing programmers

amotif — Wed, 22 Aug 2007 14:41:51 GMT

andy_hanger18 wrote:

Do people really go this nasty and technical in interviews?

By "nasty" do you mean deep probing highly technical questions?

Then, yes, but largely it depends on whether the position is suited for a new grad's knowledge or a seasoned pro's experience.

Coffeehouse - Interviewing programmers

blowdart — Wed, 22 Aug 2007 14:51:15 GMT

amotif wrote:

andy_hanger18 wrote:
Do people really go this nasty and technical in interviews?

By "nasty" do you mean deep probing highly technical questions?

Then, yes, but largely it depends on whether the position is suited for a new grad's knowledge or a seasoned pro's experience.

I interviewed 9 people in the last two weeks. One didn't even know what boxing was despite his claim of 5 years .net. Frankly if you're going to lie then my questions may well be considered nasty.

Two of the candidates fed back that the interview was challenging and one of those said he found it fun. They got offers.

Coffeehouse - Interviewing programmers

Lee Dale — Wed, 22 Aug 2007 14:58:22 GMT

One of the best interviews I had was for a financial company who wanted a ASP.Net developer.

I had two senior guys grilling me for over an hour. They were asking me some pretty hard questions and asking me to come up with soluti9ons for business problems for which I was at the most part answering quite well.

I came out feeling like i'd been taken down a peg and it helped me to realise where my knowledge gaps were.

I didn't get the role, they said I knew my stuff but they were looking for someone with maybe 1 or 2 more years experience at a senior level

Anyway is was a great learning experience and still the most challenging interview I've ever had.

Coffeehouse - Interviewing programmers

lorad — Wed, 22 Aug 2007 17:12:32 GMT

In my past experience I have found that a short programming problem that I gave to candidates before they came in was the best thing I could do.

Some people just don't interview well, they forget what polymorphism is but they use it and know when to use it. Or they forget what ABC means, or they don't know what methodology they use in strict naming terms.

Lots of good developers don't bother to memorize definitions (at least ones I have worked with) and alot of crapy ones do.

I have never hired a person that could not do the job I wanted after I started giving out the small project. I have had people refuse to do it (It took me 2 hours to do it from scratch, so I figure it should not take more than 6 hours worst possible case), sure that may seem like a lot, but I don't want someone that does not like to code at home (not necessarily work but for fun at least a little).

The basic outline is to read and XML file with some set of data. Create 2 classes that have an obvious hierarchy. Write and use a simple web service to do calculations. Write a simple UI to query a small set of data in a very limited and controlled way.

I don't even care how you do it, if you do it with no inheritance etc. but you better be able to tell my why not. Then the whole interview is mostly about the application, and that spawns more questions and usually a good dialog.

Coffeehouse - Interviewing programmers

Minh — Wed, 22 Aug 2007 17:13:09 GMT

amotif wrote:

andy_hanger18 wrote:
Do people really go this nasty and technical in interviews?

By "nasty" do you mean deep probing highly technical questions?

Then, yes, but largely it depends on whether the position is suited for a new grad's knowledge or a seasoned pro's experience.

No, he meant obscure question like:

- Why does this statement not give me the right time? DateTime.Now.ToString("hh:MM:ss")

that's design more to show the interviewer's smugness than test the interviewee's ability to work

Coffeehouse - Interviewing programmers

amotif — Wed, 22 Aug 2007 17:53:56 GMT

Minh wrote:

No, he meant obscure question like:

- Why does this statement not give me the right time? DateTime.Now.ToString("hh:MM:ss")

that's design more to show the interviewer's smugness than test the interviewee's ability to work

Hmm, no clue. But I do notice that the minutes, which are incorrect, happen to be the current month... 10:08:21

What really drives me nuts is interviewers who try to show how smart they. Far worse than interviewers who ramble on about the cool stuff they work on when it has nothing to do with what I would be working on.

Coffeehouse - Interviewing programmers

Minh — Wed, 22 Aug 2007 18:00:11 GMT

amotif wrote:

Hmm, no clue. But I do notice that the minutes, which are incorrect, happen to be the current month... 10:08:21

That's correct! It's because there's a freakin' googlie-eyed face in the freakin' format string!

DateTime.Now.ToString("hh:MM:ss")

amotif wrote:

What really drives me nuts is interviewers who try to show how smart they. Far worse than interviewers who ramble on about the cool stuff they work on when it has nothing to do with what I would be working on.

Yep! Interviewing people is a head trip. I don't know how Blowdart does it!

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 18:05:48 GMT

Dr Herbie wrote:

OK, firstly polymorphism has nothing to do with code-reuse. That's where you're confusing class inheritance with polymorphism (although you're right, polymorphism does depend on inheritance).

No, that's wrong. Value based dispatch depends on inheritance, polymorphism does not. Polymorphism does have something to do with code reuse preciesly because you can write a function that works on values of multiple types.

Here's a polymorhic method that doesn't depend on inheritance in the least:

static T pickFirst(T a, T b)
{
return a;
}

Normally this isn't very useful, you'd have to constrain the template parameter somehow (and obviously you'd do that using interfaces, and you might almost be able to claim that interfaces depend on inheritance, but that would also be wrong - consider something like Haskell that has no inheritance but manages to have a type hierarchy and polymorphism anyway; by simply using type-based dispatch rather than value-based dispatch). Consider something like

static uint length( MyList list )
{
return list.IsEmpty ? 0 : 1 + length( list.tail);
}

This is a much more useful function that does not depend on inheritance either, and would still be exceedingly polymorphic in that it can work on lists of any element type (in this case an immutable singly linked list).

So yeah, inheritance is one way of doing subtyping, but not the only way of doing polymorphism.

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 18:18:07 GMT

evildictaitor wrote:

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.

NO! A delegate is a tiny object that captures any variables in scope at the definition (that are also used in the definition). It's NOT anywhere close to a function pointer, it's more like a quick one-off class with a single method.

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 18:22:20 GMT

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.

And above all, they capture variables (proper lexical closures, in other words)! Comparing with function pointer is useful if and only if the next sentence out of your mouth is "but they're really completely different".

Coffeehouse - Interviewing programmers

amotif — Wed, 22 Aug 2007 18:24:36 GMT

Minh wrote:

Yep! Interviewing people is a head trip. I don't know how Blowdart does it!

I forked a new thread on interviewers: Bad Interviewer, No Cookie

Be gentle.

Coffeehouse - Interviewing programmers

blowdart — Wed, 22 Aug 2007 18:32:05 GMT

Minh wrote:

Yep! Interviewing people is a head trip. I don't know how Blowdart does it!

Actually I usually hate it because people are generally lying gits about their experience. It's almost worth it to find someone decent, but the muppets just depress me.

Coffeehouse - Interviewing programmers

andy_hanger18 — Wed, 22 Aug 2007 18:32:33 GMT

Minh wrote:

amotif wrote:

andy_hanger18 wrote:
Do people really go this nasty and technical in interviews?

By "nasty" do you mean deep probing highly technical questions?

Then, yes, but largely it depends on whether the position is suited for a new grad's knowledge or a seasoned pro's experience.

No, he meant obscure question like:

- Why does this statement not give me the right time? DateTime.Now.ToString("hh:MMs")

that's design more to show the interviewer's smugness than test the interviewee's ability to work

That saved me replying Sorry, it is what I was trying to say. I just meant nasty in a loose term.

Coffeehouse - Interviewing programmers

fuzzylintman — Wed, 22 Aug 2007 18:36:55 GMT

Regarding naming a class without ToString, what about the 'Math' class (or any purely static class)?

-mdb

Coffeehouse - Interviewing programmers

Herbie Smith — Wed, 22 Aug 2007 18:52:12 GMT

sylvan wrote:

Dr Herbie wrote:
OK, firstly polymorphism has nothing to do with code-reuse. That's where you're confusing class inheritance with polymorphism (although you're right, polymorphism does depend on inheritance).

No, that's wrong. Value based dispatch depends on inheritance, polymorphism does not. Polymorphism does have something to do with code reuse preciesly because you can write a function that works on values of multiple types.

Here's a polymorhic method that doesn't depend on inheritance in the least:

static T pickFirst(T a, T b)
{
return a;
}

Normally this isn't very useful, you'd have to constrain the template parameter somehow (and obviously you'd do that using interfaces, and you might almost be able to claim that interfaces depend on inheritance, but that would also be wrong - consider something like Haskell that has no inheritance but manages to have a type hierarchy and polymorphism anyway; by simply using type-based dispatch rather than value-based dispatch). Consider something like

static uint length( MyList list )
{
return list.IsEmpty ? 0 : 1 + length( list.tail);
}

This is a much more useful function that does not depend on inheritance either, and would still be exceedingly polymorphic in that it can work on lists of any element type (in this case an immutable singly linked list).

So yeah, inheritance is one way of doing subtyping, but not the only way of doing polymorphism.

OK, to qualify I should have said OOP polymorphism, not type polymorphism. And I still say OOP polymorphism is nothing to do with code reuse (because you can use interface or pure abstract classes as the polymorphic base and by definition these contain no logic).

But as I stated, most (of the dozen or do) candidates that I've interviewed over the last couple of years for C# development positions couldn't explain either version of polymorphism.

Herbie

Coffeehouse - Interviewing programmers

evildictaitor — Wed, 22 Aug 2007 20:25:14 GMT

sylvan wrote:

evildictaitor wrote:

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.

NO! A delegate is a tiny object that captures any variables in scope at the definition (that are also used in the definition). It's NOT anywhere close to a function pointer, it's more like a quick one-off class with a single method.

In ASM a delegate is any memory length of n bits that is addressable
In C a delegate is a size_t, which is an int or long or long long depending on the processor size.
In C++ a delegate is not significantly changed from C, but it is type-checked at compile time.
In C# a delegate is a C++ function pointer which is (and I quote)
Delegates are roughly similar to function pointers in C++; however, delegates are type-safe and secure.

C# encapsulates the delegate as follows:

System.Delegate {
System.Reflection.MethodBase _methodBase;
int _methodPtr;
int _methodPtrAux;
object _methodTarget
}

When invoked statically the _methodPtr is the *void which fully describes the function. When invoked via reflection, the _methodBase describes a reflection-safe method of invokation. The methodTarget is required for instance functions which are passed as the last parameter to an instance call (OOP functions arn't actually OOP when they are compiled).

A C# delegate invokation in CIL involves pushing the arguments of the delegate onto the stack, followed by asking the System.Delegate to invoke, which optionally pushes the target to the stack (it doesn't if the delegate is static) and then CIL-calls the methodptr, which is *void.

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 21:48:58 GMT

evildictaitor wrote:

In ASM a delegate is any memory length of n bits that is addressable
In C a delegate is a size_t, which is an int or long or long long depending on the processor size.
In C++ a delegate is not significantly changed from C, but it is type-checked at compile time.
In C# a delegate is a C++ function pointer which is (and I quote)
Delegates are roughly similar to function pointers in C++; however, delegates are type-safe and secure.

You can do the same trick with, for example, "a class" ("in ASM a class is a slab of memory".. etc.), doesn't make it true. A delegate, which is a C# concept, is only very superficially similar to a function pointer, but is really nothing like it. Like I explained, a delegate is a lexical closure, which is pretty isomorphic to classes (you can model one with the other). A function pointer is just a way of doing an indirect function call. Very, very different.

The fact that delegates are also type safe etc. is nice and all, but that's not the key difference.

Coffeehouse - Interviewing programmers

evildictaitor — Wed, 22 Aug 2007 22:40:52 GMT

sylvan wrote:

evildictaitor wrote:

In ASM a delegate is any memory length of n bits that is addressable
In C a delegate is a size_t, which is an int or long or long long depending on the processor size.
In C++ a delegate is not significantly changed from C, but it is type-checked at compile time.
In C# a delegate is a C++ function pointer which is (and I quote)
Delegates are roughly similar to function pointers in C++; however, delegates are type-safe and secure.

You can do the same trick with, for example, "a class" ("in ASM a class is a slab of memory".. etc.), doesn't make it true. A delegate, which is a C# concept, is only very superficially similar to a function pointer, but is really nothing like it. Like I explained, a delegate is a lexical closure, which is pretty isomorphic to classes (you can model one with the other). A function pointer is just a way of doing an indirect function call. Very, very different.

The fact that delegates are also type safe etc. is nice and all, but that's not the key difference.

Well, everything is a slab of memory. The point is that in ASM a delegate is a single number that has a number of bits equivilent to the processor architecture.

Coffeehouse - Interviewing programmers

jimMarriott — Thu, 23 Aug 2007 13:25:21 GMT

Wow! shouting 'NO' at someone's explanation of something is pretty lame - but to then go on and impose your misunderstanding of the difference between the System.Delegate class and the C# compiler generated class allowing for closures as fact is - frankly- embarassing for you. Bless. You should download Reflector it will help you avoid these kind of situations in future.

Coffeehouse - Interviewing programmers

jimMarriott — Thu, 23 Aug 2007 13:26:25 GMT

That's to Sylvan BTW...

Coffeehouse - Interviewing programmers

blowdart — Thu, 23 Aug 2007 13:30:54 GMT

Oh yea one funny thing this week. The guy I was interviewing recognised the questions I'd taken from Scott Hanselman's interview questions blog posts.

Yes he stumbled on some of them (why can't people explain the difference between a thread and a process?) but the fact that he recognised the source was a big bonus point in his direction.

Coffeehouse - Interviewing programmers

Herbie Smith — Thu, 23 Aug 2007 13:37:16 GMT

blowdart wrote:

Oh yea one funny thing this week. The guy I was interviewing recognised the questions I'd taken from Scott Hanselman's interview questions blog posts.

Yes he stumbled on some of them (why can't people explain the difference between a thread and a process?) but the fact that he recognised the source was a big bonus point in his direction.

Assuming he would want to work for someone who blatantly plagarises other peoples interview questions

Herbie

Coffeehouse - Interviewing programmers

Sven Groot — Thu, 23 Aug 2007 13:49:59 GMT

blowdart wrote:

why can't people explain the difference between a thread and a process?

Maybe they come from a Unix background?

Coffeehouse - Interviewing programmers

Wil — Thu, 23 Aug 2007 22:06:35 GMT

"Under what circumstances would you, or would you not, use (A) static polymorphism, (B) dynamic polymorphism, and (C) the Barton-Nackman trick?" Then, "How many different ways is the keyword 'static' overloaded - and why???"

Coffeehouse - Interviewing programmers

blowdart — Thu, 23 Aug 2007 22:08:25 GMT

Wil wrote:

"Under what circumstances would you, or would you not, use (A) static polymorphism, (B) dynamic polymorphism, and (C) the Barton-Nackman trick?" Then, "How many different ways is the keyword 'static' overloaded - and why???"

And why are you talking about C++ in .net interview situation?