cswork / libraryOpen practice workspace

Interview guides · Smart Energy Water

Smart Energy Water Software Engineer Interview Guide

Smart Energy Water Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

A Software Engineer at Smart Energy Water (SEW) plays a pivotal role in designing, building, and scaling the industry-leading cloud platforms that power global utility companies. As a member of the engineering team, you will contribute directly to products that help millions of users manage their energy and water footprint, optimize workforce operations, and streamline customer experiences. The applications you build are critical to modernizing infrastructure, promoting sustainability, and delivering high-availability digital solutions to utility providers worldwide. The work at Smart Energy Water is highly impactful, bridging the gap between complex enterprise data and intuitive consumer applications. You will be responsible for developing robust backend services, building clean APIs, and maintaining scalable database structures.

This guide is scoped to a Software Engineer candidate at Smart Energy Water.

Focus areas

  • Object-Oriented Programming (OOP) Fundamentals
  • Object-Oriented Programming (OOP) & Language Fundamentals
  • Key Responsibilities

Where to focus your preparation

No round sequence has been reported for Smart Energy Water. Confirm the format with your recruiter.

Preparation focus

No round sequence has been reported for this company, so confirm the format with your recruiter and work the reported questions below.

What to demonstrate

  • Breadth across the topics this company reports testing
  • Whether you confirm the format before preparing for it

How to prepare

  • Ask the recruiter for the sequence, the duration of each stage and whether you will be writing code
  • Work the reported questions below and time yourself

Where candidates lose points

Master the SQL Basics

Do not overlook simple SQL queries. Be completely comfortable writing joins, using aggregate functions, and explaining the differences between common SQL commands on a whiteboard or shared screen.

Make sure you can write clean, syntactically correct SQL queries on a whiteboard or shared document

Interviewers appreciate candidates who do not rely on IDE auto-complete features to write basic database commands.

Be Ready to Whiteboard Your Projects

Practice drawing out the architecture of your previous projects. Be prepared to explain how data flows through your system, where the bottlenecks were, and why you made specific technology choices.

Questions & practice

The Four Pillars of OOP – Deep understanding of encapsulation, inheritance, polymorphism, and abstraction.

Medium · Object-Oriented Programming (OOP) & Lang

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Interfaces vs. Abstract Classes – Knowing when to use each to design flexible software systems.

Medium · Object-Oriented Programming (OOP) & Lang

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Memory Management – How your language of choice handles allocation, stack vs. heap, and garbage collection.

Medium · Object-Oriented Programming (OOP) & Lang

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Must-have skills – Strong proficiency in at least one object-oriented programming language (such as C#, Java,

Medium · Technical Skills

Must-have skills – Strong proficiency in at least one object-oriented programming language (such as C#, Java, or Python), solid understanding of relational databases and SQL, and clean coding practices.

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Master the SQL Basics: Do not overlook simple SQL queries. Be completely comfortable writing joins, using aggr

Medium · Other General Tips

Master the SQL Basics: Do not overlook simple SQL queries. Be completely comfortable writing joins, using aggregate functions, and explaining the differences between common SQL commands on a whiteboard or shared screen.

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Explain the four pillars of Object-Oriented Programming (OOP) and provide a real-world example of polymorphism

Medium · Object-Oriented Programming (OOP) Fundam

Explain the four pillars of Object-Oriented Programming (OOP) and provide a real-world example of polymorphism.

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

What is the difference between an abstract class and an interface, and when would you use one over the other?

Medium · Object-Oriented Programming (OOP) Fundam

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

How does inheritance differ from composition, and why is composition often preferred in modern software develo

Medium · Object-Oriented Programming (OOP) Fundam

How does inheritance differ from composition, and why is composition often preferred in modern software development?

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Explain the concept of encapsulation and how it helps in writing secure and maintainable code.

Medium · Object-Oriented Programming (OOP) Fundam

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

What is method overloading versus method overriding?

Medium · Object-Oriented Programming (OOP) Fundam

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Developing clean, secure, and well-documented code using modern programming languages and frameworks (such as

Medium · Key Responsibilities

Developing clean, secure, and well-documented code using modern programming languages and frameworks (such as C#,.NET, Python, or Java).

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Designing and implementing RESTful APIs and microservices that integrate seamlessly with external utility syst

Medium · Key Responsibilities

Designing and implementing RESTful APIs and microservices that integrate seamlessly with external utility systems and third-party applications.

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Optimizing database queries, schemas, and indexing strategies to ensure high performance and low latency acros

Medium · Key Responsibilities

Optimizing database queries, schemas, and indexing strategies to ensure high performance and low latency across all platform modules.

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Collaborating with product managers, QA engineers, and system architects to define feature specifications, est

Medium · Key Responsibilities

Collaborating with product managers, QA engineers, and system architects to define feature specifications, estimate development efforts, and deliver high-quality releases.

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Nice-to-have skills – Experience with ASP.NET, MVC Architecture, Entity Framework, cloud platforms (AWS, Azure

Medium · Technical Skills

Nice-to-have skills – Experience with ASP.NET, MVC Architecture, Entity Framework, cloud platforms (AWS, Azure, or GCP), and modern JavaScript frameworks (React, Angular).

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Experience level – A bachelor's degree in Computer Science, Information Technology, or a related field. Prior

Medium · Experience & Soft Skills

Experience level – A bachelor's degree in Computer Science, Information Technology, or a related field. Prior internship or professional product development experience is highly valued.

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Be Ready to Whiteboard Your Projects: Practice drawing out the architecture of your previous projects. Be prep

Medium · Other General Tips

Be Ready to Whiteboard Your Projects: Practice drawing out the architecture of your previous projects. Be prepared to explain how data flows through your system, where the bottlenecks were, and why you made specific technology choices.

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Review Core OOP Concepts: Make sure you can define and provide practical code examples for inheritance, polymo

Medium · Other General Tips

Review Core OOP Concepts: Make sure you can define and provide practical code examples for inheritance, polymorphism, encapsulation, and abstraction. Do not just memorize definitions; understand their practical benefits in software design.

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Maintain a Professional and Calm Demeanor: The interviewers at SEW are generally friendly and supportive. Appr

Medium · Other General Tips

Maintain a Professional and Calm Demeanor: The interviewers at SEW are generally friendly and supportive. Approach the interview as a collaborative technical discussion rather than a high-pressure exam. Speaking confidently and explaining your thought process clearly will leave a strong impression.

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

  1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
  2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
  3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
  4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

  • The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
  • Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

Built from the topics and questions Smart Energy Water candidates report; no round sequence has been reported.

Day 1 — Establish the Smart Energy Water format

  • No round sequence has been reported, so ask your recruiter for the sequence, the duration of each stage and whether you will write code.

Deliverable: A written reply from your recruiter confirming the format.

Day 2 — Answer out loud: Object-Oriented Programming (OOP) Fundamentals

  • Answer aloud, timed: Explain the four pillars of Object-Oriented Programming (OOP) and provide a real-world example of polymorphism.
  • Answer aloud, timed: What is the difference between an abstract class and an interface, and when would you use one over the other?

Deliverable: Spoken answers to 2 reported Object-Oriented Programming (OOP) Fundamentals question(s), under time.

Day 3 — Answer out loud: Object-Oriented Programming (OOP) & Language Fundamentals

  • Answer aloud, timed: The Four Pillars of OOP – Deep understanding of encapsulation, inheritance, polymorphism, and abstraction.
  • Answer aloud, timed: Interfaces vs. Abstract Classes – Knowing when to use each to design flexible software systems.

Deliverable: Spoken answers to 2 reported Object-Oriented Programming (OOP) & Language Fundamentals question(s), under time.

Day 4 — Answer out loud: Key Responsibilities

  • Answer aloud, timed: Developing clean, secure, and well-documented code using modern programming languages and frameworks (such as C#,.NET, Python, or Java).
  • Answer aloud, timed: Designing and implementing RESTful APIs and microservices that integrate seamlessly with external utility systems and third-party applications.

Deliverable: Spoken answers to 2 reported Key Responsibilities question(s), under time.

Day 5 — Consolidate

  • Re-work the problem you got wrong earliest in the week, from scratch, without looking at your previous attempt.

Deliverable: A second, cleaner solution to the problem you got wrong first.

Day 6 — Rehearse your own examples

  • Prepare three examples from your own work where you made the decision, each with the outcome you can quantify.

Deliverable: Three examples written out, each with a number attached.

Day 7 — Dry run for Smart Energy Water

  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

  1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
  2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
  3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
  4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

  • What in that decision was irreversible, and did you know it was irreversible when you made it?
  • How did you tell the people who had already built on top of the original decision?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

  1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
  2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
  3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
  4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

  • Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
  • The author says clients cannot handle a 409. How do you check whether that is true?