Accenture Placement Practice: Original Technical Exercises

The questions below are original exercises. They are not Accenture placement papers, copies of a live assessment, or a description of an Accenture hiring process. The official Accenture careers page publishes employer role material; consult that official page and the written invitation to verify the live details that apply to an application. This guide deliberately does not publish a company cutoff, a role hierarchy, an assessment platform, a compensation figure, or a stage count.

Exercise: trace a data-cleaning decision

Imagine a spreadsheet of support requests where the same requester may appear with upper- and lower-case spellings. Describe how you would normalise the data before grouping requests. Say what you would preserve, what you would change, and how you would test that two genuinely different names were not merged by mistake.

A good response explains the rule before presenting code. It also describes a sample input and expected output. If a field is missing, state whether the program should reject the row, preserve it for review, or use a documented default. The answer is about accountable data handling, not a guessed company test pattern.

Exercise: compare two search strategies

You need to determine whether a list contains a repeated identifier. First explain a direct comparison method. Then explain a method based on a set. For both methods, identify the work performed as the list grows and the extra memory required. Finally, explain why sorting first may change the meaning if original order matters.

The purpose is to practise a decision narrative: constraint, candidate approach, trade-off, and test. That narrative is more durable than a prepared answer to a named question.

Exercise: write a careful defect report

Suppose a form accepts a date in one browser but rejects the same date in another. Draft a report that includes the steps to reproduce, the exact observed result, the expected result, the environment you can verify, and the smallest attachment that demonstrates the issue. Do not state a cause until the evidence supports one.

Then propose a narrow test after a change. Explain what result would show that the issue is resolved and what adjacent behaviour should still be checked. This avoids confusing a plausible fix with a demonstrated one.

Exercise: defend a project decision

Select a project from your own work. Describe one option you considered but did not choose. Name the constraint that mattered, such as time, maintainability, accessibility, or a dependency boundary. Explain the downside of your choice and the signal that would lead you to revisit it.

Do not claim an audience size, performance improvement, or business impact unless you can point to your own evidence. A precise limitation is stronger than an impressive-looking number with no source.

A review routine that stays useful

After every session, write a note under four headings: fact from the prompt, inference you made, assumption you added, and test you would run. Rework only the questions where an assumption changed the answer. Over time, this creates a personal error log that is tied to your actual work rather than to rumours about a company assessment.

Use the official source for live details

An employer can revise a role, application instruction, or assessment notice. When you are ready to apply, read the live source again and retain the document that governs your application. If you need a clarification, ask through the official channel identified by the employer. A practice page cannot confirm a current rule.