开源日报 - Page 40 of 262 - Open Source Daily

开源日报第882期：《样例 Compose-samples》

1 9 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《样例 Compose-samples》
今日推荐英文原文：《My Advice After Interviewing 100+ Software Engineers》

今日推荐开源项目：《样例 Compose-samples》传送门：项目链接
推荐理由：该项目包含许多使用 Jetpack Compose 搭建安卓应用的示例。Jetpack Compose 是安卓用于构建 UI 的一种新方式,采用代码而非 xml 文件的方式。
今日推荐英文原文：《My Advice After Interviewing 100+ Software Engineers》作者：Hugo Rocha
原文链接：https://medium.com/swlh/my-advice-after-interviewing-100-software-engineers-e34bc3cbc669
推荐理由：一个面试官给软件工程师的一些面试和工作上的建议。
My Advice After Interviewing 100+ Software Engineers
This awkward and stressful thing between emerging a hero after completing the 12 labors of Hercules and the pointless successive hula hoops jumps of a circus trained animal, which we lightly call job interviews. We all hate them, yet they are an unavoidable fact of our professional lives.

When for the first time I ventured naively into the uncomfortable and inhospitable world of software engineering technical interviews, it didn’t take long for me to feel that judging a software engineer’s ability in 2 or 3 hours is as accurate as cruentation.

However, I always wondered how it was to be like the one sitting on the other side, what it takes to understand if an engineer is a good fit for the role. For the last couple of years, I conducted over 100+ software engineering technical interviews, and although each company has its unique process, there are common pitfalls people tend to fall. Here is my honest advice on how to avoid them.

The good software engineer

“The road to success and the road to failure are almost exactly the same.” – Colin R. Davis
There isn’t a unique definition for a good software engineer. It relates to the needs of the role and the diversity and maturity of the company. A recent startup would undoubtedly need a short time to market, while a more mature company that grew to a large customer base would probably be facing some scaling and architectural challenges. Building product while understanding what makes sense to the business is different than solving complex technical challenges. A detailed perfectionist engineer is different from a fast iterating one. You need to understand what the company is looking for and frame your behavior and discourse into that mindset. Don’t do a one fits all CV, instead adapt it to that reality. If you have to do a pitch (in a way, you always do one formally or otherwise), frame it in a way that you show how you will be an asset to that specific company. You should understand the necessity the role is trying to fill and ask yourself if that motivates you if it does then embrace it. You should figure what the “good” definition looks like for the company’s context and show how your knowledge, experience, and attitude fits in that definition.

Do your homework

“By failing to prepare, you are preparing to fail.” – Benjamin Franklin
Going on an interview without having a clue about the company it’s like going on a date and talking only about yourself, doesn’t mean there won’t be a second date but doesn’t give a good impression. Put in the effort to learn about the business, its objectives, it’s mission, strategy, and results. I would never fail someone for not knowing anything about it, but it is a hint of the candidate’s motivation. Also, it is a standard criterion HR tends to evaluate. Besides business goals, be sure to check the company’s tech blog if they have one and know their tech stack. Not very often candidates show legitimate interest for the company, but when they do, it is an excellent way to stand out.

Have a critical sense

“It is the mark of an educated mind to be able to entertain a thought without accepting it.” – Aristotle
I’ve met exceptional technical experts throughout my career and they were all kinds of different people. Still, all of them had at least one thing in common; they were the ones who defied the status quo and made the processes and technologies improve. So many candidates, when asked if they have questions, have nothing to add. Avoiding asking questions is a wasted opportunity, grab that moment to ask about the technical decisions the company made and the challenges they are facing and discuss the tradeoffs of each technology.

Examples:

Are they considering moving to HTTP/3 yet?
Are they moving to an event-driven microservice architecture? What kind of message broker are they using? Why not use Kafka instead of RabbitMQ?
What kind of database technology are they using? What was the use case? Would ElasticSearch be a good alternative to SQL in that use case?

And so on. Questioning the technical decisions will show that not only you know these technologies and can argue when they should be used but also that you can think critically and ultimately care about improving whatever applications you work with.

Technical challenges

No amount of experimentation can ever prove me right; a single experiment can prove me wrong. – Albert Einstein
The ungratefulness and straight-up unfairness of the current technical interview state is appalling. Most processes involve solving some kind of algorithmic problem related to computer science fundamentals like a graph search or sorting algorithm. I find anecdotal that a candidate has to implement a tree transversal algorithm with a minimal resource footprint so that when he gets the job, the first thing to do is to debug a ten-year-old monolith. As both a candidate and interviewer, I find this pretentious attempt to glorify the complexity of our work disheartening. These types of challenges are very likely to dismiss senior developers who don’t have these concepts fresh on their minds, even though they might have paramount experience in the role.

I agree these types of exercises aren’t entirely useless; the ability to solve small problems fast relates to the ability to solve complex problems that sprawl over several days, but they are fundamentally different. The interview process should reflect the best it possible can the reality of day to day work. Some processes include finding and patching bugs on a real application, pair to pair programming, or implement automated tests that I find much more adequate than an esoteric algorithmic problem. For these types of situations, be sure to feel comfortable with the company’s language of choice, and don’t be afraid to ask questions to understand the full picture of the challenge.

For most processes though, you will be faced with some kind of algorithmic or data structures problem, no way around it unless to have a sound knowledge of computer science fundamentals. Resources like the book Cracking the coding interview, Leetcode, or Pramp can be good references.

Either way, be sure to explain your reasoning out loud. Usually, problems build atop of each other, it doesn’t matter if you fail in a subject as long as you can ace the rest of the problem. The interviewer will help you if you get stuck, it is crucial to see a candidate recover from a less-known subject and do well on the rest. Also, an experienced interviewer might change from questioning to teaching when you struggle, don’t interpret this change as a failure; the changing of context helps unblock most people.

The interviewer is there to help you as well as to evaluate you, not to judge you. See him as an old colleague that is mentoring you on a problem. Make sure to discuss the various solutions and tradeoffs; it will show how knowledgeable you are with the subject.

Don’t get demotivated

Success consists of getting up just one more time than you fall. – Oliver Goldsmith
I once had a candidate who was very shaky and unsure during the interview. Despite being insecure and second-guessing himself, he did well so he still got hired. However, after settling, on the day to day job, he was extremely confident, able to lead discussions, and guide the team on technical subjects. Later I asked him how come he had such a diffident attitude during the interview. He then explained to me that he had a string of disastrous interviews and at the time wasn’t coping too well with the rejection. Rejection is a part of the process and you can’t let it get to you.

It simply isn’t possible to evaluate every single ability relevant to a software engineer in a few hours. Each process chooses the relevant ones for the company and tries to evaluate them the best way possible. Which can be the ones you excel at or not.

Bad hires are tough for the company, especially the team they join in terms of morale. They also have a significant cost. Add that to many companies not having a standardized process (the point is comparing candidates, so every interviewer should tackle the same subjects, and there should be a defined process, equal for every interviewer) and you are left with a significant percentage of false negatives. Doing bad on an interview doesn’t mean you’re bad. It means that the abilities you showed weren’t the best for that process at that given time.

I know, when I fail and read or listen to something like this, I always think it’s bullshit. All my life I’ve always tried to be a fighter. However, there were times that I lost too many fights. A fighter that is always losing is nothing more than a punching bag. But sometimes you have to find that inner strength to drag yourself out of the wreckage where you have given in. To get up, raise your hands and fight one more time and not let the failure get to you.

It’s all about passion

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it.” – Steve Jobs
As we make our way through the confusion and chaos of our daily lives, we thirst for those moments of clarity, where time bends and reality fades as we lose ourselves in a challenge or a task. In those moments of transcendence, a whole lifetime can pass you by without you even noticing. That’s what programming is to me and so many of us, that everlasting and unwavering passion that is chiseled in our core. And that same passion is the secret ingredient to success.

I saw candidates ace our interview process to only be average on the role they were hired for. They weren’t bad, they were talented and knowledgeable, but they just performed averagely. Sometimes you are good at things you don’t really care for, but it’s that passion that will drive you to succeed. It’s not easy to rate a software engineer’s passion. But if I asked you what kind of side projects you have or what was the best project you ever worked on, you would probably be able to eagerly discuss a handful of projects for a whole afternoon. It doesn’t matter if it was a platform with millions of users or a side project that barely works. A passionate programmer would enthusiastically describe every pattern he applied, every challenge he conquered, even every hack and failure, with joy and nostalgia. Then any interviewer would know, the guy across the table is just like him, a fellow programmer hopelessly passionate about coding.

It is a very authentic reaction; you almost can see it on their eyes and body language. Either you are passionate about it, or you aren’t. If you are, be sure to talk about those projects that move you, that can be the difference between an average interview or an excellent one.

Wrapping up
I always felt that the stressful part of being a candidate was knowing I needed to get the job and to prove myself I was good enough. The role of the interviewer isn’t completely deprived of stress, the interviewer needs to be sure to have strong reasons to either approve or fail someone so the decision can be audited, in my case, it always is, especially by my conscience.

Most interviewers had to be interviewed at some point so odds are they are sympathetic. I hope I helped to shed some light on the view from the other side, and I honestly hope my advice will help you get the job you really want.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第881期：《Material Dashboard》

31 8 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《Material Dashboard》
今日推荐英文原文：《Zuckerberg: Facebook’s failure to remove militia page sooner was an ‘operational mistake’》

今日推荐开源项目：《Material Dashboard》传送门：项目链接
推荐理由：Material Dashboard 是一个开源的 Material Bootstrap Admin，其设计灵感来自谷歌的 Material Design 。Material Dashboard 基于 Bootstrap 4 ，并附带了一些特别设计过的第三方插件以适应其余元素。
今日推荐英文原文：《Zuckerberg: Facebook’s failure to remove militia page sooner was an ‘operational mistake’》作者：Queenie Wong
原文链接：https://www.cnet.com/news/zuckerberg-facebooks-failure-to-remove-militia-page-sooner-was-an-operational-mistake/
推荐理由：美国的种族抗议再度掀起波澜. Facebook 首席执行官马克・扎克伯格（Mark Zuckerberg）告诉员工，该社交网络未能删除由民兵组织 “基诺沙卫队” 创建的页面，然后因 “操作失误” 在威斯康星州的一次抗议示威中枪杀. 不知社交软件接下来会采取什么样的行动控制舆论.
Zuckerberg: Facebook’s failure to remove militia page sooner was an ‘operational mistake’
Facebook CEO Mark Zuckerberg told employees that the social network failed to remove a page created by a militia group called the Kenosha Guard before a deadly shooting at a protest in Wisconsin because of an “operational mistake.”

Facebook users notified the company of an event organized by the Kenosha Guard that issued a “call to arms” before racial justice protests in Kenosha, Wisconsin, The Verge reported this week. Users reported the event for inciting violence, but received messages stating the content didn’t run afoul of the social network’s rules. BuzzFeed, which viewed an internal report, said the Kenosha Guard event was reported to Facebook at least 455 times.

Protests erupted after Jacob Blake, a 29-year-old Black man, was shot seven times in the back by Kenosha police during an arrest on Sunday and became paralyzed. On Tuesday, two protesters were shot to death and another person was wounded during a protest in that city. Kyle Rittenhouse, a 17-year-old resident of Antioch, Illinois, was accused of killing the two protesters. He was arrested and charged with first-degree intentional homicide and other criminal counts.

Zuckerberg admitted Facebook made the wrong call by not pulling down the Kenosha Guard and event sooner. The page and event did violate new rules the company rolled out last week about “Dangerous Organizations and Individuals,” Zuckerberg told employees in a video posted on his Facebook page on Friday. Under those rules, Facebook would remove accounts, pages and groups formed by organizations and movements that pose a threat to public safety if they discussed potential violence.

Zuckerberg told employees that the team that reviews dangerous organizations and individuals has to understand the “nuances” of how militia groups and conspiracy theory movements work.

“The contractors and the reviewers who the initial complaints … were funneled to … basically didn’t pick this up,” he said.

After reviewing the content again, the company pulled down the Kenosha Guard page on Wednesday after the deadly shooting. Facebook hasn’t found any evidence that Rittenhouse followed the Kenosha Guard Page or that he was invited to the group’s event. But Facebook’s failure to remove the page more quickly sparked scrutiny from civil rights groups and the company’s employees. Facebook’s employees criticized Zuckerberg’s leadership and questioned whether the company was doing enough to combat hate speech during an internal virtual meeting on Thursday, BuzzFeed reported.

“At what point do we take responsibility for enabling hate filled bile to spread across our services?” one employee reportedly said during the meeting. “[A]nti semitism, conspiracy, and white supremacy reeks across our services.”

The backlash from employees shows that discontent over the company’s content moderation decisions continues to grow. In June, Facebook employees staged a rare virtual walkout and publicly criticized Zuckerberg after the social network left up a post from President Donald Trump they said could incite violence. In the post, Trump wrote “when the looting starts, the shooting starts” but Facebook determined those remarks didn’t violate its rules against inciting violence. Trump also made the same comments on Twitter but his tweet was labeled for violating the site’s rules against glorifying violence.

Facebook didn’t immediately respond to a request for comment, but spokeswoman Liz Bourgeois told BuzzFeed that the Kenosha shooting was “painful for everyone, especially our Black community.”

“The Kenosha Guard Event and Page violated our new policy on militia organizations and have been removed on that basis. We launched this policy last week and we’re still scaling up our enforcement of it by a team of specialists on our Dangerous Organizations team,” she said.

Earlier this month, Facebook said it took down 790 groups, 100 pages and 1,500 ads tied to the right-wing conspiracy theory known as QAnon that falsely claims there’s a “deep state” plot against Trump and his supporters. Civil rights groups organized a campaign this year calling on businesses to stop buying ads on Facebook in July, until the social network does more to combat hate speech.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第880期：《命令行谷歌 googler》

30 8 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《命令行谷歌 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).
I find it useful to spend ten minutes thinking about your solution. You never want to be in a position where you are in a 45-minute interview, and for 30 minutes you’ve been coding out your solution. Once you finish coding, the interviewer may say something like, “your solution doesn’t seem to work for this edge case, how can we change your solution to work here?” Maybe it’s a simple fix, but what if your algorithm is fundamentally wrong? You’ll then only have 15 minutes left to rethink your whole solution, which can be highly stressful and probably means you won’t be passing the round.
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://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第879期：《构建桌面应用 Wails》

29 8 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《构建桌面应用 Wails》
今日推荐英文原文：《A Better Question Than ‘What Makes You Happy?’》

今日推荐开源项目：《构建桌面应用 Wails》传送门：项目链接
推荐理由：Go 主要用于构建 API、web 后端和 CLI 工具，但同时，我们也可以通过 Wails 框架用 Go 和 Vue.js 构建一个桌面应用程序。
今日推荐英文原文：《A Better Question Than ‘What Makes You Happy?’》作者：Niklas Göke
原文链接：https://forge.medium.com/what-do-you-hate-not-doing-b9f8882818da
推荐理由：我们时常会思考什么真正是我们快乐，但是不妨换个角度思考：如果没有什么，我们会不快乐。通过第二个问题可能得到更加重要的答案，因为快乐的源泉可以很多。
A Better Question Than ‘What Makes You Happy?’

Tuning into your anger can help you discover your real life’s work
When I go too long without writing, I get angry. I sense it every time I get caught up in other commitments and realize I haven’t written an article or journaled in a while. I feel on edge, as if there’s something bottled up inside me.

According to the entrepreneur Derek Sivers, I should lean into that anger. “What do you hate not doing?” he asks in his book Hell Yeah or No. “What makes you feel depressed, annoyed, or like your life has gone astray if you don’t do it enough?”

If you’re trying to discover the work you should build your life around, Sivers explains that this double-negative question seems to deliver better ideas than the generic “What makes you happy?”

Why? Because chances are, you won’t find that golden career path if you’re only searching for happiness. You’ll follow every distraction and seemingly attractive opportunity if what you’re after is a fleeting thrill.

Aiming for happiness also doesn’t narrow the field enough. If you’re a generally positive person, you’ll always find some happiness along the way, no matter what type of work you do. How happy you are is more a reflection of the habits you’ve cultivated in your life — optimism, hope, humility — than your occupation.

I can find happiness in a lot of work that is not writing. I enjoy setting up meetings. I have fun choosing artwork for my articles. I find satisfaction in analyzing traffic reports. But none of this means I should pursue these things as a career.

What if instead of asking yourself what makes you happy, you tuned into what makes you angry? When you’re deep in the flow of a design project and someone interrupts you, do you become furious? When you’re caught up in the administrative tasks that come with being a freelance photographer — and not out there shooting photos — do you start to feel anxious? When you’re not standing inside a classroom teaching a room full of students because of the pandemic, do you feel like something inside you is going to explode?

What do you hate not doing?

My commitment to writing is irrational. It does not make sense financially or emotionally. I should not want to write this much. But I do. If I’m not writing, whatever I’m doing instead starts to feel like an annoying barrier to my real life’s work.

I already knew writing makes me happy. Now I’m realizing how much not writing makes me unhappy. That might be the most valuable lesson of all.

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

开源日报第882期：《样例 Compose-samples》

My Advice After Interviewing 100+ Software Engineers

The good software engineer

Do your homework

Have a critical sense

Technical challenges

Don’t get demotivated

It’s all about passion

Wrapping up

开源日报第881期：《Material Dashboard》

Zuckerberg: Facebook’s failure to remove militia page sooner was an ‘operational mistake’

开源日报第880期：《命令行谷歌 googler》

How You Practice With Leetcode for Interviews Is Probably Bad

I’ve experienced it first-hand

1. Clarifying Ambiguity

2. How Do You Respond to Feedback?

3. Communication

4. Coding Ability

5. Understanding Tradeoffs

My Specific Gripes with Leetcode and How To Optimize Your Time Using It

Conclusion

开源日报第879期：《构建桌面应用 Wails》

A Better Question Than ‘What Makes You Happy?’

Tuning into your anger can help you discover your real life’s work