今日推荐开源项目：《命令行谷歌 googler》
今日推荐英文原文：《How You Practice With Leetcode for Interviews Is Probably Bad》
今日推荐开源项目：《命令行谷歌 googler》传送门：项目链接
推荐理由：众所周知，命令行操作起来虽然难以上手但是速度很快，这就有个将常用的功能整合到命令行上的项目——在命令行上使用谷歌搜索，还能指定搜索结果的数量与结果的来源等等，大量的可调整搜索选项与命令行的结合能够满足广范围的搜索需要的同时保证使用者能够快速完成操作，虽然最后要打开找到的网站浏览时还是免不了要打开浏览器就是了。
今日推荐英文原文：《How You Practice With Leetcode for Interviews Is Probably Bad》作者：Nathan Patnam
原文链接：https://medium.com/better-programming/how-you-practice-with-leetcode-for-interviews-is-probably-bad-d4ee2bd7b05f
推荐理由：算法题的刷题环境和面试中还是有一些不同点要注意的
How You Practice With Leetcode for Interviews Is Probably Bad
I’ve experienced it first-hand
I’m writing this article because I never want someone to put in hundreds of hours into Leetcode and for them to get a false sense of confidence that they can pass any coding interview. Then, when they get rejected from all of their interviews because they don’t understand the technical interview process or the criteria being assessed, to have that crushing feeling of remorse, thinking, “I wasted hundreds of hours and/or hundreds of dollars on Leetcode.” I’ve had painful first-hand experience of this.I think it’s great to practice your problem-solving coding skills with Leetcode or even AlgoExpert, especially if you are unfamiliar with data structures like stacks, queues, heaps, tries, etc. In the past, I’ve purchased monthly subscriptions for both when I was actively interviewing for internships in college. However, I think there’s a lot of value in understanding what interviewers are expecting in a technical interview. Even if you were to get the most optimal solution for a given problem, that’s not all we are looking for (which surprises many people).
From an interviewer’s perspective, we evaluate candidates on five different axes during a coding interview. Some of the specifics may vary from company to company, but the overall criteria remain the same. I’ll use a trivial coding question as an example, but you can imagine that the same concepts apply as the questions get harder or more complex.
1. Clarifying Ambiguity
Suppose I gave you a question like, “given a collection of numbers, return the largest number,” in an interview. Do you immediately start coding, or do you spend some time (5, 10, or even 15 minutes) asking some questions upfront and try to identify some of the edge cases? Over time, you will get better at asking questions and identifying edge cases. If you have never done this before, next time, when you are solving a Leetcode problem, start thinking about some of the test cases, Leetcode may be running against your solution behind the scenes. Clarifying questions you may want to ask for the problem above (I purposely left the question vague since you may face this type of wording in an interview) are:- “How will my input be given to me, will it be in a list, set, etc., of numbers?”
- “What should I return? The largest value or the index of the largest value”?”
- “If the list is empty, what should I return?”
- “Can I assume that the list of numbers will fit into memory” (Not a super crucial question, but it shows that you have some understanding of the limitation of memory).
2. How Do You Respond to Feedback?
If you start coding out your solution, and I say something like “instead of using this data structure, do you think we could solve this question with this other data structure”?There are two ways to respond. Either you can say something like, “No, I think you’re wrong,” or you could say, “Sure, let me think about how we could use that data structure.”
The actual response I gave may sound a bit exaggerated, but the overall premise is to make sure if the interviewer offers some advice, you don’t immediately disregard it. The interviewer probably knows about 95% of all the different solutions for the problem, so they may be helping you by steering you away from a solution that might not work for a couple of edge cases, which will save you time.
Sometimes when interviewees don’t know the answer to something or get frustrated because they can’t figure out the solution, they may take that frustration out on the interviewer by giving snappy answers or ignoring feedback. The problem is that the person interviewing you will likely be working with you if you were to get hired. If you act badly in the interview, your interviewer may wonder how you’ll respond when working on a real project or new feature when there isn’t a lot of clarity around what to do.
3. Communication
Do you tell me (as the interviewer) your whole solution aloud before you start coding, or do you immediately start coding your answer in silence? I’ve been in interviews where the interviewee doesn’t say a word for 45 minutes (or however long the conversation is) and, in the end, tell me that their solution works and the corresponding time/space complexity. You can imagine that can be pretty awkward for interviewers, since we don’t know what you’re thinking and don’t know how we can help if you get stuck. You don’t have to make it sound like you’re teaching me something, but make sure every minute or two minutes you give some audible cues about what you’re doing or whether you’re stuck on something.When you’re first given the problem (or even throughout the interview), it’s perfectly okay to ask the interviewer, “Can I take a couple of minutes to think about the problem?” Just make sure you tell me something before you stop talking for three or more minutes. When talking about your solution out loud, you may not know how to implement something, and it’s okay to stub out the functionality. You could say something like, “I don’t know how to implement this specific portion of my algorithm, but suppose I had a function that will give back this output and will have this space/time complexity when given a specific input.”
4. Coding Ability
This can encompass everything from:- Do you type quickly?
- Do you have a good understanding of the built-in methods and libraries in the programming language you use, or do you continuously have to lookup documentation during the interview?
- Do you use meaningful variable/function names and create helper methods when some of your logic is starting to get complicated?
- Do you mindlessly click the run button every time you make a small change to your code, or can you write 20 lines of syntax free code and then click run to see what your program does?
- If applicable, do you use classes or some OOO concepts?
- Did you write tests (especially with edge cases) to test the function you created?
5. Understanding Tradeoffs
Every coding problem probably has many different solutions from the brute force way to the most optimal way. It’s always great to say things like, “One way we could solve this problem is by using this solution which will have this time/space complexity.” or “Another solution that would have a higher time complexity, but lower space complexity is … “. Like I said before, this is something that you will get better at over time.My Specific Gripes with Leetcode and How To Optimize Your Time Using It
One thing that you may notice is that the actual process of writing code is only one of the things we look for. When I conduct an interview, at the end of the day, I want to hire a candidate with great problem solving, coding, and communication skills. Technical coding interviews are far from perfect, but some talent is shown when a candidate can do well in them. The reasons why I’m on the fence about outright recommending Leetcode are:- Leetcode doesn’t make you explain your algorithm out loud before you start writing code. I think this is important because if you can’t clearly articulate your algorithm, maybe you need to spend a couple more minutes thinking about it. I’d rather have a candidate do that then start naively coding up a solution for 30 minutes, hit a roadblock, and have no working solution at the end of the interview. Remember, the brute force solution is better than no answer. First, get a working solution, then a better solution.
- Leetcode doesn’t make you say what the time and space complexity of your algorithm is. You will be asked this question in any technical interview where you write code since that’s how we are objectively able to measure two solutions and say which one is better from time, space, readability, etc. perspective. Additionally, if you say something like the time complexity is O(n), tell me what n (and any other variable you use) means. Does n represent the number of characters in a list, the number of items in a list, or what?
- In Leetcode, you can run your code many times and not get punished, but in an interview setting, you probably will only be able to click the “Execute Code” button four or five times. So make sure you’re more critical of syntax errors or logic errors before testing your code. I think Google was the only company I applied for where they don’t even give you a button to run your code, since you have to write it all in a Google doc. You don’t have to be that extreme, but make sure you don’t rely too much on the run button when creating a solution.
- Leetcode doesn’t force you to think of edge cases or ask clarifying questions since all of that information is given to you in advance.
- Leetcode doesn’t ask follow-up questions like “how would your solution change if we introduced this new requirement,” or “what’s the bottleneck in your algorithm.”
- Leetcode doesn’t penalize you if you have lousy variable names or have 100 line methods. Readable code is something you don’t see very often on the Leetcode submissions for problems.
Conclusion
To recap, Leetcode is not inherently bad. I think that Leetcode is kind of like riding your bike with training wheels, and in an interview, you won’t have those training wheels for support.It’s always great to practice in an environment that mirrors what the real setting will be like. More often than not, the people interviewing you will probably be the same people you’ll be working with if you were to get the offer. You interviewers want to make sure you are smart, but also want to make sure you don’t have a big ego and are reasonably easy to work with.
Additionally, it’s 100% completely okay if you can’t solve a LeetCode problem and look at the solution. At the end of the day, we do all of this practice for a real technical interview, and I want to showcase what you can expect.
Data structures and coding questions being asked haven’t changed that much in the past couple of decades, nor will they change any time soon. Any effort you put in preparing for technical or behavioral interviews today will help you down the road when you interview again (or even at your job/making side projects.)
The next time you are practicing Leetcode questions, try remembering some of the points above and start treating practice like an actual interview. I used to record myself when I did Leetcode to see how I sounded. I had a bad habit of rambling or making stuff up (saying “Ummm” or “ugh”) when I didn’t know the answer. Over time I’ve gotten better at it, but I would have never noticed it without recording myself. It’s probably going to be awkward watching yourself, but self-reflection is arguably one of the best ways to get better at these things.
Just a couple of disclaimers and FYIs. As always, the ideas and thoughts I share are in no way endorsed or supported by Salesforce (nor any other company I have worked at in the past). Also, there’s nothing wrong with doing LeetCode (since any time practicing writing code is better than not writing any code, especially for bootcamp grads or new grads who haven’t been coding for a long time).
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
