What to expect
An employee asks an enterprise assistant to summarise a project. The search layer finds the right document, but the employee lost access to it yesterday. A plausible answer is still a failure if it reveals information the user should no longer see. This is a useful Acuvate Software preparation case because it joins application development, data integration, and governed AI.
Acuvate's official site describes enterprise data, application modernisation, and AI services; its company page describes digital transformation consulting. The supplied company name is preserved as Acuvate Software. Those sources establish context but do not identify the stack or assessment used for your particular opening.
This guide uses an invented document-assistant project. It is not a claim about Acuvate's internal products or actual interview questions. If the role concerns conventional application development, use the permissions and integration portions as a software exercise and adjust the AI depth to the job description.
Prepare the application around the model
Begin with the user's task and the sources they are permitted to use. A model is only one component: identity, retrieval, document updates, feedback, and evaluation also determine whether the application works. In a design interview, explain what happens before a prompt is assembled and after a response is generated.
Ask which platforms are explicit requirements and whether the role owns frontend, backend, data integration, or evaluation. Prepare one example of implementing an access boundary and one example of measuring whether a feature improved the user workflow. Avoid presenting a polished demonstration as evidence that every failure case has been solved.
Coding case: select only permitted documents
Original practice exercise: documents have an identifier, a tenant identifier, and a set of permitted groups. A user has a tenant and group memberships. Return documents belonging to the same tenant with at least one matching permitted group. An empty permission set denies access under this exercise's rules.
For a user in tenant T with groups engineering and support, a T document permitted to support is eligible. A document in tenant U remains ineligible even if its group name matches. A document with no groups is denied. These examples make it difficult to accidentally use group overlap as a substitute for tenant isolation.
A direct implementation builds a set of user groups, filters by tenant first, and tests group intersection. Its cost depends on the total number of group entries examined, rather than just the document count. State whether group identifiers are globally unique or tenant-scoped. Do not invent a normalisation rule that merges different identifiers.
Test cross-tenant group-name collisions, empty user memberships, empty document permissions, duplicate group entries, and a user who has just lost access. A pure function operates on the supplied snapshot; a production system also needs a freshness contract for identity and permissions.
For a follow-up, ask where enforcement happens. Filtering in the browser after receiving unauthorised text is too late. Restrict retrieval and recheck access before assembling model context or returning citations. If a cache stores answers, include the relevant security scope and invalidate or reauthorise when that scope changes.
SQL case: locate stale search-index entries
Assume documents(id, version) and index_state(doc_id, version), each with a unique document identifier. Find documents missing from the index or indexed at a different version.
SELECT d.id, d.version
FROM documents AS d
LEFT JOIN index_state AS i
ON i.doc_id = d.id
WHERE i.doc_id IS NULL
OR i.version <> d.version
ORDER BY d.id;
Test a matching version, an old version, and a missing index row. This query does not find deleted source documents still present in the index; add a reverse comparison for that case. Nor does a matching content version prove permissions are current if permissions have their own revision.
Discuss how to avoid marking an index version complete before every required fragment is searchable. A partially processed document should not look fully fresh. Track indexing status and errors explicitly and design a reconciliation job that can safely retry failed work.
Design case: an enterprise assistant with traceable answers
Authenticate the user, establish tenant and permission context, and retrieve only eligible sources. Keep the retrieved document identifiers and versions attached to the request. If access checks fail or sources are unavailable, return a useful limited outcome rather than filling the gap with a confident guess.
Treat retrieved text as data. It may contain instructions intended for another reader or a malicious attempt to redirect the assistant. The application should retain its own task and authorisation boundaries. A document saying “send this to everyone” does not grant the software permission to send messages.
Give answers citations to sources the user can actually open. Evaluate whether those citations support the answer, not merely whether a URL is present. For frequently changing information, expose the source version or update time where it helps a user judge currency.
Design tool actions separately from read-only answers. Looking up a policy and modifying a record have different consequences. For the exercise, require an explicit user action before submitting a change and preserve a reviewable summary of what will be changed. Avoid giving a language model unrestricted authority simply because it can generate a valid tool payload.
Build an evaluation set with answerable questions, missing evidence, ambiguous terms, revoked access, cross-tenant content, and source text containing misleading instructions. Measure retrieval success, groundedness, access-control failures, latency, and cost separately. A single average quality score can hide a small but serious permission failure.
Debugging: an answer cites yesterday's restricted document
Trace the answer to its source document version and permission revision. Determine whether the error came from retrieval, cached context, answer caching, or a citation endpoint. A newly correct search query does not necessarily invalidate an already cached answer.
Test the exact permission change with the same user identity and a fresh session. Inspect what content reaches the model and what content reaches the browser. Avoid copying sensitive source text into broad debugging logs just to prove that the leak happened.
Contain the affected path, repair the freshness boundary, and add a regression case that revokes access between indexing and answering. Explain why a prompt telling the model to “respect permissions” is insufficient if the application has already supplied unauthorised content.
Project stories and questions for the team
Prepare a story about balancing a useful feature with a permission or data-quality constraint. Explain the design change, the user impact, and the test that made the boundary observable. If you have not built AI applications, describe a comparable search or enterprise integration problem honestly.
Ask which data sources the team connects, how permissions are synchronised, how evaluations are reviewed, and what happens when an answer lacks supporting evidence. These questions are more useful than assuming a specific model vendor or orchestration framework.
Your practice deliverables
Write the document-permission filter, the index-freshness query, and an answer path with source versions. Add a small evaluation table covering unsupported questions and revoked access. Rehearse how you would explain an intentionally limited answer to a product stakeholder.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acuvate Software's hiring timeline. Adjust it to the current job description and the time you actually have. If the recruiter confirms a different emphasis, move time toward that assessment instead of completing every exercise mechanically.
Days 1–3: turn the coding case into an executable contract
Implement the document filtering exercise in your strongest interview language. Before coding, write the input shape, invalid-input policy, tie-breaking rule, and expected output. Keep one deliberately small example that you can trace by hand. Add a test for each boundary described in the exercise rather than relying on a large random input to discover mistakes.
After the first working version, explain why your chosen data structure fits the operations you need. State both time and space costs, including retained retry history or copied state where relevant. Then change one requirement and identify which assumption breaks. Your goal is to demonstrate controlled reasoning when a problem changes, not to memorise one implementation.
Days 4–5: prove the SQL result on a tiny dataset
Create the tables used in the SQL case and insert a normal record, a missing-related-record case, and a duplicate or irrelevant record. Predict the output before executing the query. Check whether the result is one row per entity or one row per event, and whether null means missing data, unknown state, or a legitimate business value.
Explain how a join can multiply rows and why filtering a joined table in the wrong place can remove the very records you are looking for. For performance, begin with the lookup keys and expected access pattern; inspect an execution plan before promising that an index will solve the problem. Keep correctness and performance as separate review questions.
Days 6–9: draw the state boundary and break it
Use the architecture diagram as a starting point, then mark the operation that must be atomic. Write down what the caller is entitled to believe after a success response. For this case, make the current access decision and cited document version visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a user losing document access while an answer is cached. Record the state before the failure, the durable evidence after it, and the next action each component takes. A useful recovery story explains how the system distinguishes an incomplete operation from a completed operation whose response was lost. It also states what an operator can inspect without making the incident worse.
Days 10–12: practise diagnosis and communication
Rehearse the incident where an answer cites a restricted document from yesterday. Give yourself a short log extract or a handful of records rather than omniscient knowledge of the bug. Separate observations from hypotheses. Name the first query or trace you would inspect and explain which competing explanations its result would rule out.
Prepare one experience from your own work that demonstrates similar judgment. Describe the constraint, the decision you personally made, and the evidence that the change helped. If you do not have production experience, use a course or personal project honestly and explain the additional controls a production deployment would require.
Days 13–14: run a mock and repair the weakest answer
Spend one session on coding and another on design. Ask your mock interviewer to challenge a hidden assumption rather than only checking the final answer. Afterward, choose one specific weakness: unclear failure semantics, an untested boundary, an ambiguous schema, or an explanation that begins with tools before requirements. Revise that artifact and run the same scenario again.
Frequently asked questions
Are these verified Acuvate Software interview questions?
No. The coding, SQL, and design cases are original preparation exercises informed by the company's public business context. The linked sources establish that context; they do not verify that these prompts appeared in an interview. Use any current recruiter instructions as the authority for your actual assessment format.
Which language should I use?
Use a language in which you can implement and test the exercise clearly, unless the current role or assessment specifies one. Practise explaining your standard library choices and failure handling. A company product page is not enough evidence to infer the language required in an interview.
What should I prioritise if I have only a weekend?
Complete one tested coding solution, run the SQL example against a tiny fixture, and walk through the failure scenario above. Then prepare two concise project stories and questions about the actual team. A small set of defensible answers is more useful than superficial familiarity with every possible technology.
For broader practice, use the PracHub Software Engineer question bank. Its questions are general role practice and should not be treated as verified questions from Acuvate Software.