PocketMatrix

The problem is that due to the truly bizarre hiring "policy" here, I haven't even seen their CVs yet... and the interviews have been booked by the HR department, so I can't ask them for code.

I definitely don't want to do a cold "What is inheritance? What is polymorphism?" test, because that's just pointless; I could answer those questions in my sleep years before I could actually design a "proper" OO setup with reasonable responsibilites assigned.

As for fitting into the team, that "team" is, at the moment, just me. They're being employed to help me develop a framework for a modular application and do lots of technical leg-work that I'm too busy to do.

I'm wondering whether it's better to find somebody fresh out of Uni. and train him in (my particular) ways of OO - or whether I hope and pray that there's a candidate who knows what he's doing enough to beat me into shape

Most people that I've met that say they can "do" OO, can do the code syntax but not design the structuring/hierarchy (including myself in that, to a certain extent).

The irony, of course, is the person who'd be my first choice was fired a couple of weeks ago while I was on holiday.

I'm really struggling to think up examples of "bad" "OO" design for them to "fix"

Cheers,

Ref.

I have to agree with MeumSimulacrum. But, my way of doing interview is asking about the work they have done (normally on CVs) and asking more specifics informations about it. If you find him to hesitate about his own works... that's not a good sign. Doing this, you know how can he communicate and his skill in programation. Viewing some of his code could be interesting too, to see how he works. I think it's not a good way to bother about the tools. But in your case, having knowledge in C# and VB looks like that he should know how to use .Net and databases ^_^

Also, It's not because they know about UML that they really know How to use it. It need a lot of OO experience to be able to use UML efficiently. MeumSimulacrum told also about really difficult questions. I think it's a good thing too. You can easyly see how a programmer can react when he face a new situation and how logical he can be. For example, myself in my first interview, I was asked if we could have a private default constructor? After some thinking and speaking, I was able to answer the question. It takes me some time, but even if the answer is wrong, it does'nt means that he's not a good element.

Another important part, is your instinct :P If you feel that the person does not fit the job even if he's good, I think you should follow what you feel.


Have fun with your interviews ;)
/adlm[/quote]