Formal vs Informal Register in IT English
0 / 10 completed
1 / 10
An engineer needs to flag an urgent issue. Which version is most appropriate for a Slack message to the team?
Option B is correct for Slack. Slack messages in engineering teams use: lowercase, abbreviations ("db"), contractions, direct language, and no formal structure. It signals urgency without being overly formal or creating unnecessary alarm. Option A is appropriate for an incident report or executive email — far too formal for a team Slack message. Option C is acceptable but more formal than natural Slack register. Option D is appropriate for a major incident alert, not a preliminary investigation message.
2 / 10
The same engineer then writes the post-incident report. Which version is most appropriate?
Option C is correct for a postmortem report. Formal incident reports include: specific timestamps (UTC), metric values (P99 latency), technical precision (commit hash), passive or nominative constructions, and complete sentences. Option A uses inappropriate informal language (lol, "went weird"). Option B lacks specific detail. Option D uses complete sentences but lacks the precision required for a technical incident record.
3 / 10
An engineer writes a code comment. Which version is most appropriate?
Option B is correct. Code comments should be: precise, explanatory of constraints or assumptions, and professional — without being overly formal. "Assumes single-threaded access; concurrent calls require a mutex" is a valuable technical constraint that prevents bugs. Option A is unprofessional. Option C is too verbose and subjective. Option D is too vague — it identifies a problem but provides no information about what the fix should be.
4 / 10
An architect is writing an ADR (Architecture Decision Record). Which opening sentence is most appropriate?
Option C is correct for an ADR. Architecture Decision Records require: formal register, complete sentences, precise technical vocabulary, and structured information. Option C explains what was decided, why, and what the future plan is. Option A is inappropriate informal register. Option B is too brief and lacks context. Option D uses a note-taking format inappropriate for a formal decision record.
5 / 10
A developer advocate is giving a conference talk and wants to introduce the concept of eventual consistency. Which opening is most appropriate?
Option B is correct for a conference talk. Technical presentations to practitioners should: use relatable analogies, be engaging and conversational, and build intuition before precision. Option A is a textbook definition — accurate but dry for a talk opening. Option C is too academic and references prior knowledge the audience may not have. Option D is a bullet-point format — inappropriate for spoken presentation.
6 / 10
Which message is MOST appropriate to send to an external enterprise client about a planned maintenance window?
Option B is correct for external client communication. External enterprise clients expect: formal register, specific dates and times with time zones, precise scope of impact, and actionable recommendations. Option A is appropriate for an internal Slack channel, not a client. Option C omits the formal framing and actionable context. Option D is too vague and informal for a client notification.
7 / 10
Which sentence best suits a README installation section?
Option C is correct. README installation sections should be: imperative ("Run"), concise, technically precise (with code formatting for the command), and direct. Option A is conversational and includes filler ("just", "pretty straightforward") — appropriate for a tutorial intro, not a reference section. Option B is excessively formal and uses passive nominalisation inappropriate for an instruction. Option D is too terse — it works as a bullet point but not as prose documentation.
8 / 10
A developer writes an error message for end users. Which version is most appropriate?
Option C is correct for an end-user error message. User-facing error messages should be: in plain language (no stack traces), empathetic, actionable, and helpful. Option A exposes internal implementation — a security and UX problem. Option B is too vague to be helpful. Option D is too technical for a general user but would be acceptable in a developer-facing API error response.
9 / 10
In a sprint standup, an engineer says they are blocked. Which phrasing is most appropriate?
Option B is correct for a standup. Standups should be: concise, clear, professional but conversational — not overly formal. "I'm blocked — I need X before I can do Y" is the natural standup format. Option A is too formal for a standup (nominalisations, passive). Option C is note-taking style — appropriate for standup notes, not spoken standup. Option D is imprecise and potentially blame-y in phrasing ("hasn't done their bit").
10 / 10
Which pair of sentences demonstrates the CORRECT register shift from Slack to a formal incident summary?
Option B is correct. It demonstrates the appropriate register shift: the Slack message uses informal, conversational language ("throwing 500s", "investigating now") appropriate for rapid internal communication. The formal summary uses complete sentences, specific timestamps, technical precision (HTTP 500), and passive/nominative constructions. Option A makes no register shift. Option C uses a crisis Slack message but the summary is too brief for a formal record. Option D maintains informal language in the summary ("having issues" is too vague).