开源日报 - Page 159 of 262

开源日报第408期：《代码树 octotree》

27 4 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《代码树 octotree》
今日推荐英文原文：《A Guide to Building Your Own Technical Interview》

今日推荐开源项目：《代码树 octotree》传送门：GitHub链接
推荐理由：在使用 GitHub 的时候如果想要了解仓库的结构，最好的方法就是把仓库变成本地文件——浏览器上要一个个的点开是很麻烦的。但是现在这个项目可以解决这个问题，它会像自己平时写代码时一样在浏览器上展开 GitHub 仓库的代码树，在阅览仓库的时候可以省下不少功夫。

今日推荐英文原文：《A Guide to Building Your Own Technical Interview》作者：CSPA
原文链接：https://medium.com/@cspa_exam/a-guide-to-building-your-own-technical-interview-95c32f1d43d2
推荐理由：终于有一天你也有足够的能力了，然后轮到你去面试那些新人，这篇文章就是介绍面试别人的方法
A Guide to Building Your Own Technical Interview
What’s the difference between Fizz Buzz and a Traveling Salesman variant? What about whiteboarding, live coding, and take-homes? Is it merely “difficulty” and format? Or is it something more that most interviewers don’t think about? Unknown to some, having technical skills is quite different from assessing technical skills. In other words, being a great engineer does not automatically imply competence in interviewing for great engineers. Realizing this is the first step to designing good technical assessments. In this post we will cover the many different ways to assess technical skills. Whether you’re a company looking to hire new talent, a recruiter looking to screen potential clients, or even a coding school looking to write an entrance exam, this post will help you better achieve your goals.
Motivation
It’s not uncommon to hear programmers’ frustrations with the current state of the interview process [1] [2] [3]. If you want to hire top talent, you have to understand the pros and cons of how you’re interviewing your candidates. No technical assessment is perfect, and you need to account for the imperfections in your own. Another motivation is maintaining a professional persona. Poor interviews can cause your candidates to lower their perspective of your company. Instead, you should aim to give an excellent interview — excellent enough for your candidates to recommend your company to their colleagues, even if they don’t fit the role. Lastly, you don’t want to design a technical assessment without any kind of study. If you do, you’ll almost certainly design an assessment with problems— uninformative results, false negatives, and even unintentional bias.
Overview
After going through this post, you should be more proficient in:
- Articulating the purpose behind each technical question you ask
- Specifying what it means to answer a question correctly / incorrectly
- Minimizing the bias as you design your problems and questions.
And to acheive these goals, we will go over:
- Two Conflicting Approaches to Designing Assessments
- Common Types of Technical Interviews
- Assessment Design Guidelines
- Putting Your Technical Assessment into Practice
Two Conflicting Approaches to Designing Assessments
Not all assessments have the same goals. Consider a college math professor grading final exams. The professor has two main approaches to choose from: a normative assessment, and a qualification assessment.
Normative Assessments
The method of a normative assessment is to pit students against each other, usually by the use of a curve. This type of assessment aims to be high enough in difficulty to achieve a normal distribution of graded scores, thereby limiting the number of students who get top marks. When it comes to the software industry, everyone wants to hire “the best”. But issues arise when attempting to put this into practice:
- What is “the best” in software engineering, and how do you quantify it?
- Upon deciding how to quantify it, unless you have a standardized platform like CSPA, a normative technical assessment is probably impractical; you need a large number of test-takers b+re your data becomes informative.
- Even if you do use a standardized assessment platform, unless you are a large corporation, you may not be able to afford the top X% in the first place. A qualification assessment (explained in the next section) might better suit your needs.
Normative assessments correspond academia’s norm-referenced tests. In most cases, a qualification assessment will be strictly better for the goals of hiring software engineers. Aside: One plus to normative assessments is they can level the playing field with regard to credentials. For example, a self-taught programmer without a college degree can prove themselves by scoring a high mark.
Qualification Assessments
Instead of comparing against peers, a qualification assessment tests whether or not a candidate is ready for a specific skill or role. Aside: Qualification assessments correspond to criterion-referenced tests in academia. Qualification assessments have several benefits:
- They can be directly related to the role you’re hiring for.
- Their focused scope makes them easier to write and maintain.
- They are less likely than normative assessments to push away good candidates.
Keep in mind that in order to achieve fair, unbiased, and informative results, qualification assessments must be designed exceptionally well. The goal of this post is to help you do just that. Note: Although many points will also apply to normative, the rest of this post will be primarily applicable to qualification.
Common Types of Technical Interviews
Although there is currently no standard for technical interviews, you’ll find many patterns if you study industry trends. Here’s a list of some of the most common formats, ordered from least to most useful (in our opinion):
- Whiteboard Problems
- Technical Details
- Live Coding
- On-site pair programming
- Take-home Projects
If you’re constructing your own technical assessment, you need to be familiar with the pros & cons of each one.
Whiteboard Problems
Whiteboard problems — also known as whiteboarding — is one of the lowest candidate-rated interview formats, yet is among the most frequently used. Whiteboard problems assess a candidate on their ability to solve a problem “on the spot”, using only a whiteboard and a dry-erase marker, all within a limited amount of time. Candidates are typcially not allowed to use research tools, although sometimes they can ask the interviewer questions. Whiteboarding attempts to assess a candidate’s problem-solving skills. However, due to its constraints, this goal is hard to meet:
- Limited time. Whiteboard sessions are usually 30–60 minutes. If a candidate does well, it could be due to their problem-solving skills, but could also be because they’ve seen a similar problem before. If a candidate does poorly, that doesn’t imply they have poor problem-solving skills; they may have done well in more realistic conditions that allow more time, uninterrupted pondering, use of Google, etc.
- Subjective impression. Defining a useful, objective metric for a whiteboard problem is difficult. If the metric is “they solved the problem”, then you are filtering for candidates who have seen your type of problem before. If the metric is to “see how they think”, then you are filtering for candidates who appeal to the subjective impression of the interviewer.
- Low Relevance Unless the role involves a high amount of algorithmic problem solving, whiteboarding may be filtering for irrelevant skills. This is often demonstrated by how much an interviewer has to study before conducting a whiteboard session.
Whiteboarding has a significant risk to filtering out top candidates. Given the choice, we recommend using one of the other formats described in this guide.
Technical Details
The technical details format intends to gauge how well a candidate knows a technology that they will likely be working on. The idea is, if a candidate can answer questions sufficiently, then they have competence in that subject. This format has its benefits:
- Low commitment. This format is quick and simple to execute.
- Least resistance. No candidate will think this format is unreasonable.
- Effective screening. This highly depends on how skilled the interviewer is at asking questions, however.
Like all others, it has its cons:
- Low information. Talking about coding is different from actual coding. It’s possible someone can talk well but not program well.
- Subjective impression. The assessment boils down to “do they sound like they know what they’re talking about?”
- Reliance on familiarity Because the tech world is vast with knowledge, there is no way one can know everything about anything. It’s possible that two experts in one domain may know very different things. Thus, a candidate not knowing the answer to a question does not necessarily imply lack of expertise.
- Vulnerable to inconsistency. Is the interviewer asking quality questions or technical trivia? Is the interviewer following a standard script to maintain consistent assessment across candidates?
Asking technical details is certainly useful, but should not be the sole format in a technical assessment. There are ways to mitigate its cons, as we’ll explore how in a future section.
Live Coding
Live coding is an interview format where candidates are presented a programming problem, and then code the solution in real-time. This is most often done remotely. This format offers several benefits:
- Real coding. Unlike whiteboarding or abstract discussions, you get to see the candidate create real code.
- Available tools. A candidate can have access to tools like Google, making the coding session more realistic.
- Live debugging. You can see how a candidate responds to bugs and how they go about fixing them.
- Familiar Environment. Depending on how you conduct the session, the candidate may have access to their own text editor, and not be hindered by a foreign machine or an in-browser setup.
Live coding sessions can also go poorly:
- High pressure. Despite having relevant experience and skills, some engineers simply cannot perform under the specific type of stress in a live coding environment.
- Unfamiliar environment. Some online live coding solutions don’t account for editor environments, which will make your candidate seem slower than they really are.
- Low relevance. Companies often ask Project Euler-type puzzles, causing similar issues as other formats.
- Subjective impression. Similar to whiteboarding, if the metric is “they solved the problem”, then you are filtering for candidates who have seen your type of problem before (which is only bad if the problem is of low relevance). If the metric is to “see how they think”, then you are filtering for candidates who appeal to the subjective impression of the interviewer.
Live coding has the potential to be highly effective, but it’s also hit or miss, especially due to the personality of the candidate. If you decide to administer this format, we recommend you provide it as an option among one or more other formats to achieve the best results.
On-Site Pair Programming
On-site pair programming is like an improved version of live coding. As part of the interview process, candidates travel to the company for an on-site day of programming with current employees on production code. This format offers some good benefits:
- Real coding. Instead of showing how a candidate codes in a vacuum, this format shows how they work with actual code that other people wrote.
- Face-to-face interaction. The candidate works directly with the team while programming, allowing for higher quality feedback and assessment.
- High relevance. The candidate works with real production code, so there is little chance the interview will be irrelevant.
But also has some cons:
- Lack of domain knowledge. Your candidate will not be familiar with your exact production setup. Depending on your business, candidates may only be able to work on trivial parts of the app. You also might not see effective debugging (unless they’ve worked with your exact stack before).
- Unfamiliar environment. Candidates will be hindered as they won’t be able to use their own machine / editor, unless you grant them access to your codebase.
- Higher commitment. Companies often want their candidate to spend a half or full day with the team. This is higher commitment for the team as well as the candidate.
Ultimately, on-site pair programming is a good format for last-round candidates, but it’s high risk if you’re evaluating whether or not someone has technical ability in the first place.
Take-Home Projects
A take-home project is a format where a candidate receives a small project specification, perhaps with some starter code, and implements the spec remotely using their own machine and environment. Upon completion they submit their work to the company, either by email or source control. Take-home projects can be the most efficient way to evaluate a candidate’s technical ability — but with a catch. First the benefits:
- Real Coding. Like the previous two formats, take-home projects produce real code you can evaluate and discuss.
- Less stressful (potentially). Many top candidates do poorly when live coding under constant watch. Take-home projects are a way for them to better demonstrate their skills.
- Higher relevance. This format gives opportunity to assign a project that’s more relevant to the job than Euler-style programming puzzles.
- Familiar environment. Because this format is done at home, candidates are not hindered by unfamiliar setups or environments.
Take-homes do have some cons:
- Higher commitment. This is the catch mentioned earlier. Remember that you’re competing against other companies. Take-homes take hours to complete, and not all engineers — seniors engineers, especially — have the time to code more than one.
- Higher cost. Take-homes are full projects; they require more time from your engineers to evaluate, as they should look for qualities that aren’t covered by automated tests.
- Difficult to scope. It’s almost too easy to add requirements that increase the time required to too much.
If it were not for the high time requirements, we would highly recommend issuing take-homes by default. Instead, offer them as an option for candidates who don’t mind spending the extra time applying to your company. If your candidate agrees to a take-home project, prepare for a follow-up conversation. This is one of the best ways to assess technical ability — talking about code that the candidate has written themselves. Aside: Be sure to read the Evaluating Code Submissions section before conducting your follow-up conversation!
Assessment Design Guidelines
Now that we’ve covered some common technical interview formats, let’s move on to designing your own technical assessment. The primary goal of a technical assessment is to ensure technical competency. To do this you need to consider:
1. Choosing formats
2. Defining your criteria
3. Reducing potential bias
4. Testing
1. Choosing Formats
As explained earlier in the post, your assessment should be a qualification assessment and not a normative one. You should also strive to choose formats that will yield the largest pool of candidates. To do this, you must take into consideration:
- Relevance. Be sure to use techniques and ask questions relevant to the role, or candidates will be unhappy you’re wasting their time.
- Time commitment. Be conscious of how much time you’re asking for from your candidates. Too much time required will filter out good ones. For example, senior engineers are often older and have less time due to more life responsibility (family, kids, etc.)
- Stress. People respond to stress differently in different situations. A good candidate may do poorly in one interview format, but could excel in another.
Considering the above, offer more than one assessment format and allow a candidate to choose between them. By allowing your candidate to do their best in their own way, you will better identify top candidates that you may have missed otherwise.
2. Defining Your Criteria
Next you need to specify what a good candidate response looks like. This is a predefined list of relevant criteria that you use to judge each of your candidate’s technical responses. Similar to user stories, you need to define the purpose of each criterion you list. For example:
Our designer role needs to know responsive CSS so that they can implement the designs they create.
Writing each purpose like this will help you identify and remove criteria that may not be essential to the role you’re hiring for. This will save you time and money. For example, let’s say you are considering adding a criterion for gulp.js. You begin to write: “Our node.js engineer role needs to know gulp.js so that they can…”. Write gulp tasks? Use it on the command line? Perhaps this criterion is not as important as you first thought. After going through this process, you should have a list of criteria where each item is a specific point to test for in your assessment. Point System To reduce subjective bias, you should assign point values to each of your criteria. The following is a suggestion to model. Each criterion should have three defined outcomes:
- Full credit, where a candidate is awarded full points for the criteria,
- Partial credit, where a candidate is awarded a fraction of the full number of points (for example, half),
- And no credit, where the criterion is awarded zero points, due to the criterion being met close to not at all.
Each outcome should be clearly defined so that a grader can objectively chose one to match a candidate’s response. For example, if you’re assessing CSS qualification, a criterion might look like the following:
- [30 points] Responsiveness
- Full credit: Site is fully responsive from at least 320px in width
- Partial credit: Site does not gracefully handle some widths
As shown above, each criteria is well-defined for both full and partial credit. “No credit” should only be marked in extreme cases, and should be obvious to everyone when it is. Point System Benefits A response is almost never strictly “pass/fail”. Yet, restricting grading to “full/partial/none” helps reduce bias by only allowing three options for a grader to choose from. This is an improvement over, for example, a 100-point scale or a “five-star” system because there are fewer lines to judge by, and thus fewer opportunities for subjective bias. Example Here’s an example of a point system for a take-home project: Project: Implement a given photoshop design file in HTML & CSS Criteria:
- [30 points] Responsiveness
- Full: Site is fully responsive from at least 320px in width
- Partial: Site does not gracefully handle some widths
- [30 points] Use a CSS methodology
- Full: All CSS uses BEM, SMACSS, or OOCSS
- Partial: Only some CSS uses the above
- [20 points] Flexbox
- Full: An example of flexbox is used and works correctly
- Partial: An example of flexbox is used but has issues
- [10 points] CSS Tables (optional)
- Full: An example of CSS Tables is used and works correctly
- Partial: An example of CSS Tables is used but has issues
- etc.
3. Reducing Potential Bias
After you’ve defined and assigned points your list of criteria, you now need to re-review its effectiveness. Ask yourself these questions:
- Assuming all non-technical requirements are met, if a candidate meets all my listed criteria, does that imply a job offer?
- Are there any criteria that may be unintentionally bias against certain groups, thus limiting your potential pool of candidates?
- Are there any criteria that may be bias favoring your own technical familiarity that might cause false negatives?
Reducing bias is an important way of identifying top candidates that you would have passed on otherwise.
4. Testing
Before finalizing your technical assessment, you need to see how it fares against real engineers. Find a volunteer — perhaps a coworker, or someone you know — and have them run through your technical assessment as if they were a candidate. They will inevitably run into problems. Things like:
- Unclear directions
- Given code not working as it should
- Broken links
- Incorrect automated tests
- Solutions you didn’t expect or want
- And so on.
These sorts of problems can have a negative impact on your company’s brand, so make sure you iron them out before you invite your candidate to take your assessment.
Putting Your Technical Assessment into Practice
Designing a solid technical assessment is only the beginning. As you conduct it in the real world, be sure to keep the following things in mind.
- Be explicit about your expectations. If you have a point important enough to reject a candidate over, you should tell the candidate about that point as part of the project requirements.
- Assign engineers who have interest in interviewing & grading. Nothing is worse than a conducting interviewer who doesn’t want to be there. Grading should be assigned to a single person for better consistency.
- Ensure a proper interviewer mindset. An interviewer should not try to make a candidate feel bad or inferior. Instead, they should strive to make candidates feel great about your company, even if the candidate does not get an offer.
- Think big picture. When evaluating candidate code, don’t pay attention to things such as conventions, spaces vs tabs, functional versus imperative, etc. The coding styles at your company can be taught to any competent programmer; a candidate doesn’t need to code that way naturally in the first place.
- Verify what you think are flaws. If a candidate does something differently than you would, don’t immediately conclude it’s inferior! Use it as an opportunity to ask and discuss their alternative approach.
Conclusion
Designing a technical assessment is difficult. Done properly, you will widen your pool of candidates, properly identify the best ones for your company, and make great hires. Done improperly, you will cause frustration, miss out on top talent, and might even damage your company’s reputation. We hope this guide will be useful to you as you construct better assessments, and ultimately better experiences, for your candidates. Thanks for reading!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第407期：《没必要再用 print 来调试了 PySnooper》

26 4 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《没必要再用 print 来调试了 PySnooper》
今日推荐英文原文：《Tips for Effective Data Visualization》

今日推荐开源项目：《没必要再用 print 来调试了 PySnooper》传送门：GitHub链接
推荐理由：说到调试，相信调试器是一个很好的选择——断电和变量观察都是解决问题的好帮手。但是兴许有的时候对于一些尝试性的小玩意来说专门装一个调试器显得有些小题大做了……然后有些人就会在项目里加 print 来充当简单的调试器用。这个项目让你再也不需要一行行的 print（1）或者某个变量，只需要运行一遍，然后看看它的输出日志——变量的变化，当前运行的位置都一览无遗，这可比 print 管用得多。
今日推荐英文原文：《Tips for Effective Data Visualization》作者：Suraj Thatte
原文链接：https://medium.com/@sursthatte/tips-for-effective-data-visualization-d4b2af91db37
推荐理由：在数据可视化时如何提升观看体验
Tips for Effective Data Visualization

Data visualization has a strong design element to it. Given the differences in domains, applications and audience it’s hard to put a structure around the best way to visualize your data. However, there definitely are wrong ways of doing it! I have come across multitude of such instances which were a driving force behind this post.

In this article I’d like to share some useful tips to help prevent blunders in your visuals.
1. Choose the right visual
This one may seem too obvious! But I have seen several people trying to demonstrate their artistic side for no reason..
Always remember that “form follows function” — purpose of a visual should be the starting point of its design
Ask yourself — are you trying to compare values, show trends, explore distribution or relationship between variables? Then choose appropriate visual(s) depending on the message you are trying to convey.
Consider the following charts. The underlying dataset contains product complaints/defects. We are trying to show products that need attention with a defective rate ppm (parts per million) A bar chart is a simple yet effective way to display this data. One of the downside of tree maps and packed bubble charts is that is asks the reader to compare area instead of height which is visually taxing.

Choosing the right visual based on it’s function
2. Trivial are many but vital are few (data points)

Do not merely slap a visual on the dataset. Analyze and convert your data into an information ‘nugget’ that the audience can grasp.

The figure alongside shows a time series chart of a process variable. Line A-A’ shows a point in time when both period and amplitude changed which was the onset of an issue that utlimately led to the sudden dip in its value after a few cycles. Which chart does a better job at uncovering this insight?

The chart on the top simply converts the data into a visual whereas the one at the bottom “conditions” it to provide an insight.

Let’s say that we want to show total annual spend by project ID. There are 41 unique categories. Chart on the left looks crowded with all categories cramped in it. A better way to display this is to show the top 5 categories and combine the remaining into ‘others’ bucket.

Suppressing the “noise” in the data

Also, beware that filtering out the ‘others’ category may exaggerate the area of the pie chart or change the percent of total calculations. This can be misleading! While displaying percentages, always make sure that they add up to a 100% or explain why and what’s being excluded.
3. Figures don’t lie, but lairs figure!
Visuals should reflect reality and not distort it. Formatting of the chart plays an important role as it sets up a frame of reference for the audience.
In the example below, the yield of a process increased from 56% to 67% over a period of 6 months. Chart to the left is trying to overstate the improvement by formatting the y-axis to start at 50%. The latter visuals paints an accurate picture where y-axis starts off at 0 and also includes a goal line.

Figures don’t lie..liars figure!
4. Use color wisely
Use of color should be made to add more information or to highlight key data points in a visual. In all other cases, it’s redundant and distracting.
This article by Lisa Charlotte Rost has several pointers to consider while choosing a color scheme for your visuals. I would also recommend trying the Viz Palette tool developed by Susie Lu and Elijah Meeks.

5. How important are aesthetics as compared to functionality?
Visualization tools available today allow us to create most stunning and rich visuals in a few mouse clicks. However, over-doing the aesthetic elements may distract people from the key message of the visuals. One of the seven wastes in the Lean philosophy is ‘Over-processing’.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第406期：《响指 Thanos.sh》

25 4 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《响指 Thanos.sh》
今日推荐英文原文：《The dangerous rise of “crazy-busy” product managers》

今日推荐开源项目：《响指 Thanos.sh》传送门：GitHub链接
推荐理由：这不复联4最近正播着嘛……这个项目可以让你非常简单，轻松的变成灭霸一样的存在——对于你电脑上的文件来说，因为你可以弹指之间删掉一半文件，完全随机。在使用之前切记确认好使用环境——毕竟这是没有撤销键的，你不会希望在自己的常用电脑上来一下的。
今日推荐英文原文：《The dangerous rise of “crazy-busy” product managers》作者：Rian van der Merwe
原文链接：https://medium.com/elezea/the-dangerous-rise-of-crazy-busy-product-managers-d510333d7dca
推荐理由：很明显，过于繁忙并不是一个良好的状态——对于 PM 来说也是如此
The dangerous rise of “crazy-busy” product managers
Over the past few months I have become fascinated by what I like to call “crazy-busy PM” thinking in the product management world. I’m sure you’ve seen a few tweets or articles about this yourself, but here’s a small sample, all from fairly big voices/blogs in the industry.

From 15 Things You Should Know About Product Managers:

It is common to go through the whole day as a PM, and get absolutely nothing done. Your calendar is stacked. The meetings are booked. There is a ton of talk, but nothing seems to have actually happened (outside of a bunch of new items for you to follow up on). Meanwhile your team is sitting there with important questions, you have two-hundred unanswered emails in your inbox, Slack is firing off notifications left and right, and you have a doctor’s appointment at 4:30pm you have to get to (because you’ve missed your appointment three times in a row). It is frenetic.

From The State of Product Leadership 2019:

The best PMs I know are crazy-busy humans who often seem caught in a precarious equilibrium between enthusiasm and frustration.

From Emotional Debt:

Being a product manager can be like riding a bike, except the bike is on fire — you’re on fire, everything is on fire. That’s how our days can feel. We have to take care of our product, our team, perhaps our finances. Our schedules are full from looking after other people or things. And these things invariably drive emotions; we care passionately about our products, we can love and loathe our stakeholders, and we feel an almost parental-like responsibility for our teams.

I think it’s time to have a real discussion about this, and the damage this kind of thinking is doing — not just to the individuals who work in such environments, but also the industry as a whole. In this article I’d like to discuss why I believe this is such harmful thinking, and what we — and you — as individual product managers can do about it.
Why “crazy-busy PM” thinking is harmful

First, it needs to be said that if your days are “frenetic” and “you’re on fire, everything is on fire,” you cannot possibly be doing your job well.
That’s not my opinion, that’s just how your body works. There’s plenty of research and science around this, with the most succinct and relevant explanation probably being Cal Newport’s book Deep Work:

Then there’s the issue of cognitive capacity. Deep work is exhausting because it pushes you toward the limit of your abilities. Performance psychologists have extensively studied how much such efforts can be sustained by an individual in a given day. In their seminal paper on deliberate practice, Anders Ericsson and his collaborators survey these studies. They note that for someone new to such practice (citing, in particular, a child in the early stages of developing an expert-level skill), an hour a day is a reasonable limit. For those familiar with the rigors of such activities, the limit expands to something like four hours, but rarely more.

So the first thing to realize about “crazy-busy PM” thinking is that it is, quite literally, making you do sub-par work. In such environments you don’t have time or space to be thoughtful in your questions, feedback, and responses. So you are selling yourself short, first and foremost.

The second way this is harmful is to the future of the industry in general. Who in their right minds would look at a sentence like “it’s like riding a bike, except the bike is on fire — you’re on fire, everything is on fire” and go, “oh, that sounds great, sign me up.” How are we going to attract deep strategic thinkers to the role if that’s the expectation? We are doing the entire future of product management (and, not to be dramatic, but quality products in general) a disservice by perpetuating this myth that to be a good PM, you have to be a “crazy-busy human.”
How to be a more balanced product managers
If you are in a role like this, the first thing I want to say is that it doesn’t have to be this way. It’s possible to change your environment.
The way I look at it, your personal workflow is a product just like any other product you’re managing. And if your product is dysfunctional, you have to prioritize making it better.
Let me be clear that I’m not saying product management isn’t a stressful job. I know that it is, and our ability to care deeply about what we make is an essential characteristic of the job. But the irony is that “crazy-busy” works directly against that care. So we have to change it.

How do we do that? By viewing your workday through the same lens you approach all your projects.
If a project/feature is going off the rails, there are two, and only two options: increase the timeline, or reduce the scope.
A “crazy-busy PM” lifestyle means you are off the rails, and you need to do one of those two things to get it back on track.
Increase the timeline
First, you can increase the timeline. Give yourself — and everyone else — more time to do the things they need to do. Argue for more realistic timelines. Explain how it will result in higher quality products and happier and more effective teams. I often find that teams run at the speed of the product manager. So this might be as simple as just you slowing down. The rest of the team will follow.
Reduce the scope
The other option is to reduce the scope of what you do. There are two primary ways I can see that happening.

First, delegate more of your tasks to the rest of the team. Do you collect all feature request? Set up a system for the team to submit them in a central place (we use productboard, but anything will do), and look at it at a designated time. Are you doing a bunch of first-line support? Great, keep doing that! But also get some developers involved. They’ll understand customers better and lighten your workload at the same time.
The point is to think about areas where you do all the work or where you’re a bottleneck and you don’t need to be.
In our case at Postmark, I frequently got overwhelmed with spec writing. So we changed that. The lead designer/developer on a project now writes the first draft of the spec (we have a really nice template), and the rest of the team (including me) comes in afterward to ask questions and polish to the doc. The added benefit? Those team leads now have a way better understanding of the work they’re about to do, and they also feel a strong sense of ownership.

The second way to reduce scope is to split the product, and hire another PM. The best time to hire a new PM is just before they become “crazy-busy”. I want to reiterate that “crazy-busy” is not a sustainable position for a company to be in, and in these environments PMs will burn out (and do sub-par work while they’re at it). If none of the other things in these recommendations is an option where you work, you have to hire more PMs. Your company depends on it.

I understand the need for framing the PM role like it’s a constant rat race that no one except us understands. We want to feel like we do important work, and we want to be valuable to our companies. But I have to say, “crazy-busy PM” thinking is not the way to go about that.
We chose to do a job that requires a very particular set of skills, just like every other technology job. So, with apologies, I submit that we are not that special.
The way to prove our value is to build amazing products that customers love. But that shouldn’t be our only metric. The safety, efficiency, and happiness of our teams (and ourselves) is an essential part of that. Let’s not kill ourselves in the name of good product. It’s not necessary, and in fact, it’s extremely counter-productive.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第405期：《老古董 React95》

24 4 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《老古董 React95》
今日推荐英文原文：《React Technical Interview Questions》

今日推荐开源项目：《老古董 React95》传送门：GitHub链接
推荐理由：如果你需要一些古老的组件来制造些复古氛围，而你正好又在使用 React，那么这个项目就能满足你的需求——React 的 Window95 风格 UI 组件。当然了，它们还特地为这些组件加入了一些配色主题——不得不承认紫色和粉色实在是有点破坏画风……不过兴许这能让你的风格别具一格也说不定。

今日推荐英文原文：《React Technical Interview Questions》作者：Gary Bermudez
原文链接：https://medium.com/@garybm.17/react-technical-interview-questions-378513c27329
推荐理由：在面试中关于 React 的可能提及的问题
React Technical Interview Questions
Applying for a React job? Here are some technical questions your future employer could ask in an interview.

React is one of the most popular JavaScript libraries for building user interfaces. In addition to learning how to implement the new concepts from this powerful library, you need to become comfortable discussing them too, so you may accurately demonstrate and communicate your skills to potential employers in an interview.

Here are some questions that might help you in that process:
1-What is the difference between a library and a framework? Can you list an example of each?
Both libraries and frameworks are reusable code written by someone.

The technical difference between framework and library lies in a term called inversion of control.

When you use a library, you are in charge of the flow of the application. You are choosing when and where to call the library. When you use a framework, the framework is in charge of the flow. It provides some places for you to plug in your code, but it calls the code you plugged in as needed. The framework inverts the control of the program. It tells the developer what they need. A Library does not. The programmer calls the library where and when they need it.

Libraries: jQuery, React, Bootstrap

Frameworks: Angular, Vue, Rails
2-What does it mean when we say a programming library or language is declarative? How can we tell React components are declarative?
Declarative programming is when you write your code in such a way that describes what you want to do, and not how you want to do it. It is left to the compiler to figure out how.

Difference between declarative/imperative programming:

A declarative style, like what React has, allows you to control flow and state in your application by saying “It should look like this”. An imperative style turns that around and allows you to control your application by saying “This is what you should do”.

The benefits of declarative are that you don’t get bogged down in the implementation details of representing the state. Being able to describe the state reduces the surface area for bugs dramatically, which is a benefit. On the other hand, you might have less flexibility on how things occur because you are delegating or abstracting away how you implement state.
3-What is the benefit of using JSX? Make a case for (or against) this technology.
JSX is just an HTML-like syntax, it’s optional, and its purpose is to simplify the creation of React tree module nodes with attributes. It lets you create JavaScript objects with HTML syntax. While not mandatory, developers report that JSX makes developing in React much easier. Nearly all React applications use JSX syntax.
4-Describe what Webpack does in a project
Webpack is a module bundler for javascript applications. Webpack recursively builds every module in your application, then packs all those modules into a small number of bundles.

In addition to the general benefits listed above, Webpack offers a few of its own helpful features:

Flexible Configurations: Webpack supports things called plugins and loaders that can further configure it to work with other tools. We’ll learn more about them in a moment.

Development Server: It also offers a development server that can be configured to re-bundle code every time it changes. This is called hot reloading or hot module replacement. (We’ll work on this in an upcoming lesson.)
5-What are keys in React, and why are they important?
A “key” is a special string attribute you need to include when creating lists of elements.

Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity. The best way to pick a key is to use a string that uniquely identifies a list item among its siblings. Most often you would use IDs from your data as keys.

When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort.
6-Describe React’s reconciliation process used to update the DOM.
Reconciliation is the process through which React updates the DOM. When a component’s state changes, React has to calculate if it is necessary to update the DOM. It does this by creating a virtual DOM and comparing it with the current DOM. In this context, the virtual DOM will contain the new state of the component.

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