今日推薦開源項目：《面試代碼題 javascript-code-challenges》
今日推薦英文原文：《Acing the Coding Interview Even If You Can』t Solve the Problem》
今日推薦開源項目：《面試代碼題 javascript-code-challenges》傳送門：項目鏈接
推薦理由：這個項目收集了面向初學者的在面試中可能會問到的 JS 代碼題，在使用指南中還列舉了一些值得一讀的書籍與教程網站。面試中問的代碼題並不是說真的每個都會在實際開發中需要解決（有些題目真的很奇怪而且很多時候實際開發不需要重複造輪子），只是用來測試應聘者對基礎知識的掌握水平；對於初學者來說，建議對基礎有一定了解之後通過這些代碼題來補足自己基礎知識中的漏洞。
今日推薦英文原文：《Acing the Coding Interview Even If You Can』t Solve the Problem》作者：Brett Fazio
原文鏈接：https://medium.com/better-programming/acing-the-coding-interview-even-if-you-cant-solve-the-problem-91a950947226
推薦理由：在面試中展現出你如何解決問題，就像考試一樣——除了結果，過程也有分。
Acing the Coding Interview Even If You Can』t Solve the Problem
When your explanations are just as important as the code you write
At the beginning of the interview cycle for most software positions, there is a series of technical programming challenges, some on the phone with a person and some auto-graded. Those auto-graded assessments are really a mental test between you and the problem: get as many test cases to pass in the shortest amount of time possible.Many people assume the same about the phone interview: get as many to pass as you can to impress the person on the other end of the line. This route is definitely not the most optimal. You should replace to impress with and work with. You should treat the phone interview as a partnership or a pair-programming task where you are the primary programmer.
By treating this like a partnership rather than a polygraph, you can establish a sort of rapport with your interviewer and improve your chances of success. Success in a technical interview is not predicated on solving every problem they can throw at you.
Whether you can or can』t solve the problem, there are some things you should do in the interview to increase your chances, including asking clarifying questions, explaining your thought process as you go along, and identifying pain points to your interviewer. If you can』t solve the problem you』ve been given, instead of just giving up, do these three things so you can demonstrate your problem-solving ability and possibly elicit some sort of hint from the interviewer.
Ask for Clarification
This is one of the first things you should do in your interview, regardless of whether or not you completely understand the problem.Especially in the context of phone interviews, you may not get a complete problem specification. It may just be a few lines of comments and one or two examples. Before you even start coding, you should begin to pick your interviewer』s brain about the problem and test cases.
If you feel the problem specification leaves room for some edge cases, this is a great time to pose the question about those so you can have that information before you begin coding. For example, if the problem is to find the lexicographically first string in an array, you could ask what sort of characters are allowed in the array or how many strings will be given. The answers to those questions may be obvious to you, but asking could uncover some detail that wasn』t originally laid out for you.
Another good thing to do is to walk through one of the test cases verbally and seek confirmation for the steps you took to solve it. If we use the same simple problem from above, let』s say our input is as below.
apple, orange, Apple, 1apple
Explain Your Thought Process
After you ask your clarifying question at the beginning, the next step is not coding — it is explaining.After I ask my questions about the problem I say, 「Is it okay if I walk through my ideas for a solution with you now?」 Interviewers always say yes to this question because they want you to succeed, and having a thorough and concrete understanding of your solution before you start coding is a great way to ensure success.
Even if you don』t know an optimal answer to the problem, you can verbalize it: 「I』m not sure if this is optimal, but I had the idea of double for-looping over the input and storing answers in a set.」 Right away you may find out that O(n^2) isn』t the runtime you are looking for, and you may find out if a set is not the right data structure you should be using, based on their response. Now you can have a back-and-forth conversation, throwing ideas around about a more optimal solution in hopes of getting to one, even though coming into it you weren』t sure one existed.
On the flip side, if they come back and say that your solution sounds good to them and that they would like you to begin coding, that probably means the solution you verbalized was correct. At this point you can finally begin programming — but you can』t stop talking.
Identify Pain Points
As you begin coding, you should continually verbalize everything you are doing for the interviewer. If you』re making a method to ensure you』re not getting an IndexOutOfBoundsError, tell them that. Don』t just make a random method stub without telling them what it is for.If you know the solution completely, you may get to the end of the interview without a problem — but what should you do if you get stuck while coding? Or get to the end and don』t have passing test cases?
What you shouldn』t do is frantically panic (I know I』ve fallen victim to this once or twice) and try to thrash your way to a working solution. You should instead verbalize your difficulties. Not only will this give you a specific thing to fix in your code (instead of thrashing around the whole thing) but also your interviewer now knows your plan to fix your solution and can help guide you as you go about it.
If you finished the problem and are failing test cases, saying 「I think that this portion of the code could be causing the test case to fail, so I think I will read over that for a second」 is a perfect thing to do. It gives you a clearly defined goal — read over lines X-Y. It tells the interviewer exactly what you are doing so they can scroll to that portion of the code as well. And your interviewer could give you insight into whether that code block has any effect on your failing test cases.
If you haven』t finished the problem but are just experiencing difficulties getting to the finish line, you should verbalize exactly what your pain points are. Maybe they are language-specific or maybe they are problem-specific.
If you are using a language you are not 100% familiar with, it』s perfectly acceptable to say to the interviewer 「I know I can do this in Java using Comparable, but I』m not sure how to do it in C++.」 Now that the interviewer knows that it is a language-specific problem that you understand the scope of, they can give you tips on how to do it in the language you are currently working in.
If your pain point is more problem-specific, you can verbalize that you are having trouble completing this specific portion of the problem. The interviewer can take a look at what you are doing and help to guide you to complete that part or guide you to a more correct solution.
TLDR
If there's one theme you should take away from this article, it』s definitely to verbalize during your phone interview. They gave you a phone for a reason, and it』s not just so you can have the problem delivered verbally (we have plenty of software that will deliver you a problem to your browser). It was so you could have some back-and-forth conversation and explain your ability to solve problems. If you go into the interview with that mindset, I』m sure you will do great!下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
