Interviewing / candidate qualifying tips
-
John Simmons / outlaw programmer wrote:
They're not serious about being a programmer. Don't hire them.
It's unlikely that I would have a laptop if I did not get the company to pay for it for remote debugging purposes. And I would definitly call my self a serious programmer. I have churned out somewhere between 500K to 750K new C++ (mostly MFC but now Qt) lines in the past 12.5 years..
John
I own a laptop so I can code when not at home. The difference between me and about 99.9% of every other programmer is that I code at home almost as much as I do at work. I have about half a dozen things I'm working on that will eventually result in CP articles.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
I spent some time reading through everyone's response and it's really discouraging to see the amount of people who say "If they don't know specific 'x', then they don't know what their doing. Don't hire them". Really? 'Cause I'd bet when you started your programming career you didn't know that, so by your definition you shouldn't have been hired. Specifics are a learned commodity. What I look for in hiring is someone who can solve a problem, not necessarily someone who already knows the answer. Usually those who want specifics are just looking for a clone of themselves. That doesn't make your application better. Sometimes you need someone to look at it differently. Now there are those positions that require a specific skill set and need it immediately. If that's the case then by all means ask the specific questions. More often, there are people who think they have one of those types of positions and they "need someone who can hit the ground running". Usually, they take longer finding that person than if they found a developer with good potential and let him do some on the job training. Another thing to consider is that "I don't know" is not an automatic fail. Anyone who claims to have the answer to everything are those who I am suspicious of. I've had people reply with "I can do anything you need." when I've asked them a question. It would have been better to explain how they would have done what I needed. We have several questions - both verbal and written we ask candidates, but only a few I pay the most attention to: 1) Can they verbally explain OOP concepts and give an example of how/why you would design this way. Nervous candidates may struggle with this, but that's why we follow up with the written problem: 2) Design and code an application to import a list of entries from a text file, sort them in alphabetical order, then display to the screen. Please implement the sort function, rather than utilizing a pre-defined sort call. (Any language) I just have them write this out by hand on a blank sheet of paper. This shows they don't need a wizard to design their skeleton app. Syntax is not incredibly important as the majority of developers today rely on the IDE to point out their mistakes. I really look for their use of classes and functions, do they add comments, and can they design a way to sort other than what's provided for them in a language. After this you can review their response and discuss why they picked one technique over another. If SQL is
-
kryzchek wrote:
They may not own a laptop
They're not serious about being a programmer. Don't hire them.
kryzchek wrote:
Their development work may belong to their previous employer, so it's proprietary, private or not even in their personal possession (say that 3 times, fast).
Not a valid assumption. I have a laptop, and I have a development environment on it that includes all of my tools and whatever source code *of mine* I might be working on. That's what I meant by "development environment". Providing a code sample without being able to show that it actually works and that I know what it does is a waste of everyone's time. I took my laptop to every job interview with several of my codeproject articles ready to demonstrate, as well as some of the web sites I've built. Nobody wanted to see them, but I was ready if they did.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001I considered getting a laptop. Then I decided to simply place my "top 100" best components on CodeProject, so I can access them wherever I am. :)
Best wishes, Hans
-
I own a laptop so I can code when not at home. The difference between me and about 99.9% of every other programmer is that I code at home almost as much as I do at work. I have about half a dozen things I'm working on that will eventually result in CP articles.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001I code at home hopefully not as much as at work. Although I certainly have done this in the past I do not like pulling 80 hour weeks. My code however is on a cvs/svn server that is accessible from both locations. To make a long story short the cvs server is on my home machine since it would be too difficult to the network security guys to allow this to happen at work..
John
-
I spent some time reading through everyone's response and it's really discouraging to see the amount of people who say "If they don't know specific 'x', then they don't know what their doing. Don't hire them". Really? 'Cause I'd bet when you started your programming career you didn't know that, so by your definition you shouldn't have been hired. Specifics are a learned commodity. What I look for in hiring is someone who can solve a problem, not necessarily someone who already knows the answer. Usually those who want specifics are just looking for a clone of themselves. That doesn't make your application better. Sometimes you need someone to look at it differently. Now there are those positions that require a specific skill set and need it immediately. If that's the case then by all means ask the specific questions. More often, there are people who think they have one of those types of positions and they "need someone who can hit the ground running". Usually, they take longer finding that person than if they found a developer with good potential and let him do some on the job training. Another thing to consider is that "I don't know" is not an automatic fail. Anyone who claims to have the answer to everything are those who I am suspicious of. I've had people reply with "I can do anything you need." when I've asked them a question. It would have been better to explain how they would have done what I needed. We have several questions - both verbal and written we ask candidates, but only a few I pay the most attention to: 1) Can they verbally explain OOP concepts and give an example of how/why you would design this way. Nervous candidates may struggle with this, but that's why we follow up with the written problem: 2) Design and code an application to import a list of entries from a text file, sort them in alphabetical order, then display to the screen. Please implement the sort function, rather than utilizing a pre-defined sort call. (Any language) I just have them write this out by hand on a blank sheet of paper. This shows they don't need a wizard to design their skeleton app. Syntax is not incredibly important as the majority of developers today rely on the IDE to point out their mistakes. I really look for their use of classes and functions, do they add comments, and can they design a way to sort other than what's provided for them in a language. After this you can review their response and discuss why they picked one technique over another. If SQL is
I agree with you 100%. To me it's more important to see how someone approaches a problem rather than their command an particular language. I suppose this is the part of the interviewing process that I'm having difficulty with. I think I'll use your second test question as I think it gives some valuable insight as to how a candidate thinks. And for the record, I'd never be able to hire you simply because your prefix your SQL tables with "tbl", and that drives me nuts :-D Thanks again for the tips and help.
-
I code at home hopefully not as much as at work. Although I certainly have done this in the past I do not like pulling 80 hour weeks. My code however is on a cvs/svn server that is accessible from both locations. To make a long story short the cvs server is on my home machine since it would be too difficult to the network security guys to allow this to happen at work..
John
You'll need to cut John some slack. His new love for VB.NET has his nerves a little on edge. :)
-
kryzchek wrote:
They may not own a laptop
They're not serious about being a programmer. Don't hire them.
kryzchek wrote:
Their development work may belong to their previous employer, so it's proprietary, private or not even in their personal possession (say that 3 times, fast).
Not a valid assumption. I have a laptop, and I have a development environment on it that includes all of my tools and whatever source code *of mine* I might be working on. That's what I meant by "development environment". Providing a code sample without being able to show that it actually works and that I know what it does is a waste of everyone's time. I took my laptop to every job interview with several of my codeproject articles ready to demonstrate, as well as some of the web sites I've built. Nobody wanted to see them, but I was ready if they did.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
kryzchek wrote: They may not own a laptop They're not serious about being a programmer. Don't hire them.
Would you enter a pinto into the Daytona 500? And why would you have a pinto to begin with?
Todd Smith
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
I personally believe that trying to glean something from a programming test at interview time is worthless. The length of time available limits the complexity and the situation will always be somewhat contrived. My method has always been to have a first interview during which I explain, in detail, what the role involves. I whose them the application(s) in action, I show them source code and database structures. I converse with them about these (few, if any , outright questions - a conversation is necessary - I need to work with these people and know I can do so at a technical level). If available I show them some crap code (maybe some prototype code, maybe something that's causing issues - but nothing too complex) and get them to understand the issues and help suggest improvements (e.g. in once case we had a 'fetchObjectFromDb' method that fetched a massive customer object by selecting from the customer table, then for each 'id' on that table, selecting from the child tables and building the child objects (Name, Address, and other business objects). I asked them to think of any issues (this object was used even if the app was displaying just the customer name in a list, and required up to about 200 calls to the DB to populate all of the objects). Discussion was my point - I didn't expect them to have an answer off the top of their head, I wanted them to think about, and discuss with me, the problem. At the end of the interview, after their opportunity to ask any questions about the requirements of the role) I would tell them that, if called for a 2nd interview they would meet the team (not applicable in your case, I guess!) to make sure they would get on with the members, and be able to ask them any questions - and the team could ask them questions too. And finally I would tell them that, if they were not 100% comfortable with their ability to perform the role I had discussed, that they should get back to me before any second interview to discuss the issues. I insisted (and meant it) that this would not preclude their selection, but that if hired they would be on probation, and I treat probation VERY seriously. If they were unable to perform according to my expectations (which I had carefully explained) using the code base and DB they had been shown, I would sack them during probation. No second chances. Of the 12 or so candidates I employed over 8 or 9 years, I sacked one. (I'm sill not sure if he had some mental illness, was on drugs or what, but the guy that turned up to work could have be
-
mincefish wrote:
I don't want to work with people who don't have other things to talk about when you're having a beer after work.
So being able to enjoy a beer (or socialize after work) with a co-worker takes precedence over how they perform on the job? That seems like a strange metric on which to base a hiring decision. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
We give them a piece of paper with a vague written description of a real world scenario that we have solved. Sit them in a room for half an hour with some blank paper and a pen and tell them you want them to describe their proposed solution when you return. Two of us go back with a white board and just invite them to talk about their solution. It's interesting to see: * Can they communicate well * Are they confident * Do they look you in the eye * Do they start writing code * Do they draw diagrams * Do they ask questions..."Im not sure about X. if its A I'd do this if it's B I'd do this". This is a big one for me, the scenario is purposefully a little vague, if they make assumptions and then are unwilling to consider that they might be wrong it ends pretty quickly * If you change the requirement slightly can they think on their feet? * If they misunderstood or have gone down the wrong path are they prepared to rethink their solution or do they dig their heals in and insist they are right? * Both interviewers ask a few questions quickly without giving time to answer, do they cope and answer each when given the opportunity or crumble under pressure * Ask them to write out one of the solution's algorithms in code on the board while you watch This is a technical interview, its sole purpose is to determine if this person is someone you want to touch your code. If they do well there is a "soft skills" interview which I dont usually do. In your case I suspect you are going to have to do quite a bit of adjusting to working with someone else. If it's going to just be the two of you you'll really need to get along so take your time and be confident in your decision.
-
We give them a piece of paper with a vague written description of a real world scenario that we have solved. Sit them in a room for half an hour with some blank paper and a pen and tell them you want them to describe their proposed solution when you return. Two of us go back with a white board and just invite them to talk about their solution. It's interesting to see: * Can they communicate well * Are they confident * Do they look you in the eye * Do they start writing code * Do they draw diagrams * Do they ask questions..."Im not sure about X. if its A I'd do this if it's B I'd do this". This is a big one for me, the scenario is purposefully a little vague, if they make assumptions and then are unwilling to consider that they might be wrong it ends pretty quickly * If you change the requirement slightly can they think on their feet? * If they misunderstood or have gone down the wrong path are they prepared to rethink their solution or do they dig their heals in and insist they are right? * Both interviewers ask a few questions quickly without giving time to answer, do they cope and answer each when given the opportunity or crumble under pressure * Ask them to write out one of the solution's algorithms in code on the board while you watch This is a technical interview, its sole purpose is to determine if this person is someone you want to touch your code. If they do well there is a "soft skills" interview which I dont usually do. In your case I suspect you are going to have to do quite a bit of adjusting to working with someone else. If it's going to just be the two of you you'll really need to get along so take your time and be confident in your decision.
Josh Gray wrote:
In your case I suspect you are going to have to do quite a bit of adjusting to working with someone else. If it's going to just be the two of you you'll really need to get along so take your time and be confident in your decision.
You hit the nail on the head. The idea of bringing on a second developer has been brought up once or twice in the past 2 years or so and I've always resisted it. I'm having a hard time trying to accept that someone else is going to be touching projects that I've worked very hard on and take great pride in. I'll freely admit that I'm a total hack and certainly, someone else could come in and easily improve my software--and by extension--my work abilities. I just have a fear of constantly butting heads with someone who has a Masters in CS telling me that my app doesn't follow a single design methodology and is insistent that we do things THEIR way.
-
Josh Gray wrote:
In your case I suspect you are going to have to do quite a bit of adjusting to working with someone else. If it's going to just be the two of you you'll really need to get along so take your time and be confident in your decision.
You hit the nail on the head. The idea of bringing on a second developer has been brought up once or twice in the past 2 years or so and I've always resisted it. I'm having a hard time trying to accept that someone else is going to be touching projects that I've worked very hard on and take great pride in. I'll freely admit that I'm a total hack and certainly, someone else could come in and easily improve my software--and by extension--my work abilities. I just have a fear of constantly butting heads with someone who has a Masters in CS telling me that my app doesn't follow a single design methodology and is insistent that we do things THEIR way.
kryzchek wrote:
I'll freely admit that I'm a total hack and certainly, someone else could come in and easily improve my software--and by extension--my work abilities. I just have a fear of constantly butting heads with someone who has a Masters in CS telling me that my app doesn't follow a single design methodology and is insistent that we do things THEIR way.
I am unqualified. Three of the people that have worked for me here have phd's in CS. It's really no big deal. One of them came from a very different background with an emphasis on test driven development. He's been a massive influence on our team and we are much better off for it. It's not a case of doing it my way or their way, its about accepting that they have different experiences and being willing to learn from each other. Try to keep in mind that its not really your code but your employers code, they paid for it to be written, they own it, they profit from it and it's your job to make decisions about that code that will benefit them. My advice is to be open with people about the role, what your concerns are and what you hope they will bring to the table.
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
Make it simple - something solvable in 10..20 lines. Try to help them when they get a detail wrong - it's not about "right" or "wrong", but how they approach it. If the candidate cobbles together something that works, let him discuss what could go wrong. I wasn't convinced if that is such a good approach - until I first saw the results. Even after heavy pre-screening there were lots of surprises. It also helps readjust the compromises you invariably make when expectations meet reality. Bonus points if the candidate asks for clarification of the requirements, and can tell you what he's going to do. The other thing I am looking for is passion. What project was most interesting for them, why? What was good, what was bad? Also can they explain the prupose of a previous application to a non-programmer?
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
What one does outside of work should be none of the company's business (unless it's detrimental in some way which is unlikely). But on the other hand, "chemistry" with one's colleagues is a valid concern so I kind of understand.
No argument there - the ability to interact well with coworkers and be a team player is essential. I was referring to the requirement that the potential new hire has to "have a life" outside work. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Marc, your're the guy we google when we want the defintive answer on a technical question!
Don Burton wrote:
Marc, your're the guy we google when we want the defintive answer on a technical question!
My gf finally caught on that I tend to make up a reasonable sounding answer. I guess I can't live by the "I'm right until proven wrong" principle anymore. :sigh: Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
I work primarily in C++ and one very good method to weed people out is talking about multi-threading. My team lead and came up with a one question interview: how would you make two processes on the same computer communicate with each other? While there are many answers for this, there is one vastly superior to the rest and the question is how long they take to arrive at it, if at all. The biggest problem I've run into are developers who claim a more central role at a previous employer than they really had. For example, they may claim they helped design something, when their help consisted of one suggestion if that. To get around this, just talk about details and then verify them with his previous manager--doesn't matter if the potential employee listed them as a reference or not. In fact, if they didn't list their manager but insisted they got along with him or her, that's a huge warning sign that something is wrong. (It's important to verify that relationship; I've had a managers that lied to me and misrepresented my work to upper management.)
Joe Woodbury wrote:
While there are many answers for this, there is one vastly superior to the rest and the question is how long they take to arrive at it, if at all.
I would think a queue. Is that more-or-less correct? Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
Joe Woodbury wrote:
While there are many answers for this, there is one vastly superior to the rest and the question is how long they take to arrive at it, if at all.
I would think a queue. Is that more-or-less correct? Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
Marc Clifton wrote:
I would think a queue. Is that more-or-less correct?
Exactly, though shared-memory queue is more precise. If they say named pipes, they are summarily shot. We've actually interviewed people who fumbled around and finally said TCP! To which we answered "Yes, but what about using shared memory?" To which we've gotten the reply, "What's shared memory?" Needless to say, those people are shown the door immediately. We even had a guy suggest writing the file to disk and the other process would poll (yes, poll) that directory.
-
Make it simple - something solvable in 10..20 lines. Try to help them when they get a detail wrong - it's not about "right" or "wrong", but how they approach it. If the candidate cobbles together something that works, let him discuss what could go wrong. I wasn't convinced if that is such a good approach - until I first saw the results. Even after heavy pre-screening there were lots of surprises. It also helps readjust the compromises you invariably make when expectations meet reality. Bonus points if the candidate asks for clarification of the requirements, and can tell you what he's going to do. The other thing I am looking for is passion. What project was most interesting for them, why? What was good, what was bad? Also can they explain the prupose of a previous application to a non-programmer?
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v serverOne of my favorite stories. Interviewed at a satellite office of a well known company by a gang (flock?) of developers. One developer asked me to go to the white board and write a string reverse function. I wrote "strrev()". Later, a developer asked how Intel implemented the hardware to prevent collisions with two processors. I said I could tell him but it didn't matter because that wasn't why I was interviewing. One of the other developers commented that that was dumbest question he ever heard, so I scored points there as well. Didn't get the job, but nobody did. Turns out they interviewed lots of people, but never hired anyone. I found out later through my brother that when corporate found out, they went ballistic and eventually fired the satellite office manager.
-
Marc Clifton wrote:
I would think a queue. Is that more-or-less correct?
Exactly, though shared-memory queue is more precise. If they say named pipes, they are summarily shot. We've actually interviewed people who fumbled around and finally said TCP! To which we answered "Yes, but what about using shared memory?" To which we've gotten the reply, "What's shared memory?" Needless to say, those people are shown the door immediately. We even had a guy suggest writing the file to disk and the other process would poll (yes, poll) that directory.
Joe Woodbury wrote:
Exactly, though shared-memory queue is more precise.
See, this is why I fail interviews. Because the idea that the memory is shared is like, so obvious. ;) Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
John Simmons / outlaw programmer wrote:
They're not serious about being a programmer. Don't hire them.
I do not own a laptop because I just cannot work on such a crammed keyboard and monitor (No, not even for a short while. Thanks for asking. I've managed for so long without it). I think that it's a personal preference. There may also be those programmers who are serious, but don't have the money to buy a laptop. All those laptops that I've ever purchased and used were given to me by my employer. But I pester them continuously and give it back to them. Emails will be checked on the phone while on travel.
“Follow your bliss.” – Joseph Campbell
Rajesh R Subramanian wrote:
I do not own a laptop because I just cannot work on such a crammed keyboard and monitor
Most people connect the laptop to a full mouse/keyboard and one or two large monitors :-) The only time the laptop is used as it is is in a long flight or in an airport.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link