開源日報每天推薦一個 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》