UST Practice: Problem Solving and Project Explanation

This is original technical practice, not UST placement-paper material or a current UST hiring specification. Check the official UST careers page, the current role posting, and the written role information supplied to an applicant for live conditions. This page does not publish eligibility criteria, a test schedule, interview duration, compensation terms, a selection rate, or a training promise.

Start with a specification you can test

Given a list of transactions, write a function that returns only the entries whose amount is valid and whose identifier has not been seen before. Before coding, define what “valid” means in the prompt, what happens to a duplicate, and whether the original order must be preserved.

Describe a simple implementation first. Then compare it with an approach that keeps a set of identifiers. Explain the extra memory used, the error case you would log, and the test input that would reveal a bad assumption. A solution is easier to trust when its behaviour is explicit.

Investigate a slow endpoint

Suppose a service takes longer to respond after a new feature is enabled. Lay out an investigation that begins with a reproducible request, a time measurement, and a comparison with the prior behaviour. Identify possible boundaries: database access, an external call, a cache, or a larger response. Do not declare one of them responsible without evidence.

For each hypothesis, state the smallest test that could rule it in or out. If an experiment could affect users, propose a safe test environment or a reversible change.

Explain a project decision under pressure

Choose a feature from a project and describe an early decision that you later changed. Explain the constraint at the time, the signal that showed the decision was weak, and the specific change you made. If you did not have a measurement, say that plainly and describe what evidence you would gather in a future iteration.

This answer is more credible when it distinguishes your contribution from the wider team's work. It also avoids pretending that a small project has the same conditions as a company's production system.

Write a useful handoff note

After resolving a problem, write a handoff with the observed symptom, the cause supported by evidence, the change made, the test run, and the remaining limitation. A future reader should be able to understand why the change exists without relying on your memory.

Avoid a note that merely says “fixed.” A clear handoff reduces repeated work and makes it possible to reverse a change if its assumptions no longer hold.

Use current employer material for live questions

Before submitting a live application, read the actual role posting and preserve the written instructions that apply to it. If a requirement is unclear, use the official contact route given by the employer. A generic practice guide cannot establish a current rule.