今日推荐开源项目：《面试代码题 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/
