- Location
- Muntinlupa, Metro Manila, Philippines · published
- Department
- Engineering
- Seniority
- Senior
- Source
- Workable
Description
Design and Engineering Judgement
Own how a change is designed, not only that it works. Apply SOLID and the common design patterns where they earn their place, and know when not to. On legacy code, choose the smallest safe change and improve the structure around it once the risk is understood. You are expected to explain why a design holds and what it trades away.
• Design decisions defended at review, with the trade-off stated
• Changes to legacy code made safely, without widening it
• Components other engineers extend without having to rewrite them
Delivery on the Java Estate
Deliver changes across the stack, from JSP, JSF and Angular screens through the Java services to the Oracle and SQL Server data. Current Java and Spring, the older frameworks still in production, application servers such as Intershop, Tomcat and JBoss, and ActiveMQ and Elasticsearch where the product uses them.
• Java and framework upgrades planned rather than forced by an incident
Performance and Production Diagnosis
Find the real cause of a production problem, not the workaround. Read traces and logs in New Relic, profile slow screens, and follow a problem down to the query, the lock or the unclosed connection behind it. Fix it in the code and prove the fix against production data.
• Root cause identified in the code or data, with the evidence
• Fixes confirmed against production monitoring after release
• Recurring problems trending down
Rebuilding Knowledge of the Code
Much of this code was written by people who are no longer here. Work out how the product actually behaves, write down what you learn where the next engineer will find it, and use AI tools to read and explain unfamiliar code faster, checking what they tell you against the code itself.
• Documentation kept current for the areas you have worked on
• Fewer questions that only one person can answer
• Handover from the third party closed out on schedule
Unit Testing as Part of the Code
Unit tests are part of the code you write, not a task that follows it. They are committed in the same change, cover the logic and edge cases you introduced, and run fast enough for the pipeline to rely on them. Where legacy code has no tests, add them around the area you are about to change before you change it. Above that level you agree with the Quality Engineer what belongs where.
• Unit tests merged in the same change as the code
• Tests added around legacy code before it is changed
• Test level agreed with the Quality Engineer rather than duplicated
Source Control, Deployment and Run
Work reaches production through source control and the pipeline. Small changes, short-lived branches, a history someone can follow, and a pull request reviewed before merge. Nothing is edited in place on a server. Take your change into production, watch it, and own it afterwards, including a share of the on-call rota for what your team holds.
• Changes delivered through pull request and pipeline
• On-call covered, with the incidents you owned closed to root cause
• Recurrence rate on the problems you have closed
Working with AI and as One Team
Specify the work and its acceptance criteria first, use coding agents to produce it, then review the result against what you wrote. Review other people's work honestly, explain the reasoning behind your own, and contribute back to the shared standards.
• Generated code reviewed against the specification rather than accepted because it runs
• Reviews that improve the work rather than approve it
• Contributions to the shared standards, versioned and maintained