Interviewing programmers | The Coffeehouse

Massif
aim stupidly high, expect to fail often.

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.

Dr Herbie
Horses for courses

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

amotif
No Silver Bullet

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 Smiley

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.

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

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.

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

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.

amotif
No Silver Bullet

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.

blowdart
Peek-a-boo

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.

leeappdalecom
.nettter

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 Sad

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

lorad
Lorad

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.

Minh
WOOH! WOOH!

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 Smiley

amotif
No Silver Bullet

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 Smiley

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.

Minh
WOOH! WOOH!

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! Smiley

sylvan

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>(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<T>( MyList<T> 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.

sylvan

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.

sylvan

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

amotif
No Silver Bullet

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

blowdart
Peek-a-boo

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.

andy_hanger18

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 Smiley

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

fuzzylintman

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

-mdb

Dr Herbie
Horses for courses

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>(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<T>( MyList<T> 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

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

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.

sylvan

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.

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

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.

jimMarriott

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.

jimMarriott

That's to Sylvan BTW... Wink