As Dean said, you are being assessed on multiple attributes, and these are usually:
- Technical Skills
- Whether you would fit into the team
- Thought process
The technical skills requried for the role will differ depending on which team you are interviewing with, so if it doesn't work out with one team, you could (depending on the company) re-apply and find a better fit with another team. So don't lose hope!
The majority of technical skills are usually tested with coding problems. You mentioned that occaisionally you missed a border case and that a few bugs crept in (as they inevitably do when asked to code on a whiteboard). A good approach to answering these coding questions is to do the following:
- Understand what is being asked (ask to repeat certain parts if necessary)
- Ask clarifying questions (iteratively/recursively, Do specific constraints exist?, which language?, etc)
- Identify appropriate data structures, algorithms, design patterns that may be used (Programming interviews exposed and Programming Pearls are helpful for this)
- Write the code, whilst explaining out loud to the interview what your thought process is. If the interviewer knows what you are thinking, they may be able to identify problems in your approach early, and guide you towards a better solution.
- Before telling the interviewer that you are complete, think and explain to the interviewer how you would test the software you just wrote. Think about simple cases, border cases, concurrency, whether the approach makes sense for other cultures, security implications, stress testing, etc.
Finally admitting that you don't know something is (IMHO) preferable to stumbling along trying to fake it. Granted, the interview is asking you to solve a problem, but if you don't know where to start, I'd recommend talking about the valid approaches and trying to narrow dow a correct one that addresses the contraints given. If you have no idea where to start, it may be time to explain that (This also ties into how you fit into the team. I'd say that it is better to ask for direction early). So I don't think that saying you don't know is a bad thing (assuming that it isn't all that is said =])
There isn't specifically much that you can do about fit, as often to comes down to a personal opinion of the interviewer, but conversing with the interviewer about what you're thinking/doing is preferable to coding in silence for 15min and then declaring "I'm finished".
Keep in mind that these things are usually a two way interview. They are not only interviewing you, you are also interviewing them. Feel free to ask questions about the job/team/company.
Finally, Microsoft recruiters post quite a fair amount of info on what they are looking for during a phone screen/interview so I'd recommed having a read. Additionally GlassDoor has a lot of info on interview processes for companies (but the user submitted answers aren't always correct). A google search for MS/Google/Amazon/Apple/etc interview questions will also yield results.