今日推薦開源項目：《形象生動 algorithm-visualizer》
今日推薦英文原文：《How To Stop Being Afraid of Technical Interviews》
今日推薦開源項目：《形象生動 algorithm-visualizer》傳送門：GitHub鏈接
推薦理由：這世界上有很多千奇百怪的演算法，它們有的用於解決千奇百怪的問題——這兩點混在一起，就搞不懂這演算法到底在幹啥了。這個項目將演算法的執行過程可視化，從而降低其學習難度，演算法的每一個步驟都將會輸出在命令行界面，同時還將顯示整個演算法操作的數據來讓演算法的下一步變得容易把握，類似於程序調試器一樣的單步前進和後退也能幫助重現一些難以理解的過程。
今日推薦英文原文：《How To Stop Being Afraid of Technical Interviews》作者：Joey Colon
原文鏈接：https://medium.com/better-programming/how-to-stop-being-afraid-of-technical-interviews-b60b064ff003
推薦理由：對策技術面試提問的六個步驟
How To Stop Being Afraid of Technical Interviews
Learn the UMPIRE technique
Introduction
If you are an up-and-coming developer or a seasoned developer with multiple years of industry experience, you probably have heard or experienced first-hand how nerve-wracking technical interviews can be.While it was true for myself initially, there were a few things that I did to help cope in these high-pressure situations.
This post and subsequent posts are to not debate whether or not the current way of interviewing is the correct way of conducting interviews for developers. I am treating it as truth and explaining some important concepts on how I played the 「game」 of interviewing.
In this post, I would like to shed some light on the problem-solving framework I utilized in my interviews. It is best to always have some form of structure when tackling an algorithm question.
The worst possible thing you can ever do in an interview is immediately starting to write code after being presented with the question.
So, if you are not supposed to be coding, then what are you supposed to be doing? This is where UMPIRE comes into play.
UMPIRE
UMPIRE is a problem-solving framework that I picked up this past summer from the CodePath technical interviewing course.The purpose of UMPIRE is to break down an algorithm question into very specific parts to help better your understanding and solution to the problem.
U — Understanding the problem.
M — Matching the problem.
P — Planning your solution.
I — Implementing your solution.
R — Reviewing your solution.
E — Evaluating your solution.
Understanding the Problem
The first step in the UMPIRE method. You were just asked a question; this is your time to really understand what the interviewer is asking of you.A common pitfall in the interview is solving the wrong problem. This step is used to eliminate any confusion you may have, assumptions you can make about the problem/edge cases, and most importantly, making your own examples.
In these algorithm problems, you want to create your own examples to not only solidify your understanding of the problem but to see how you would solve the problem — as a human.
Through making your own examples and solving them, you should be able to notice some patterns that your brain is automatically making when solving them by hand.
This is where you need to take note and reverse-engineer how you solved it as a human so that you can write it in code.
Matching the Problem
After creating your own examples, you should have a greater understanding of how you were able to solve it by hand.This step is used to think about which data structures/algorithms/techniques can I use to help me with this problem? Is the input array sorted? How can we leverage binary search to help us? Linked list problem? Could we maybe use a slow/fast pointer technique here?
These are the questions you should be thinking about out loud. Being able to comment on the tradeoffs between two different approaches provides a good signal to your interviewer, and chances are, if you are talking about the favorable approach, the interviewer will provide signal that you are on the right path.
Planning your Solution
So, you have a solid idea of which data structure you want to use and just hand-solved some of your own examples.Using the previous information from the last two steps, you will want to start writing out your approach in either plain English or pseudo-code.
Personally, I have had interviews where I had two approaches to solve the problem in mind. If you fall into this case, you want to vocalize your thought process about which tradeoffs you are making for each solution.
By vocalizing this, you convey to the interviewer that you are a calculative thinker and you are open to discussion/collaboration on the type of solution they are wanting. Again, this is the type of signal you want to provide.
When writing up the flow for how my algorithm will work, I will usually leverage helper methods.
For example, if I want to populate a frequency counter, I』ll typically write populateMap(arr, map) in the main flow of my code and note this helper method outside of the main method, all while letting the interviewer know what the method will do.
Interviewers don』t care about watching you write pseudo-code for how to implement a frequency counter, they care about how you will use it to solve the main problem. Don』t trip up on the boring details.
When writing up your approach, you should always use insightful variable names and method names. Having unreadable/irrelevant variable names is most definitely correlated to a bad signal and might even be harder for you to understand if you have to debug through your code in the later steps.
After completing the flow of my algorithm and feeling confident, I will go ahead and ask the interviewer the question: 「Is it OK if I code this solution up now?」
Implementing Your Solution
After spending the majority of your time planning your approach, implementing the solution should be relatively trivial.When I typically enter this step, I like to write my code directly under the respective English comment from the previous step.
In my opinion, keeping your thoughts organized will help keep you focused. As I code, I like to reiterate out loud what I am coding so the interviewer has an easier time to follow along.
Reviewing Your Solution
After writing up the code to your solution, this is where I would take the examples I created from step one and trace through my code with the respective input line-by-line.This will, again, provide a positive signal to your interviewer that the approach is correct and proves that you have strong tracing skills.
Also, this may be a time where you catch a small syntax bug in your code and allow for any small patch-ups as needed. I typically write a comment above the method with the respective variables and what their value is as I go line-by-line in the program.
There』s no need to make it more stressful on yourself by trying to remember it all in your head.
Evaluating Your Solution
This step is primarily about commenting on what your big-O complexities are.It is also a chance to reiterate your previous discussion on why you chose to use this particular algorithm. This step can also be used as a way to talk about the potential areas you would have expanded on if you had more time in the interview.
Conclusion
Technical interviewing is hard — there』s no denying that.Likewise, with many things in life, the skill can be improved upon with consistent practice. If it was easy, everyone would be passing interviews and it would feel a lot less rewarding.
In upcoming posts, I plan on talking about the timeline I used to study. It will include the resources that I used to learn algorithm questions, as well as learning a new language from scratch that I could use to interview with.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
