Bài chia sẻ thú vị và hiếm hoi ở góc độ của người phỏng vấn:
How to conduct a good Programming Interview
Đoạn bên dưới trích từ bài viết trên, bản đầy đủ xem chi tiết link đến bài viết.
======
Any software engineer who has ever looked for a job has had the interview experience: being locked in a small room for an hour, asked to write code to solve some arbitrary programming task, while being grilled by one or two interviewers whether or why the code they've written is correct.
You can find lots of material online about how to ace the interview as an interviewee, but very little has been written about how to conduct one as the interviewer. This post will lay out a coherent set of principles and cover many concrete steps you can use to make the most out of the next time you find yourself interviewing a potential software-engineering hire.
Goals
While there are a variety of ways you can conduct a programming interview, the goals typically are the same:
- Will the candidate be able to write working code if they join the team?
- Can the candidate discuss code and problems with the people they'll be working with?
- Can the candidate reason about arbitrary problems and constraints?
- Is the candidate someone we would enjoy working with?
There are a lot of more tactical goals that you can try to accomplish, along with specific skills you may want to test (e.g. knowledge of a specific platform or programming language) but at a high level these are the primary questions you are trying to answer in a programming interview. There are other interviews (e.g. resume review, architecture design, etc.) that cover other things you'd want to know before hiring the fellow.
While you usually give the candidate a programming task to work on during the interview, it is the process through which a candidate finds a solution that reveals the most about whether they can write code. As an interviewer, you should end up with a much more holistic view of the candidate than "finished task X in Y minutes":
Everyone makes mistakes. Were they stupid mistakes, or were they mistakes that any reasonable person would make? Do they indicate sloppiness on the part of the candidate, or just unfamiliarity with the problem? How fast were they able to recover from them?
When the candidate makes a decision that turns out to be correct, were they just lucky or did they have a solid reason for doing so?
Was the candidate able to discuss and convey what they were trying to do, in a way you could understand?
Did the candidate have a good grasp of their own code, and be able to smoothly make changes when necessary? Or did they get lost in their code, tangled up in their own logic totally independent from the task they were trying to solve?
From these observations, you should be able to come up with answers to the four questions posed above, and then decide whether you'd call this candidate a "hire" or "no hire"
About the Author: Haoyi is a software engineer, an early contributor to Scala.js, and the author of many open-source Scala tools such as the Ammonite REPL and FastParse.
If you've enjoyed this blog, or enjoyed using Haoyi's other open source libraries, please chip in (or get your Company to chip in!) via Patreon so he can continue his open-source work