Articles
CGI Graduate Written Exercise: Structure a Timed Technical Case Report
Prepare for the CGI graduate written exercise with verified UK guidance, a 30-minute practice plan, an original technical case report, and final editing checks.
The CGI graduate written exercise is best prepared for by practicing a clear decision under a time limit: identify the requested deliverable, select the case evidence that matters, compare realistic options, and finish with a recommendation the reader can act on. Technical knowledge helps when the case calls for it; a detailed architecture essay is a poor answer to a request for a short client briefing.
Official UK guidance: CGI's current Early Careers application page describes a timed individual scenario, gives 30 minutes, and says to follow the instructions provided on the day. It assesses organisational and written communication skills. CGI Early Careers application process
For adjacent communication practice, use Explain a project to non-technical stakeholders. The fictional report below is an original exercise, not a disclosed CGI assessment question.
CGI graduate written exercise: what is confirmed and what varies?
There is an important difference between two public CGI pages. The current Early Careers page describes an individual scenario with instructions supplied on the day. A separate graduates-and-industrial-placements page describes a 30-minute handwritten exercise: answer one case-study question in report format with a structured argument. CGI graduate application process
Preparation inference: report writing is a useful practice format, but do not assume that handwriting, a particular report template, or a technology-specific case applies to every invitation. Check your candidate pack for the medium, audience, task, time allowance, and submission instructions. If it requests an email, produce an email; if it requests ranked actions, do not substitute an essay.
Candidate-report boundary: this research did not verify two independent same-cycle UK candidate accounts of this exact exercise. No candidate story is used to predict its topic, scoring, or follow-up questions. Experiences from CGI recruitment in another country would not establish the UK graduate format.
CGI's technical-graduate page links applicants to its Early Careers application guidance. That connection supports using the UK process page for preparation; it does not establish a universal software-engineering test or a particular technology stack. CGI technical graduates
Treat the invitation as the operational contract. Read it before investing your preparation time in a rumored template.
A report starts with the decision, audience, and constraints
Preparation guidance: before drafting, write a one-line task contract. For example: “Recommend a delivery approach to the service director, using the supplied evidence, within the stated budget and deadline.” That sentence keeps your answer tied to a decision rather than a broad discussion of digital transformation.
Then extract three things from the prompt:
- Decision: what must the reader choose, approve, or do?
- Constraints: which dates, costs, service obligations, or staffing limits restrict the choice?
- Evidence: which statements support or weaken each option?
These are planning questions, not an asserted CGI marking rubric. They help you use a short assessment period effectively.
A technical candidate often notices an implementation detail first: authentication, a database migration, or an integration interface. Translate that detail into its consequence for the reader. “The directory integration is untested” matters because staff might lose access, because support may need a fallback, or because the cutover date may be unsafe. Specify which consequence the case supports.
Avoid importing familiar project requirements that the prompt never mentions. If accessibility, data residency, or a procurement constraint would matter but is unspecified, record it as an assumption or a check. Do not convert your professional instinct into a fictional case fact.
Original case: should a council replace its service-desk tool?
Original practice material. All organisations, numbers, options, and deadlines below are fictional. They are not CGI assessment content or industry benchmarks.
A council's service director asks for a short report recommending how to introduce a new service-desk tool. The objective is to reduce ticket-tracking friction while maintaining support during the transition. The brief supplies:
Decision date: today; target rollout: six weeks away
Budget ceiling: £40,000 for the stated first-year project scope
Current workload: 500 tickets per week
Sample: 50 recent tickets; 12 needed manual reassignment
Option A: standard hosted tool, £30,000, estimated four-week setup
Option B: custom build, £38,000, estimated eight-week delivery
Integration: staff-directory connection has not been tested
Support: two administrators available; no extra staffing confirmed
The case does not state that reassignment is caused by the old tool. It does not state that the hosted product will eliminate it. It also does not give a migration cost outside the option estimates or a historical delivery record. Those gaps should shape your recommendation.
Build an evidence ledger before choosing
| Case observation | Decision implication and limit |
|---|---|
| A is estimated at four weeks | Leaves nominal time before the six-week target; the estimate is not a guarantee. |
| B is estimated at eight weeks | Misses the target on the supplied estimate unless the scope or deadline changes. |
| 12 of 50 sampled tickets required reassignment | Shows a problem worth investigating; does not prove a weekly rate or the tool's causal effect. |
| Directory integration is untested | A rollout depends on successful access testing and a fallback. |
| Two administrators are available | Training and migration must fit their capacity; their spare time is not specified. |
The sample fraction is 24%. You may compute it to describe the sample, but do not confidently write “120 weekly tickets will be fixed.” That extrapolation assumes representative sampling, and the improvement claim assumes a causal relationship the brief has not established.
Preparation inference: evidence selection is as much about limiting claims as finding support. An assessor can follow a modest, explicit argument more easily than an impressive number with an unstated denominator.
Turn the ledger into a short client report
The following model is an original preparation example, not a CGI-approved answer. Its sections are useful when a report is requested; their order should change if the supplied instructions require something else.
Recommendation
“Proceed with a limited pilot of Option A, conditional on directory-access testing and a complete cost check. Its stated four-week setup estimate is compatible with the six-week target; Option B's eight-week estimate is not. Do not approve a full migration until the pilot confirms access, ticket routing, and administrator capacity.”
This makes a choice, gives the decisive comparison, and states the conditions. It avoids the weak conclusion “both options have advantages,” which leaves the decision with the reader without helping them make it.
Evidence and alternatives
“The ticket sample suggests reassignment creates avoidable handling work, but it does not establish the cause or expected saving. Measure reassignment reasons during the pilot. Option A is £10,000 below the budget ceiling on the quoted scope. Confirm that integration, migration, and training are included before treating that difference as available contingency.”
“Option B offers scope for customisation, but the brief provides no quantified benefit that justifies missing the target. Reconsider it if the hosted pilot reveals a mandatory requirement that A cannot satisfy and the service director accepts a revised deadline.”
Notice that the case does not explicitly say B offers every imaginable custom feature. The report should not fabricate a capability comparison. The phrase “scope for customisation” describes the proposed approach cautiously; a real assessment answer should use only the capabilities actually stated in its case pack.
Delivery, risks, and next decision
“Ask the integration owner to test staff access, account changes, and failure recovery before the pilot. Have the two administrators confirm the training and migration workload. Preserve a usable support fallback during transition. At the pilot review, compare reassignment causes, access failures, and support handling against the current sample and a clearly defined observation period.”
“Approve wider rollout only after the access test, cost check, and capacity review pass. If any fails, retain the current service while the team resolves the gap and presents a revised plan.”
This paragraph attaches conditions to a decision. It does not claim a deployment method, rollback mechanism, or measurable improvement that has not been tested.
Use a 30-minute practice session deliberately
Original practice allocation: try five minutes to read, four to plan, sixteen to write, and five to edit. These intervals total 30 minutes. They are a suggested rehearsal, not CGI's prescribed internal schedule. Use your actual invitation's timing and any agreed adjustment on assessment day.
During the first five minutes, underline the requested output and extract the decisive constraints. During planning, select a provisional recommendation and identify one serious objection. If you cannot explain why the rejected option loses, your choice may be based on familiarity rather than the case.
Spend the writing period on a complete argument. Draft the recommendation early so it remains visible even if you run short of time. Develop the evidence and delivery conditions around it. A polished introduction without a conclusion leaves the main task unfinished.
The final five minutes are for substantive editing as well as spelling. Verify the arithmetic, option names, dates, and conditional language. Confirm that the report answers the actual question and that its last paragraph tells the reader what happens next.
If you practice by typing but your invitation requires handwriting, rehearse once in that medium. You are testing legibility and achievable length, not aiming at an invented word-count threshold. CGI's separate graduate guidance recommends planning to finish and checking spelling and grammar. CGI graduate application process
Final editing: repair the argument before decorating it
Original revision exercise. Start with this weak sentence:
“Option A will solve the ticket problem and save the council money because it is cheaper and faster.”
Replace it with:
“Option A fits the stated deadline and quoted budget more closely. A pilot should test whether it reduces reassignment without creating access failures, since the case does not establish the cause of the current problem.”
The revision removes an unsupported guarantee, specifies the comparison, and explains the uncertainty. It gives the reader a reason to proceed cautiously rather than presenting caution as indecision.
Under severe time pressure, edit in this order: unanswered task, contradictory recommendation, wrong fact or calculation, missing decision condition, then wording and punctuation. Do not spend the remaining minutes redesigning headings while a report recommends an eight-week plan for a six-week non-negotiable deadline.
Read each paragraph's first sentence. Together, they should describe a coherent decision. If they only repeat the background, shorten the background and restore the recommendation, evidence, or implementation condition that is missing.
Be ready to explain the report afterward
The separate graduate-process page says the technical interview element can explore skills on the application and the written exercise. This is a page-specific statement, not a promise about your interview agenda. CGI graduate application process
Preparation guidance: defend your report with three questions: What fact decided the recommendation? What uncertainty did you preserve? What new evidence would change your mind? For the fictional case, the timing comparison favors A, untested access prevents unconditional rollout, and a failed mandatory integration requirement could change the choice.
Do not memorize the model report. Repeat the exercise with a changed constraint: make the deadline ten weeks, or state that A fails a required integration. Rewrite the recommendation. If your conclusion remains identical regardless of the new information, you are rehearsing a script instead of reasoning.
Practice related communication and decision skills
Answer each question in its original format, then adapt one part into a short written recommendation.
| Question | Written-exercise connection |
|---|---|
| Explain a project to non-technical stakeholders | Translate technical details into audience-relevant consequences. |
| Defend a Project Decision and Its Trade-offs | Name alternatives, evidence, and a condition for revisiting the choice. |
| Drive stakeholder alignment under trade-offs | Connect competing constraints to a decision memo. |
| Describe a tough trade-off decision | Explain which cost you accepted and why. |
| Describe Resolving Stakeholder Trade-Offs | Make priorities and disagreements explicit. |
Start with Explain a project to non-technical stakeholders, then write the fictional case report against a timer. Before submission, check the invitation's format and make sure your recommendation can be traced back to the supplied facts.