开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《合成大西瓜 bigwatermelon》
今日推荐英文原文：《The Worst Mistake You Can Make in a Technical Interview》

---

今日推荐开源项目：《合成大西瓜 bigwatermelon》传送门：项目链接
推荐理由：虽然不知道为什么但是最近流行的这个游戏想要获得高分着实需要些技术成分，这个项目自然也是一种技术成分——直接给游戏增加了更换水果的新功能，这个项目还另外还拉了一个未改动过源码的分支以供后来者继续改出各种各样的新要素进去。

---

今日推荐英文原文：《The Worst Mistake You Can Make in a Technical Interview》作者：Mandi Gunningham
原文链接：https://medium.com/better-programming/the-worst-mistake-you-can-make-in-a-technical-interview-fd04dc67510a
推荐理由：尽管在面试过程中的话题应该尽可能掌握在自己的范围内，但也不要为自己说不了解而感到过于担忧

The Worst Mistake You Can Make in a Technical Interview

Interviewers aren’t robots, but they can read you like a polygraph machine

One thing that the tech industry can agree on is that technical interviews suck. Unfortunately, we also agree that they are necessary.

The ideal compromise is that applicants will prepare for technical interviews and employers will not try to stump us. This is the way most of my technical interviews have gone, and I always let my interviewers know that I appreciate their humanity.

On the other hand, we’re all human and we make mistakes. If there is one mistake you can avoid during an interview, though, it should be this: Do not speak to a topic that you do not understand.

This can be difficult advice, but it’s crucial to remember while you’re sitting across the table from the hiring manager with your adrenaline pumping. Buzzwords are not your friend.

What To Expect

I have not interviewed somewhere like a FAANG, where technical interviews go on for hours and days. That’s not my bag. I do, however, have pretty broad interview experience with various tech companies, from startup to Fortune 100.

In my experience, interviewers are usually rooting for you. They are not trying to stump you or stress you out. They need you to be as comfortable as possible so that they can properly evaluate your skill level.

Therefore, during a typical interview, they will likely ask questions at varying levels of difficulty on different technical topics that are relevant to their workflow. If they touch on a topic or technology that you’re not comfortable with, you need to be prepared to confidently say “I don’t know.”

This is important for multiple reasons. First, by being willing to state that you don’t know the answer, you show your ability to be humble. No one wants to work with a know-it-all. Also, it’s clear when you don’t actually know, so don’t try to fake it till you make it in this scenario.

On that note, being willing to admit when you don’t know something gives the interviewer an accurate assessment of your skill level. No one knows everything, and they don’t expect you to. If you know a little, definitely say so, but don’t let it get away from you. Otherwise, throw in something like “I’d have to research that” or “…but I’d love to learn more about the topic” to let them know you can take the initiative.

Finally, in my opinion, here’s the most important reason to admit to not knowing an answer: It keeps you from rambling on incoherently. You know the phrase from your 1000-level creative writing class, “show, don’t tell”? Well, this is the opposite. Don’t show them how little you know about the topic, just give them a quick “Hmm, I’m not familiar with that concept — I’d have to do some research” and move on. As long as that’s not your answer to every question, they will respect it.

Resist the Urge!

Now, with all of that in mind, here is my even better advice. Don’t bring up a topic just to get in a buzzword.

We all know tech industry meetings are often just a jumble of buzzwords and acronyms, but don’t let that be your interview. Speak clearly about the topics you do know, and don’t go throwing around buzzwords just to sound like you’re with the times.

You should only bring up a topic if you can confidently answer the follow-up: “Interesting, tell me more about that.” If that is scary to you, just drop it.

Be aware, I’m only giving this advice because I’ve made this mistake myself and it literally cost me a job offer. Obviously, no one intends to commit this faux pas, but when under pressure and unable to answer a question, it’s in our human nature to BS just a little. Resist the urge!

Embarrassing Story Time

Now that you’ve got the idea, learn from my cringe-tastic experience!

I got lucky with my first developer job and got into the company via some solid networking. There was an interview process, but it was not an intense technical challenge. Therefore, when it came time to start looking for my next role, I was not very practiced with code screenings and technical challenges.

Early on in the process, I got an interview with a large company for a data-driven, machine learning role. It had been a few years since I graduated at that point, so my algorithmic knowledge had degraded. I started studying up on my data structures, algorithms, and all that jazz.

I aced my first two interviews, which were more personal, less technical. They comprised problem-solving and general situational questions. That is my strength — I can spin any experience into a life lesson learned. And honestly, it’s not just spin, but that’s a topic for another time. We’re talking technical today.

Finally it came time for the technical interview. This was to be my second-ever technical interview, and I expected it to be more in-depth than my first. I was nervous, to say the least!

The interview began with a code challenge. I was given lines of code that were out of order, and I had to put the lines in order to create a functioning algorithm. Not super difficult, but stressful nonetheless — it included at least one nested loop, and with no context that’s more confusing than you’d expect!

Either way, I did very well on this part. One of the interviewers even said that I did better than he had during his interview! I was feeling encouraged at that point.

Next it was time to discuss the code. It was a very simple encryption algorithm, more string manipulation than anything, so I was able to keep up. Eventually, though, we got to the dreaded question: How could we improve this code?

I floundered. I took my time to read through the code again. I made a suggestion — something about stronger encryption. Not what they were asking.

Then I made the dreaded mistake. I suggested that since there was a nested loop that it would be possible to improve the time complexity. Now, I knew something about the topic, enough to know that, generally, nested loops are not super-efficient.

However, I didn’t know enough to hold an intelligent conversation or actually suggest an improvement. The interviewer was giving me nothing. I said we could improve the time complexity, and he said, “Interesting, how?” That’s the moment where I could have gracefully backed out by stating that nested loops generally weren’t efficient (tell them what you do know), but that I didn’t have an improvement off the top of my head (no bullshit).

Obviously, I didn’t do that, though, or this story would be very different. He was trying to ask illuminating questions and point me in the right direction, but I was officially in panic mode. We went around in a few circles before I finally tapped out. It was embarrassing, to say the least.

The interview ended pretty much at that point. I don’t even remember them asking me any more questions. I knew it was over at that point. I didn’t get the callback and finally heard from my recruiter that they were passing on me.

Life Lesson Learned

Honestly, I don’t regret it. I learned a true life lesson from that interview. Here’s my spin: I learned that confidently stating what you don’t know is humble and necessary at times. I have never made that mistake again.

I also went and watched a few tutorial videos on time complexity the next day. The topic came up in the interview for my most recent role, and I was able to discuss it intelligently. I calculated the complexity for an algorithm I had written and confidently stated that there was not a more efficient alternative.

That felt good. It felt like redemption.

On the other hand, my current role is full-stack while my previous roles have been purely data-driven backend. So when the topic of JavaScript and React came up, my go-to response was, “I don’t know — I’d have to look that up.” Everyone was okay with that, and the interview moved on.

Here’s the Recap

• If you don’t know the answer, say so!
• Do tell them what you know about the topic, but stop short of BSing.
• Study up afterward to be more prepared in the future.

Good luck out there!

---

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