开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《表情扫雷 emoji-minesweeper》
今日推荐英文原文：《How To Benefit From a “Failed” Technical Interview》

今日推荐开源项目：《表情扫雷 emoji-minesweeper》传送门：GitHub链接
推荐理由：扫雷应该说是家喻户晓的游戏了，小时候微机课上就靠这个来打发时间。现在这个项目将表情包和扫雷结合了起来，你可以通过自定义选择各种各样的表情来把扫雷玩出花来，表情包最起码比干巴巴的格子好看上不少了。然后择日不如撞日的打算试一下，果然当场丢人

今日推荐英文原文：《How To Benefit From a “Failed” Technical Interview》作者：Melody Habbouche
原文链接：https://medium.com/better-programming/actionable-steps-after-coding-interview-2e904c0cc3af
推荐理由：失败只不过是一种新的经验而已

How To Benefit From a “Failed” Technical Interview

What to do after an unsuccessful coding interview

Technical programming interviews are like the heartbreak of tech — nobody loves them but we all have to go through them.

They’re long, endless, and sometimes leave us walking out, thinking: “What was that?”

We’ve all been there, the long nights reviewing Cracking the Coding Interview, and solving all the problems we possibly can on HackerRank, only to arrive at an interview and be asked a question that gets us absolutely stumbled and flustered. It happens.

There’s a lot more you can do than just tell yourself you’ll do better next time. In fact, if there’s one action — well, maybe a few — that you can do after your technical interviews to benefit from this experience, here they are!

1. Go Over the Questions That Didn’t Go So Well During the Interview

So you walked out frustrated, you didn’t solve that challenge all that well and left the interviewer with a few disappointing lines of code.

Not a good experience, but the only thing you should do some time in the next few days, is taking the time to solve it on your own. You can take this unsuccessful experience and become a better problem-solver because of it.

Here’s what I like to do (similar to the approach in CTCI):

Right after your interview, write down any details you can remember about the question.
Go ahead and take your time to solve it. If you need resources, or you need a few Google searches, go ahead! You’re doing this to learn! Use the same approach you would in front of an interviewer (clarify, analyze, plan, implement, test).
Once you feel like you’ve found a good enough solution, identify the time and space complexity. Then, identify some possible improvements (a few Google searches will help here too!).
Make any improvements you can. Are you happy with your solution?

2. Identify Points of Failure (the Bad)

After you’ve come up with a new and better solution, it will make the mistakes you made during the interview more evident to you.

Write down what you think didn’t go so well:

Did you communicate your thinking and process out loud in an efficient manner to the interviewer?
Did you write an algorithm that worked for all given inputs? Or did you need to often re-iterate your solution for it to work for all the cases?
Were you careful in the naming you used for variables? Was your code clean and focused, or was it messy and contained duplications?

By identifying these impediments that happened during your interview, you can tackle them and improve on them.

3. Recall Anything That the Interviewer May Have Taught You (the Good)

Now that you’ve identified the bad, use it to become better.

All the best interviewers will mentor you to better programming during the interview itself.

Let’s focus on one example to understand this approach:

Were you careful in the naming you used for variables? Was your code clean and focused, or was it messy and contained duplications?

This has happened to me before. The interviewer pointed out that my code didn’t contain meaningful names and gave me the chance to correct them! I didn’t realize how much bad naming had an impact on my understanding of the code I was writing, i.e. getting confused between different variables.

This small exercise that the interviewer made me do of giving my variables meaningful names took two minutes but might stick with me my whole life!

A bad example

Here is a block of code to get the factorial of a number, using Python, where we use random naming for variables and function names.

a = int(input("Enter number:"))

def fact(a):
  fact = 1
  i = 1
  while i <= a:
    fact = fact * i
    i = i + 1
  return(fact)

fact(a)

The reason why this is a bad example is that the lack of precision in naming might not seem so bad in a small program but as your program gets slightly more complex, it might become difficult to recognize which variables refer to what.

We might confuse “a” with “i”, we might even confuse the function name “fact” with the variable “fact” as they have the same name.

This is an example of a bad practice to show your interviewer and can even be an identifier for you to not be selected out of other candidates because it is such a basic but essential concept in programming.

A better example

We can improve our code by giving meaningful names related to our intentions. We can also avoid using the same name twice.

user_input = int(input("Enter number:"))

def factorial(user_input):
    result_fact = 1
    i = 1
    while i <= user_input:
        result_fact = result_fact * i
        i = i + 1
    return(result_fact)

factorial(user_input)

You can read more about cleaner practices in Clean Code: A Handbook of Agile Software Craftsmanship, a very detailed book that will definitely train you to become a better programmer.

4. Understand What This Process Has Taught You About the Company Itself

The interviewer says a lot about the company itself. Anytime you are going in for an interview, you are just as much interviewing them. The interviewer could be your next mentor or manager.

This can go in two directions:

Was the interviewer grilling you with difficult questions, leading you to inevitably fail? Did the interviewer not help you or guide you in any way to get the solution? Did they not provide any feedback for improvement?
Was the interviewer challenging you in a positive way and continued to help you when you were stuck for a long time? Did they offer positive reinforcement?

How the interviewer communicates with you, offers guidance, and shows mentorship throughout the interview has a high correlation with how they actually help others in their day-to-day work.

This is something to look for, and to help you assess the company’s processes and culture and whether you want to work for them or not.

5. Solve This Challenge With Another Language

You “failed”, you learned, you did better. Now what? Go the extra mile and solve the question in another programming language that you haven’t used in a while!

Conclusion

It’s important to learn from every experience, good or bad. These steps can become second nature to you after multiple coding interviews and you’ll be repeating the process until you’ve mastered these interviews!

At the end of the day, technical interviews are just that. Interviews. A somewhat flawed process that doesn’t work for everyone.

It also doesn’t determine your abilities or your worth as a programmer, so don’t burn yourself out. Some things are out of your control, but determination and hard work definitely play a role in getting your dream job!

下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/

emoji-minesweeper

开源日报第589期：《表情扫雷 emoji-minesweeper》