|
When interviewing a .net candidate what do you look for? Let's say for a senior candidate. What kind of memorable interview have you experience, good or bad? This is going to be my first time I'll be the Interviewer. This is my second job and so I haven't got a lot of interview experience. Sure I can ask lots of .net technical questions, but what other questions can I ask and what can it bring by asking that question? Thanks, |
|||
|
|
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
Look for someone that you can envision being on your team, both in terms of skill and personality. Get to know the people you are interviewing, don't just ask them a barrage of technical questions. You need someone you can work well with, not just someone that has the necessary skills. This question should help you come up with a list of .NET technical questions you can ask. |
|||
|
Adding to Bernard's answer: If you find someone who you can work with - assuming they have a minimum level of competence - any shortfall in technical skills can be addressed via mentoring and training etc. Obviously the "minimum" level of competence will need to be higher for a senior position. It's much harder (if not impossible) to address the problems caused by someone who has exactly the right set of technical skills but doesn't fit with the team. If anything the "people" skills of a senior candidate have to be that much better than for a junior candidate as more of their job is going to be involved with clients, managers, other developers etc. |
|||||
|
|
I personally like the book "Programming Interviews Exposed" and the majority of questions interviewers ask are from that book, it's almost eerie. Also, you can get ideas by going to http://www.glassdoor.com and looking up a company like google or microsoft and go to the "interview" section to see what their interviews are like. My view is it such be 50% skill and 50% personality. I could care less if someone just answers all my technical interview questions but seems like a "mean" or "rude" person. Personally, I find the best software developers to be the ones that have an undeniable passion for programming. Do they just have a resume and that's it? The really good ones have a resume, a website(s), a technical blog, a few side projects they've worked on, tweet about, written books about it, are well known in the industry, know more than one language or technology, etc. You can just tell that they're passionate and driven. You can tell if someone does this stuff as a hobby or do they just see it as a "job". |
|||
|
|
|
I have relatively recently been dropped into the position of being "the technical guy at the interview," and to be honest, I haven't had a lot of luck trying to come up with and use specific technical questions. What I prefer is to just try to get the candidate talking about a project and take the conversation in whichever technical direction seems fruitful. e.g. the resumé says "implemented AJAX in ASP.NET web application to make it faster and more user-friendly", I'll ask: what sort of interactions were you AJAX'ifying? were these existing pages where you were replacing postbacks with AJAX updates or new pages? were you using ASP.NET AJAX or hand-rolling it with a different JS framework, or even no framework at all? how did you interact with the HTML coders? were you returning data and laying it out with javascript or returning HTML ready to insert into the DOM? how were you dealing with errors and timeouts? And then of course every answer leads to more questions: usually "..and why did you make that choice?" :-) I find a conversation like this is the best way to get a feel for whether they know their stuff or not. It also becomes, I think, fairly apparent when someone is padding their resumé by listing every project that their team or company did, even if they only had a minor involvement. If they can't converse about the project in detail, I assume they weren't deeply involved and that I should probably discount that experience and move on to something different. |
|||
|
|
"The Hanselman" had a great list of questions looking for senior software engineers. A lot of them aren't .Net based, but there are links in the article for .Net specific ones. Outside of those questions, one thing I found quite engaging recently was a simple design "discussion" that I partook in that wasn't language specific. Essentially the question was to design a chess game, ignoring UI logic and simply focusing on business logic. What this did was to open the thought process of the developer involved with a new program. Are they looking high level first? Are they looking low level first? What are they taking into consideration? What are they forgetting. A few probing questions were asked during the discussion (why are you choosing to go that route? how do you handle determining legal moves?) and the asker in effect came along side to help design the program a little, which also mocked up how they might interact with their peers in the job environment. You can take maybe 5 or 10 minutes on the discussion and I think get a lot of insight into the potential developer that way. |
|||
|
|
