Practice answering Green Software Engineering interview questions in professional English. 5 exercises on carbon-aware computing, SCI score, energy efficiency, and sustainable architecture.
What separates good from great green software answers
SCI not just carbon: Software Carbon Intensity score = (E x I + M) / R — know the formula
Carbon-aware vs carbon-efficient: shifting workloads in time or space vs doing less work per unit
Embodied carbon matters: the hardware manufacturing footprint is often larger than operational energy
Measure first: you cannot optimise what you cannot attribute — energy attribution precedes action
0 / 5 completed
1 / 5
The interviewer asks: "What is the Software Carbon Intensity (SCI) score and how would you use it to compare two system architectures?" Which answer is the most precise?
Option B is the strongest: gives the exact SCI formula with variable names and units (E in kWh, I in gCO2eq/kWh, M for embodied carbon, R as functional unit), explains why normalisation per functional unit is the key property that makes architecture comparison valid, gives a concrete numerical example, warns about the distortion that total emissions metrics create (an efficient system handling fewer requests looks worse in absolute terms), and adds the non-obvious insight about embodied carbon M being overlooked in serverless comparisons. Option A is definitionally minimal. Option C omits M (embodied carbon) entirely — a significant omission. Option D describes comparing total carbon footprint which the best answer correctly identifies as misleading for architecture comparisons.
2 / 5
The interviewer asks: "What is carbon-aware computing and how would you implement it in a batch processing system?" Choose the most implementation-complete answer.
Option C is the strongest: explains the mechanism of grid carbon intensity variation with specific examples (solar, time of day, France vs Poland), names two implementation dimensions (temporal and spatial shifting), names specific real-world APIs (National Grid ESO, Electricity Maps), describes the scheduler architecture (queries intensity data, weighs against deadline and cost, makes dispatch decision), and identifies the engineering challenge unique to this domain — forecast uncertainty — with a concrete mitigation (20% deadline buffer). Option A is correct but has no implementation detail. Option B confuses carbon-aware computing with carbon offsetting via RECs — these are fundamentally different concepts. Option D describes off-peak scheduling and overnight crons, which approximate carbon-aware computing but ignore actual carbon intensity data and miss spatial shifting entirely.
3 / 5
The interviewer asks: "What is embodied carbon in software engineering and why does it matter for architectural decisions?" Which answer shows the deepest understanding?
Option B is the strongest: defines both embodied and operational carbon, explains the cloud allocation mechanism (per CPU-hour utilisation fraction), derives the counterintuitive but important architectural principle (high utilisation reduces embodied carbon per request, meaning rightsizing is carbon optimisation not just cost optimisation), explains why serverless approaches embodied carbon near-zero, and acknowledges the practical data availability challenge with a specific tool recommendation (Cloud Carbon Footprint). Option A correctly defines the concept but has no architectural implication. Option C mentions newer hardware and high utilisation correctly but without the allocation mechanism that explains why. Option D mentions hardware lifecycle extension — also a valid point — but misses the utilisation rate insight which is more actionable for software architects.
4 / 5
The interviewer asks: "How do you measure and attribute energy consumption to individual software services?" Choose the most technically grounded answer.
Option A is the strongest: describes measurement at three specific layers (hardware RAPL, container cgroup v2, service profiling), names exact tools at each layer (perf, PowerTOP, /sys/class/powercap, cgroup v2), explains the correlation approach (energy × request throughput × CPU profiling to find energy-expensive code paths), provides the cloud fallback methodology (SPEC Power model, Cloud Carbon Footprint), and adds the governance step — publishing per-service dashboards to make energy a first-class metric. Option B describes cloud provider tools which give account-level not service-level attribution. Option C acknowledges the data limitation and names Cloud Carbon Footprint but has no multi-layer measurement approach. Option D describes the TDP estimation approach (correct as a rough estimate) but misses RAPL and cgroup precision measurement and the profiling correlation.
5 / 5
The interviewer asks: "What architectural patterns reduce the carbon footprint of a web application?" Which answer is the most comprehensive and practically grounded?
Option C is the strongest: organises the answer into four explicit architectural layers (compute, network, data, scheduling), gives specific techniques with mechanisms at each layer (scale-to-zero rationale, network energy quantification at 0.06 kWh/GB, N+1 query energy cost, carbon-aware job scheduling), and ends with the highest-leverage principle — eliminating unnecessary work — with a concrete example (a 2%-used feature running for 100% of page loads). The closing aphorism (energy you do not spend is always cheaper) is memorable and signals genuine sustainability thinking rather than optimisation thinking. Option A covers three valid areas but with no depth. Option B correctly identifies serverless but confuses serverless with green by default — the embodied carbon analysis shows this is not always true. Option D mentions SSG and image optimisation — both valid — but as a disconnected list without the four-layer framework or the elimination principle.