Skip to content

Chapter 11 Quiz

← Back to chapter

1. According to the chapter, what percentage of their working time do engineers typically spend producing written artifacts?

  1. 5% to 10%
  2. 20% to 40%
  3. 50% to 60%
  4. 70% to 80%
Answer

B. The chapter states that the average software or electrical engineer spends between 20% and 40% of their working hours producing written artifacts -- emails, design documents, pull-request descriptions, status updates, incident reports, and requirements specifications. When code comments and commit messages are added, that percentage rises further.

Concept tested: Technical Writing

Bloom's level: Remember

2. What is the standard three-part structure of a technical paragraph?

  1. Claim, evidence, counterargument
  2. Topic sentence, supporting sentences, closing or transition sentence
  3. Introduction, body, summary
  4. Question, analysis, recommendation
Answer

B. A technical paragraph follows three parts: (1) a topic sentence that states the paragraph's main claim, placed first so skimmers catch the key idea; (2) supporting sentences that provide evidence, examples, data, or reasoning; and (3) a closing or transition sentence that connects to the next paragraph or summarizes the implication. This structure differs from literary paragraphs by being shorter, more focused, and built around a single controlling idea.

Concept tested: Paragraph Structure

Bloom's level: Remember

3. An engineer writes the code comment: "// increment counter by 1." According to the chapter's guidelines, what is wrong with this comment?

  1. It is too short to be useful
  2. It uses informal language
  3. It describes what the code does rather than why it does it
  4. It lacks proper punctuation
Answer

C. The chapter's primary guideline for code comments is to comment the "why," not the "what." The code itself already shows what it does (incrementing a counter). A useful comment would explain the purpose or reasoning, such as "// Retry up to 3 times because the upstream service has transient failures during deployments." The example "increment counter by 1" is identified in the chapter as noise because it adds no information beyond what the code already communicates.

Concept tested: Code Comments

Bloom's level: Apply

4. Which of the following is a strong, well-written requirement?

  1. "The system should be fast and reliable."
  2. "The system should perform well under normal conditions."
  3. "The system shall return search results within 200 milliseconds for queries of up to 10,000 records, measured at the 95th percentile under a load of 500 concurrent users."
  4. "The system should handle a reasonable number of requests without significant delays."
Answer

C. The chapter states that good requirements are unambiguous (one interpretation), testable (a test can prove it is met or not), traceable (unique identifier), and prioritized. Option C meets all criteria -- it specifies an exact response time, dataset size, percentile, and load conditions. Options A, B, and D use vague terms like "fast," "well," and "reasonable" that have multiple interpretations and cannot be objectively tested.

Concept tested: Requirements Documents

Bloom's level: Analyze

5. What is the gold standard test for API documentation quality mentioned in the chapter?

  1. The documentation covers every possible edge case
  2. A developer can make a successful API call within 15 minutes of reading the docs
  3. The documentation includes at least 50 pages of reference material
  4. The documentation passes automated grammar checking tools
Answer

B. The chapter states that the gold standard for API documentation is that a developer can make a successful API call within 15 minutes of reading the docs. If your documentation cannot pass that test, it needs revision. This standard emphasizes practical usability over comprehensiveness. The chapter also recommends including copy-pasteable code examples for the most common use cases.

Concept tested: API Documentation

Bloom's level: Remember

6. According to the chapter, which of the following best describes the relationship between a technical report's Results section and its Discussion section?

  1. The Results section provides recommendations; the Discussion section provides supporting data
  2. The Results section presents data without judgment; the Discussion section interprets what the results mean
  3. The Results section targets executives; the Discussion section targets engineers
  4. The Results section is optional; the Discussion section is the core of the report
Answer

B. The chapter identifies separating results from interpretation as the most important skill in report writing. The Results section presents data without judgment (e.g., "The system achieved 99.2% uptime over the 30-day test period"), while the Discussion section interprets that data (e.g., "This exceeds the 99.0% target, suggesting the redundancy architecture is sufficient for production deployment"). This separation ensures clarity and allows readers to draw their own conclusions from the data.

Concept tested: Technical Reports

Bloom's level: Understand

7. When writing a professional email following the Smart Brevity framework, what should the first sentence do?

  1. Provide background context about the project
  2. Thank the recipient for their time
  3. Deliver the main point or key request
  4. Introduce yourself and your role
Answer

C. The Smart Brevity framework applied to email communication states that the first sentence should deliver the point -- do not bury the request in paragraph three. Start with what you need, such as "I need your approval by Friday to proceed with the PostgreSQL migration." The subject line serves as the headline, the body provides context using bullet points, and the close specifies a clear call to action.

Concept tested: Email Communication

Bloom's level: Understand

8. Which of the following is NOT one of the five questions that every effective technical proposal must answer?

  1. What is the problem?
  2. Who are the competitors?
  3. What are the trade-offs?
  4. What resources are needed?
Answer

B. The five questions every effective technical proposal must answer are: (1) What is the problem? (2) Why does it matter? (3) What is the proposed solution? (4) What are the trade-offs? (5) What resources are needed? Competitor analysis (B) is not one of the five questions. The chapter notes that proposals fail most often because they skip the problem definition and jump straight to the solution.

Concept tested: Technical Proposals

Bloom's level: Remember

9. Your engineering team has no documentation standards, and ten engineers are each writing in their own style. Using concepts from the chapter, explain what you would include in a team style guide and why consistency matters for technical writing.

Answer

A strong answer should identify the core components of a style guide and explain why consistency matters.

Core components of a technical style guide:

  • Terminology glossary: Approved terms and definitions, plus terms to avoid (e.g., decide whether to use "login," "log in," or "log-in" consistently)
  • Formatting rules: Heading levels, code formatting, list punctuation, image captioning
  • Voice and tone: Active vs. passive voice guidance, formality level, person (first, second, third)
  • Templates: Standard structures for each document type (design docs, incident reports, RFCs)
  • Review and approval workflow: Who reviews, what is checked, how changes are tracked

Why consistency matters: Without a style guide, ten engineers produce ten slightly different writing styles, creating an inconsistent experience for readers. Inconsistency increases cognitive load -- readers must re-learn conventions with each document. Style guides and templates are force multipliers that make every writer on the team more consistent and efficient. Major technology companies (Google, Microsoft, Apple) publish their style guides publicly, reflecting the industry-wide recognition that documentation standards are essential.

Concept tested: Style Guides, Documentation Standards

Bloom's level: Apply

10. Compare and contrast a technical proposal and a technical report. Under what circumstances would an engineer write each one, and how do their structures differ?

Answer

A strong answer should clearly distinguish the two document types across multiple dimensions.

Purpose: A technical proposal is a persuasive document that argues for a course of action -- it looks forward. A technical report documents the results of work already done -- it looks backward.

When to write each:

  • Write a proposal when you need to convince decision-makers to fund, approve, or adopt something (e.g., proposing a new system, adopting a technology, or requesting resources for a project).
  • Write a report when you need to document findings, analysis, or outcomes (e.g., results of an experiment, a completed investigation, or project outcomes).

Structural differences:

  • A proposal answers five questions: What is the problem? Why does it matter? What is the proposed solution? What are the trade-offs? What resources are needed?
  • A report follows a standard sequence: Abstract/Executive Summary, Introduction, Methodology, Results, Discussion, Conclusions and Recommendations, References.

Key skill difference: The critical skill in proposal writing is establishing the problem before the solution. The critical skill in report writing is separating results (data without judgment) from discussion (interpretation of what the data means).

Concept tested: Technical Proposals, Technical Reports

Bloom's level: Analyze