How to spot good programmers in interviews (transfer)

http://blog.csdn.net/cutesource/article/details/5915972#comments

I once asked an experienced embedded software developer in an interview to write a program that reverses a string and outputs it to the screen program. He struggled with this subject for a long time. This guy is an amazing person. You give him some useless parts and he can build a robot and program it to walk around the house. He was involved in the development of a satellite, which is now in orbit. He can only use his left brain better than me. But he had never, never had the opportunity to do this subject: to display something on the screen.



Some people have the skill to ask the right questions in an interview and spot great programmers. Some people are afraid to ask questions, they are timid, and ask some questions copied from the Internet. They have no opinion and will only follow the opinions of other interviewers. But interviewing is a very basic skill for most developers. A failed hiring can have serious long-term consequences for an organization, because the weakest employees bring other strong people into the company. On the other hand, shutting out good candidates is also a disservice to the company.

A technical interview consists of at least three parts. In the first part, what we're going to do is see if what's written on the candidate's resume matches the reality. In the second part, we will assess how much practical experience the candidate has. Finally, we test these experiences with some Q&A options or programming questions.

Part 1: Testing the Authenticity
of the I once interviewed a candidate with a colleague. After the interview, I thought the candidate was okay, but not very good. But my colleague looked dissatisfied. "He lied, he said he knew XXX technology, but obviously he has never done this kind of technology at all. We must not want such a person." Although this XXX technology is not very important to our company, "because he spread this panic ," my colleague continued, "I wouldn't trust anything he wrote on his resume."

Candidates should describe themselves in a very positive color on their resume. However, this positive portrayal should have a degree, beyond which it is not expressed correctly. In the example above, I don't take the matter as seriously as my colleagues because I presume that anything on the resume is false unless proven otherwise. If the resume says, "Good at XXX technology", then I think the candidate may just know the name XXX technology. If the resume says, "Worked on a team developing a multi-threaded stock trading system," I would assume that the candidate may have just picked a background color for the system. My requirements are never strict unless I meet a guy with ten years of experience who no longer writes code. If someone says he developed OpenOffice's text formatting tools, or has a Ph.D., it's easy to assume what skills they have. Assuming nothing. Everything has to be confirmed.

For each relevant description on the resume, I will first estimate the actual situation of the candidate. Then, I confirmed by the following conversation.

A real-time operating system was developed as an exercise project.
How big is the team you work with? 15 members? Oh, so, what part are you actually in charge of? message queue? very good! Please describe what happens when a high priority task sends a message to a low priority task?
Completely self-developed a set of audio transmission protocols for wireless security systems.
How many people are in your team? only you? Oh how did you test? Why don't you use RTP?
Bug fixes for XXX engine.
Please describe a particularly challenging bug you found and how you fixed it.
Part II: Discovering Practical Experiences
Having more experience is a good indicator of a good person. Experienced developers mature from making mistakes. They know when to use design patterns and when not to use them. They have a sixth sense and can sense which part of the requirement needs to be modified and which part needs to stay the same. They know when to be lazy and when to be smart. It's real experience that makes the gap between good developers and mediocre developers so big and impossible to bridge.



Experience





Not all experience is equal. It is quite possible for someone to acquire solid skills through years of work, writing or rewriting countless codes in many tasks, and making many mistakes. On the other hand, a person will modify only one line of code in a project for ten years without learning anything new.



Experience





Discovering the Hidden Time
Many great programmers start programming in their second year of college. When they leave school, they already have a few years of work experience. Also, there are some amazing programmers who learn the art of programming at a very young age. I've also known several people who wrote fairly small programs when they were teens or younger. You won't find this information on your resume, and you need to lure it out during the interview.

How did you get into software development?
What was the first programming language you ever learned?
Density of Experience A
lot of amazing programmers just code in the hours they work. It's fine, work life is balanced, and there's no reason why you shouldn't hire someone like that. However, doing some personal programming projects outside of work and study is a good indicator of a good talent. Candidates with amateur programming experience obviously have more experience and are better suited for the company. Don't have a personal project? Here are a few other indicators that do this as well:

Working in small teams or small groups.
Participated in many various projects.
Have a detailed understanding of all levels of abstraction in a large project.
Be the lead developer on a project team.
Part 3: Validation Experience
Once you have a sense of a basic level of real experience with candidates, start validating them with significant real-world programming experience. A few minutes is certainly not enough for a real test, but that's about it. We can get an idea of ​​the depth and breadth of this knowledge by asking questions about various areas of programming development. Of course, your perception of a candidate's skill level will be biased by your own experience level. It's impossible for you to judge the answer correctly in a field you are not very familiar with. So we usually have several interviewers at the same time.

Different job titles will have different interview topics. However, the following areas are common:

data structures and
algorithms multithreading
byte manipulation
memory allocation
objects, inheritance, design patterns
recursion
assembly knowledge and
how question ("What is a signal?"). The questions are very basic and can be answered as long as the candidate has done some work in the field. Each area has some other deeper issues. Candidates' answers to these questions can demonstrate whether they are professional or not. For example, if you ask an experienced embedded software developer how to convert 0x4c to binary, and he writes a 4x16+12, that's not quite right.

Coding Questions
After completing the above steps, I can usually already determine whether the candidate can pass the test, and if there are still difficulties, the coding questions will help me remove the final hurdle. This is very important, and it should not be missed even in a phone interview. To be effective, you need to think and plan the coding questions to ask well before the interview. If the question is wrong, the answer is meaningless.

First, the selection of questions must be based on the candidate's work experience. If you think of a 3D airplane and want to wrap all the questions around it, that's a great question. But you might as well save it, and talk to your colleagues at lunch is fine. If the recruiting job has nothing to do with 3D graphics, the candidate must be unfairly excluded.

The problem must be formulated precisely. "Write a function that moves a stack of cards" is a very ambiguous expression. To give functional titles to avoid misunderstandings, this kind of thing happens all the time. If you're not careful, there's a chance that the interviewer will answer a question that's harder or easier than the one you asked, rather than what you meant to ask. If the answer is a harder question, that's fine, unless the problem leaves him dumbfounded. It's of little use if the answer is a simpler question. To prevent wasting a lot of time, ask them for an outline of their answer a few minutes after they answer to see if their understanding is in the right direction.

Going Further The guidance
above does not solve all problems. These are mainly for work experience. You might miss some great programmers with little experience but great potential. Especially when the interviewer wants to test the candidate's problem-solving skills through some non-coding puzzles.

These interview techniques described here are based on an assumption, a possibility, an internal intuition. Suppose the candidate is a very good developer. What qualities should a great developer possess? You can't directly measure these qualities, so you need to think: What is the likelihood that a good developer with these qualities will give a quick answer to such a particular question? You can't get a 100% correct assessment of a candidate through an interview, but by asking as thoughtfully as possible, you'll get pretty close.