R Programming Language Certification Professional Standards & Competencies 5 — Questions and Answers
Question 1: Which practice demonstrates responsible open-source contribution when submitting improvements to an R package on GitHub?
- Opening an issue to discuss the change before submitting a pull request (Correct answer)
- Forking the repository and publishing a competing package without notice
- Modifying the package license to match personal preferences
- Adding undocumented features to keep the API surface small
Correct answer: Opening an issue to discuss the change before submitting a pull request
Discussing proposed changes in an issue first respects maintainer time and aligns contributions with project goals.
Question 2: What does the concept of 'tidy data' contribute to professional R workflows?
- It provides a consistent structure (one observation per row, one variable per column) that simplifies analysis and communication (Correct answer)
- It enforces the use of the tidyverse for all data manipulation tasks
- It requires data to be stored only in CSV format
- It eliminates the need for data cleaning before analysis
Correct answer: It provides a consistent structure (one observation per row, one variable per column) that simplifies analysis and communication
Tidy data's consistent structure reduces time spent reshaping data and makes code more predictable and readable.
Question 3: A professional R consultant delivers an analysis to a client. Which deliverable best supports auditability?
- A fully documented R Markdown report with embedded code, results, and session information (Correct answer)
- A PDF with tables and charts but no underlying code
- A verbal presentation with no written output
- A script file with no corresponding output document
Correct answer: A fully documented R Markdown report with embedded code, results, and session information
An R Markdown report with embedded code and sessionInfo() allows the client or auditors to verify and reproduce every result.
Question 4: Which strategy reduces the risk of breaking changes when upgrading R packages in a production environment?
- Testing upgrades in a staging environment and using renv to manage library snapshots (Correct answer)
- Upgrading all packages simultaneously to minimize the number of update cycles
- Never upgrading packages once a project is in production
- Upgrading only packages with known security vulnerabilities
Correct answer: Testing upgrades in a staging environment and using renv to manage library snapshots
Staged testing combined with renv snapshots allows safe upgrades by isolating changes before they reach production.
Question 5: What is the professional implication of failing to account for multiple comparisons in a statistical analysis in R?
- It inflates the false positive rate, leading to misleading conclusions (Correct answer)
- It reduces statistical power, making real effects harder to detect
- It violates R's runtime assumptions and causes errors
- It has no practical effect if the sample size is large enough
Correct answer: It inflates the false positive rate, leading to misleading conclusions
Running many tests without correction (e.g., Bonferroni or FDR) inflates the family-wise error rate, producing spurious significant findings.
Question 6: Which behavior is expected of a certified R professional when they identify an error in a previously published analysis?
- Issue a correction or retraction and update any affected downstream work (Correct answer)
- Leave the original publication unchanged to preserve the historical record
- Quietly update only internal copies without notifying stakeholders
- Attribute the error to data quality and take no further action
Correct answer: Issue a correction or retraction and update any affected downstream work
Professional integrity requires transparent correction of errors to prevent others from relying on flawed findings.
Question 7: When designing an R function for a shared package, which parameter naming practice aligns with professional standards?
- Using lowercase snake_case names that clearly describe the argument's purpose (Correct answer)
- Using single-letter parameter names for brevity
- Matching parameter names to internal variable names regardless of clarity
- Using camelCase to distinguish package functions from base R functions
Correct answer: Using lowercase snake_case names that clearly describe the argument's purpose
Lowercase snake_case descriptive parameter names follow the tidyverse style guide and improve API readability for users.
Which practice demonstrates responsible open-source contribution when submitting improvements to an R package on GitHub?