This will be the first post in the series "Little Questions for the Bored". I want to see the answers to the questions in the comments. Obviously, if you're going to be a moron and copy and paste the answer straight from Google, you'll be banned and signed up for a 1-way ticket to hell, care of me. Heh.
On to the question:
DateTime dt = DateTime.Parse("01/02/2007");
What is the value of dt.Day?
What is the value of dt.Month?
Why is it not good to use the above DateTime.Parse() method like it is shown?
Interviewing for Dummies
Just recently I had to help interview some candidates. The problem with the area that I live in is that there are very few "good" .NET developers -- and developers in general. 12+ years on your resume in the software development business means jack shit if you can't think on your own or come up with solutions that focus on more than just syntactic elegance.
I read a recent post on how to hire someone for a software development position and I'd like to offer my suggestion from the plethora of Interviews I've been through myself as to how to make a decent decision:
I read a recent post on how to hire someone for a software development position and I'd like to offer my suggestion from the plethora of Interviews I've been through myself as to how to make a decent decision:
- Have HR send ALL the technical resumes to the Department Manager that created the position that the person is sending their resume in for (since HR doesn't know a cat's ass from it's head when it comes to IT, no matter how much experience they've dealt with it). Project Managers or Department Managers are hired for their experience, let them decide who to interview not HR. Again, most companies are probably following this first rule.
- Create 3-4 code problems to send out to a potential candidate first, before phone intervewing them. (Send the candidate all 3-4 problems and tell them to choose 1 of them and send it back within 24 hours. If they can't do this, then they aren't as serious as you think they are. No exceptions! How are you to expect them to hit anytype of deadline?). This will help get a feel for how someone understands a basic problem and to see how they code. There are SO many things that can be learned from this, I have NO IDEA why most companies don't do this! If you're serious about hiring someone with potential, give them the oppurtunity to shine before moving onto Rule #5.
- Hold a code review (put a time on it, 30min max) for the code problem. Don't forget to invite 2-3 developers from the current team in on it to express their feelings. It's ok to invite the company-asshole-developer to this since he/she might find something small and ridiculous to be thought-provoking for something else.
- Phone interview (probably 30min max, any longer it's quite boring). In my past, it was ideal to have the person interviewing ask me syntax-free questions. It's pointless to explain hard-core physical code over the phone. Hold those questions for the whiteboard session.
- Face-to-face interview [PART 1: Logic tests] (It would be NICE to have the candidate on-site for a few hours for their interview). It would be ideal to give the candidate a logic test or something similar if you want to really find someone good. If not, disregard that suggestion. If your company is like most, they really don't give a shit anyway.
- Face-to-face interview [Part 2: after the logic tests]. Take the candidate out to lunch, preferably 2 developers. Have the developers armed with questions and see how they rate the guy at lunch. This will let the candidate relax without having someone that can pull the trigger. Developer-to-developer talk can be relaxing and very revealing. Just make sure you don't let the bonehead asshole developer go. NO ASSHOLE RULE AGAIN!
- Face-to-face interview [Part 3: Whiteboard session]. Get a conference room with a huge whiteboard. USE THE WHITEBOARD. Have the candidate THINK! This requires some work on your company's part before you even bring the person in. If someone has alot of "design" and "UML" on their resume, come up with a small class diagram for them to UML out for you. If you really want to test the candidate, have a project manager in the room to ask questions about the design while they're at the white-board. See how they explain things -- is it clear or not?
- Send em home tired. Review EVERYTHING from the day's interviewing experience. Developers and Managers talking via email, etc.. about the candidate. Do it.
- Make an offer or NOT. Don't be a bitch and low-ball someone. If you take the time to make a day out of interviewing someone, make them an offer that they will have a hardtime saying "No" to. Obviously this will take into account the going rates for their experience. You should already know the going rate for certain experience etc for your area. Don't forget to take Cost of Living into consideration. An offer of $75k in NYC is lame for a guy that left the interview and his experience made you stiff.
I'd consider this a rough outline of things to do when interviewing someone. The main point is to spend time with them and get a feel for the person that wants to work for you. If they show any effort upfront, you can stop the interview there. Each step requires effort on their part. It's incremental, so at any point they can stop and no further time is wasted and you have your answer.
Let me know what you think.
Subscribe to:
Posts (Atom)
