Interviewing programmers

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.

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.

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.

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

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.

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!

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.

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.

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

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.

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.

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

-mdb

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

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.

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.