Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Ethical Engineering

In 2014, Facebook’s data science team ran an experiment on 689,003 users without their knowledge. For one week, the platform’s News Feed algorithm was deliberately manipulated --- some users saw more positive posts, others saw more negative posts --- to study whether emotional contagion could spread through social networks. The results were published in the Proceedings of the National Academy of Sciences. When the study became public, the backlash was immediate and fierce. Users were outraged that their emotional states had been treated as experimental variables. Regulators took notice. The academic community questioned whether informed consent had been obtained (it hadn’t, beyond the platform’s generic Terms of Service that virtually no one reads). Facebook’s own data science team was shaken --- some researchers had raised ethical concerns internally before publication and been overruled. The Facebook mood experiment was not a story about bad people. It was a story about a culture where “move fast and break things” had become so deeply internalized that nobody stopped to ask what, exactly, was being broken. The answer was trust --- and in some cases, the mental wellbeing of hundreds of thousands of people who never consented to being test subjects. This chapter is about the ethical responsibilities that come with building software. Every architectural choice, every data collection decision, every algorithm you deploy has ethical implications. And unlike a bug that crashes a server, ethical failures crash trust, harm people, and sometimes violate laws. The stakes are not theoretical.

---

​

1. Why Ethics Matter for Engineers

​

1.1 “Move Fast and Break Things” Broke Real Things

Facebook’s original motto sounded scrappy and ambitious. In practice, it created a culture where consequences were an afterthought. Cambridge Analytica harvested data from 87 million users through a personality quiz app because Facebook’s platform policies allowed third-party apps to access not just the quiz-taker’s data, but their friends’ data too. The Myanmar military used Facebook to coordinate genocide against the Rohingya people, and internal research showed the platform’s recommendation algorithm amplified inflammatory content. Instagram’s own researchers found that the platform worsened body image issues in teenage girls --- and the company buried the findings. These are not edge cases. They are the predictable result of building systems at scale without ethical guardrails. When your platform has 3 billion users, a 0.1% harm rate affects 3 million people.

​

1.2 Engineers as Decision-Makers

Product managers set requirements. Designers create mockups. But engineers make hundreds of micro-decisions during implementation that PMs and designers never see: what data to log, how long to retain it, what defaults to set, which error messages to show, how recommendation weights are tuned. Each of these is an ethical choice, whether you recognize it or not. When you choose to log user location data “just in case we need it later,” that is an ethical decision. When you set a dark-colored “Accept All Cookies” button and a light-colored “Manage Preferences” link, that is an ethical decision. When you train a model on data scraped from the internet without checking for consent or bias, that is an ethical decision.

​

1.3 “Just Following Orders” Doesn’t Apply

Engineers have agency. When Google employees learned about Project Dragonfly --- a censored search engine being built for the Chinese market that would link users’ phone numbers to their search queries and make it trivially easy for the Chinese government to surveil dissidents --- thousands of employees signed a letter of protest. The project was eventually shelved, not by executives, but because engineers refused to build it. You are not a code monkey executing tickets. You are a professional with the power to shape how technology affects people’s lives. With that power comes responsibility --- not just to your employer, but to the people who use what you build.

​

1.4 The Ethical Debt Concept

Technical debt is code that works now but will be painful later. Ethical debt is the same idea, but the pain is borne by users, not developers. Examples of ethical debt:

• Collecting data you don’t need --- convenient now, a liability when breached or when regulations tighten
• Skipping accessibility --- faster to ship, but you’ve excluded millions of users with disabilities
• Not auditing your ML models for bias --- the model works for your test cases, but discriminates against demographics your team didn’t think to test
• Using manipulative UI patterns --- boosts short-term metrics, destroys long-term trust
• No deletion pipeline --- you can store everything, but you cannot comply with a GDPR deletion request

Like technical debt, ethical debt compounds. A biased dataset produces a biased model, which makes biased decisions, which generates biased training data for the next model. Unlike technical debt, ethical debt has human victims.

---

​

2. Bias in Software Systems

​

2.1 How Algorithmic Bias Creeps In

Algorithms are not inherently biased. But they are trained on data produced by a biased world, designed by teams with blind spots, and deployed in contexts that amplify small errors into systemic discrimination. Bias enters through three main doors: Training data bias. If your historical data reflects past discrimination, your model will learn to discriminate. Amazon built a resume-screening AI trained on ten years of hiring data. Because the tech industry had historically hired predominantly men, the model learned that male candidates were preferable. It penalized resumes containing the word “women’s” (as in “women’s chess club captain”) and downgraded graduates of all-women’s colleges. Amazon scrapped the tool in 2018 after failing to make it gender-neutral. Feature selection and proxy variables. You might remove “race” from your model’s inputs and think you’ve eliminated racial bias. But zip code is a proxy for race in the United States. So is name. So is school attended. The COMPAS recidivism prediction system, used by courts across America to predict whether defendants would reoffend, was found by ProPublica to be twice as likely to falsely label Black defendants as high-risk compared to white defendants --- even though race was not an explicit input. Zip code, employment history, and social network effects served as proxies. Feedback loops. A biased system generates biased outcomes, which become the training data for the next iteration. Predictive policing algorithms send more police to neighborhoods that already have high arrest rates (often communities of color). More police presence leads to more arrests, which “confirms” the algorithm’s prediction, which sends even more police. The algorithm does not discover crime --- it manufactures the data that justifies its own predictions.

​

2.2 Types of Bias Engineers Must Recognize

​

2.3 Detecting Bias: Fairness Metrics

You cannot fix what you cannot measure. The field of algorithmic fairness has developed several metrics, and the uncomfortable truth is that they are mathematically incompatible --- you cannot satisfy all of them simultaneously. Demographic parity: The model’s positive prediction rate should be the same across groups. If 60% of male applicants are approved for loans, 60% of female applicants should be too. Problem: this ignores whether the groups actually have different qualification rates. Equalized odds: The model’s true positive rate and false positive rate should be the same across groups. If 90% of qualified male applicants are correctly identified, 90% of qualified female applicants should be too. Problem: harder to achieve in practice when base rates differ. Calibration: If the model says someone has a 70% chance of repaying a loan, that should be true regardless of their demographic group. Problem: a well-calibrated model can still have very different approval rates across groups.

​

2.4 Mitigating Bias

• Diverse training data --- actively seek data that represents all affected populations, not just the populations most convenient to collect from
• Fairness constraints during training --- add regularization terms that penalize disparate outcomes across groups
• Regular auditing --- test model performance across demographic slices, not just aggregate accuracy. A model with 95% overall accuracy might have 99% accuracy for one group and 70% for another
• Diverse teams --- homogeneous teams have homogeneous blind spots. The MIT researcher who discovered facial recognition bias (Joy Buolamwini) is a Black woman who noticed the technology literally could not see her face
• Red-teaming for bias --- before deployment, have adversarial testers specifically look for discriminatory outcomes
• Human-in-the-loop for high-stakes decisions --- never let an algorithm alone decide who gets a loan, who goes to jail, or who gets hired

​

2.5 Algorithmic Auditing --- How to Audit an Algorithm for Bias

Detecting bias is not a one-time checkbox --- it’s an ongoing discipline, like security testing. Algorithmic auditing is the systematic process of examining an algorithm’s inputs, logic, and outputs for unfair, discriminatory, or unintended behavior. If bias detection (Section 2.3) tells you what to measure, algorithmic auditing tells you how to run the investigation.

​

When to Audit

• Before deployment --- every ML model that affects people (hiring, lending, content moderation, healthcare triage, ad targeting) should be audited before it reaches production
• On a regular schedule --- quarterly or semi-annually, because data drift means a model that was fair at launch can become unfair over time
• After incidents --- when users report disparate outcomes, when monitoring flags fairness metric drift, or when regulatory requirements change
• Before and after major retraining --- new training data can introduce new biases or fix old ones; you need to know which

​

The Five-Phase Audit Process

Phase 1: Scope and Context Define what you’re auditing and why. Document the system’s purpose, the populations it affects, the decisions it makes, and the potential harms if it’s wrong. A loan approval model and a movie recommendation model both need auditing, but the stakes --- and therefore the rigor --- are vastly different. Key questions:

• What decision does this system make or influence?
• Who is affected by that decision, and how severely?
• What protected characteristics (race, gender, age, disability, religion) could be impacted?
• What does “fair” mean for this specific context? (Choose your fairness metric explicitly --- demographic parity, equalized odds, or calibration --- and document why.)

Phase 2: Data Audit Examine the training data before you examine the model. Most bias enters through data, not algorithms.

• Representation analysis: Break down the training data by demographic groups. Are all affected populations represented proportionally? If your hiring model was trained on 85% male resumes, it has learned that “good candidate” correlates with “male.”
• Label audit: Who labeled the data, and what were their instructions? If human labelers had biases (conscious or unconscious), those biases are now in your labels.
• Proxy variable detection: Identify features that correlate strongly with protected characteristics. Zip code correlates with race. Name correlates with gender and ethnicity. School attended correlates with socioeconomic status. Use correlation analysis and mutual information metrics to flag proxies.
• Historical bias check: Does the data reflect a world you want to replicate, or a world you want to improve? If historical hiring data shows that women were rarely promoted to leadership, training on that data teaches the model that women shouldn’t be promoted.

Phase 3: Model Audit Test the model’s behavior across demographic slices.

• Disaggregated performance metrics: Don’t just report aggregate accuracy. Break down precision, recall, F1, and false positive/negative rates by every relevant demographic group. A model with 93% overall accuracy might have 98% accuracy for one group and 74% for another.
• Counterfactual testing: Change a single protected attribute (e.g., change a name from “James” to “Jamal”) and observe whether the prediction changes. If it does, the model is using that attribute (or its proxies) in its decision.
• Stress testing on edge cases: Test with inputs that are at the boundaries of demographic groups, that combine multiple protected characteristics (intersectionality), and that represent underrepresented populations.
• Explanation analysis: Use SHAP or LIME to examine which features drive predictions for different demographic groups. If “zip code” is the top driver for rejecting minority applicants but not for majority applicants, you’ve found proxy discrimination.

Phase 4: Outcome Audit Analyze real-world outcomes, not just model predictions.

• Disparate impact analysis: Calculate the selection rate for each group. Under the “four-fifths rule” (EEOC guidelines), if the selection rate for a protected group is less than 80% of the rate for the highest-performing group, there’s evidence of disparate impact.
• Feedback loop analysis: Is the model’s output being used as input for future training? If so, are biased decisions compounding over time? This is the predictive policing problem --- bias begets data that confirms bias.
• Outcome tracking: After the model makes a decision, track what actually happens. Did the people the model predicted would default on loans actually default? If the model’s predictions are less accurate for certain groups, its decisions for those groups are less justified.

Phase 5: Remediation and Documentation Fix what you found and create an audit trail.

• Remediation plan: For each bias finding, document the severity, the root cause, the proposed fix, and the timeline. Prioritize by harm potential.
• Audit report: Document everything --- scope, methodology, findings, remediation steps, and residual risks. This report serves three audiences: the engineering team (technical detail), leadership (business risk), and regulators (compliance evidence).
• Re-audit schedule: Bias is not a bug you fix once. Set a re-audit date and stick to it.

​

Tools for Algorithmic Auditing

​

When to Bring in External Auditors

Internal audits are necessary but insufficient for high-stakes systems. You should bring in external auditors when:

• The system affects legally protected decisions --- hiring, lending, housing, healthcare, criminal justice. External audits provide legal defensibility that internal audits cannot.
• You’re entering a regulated market --- the EU AI Act requires conformity assessments for high-risk AI systems. Many of these assessments must be performed by independent third parties.
• Your internal team lacks diversity --- a homogeneous team has homogeneous blind spots. External auditors bring perspectives your team may not have.
• Trust is at stake --- after a bias incident, an internal audit saying “we fixed it” carries less weight than an independent audit confirming it.
• NYC Local Law 144 and similar legislation --- New York City now requires annual independent bias audits of automated employment decision tools. Similar legislation is advancing in other jurisdictions.

Organizations like O’Neil Risk Consulting & Algorithmic Auditing (ORCAA, founded by Cathy O’Neil, author of Weapons of Math Destruction), the Algorithmic Justice League (founded by Joy Buolamwini), and the AI Now Institute at NYU provide external auditing services and frameworks.

---

​

3. Privacy Engineering

​

3.1 Privacy by Design

Ann Cavoukian, Ontario’s former Information and Privacy Commissioner, articulated the seven foundational principles of Privacy by Design in the 1990s. They are now embedded in GDPR (Article 25) and increasingly in regulations worldwide:

1. Proactive, not reactive --- prevent privacy breaches, don’t just respond to them
2. Privacy as the default --- users shouldn’t have to take action to protect their privacy. If they do nothing, they’re still protected
3. Privacy embedded into design --- not bolted on as an afterthought or a compliance checkbox
4. Full functionality --- privacy and functionality are not a zero-sum game. “We can’t do privacy because it would hurt the user experience” is a design failure, not an inherent trade-off
5. End-to-end security --- data is protected throughout its entire lifecycle, from collection through deletion
6. Visibility and transparency --- users can see what data you have about them and how it’s used
7. Respect for user privacy --- user interests come first, always

​

3.2 Data Minimization

The most secure data is data you never collected. Every field you store is a field that can be breached, subpoenaed, or misused. Questions to ask before collecting any data:

• Do we need this to provide the service the user requested? (If no, don’t collect it.)
• How long do we need to keep it? (Set a TTL. If you don’t know, that’s a red flag.)
• Who will have access to it? (Default to nobody. Grant access explicitly.)
• What happens if this data is breached? (If the answer is “significant harm to users,” reconsider whether you need it.)

Apple’s privacy stance is the industry gold standard here. When Apple built Face ID, they made the face data stay on-device --- it never goes to Apple’s servers. When they built their advertising attribution system (SKAdNetwork), they designed it so advertisers could measure campaign effectiveness without learning anything about individual users. When the FBI demanded Apple create a backdoor to unlock the San Bernardino shooter’s iPhone in 2016, Apple refused, arguing that creating a backdoor for one phone would create a backdoor for every phone. These weren’t easy decisions --- they had real business costs. But Apple bet that privacy could be a competitive advantage, and they were right.

​

3.3 Anonymization and Its Limits

Engineers often believe that “anonymizing” data makes it safe. The research says otherwise. K-anonymity: Every record in a dataset must be indistinguishable from at least k-1 other records on quasi-identifier attributes (age, zip code, gender). If k=5, every combination of quasi-identifiers must appear at least 5 times. Problem: if all 5 records with the same quasi-identifiers have the same sensitive value (e.g., all have “HIV positive”), anonymity is meaningless. L-diversity: Addresses k-anonymity’s weakness by requiring at least L distinct values for sensitive attributes within each equivalence class. Problem: if the L values are semantically similar (e.g., “stomach cancer” and “stomach flu” are both stomach-related), an attacker still learns something. T-closeness: Requires that the distribution of sensitive attributes within each equivalence class be close to the distribution in the overall dataset. This prevents both the k-anonymity and l-diversity attacks, but is harder to implement and often requires more data suppression.

​

3.4 Differential Privacy

Differential privacy is a mathematical framework that provides provable privacy guarantees. The core idea: add carefully calibrated random noise to query results so that the output is essentially the same whether or not any single individual’s data is included. How it works (simplified): Imagine a database of patient records. You want to know “how many patients have diabetes?” The true answer is 1,247. Differential privacy adds noise (say, a random number between -50 and +50), so the reported answer might be 1,221 or 1,273. An attacker who runs the query cannot determine whether any specific patient contributed to the count. The noise is small enough that the aggregate statistic is still useful, but large enough that individual privacy is protected. The key parameter is epsilon --- a smaller epsilon means more noise (more privacy, less accuracy) and a larger epsilon means less noise (less privacy, more accuracy). Apple uses epsilon values around 1-8 for their local differential privacy system, which collects usage statistics from iPhones without learning about individual users. The U.S. Census Bureau used differential privacy for the 2020 Census, with considerable debate about the epsilon values chosen.

​

3.5 Privacy-Preserving Computation

For cases where you need to compute on sensitive data without exposing it: Federated learning: Instead of sending data to a central server, the model goes to the data. Each device trains a local model on its local data and sends only the model updates (gradients) to a central server, which aggregates them. Google uses this for Gboard (keyboard predictions) --- your typing patterns never leave your phone, but the collective model improves for everyone. Homomorphic encryption: Perform computations on encrypted data without decrypting it. The result, when decrypted, matches what you’d get from computing on the plaintext. This is the holy grail of privacy-preserving computation, but it’s still 100-10,000x slower than plaintext computation for most operations, limiting practical applications. Secure multi-party computation (MPC): Multiple parties jointly compute a function over their combined data without any party revealing its individual input. Example: two hospitals want to know the combined average patient age without revealing their individual patient data. Each hospital splits its data into “shares” distributed across multiple servers, and the computation happens on the shares.

​

3.6 Data Ethics Decision Framework

Privacy principles are essential, but engineers need something they can actually use in the moment --- when a PM asks for a new data field, when a colleague proposes a new analytics pipeline, or when you’re designing a schema and need to decide what to store. This framework is a practical, sequential checklist for any data decision. Run through these six questions every time you collect, store, process, or share personal data. If any answer is “no” or “I don’t know,” stop and resolve it before proceeding.

​

Question 1: Is the Data Consented?

• Did the user explicitly agree to this specific use of their data? (Not buried in a 40-page ToS. Not inferred from “continued use of the service.”)
• Is the consent informed? Can the user understand what they’re agreeing to in plain language?
• Is the consent revocable? Can the user change their mind, and does that actually stop the processing?
• Is the consent specific? “We may use your data to improve our services” is not specific. “We will use your purchase history to recommend similar products” is.

The test: If you called the user right now and described exactly what you’re doing with their data, would they say “Yeah, that makes sense” or “Wait, what? I didn’t agree to that”?

​

Question 2: Is the Data Necessary?

• Do we need this specific data to provide the service the user requested? (Not “might be useful someday.” Needed. Now.)
• Could we accomplish the same goal with less data? (Aggregate instead of individual? Anonymized instead of identifiable? On-device instead of server-side?)
• Could we accomplish the same goal with less sensitive data? (Do you need precise GPS coordinates, or is city-level sufficient? Do you need date of birth, or is age range enough?)
• Is there a retention limit? (How long do we need it, and what happens when that period ends?)

The test: For every data field, ask “What breaks if we don’t collect this?” If the answer is “nothing breaks, but we might want it later,” that’s a “no.”

​

Question 3: What If It Leaks?

• If this data were exposed in a breach, what is the worst-case harm to each affected user?
• Could leaked data enable identity theft, financial fraud, physical stalking, employment discrimination, medical discrimination, or social stigma?
• Is this data about vulnerable populations (children, patients, immigrants, political dissidents) whose exposure risk is higher than average?
• Are we storing data whose leaking would be disproportionately harmful to specific groups? (HIV status, immigration status, sexual orientation in jurisdictions where it’s criminalized)

The test: Imagine the data appears on the front page of a newspaper tomorrow. Assess the harm not for the “average” user, but for the most vulnerable user in your dataset.

​

Question 4: Who Is Harmed If It’s Wrong?

• If the data is inaccurate, who suffers? (The user? A third party? A vulnerable population?)
• What decisions are made based on this data, and what are the consequences of a wrong decision?
• Is there a feedback loop where wrong data produces wrong decisions that produce more wrong data?
• Is there a correction mechanism? Can affected individuals challenge and fix inaccurate data about them?

The test: Trace the data’s path from collection to decision. At each step, ask: “If this is wrong, who pays the price?” If the person who pays the price has no way to know the data exists or no way to correct it, you have an ethical problem.

​

Question 5: Does It Create or Reinforce Power Asymmetry?

• Does this data give one party (the company, the government, the platform) disproportionate power over another (the user, the citizen, the employee)?
• Could this data be used for manipulation, coercion, or exploitation --- even if that’s not the current intent?
• If the company is acquired, goes bankrupt, or changes leadership, could this data be used in ways the original users never anticipated?

The test: Imagine the least trustworthy person you can think of gets access to this data and the decisions it powers. What’s the worst they could do?

​

Question 6: Have We Asked the Affected Community?

• Have we consulted with representatives of the populations this data describes?
• Are we making assumptions about what people would consent to, or have we actually asked them?
• Do the people most affected by this system have a voice in how it works?

The test: If your entire user base were in the room during this design review, would you make the same decisions?

​

Putting It All Together

Any single red means you should not proceed without changes. Two or more yellows warrant a formal ethics review. All greens means you’re in good shape --- but document your reasoning anyway, because context changes.

---

​

4. Responsible AI

​

4.1 Model Transparency and Explainability

When an algorithm denies someone a loan, they have a right to know why. The EU’s GDPR includes a “right to explanation” for automated decisions. But most powerful ML models --- deep neural networks especially --- are black boxes. The field of Explainable AI (XAI) tries to open them. LIME (Local Interpretable Model-agnostic Explanations): Explains individual predictions by approximating the complex model locally with a simple, interpretable model. “This loan was denied primarily because of the applicant’s debt-to-income ratio (40% contribution) and short credit history (30% contribution).” SHAP (SHapley Additive exPlanations): Based on game theory. Assigns each feature a contribution score for each prediction, with strong theoretical guarantees of consistency and fairness. More computationally expensive than LIME but more theoretically grounded.

​

4.2 Data Governance

Where did the training data come from? Was consent obtained? Who has copyright? The explosion of generative AI has made these questions urgent. Large language models are trained on vast corpora scraped from the internet, which includes copyrighted books, articles, and code. Artists, writers, and photographers have filed lawsuits against AI companies for using their work without permission or compensation. The legal landscape is still evolving, but the ethical principle is clear: using someone’s creative work to train a commercial AI system without their knowledge or consent is ethically dubious, even if it’s currently legal in some jurisdictions. Model cards (pioneered by Google researchers Mitchell et al., 2019) are the engineering response to data governance concerns. A model card documents:

• What the model was trained on and how the data was collected
• What the model is intended to be used for (and explicitly, what it should not be used for)
• Performance metrics broken down by demographic group
• Known limitations and failure modes
• Ethical considerations and potential harms

​

4.3 AI Safety

As AI systems become more capable, the risks of misalignment between what we want the system to do and what it actually optimizes for become more serious. Reward hacking: An RL agent trained to maximize a game score discovers an exploit the designers didn’t intend. In a boat-racing game, an AI found it could score more points by driving in circles collecting power-ups than by actually finishing the race. In a simulation environment, a robot tasked with walking learned to be very tall and fall over (technically moving forward) instead of developing a stable gait. Specification gaming: The model achieves the letter of the objective while violating its spirit. An AI tasked with “minimize customer complaints” learns to make the complaint process so difficult that customers give up. An ad system told to “maximize clicks” learns to serve increasingly outrageous and misleading content. Prompt injection and LLM security: Large language models introduce a new attack surface. Prompt injection (hiding instructions in user-provided text that override the system prompt) can cause LLMs to leak confidential context, execute unauthorized actions, or produce harmful content. This is an active area of security research with no complete solution.

​

4.4 The EU AI Act

The EU AI Act (entered into force August 2024, with staged enforcement through 2027) is the world’s first comprehensive AI regulation. It categorizes AI systems by risk level: Engineers building AI systems that serve EU citizens need to understand these categories. Non-compliance can result in fines up to 35 million euros or 7% of global annual turnover.

---

​

5. Dark Patterns and Manipulative Design

​

5.1 What Dark Patterns Are

Dark patterns are user interface designs that trick users into doing things they didn’t intend. The term was coined by UX designer Harry Brignull, who catalogs them at deceptive.design.

​

5.2 Common Dark Patterns

Confirmshaming: “No thanks, I don’t want to save money” as the opt-out text on a popup. Designed to make the user feel bad about declining. Roach motel: Easy to get into, hard to get out of. Amazon Prime’s cancellation flow used to involve navigating through multiple pages of “Are you sure?” prompts with confusing button labels. The FTC sued Amazon over this in 2023. Hidden costs: Prices shown without mandatory fees. Concert ticket sites showing a $50 ticket that becomes$78 at checkout after “service fees” and “facility charges.” Forced continuity: Free trial that auto-converts to a paid subscription with no warning email before the charge. The user forgets they signed up, gets charged, and faces a difficult cancellation process. Misdirection: Visual design that steers users toward the choice the company prefers. The “Accept All Cookies” button is large, colorful, and prominent. The “Manage Preferences” link is small, gray, and buried. Privacy zuckering: Named after Mark Zuckerberg. Tricking users into sharing more data than they intend through confusing privacy settings, double negatives (“Uncheck this box to not opt out of non-essential communications”), and defaults set to maximum data sharing.

​

5.3 The Legal Landscape

Dark patterns are increasingly illegal. The FTC has taken action against Amazon, Fortnite (Epic Games), and numerous subscription services. The EU’s Digital Services Act explicitly prohibits dark patterns. California’s CCPA amendments specifically address dark patterns in consent flows. India’s Digital Personal Data Protection Act (2023) bans dark patterns in consent mechanisms.

​

5.4 The Engineer’s Responsibility

When a PM or designer asks you to build a manipulative feature, you have an obligation to push back.

---

​

6. Accessibility as an Ethical Imperative

​

6.1 Why Accessibility Is Non-Negotiable

Over 1 billion people worldwide live with some form of disability. When your software is inaccessible, you are excluding them --- not by accident, but by neglect. Accessibility is also a legal requirement. The Americans with Disabilities Act (ADA) has been interpreted by courts to apply to websites and apps. The European Accessibility Act (EAA), which takes effect in June 2025, requires digital products and services in the EU to be accessible. Companies have paid millions in settlements for inaccessible websites --- Domino’s Pizza’s case went to the Supreme Court.

​

6.2 The Standard: WCAG 2.1 AA

The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA is the accepted standard. Its four principles (POUR):

• Perceivable --- information must be presentable in ways users can perceive (alt text for images, captions for video, sufficient color contrast)
• Operable --- interface must be usable (keyboard navigation, no time limits that can’t be extended, no content that causes seizures)
• Understandable --- content and interface must be comprehensible (clear language, predictable navigation, helpful error messages)
• Robust --- content must work with current and future assistive technologies (semantic HTML, ARIA attributes)

​

6.3 The Curb-Cut Effect

When sidewalk curbs were cut for wheelchair users, it turned out to benefit everyone: parents with strollers, delivery workers with hand trucks, cyclists, travelers with suitcases. This is the curb-cut effect --- accessibility improvements often benefit all users. Closed captions were designed for deaf and hard-of-hearing users. Today, 80% of caption users are hearing --- they use captions in noisy environments, while learning a language, or when they can’t turn on audio. Voice control was designed for motor-impaired users. Now everyone uses Siri, Alexa, and Google Assistant. High-contrast, clear UI designed for low-vision users is simply better UI for everyone.

​

6.4 Testing for Accessibility

• Automated: axe-core (browser extension and CI integration), Lighthouse (built into Chrome DevTools), Pa11y (command-line accessibility testing)
• Manual: Navigate your entire app using only a keyboard. Use a screen reader (VoiceOver on Mac, NVDA on Windows). Check all color contrast ratios against WCAG AA minimums (4.5:1 for normal text, 3:1 for large text)
• User testing: Include people with disabilities in your usability testing. Automated tools catch about 30% of accessibility issues --- the rest require human judgment

---

​

7. Environmental Impact

​

7.1 The Carbon Cost of Computing

Training a large language model is not free for the planet. Estimates suggest training GPT-4 consumed approximately 300 tons of CO2 equivalent --- roughly equal to the lifetime emissions of 30 average cars. A single data center can consume as much electricity as a small city. By 2030, data centers are projected to consume 8% of global electricity.

​

7.2 Green Software Principles

The Green Software Foundation (founded by Microsoft, Accenture, GitHub, and ThoughtWorks) promotes three principles: Carbon efficiency: Reduce the carbon emitted per unit of work. Use cloud regions powered by renewable energy. AWS, Azure, and GCP all publish carbon intensity data by region. Energy efficiency: Use the least energy possible. Efficient algorithms, right-sized infrastructure, and eliminating waste. An over-provisioned Kubernetes cluster running at 10% CPU utilization wastes 90% of the energy powering those servers. Carbon awareness: Shift workloads to times and locations where the carbon intensity of electricity is lowest. Run batch jobs at 2 AM when the grid is cleaner. Use spot instances in regions with higher renewable energy percentages.

​

7.3 The SCI Metric

The Software Carbon Intensity (SCI) metric measures the carbon emissions per unit of work: SCI = ((E * I) + M) / R where E is energy consumed, I is carbon intensity of the electricity, M is embodied carbon of the hardware, and R is the functional unit (per API call, per user, per transaction). This gives you a single number to track and optimize.

---

​

8. Building an Ethical Engineering Culture

​

8.1 Ethics Reviews

Just as you have security reviews for new features, institute ethics reviews. Before launching a new feature, ask:

• Who could be harmed by this feature, and how?
• What data are we collecting, and is all of it truly necessary?
• What happens if this is misused by bad actors?
• Does this affect different populations differently? (differential impact analysis)
• Would we be comfortable if our internal discussions about this feature were made public? (the “front page test”)

​

8.2 Red-Teaming for Ethical Risks

Security red teams try to break your system technically. Ethics red teams try to identify how your system could cause harm socially. Before launching a content recommendation system, have a team specifically try to create filter bubbles, amplify misinformation, or radicalize a test account. Before launching a hiring tool, have a team specifically test for demographic bias.

​

8.3 Whistleblower Protections

Engineers who identify ethical problems need safe channels to report them. Anonymous reporting mechanisms, protection from retaliation, and a clear escalation path that goes beyond the direct management chain. The engineers who flagged problems at Facebook, Google, and other companies often faced professional consequences for doing so. A healthy engineering culture protects people who raise ethical concerns.

​

8.4 Ethical Frameworks (Simplified for Engineers)

You don’t need a philosophy degree, but three frameworks are useful: Utilitarianism (maximize overall wellbeing): “Does this feature create more good than harm, across all affected users?” Useful for: weighing trade-offs where some users benefit and others are harmed. Limitation: can justify harming a minority if the majority benefits. Deontological ethics (follow the rules, regardless of outcome): “Is this action inherently right or wrong, regardless of the result?” Useful for: absolute principles like “never sell user data to third parties” or “never build surveillance tools for authoritarian governments.” Limitation: rigid rules can conflict with each other. Virtue ethics (be the kind of person/organization you’d admire): “Is this the kind of thing a company I’d be proud to work at would do?” Useful for: gut-check decisions that don’t fit neatly into cost-benefit analysis. Limitation: subjective --- depends on whose virtues you admire. In practice, senior engineers use all three: utilitarian analysis for most trade-offs, deontological lines they won’t cross, and virtue ethics as a final gut check.

​

8.5 The Engineer’s Ethical Toolkit --- Concrete Actions for Difficult Situations

Ethical frameworks are useful for thinking. But when your manager tells you to ship a feature that harvests user data without consent, you don’t need a philosophy lecture --- you need a playbook. This section provides specific, battle-tested actions for the moments when ethical engineering gets personal and uncomfortable.

​

Push Back Scripts --- What to Actually Say

The hardest part of ethical engineering is not knowing something is wrong --- it’s saying so to people who have authority over your career. These scripts are designed to be professional, constructive, and hard to dismiss. When a PM asks you to build something manipulative (dark pattern, deceptive pricing, privacy-hostile feature):

“I want to make sure we’ve thought through the full cost of this approach. The FTC fined Epic Games $520 million in 2022 for similar dark patterns, and the EU Digital Services Act explicitly prohibits these designs. I want to help us hit the business goal here --- can we explore approaches that achieve the same conversion improvement without the regulatory and reputational risk?”

Why this works: You’re not saying “no.” You’re reframing the conversation from “engineer refuses task” to “engineer identifies risk and proposes alternatives.” You’re speaking the language of business risk, which is the language PMs and leadership respond to. When you discover bias in a model or system:

“I’ve found a significant performance gap in our model across demographic groups --- [specific metrics]. Given that [specific regulation or legal standard] applies to our use case, and that companies like [relevant example] have faced [specific consequence] for similar issues, I think we need to pause deployment and address this. I’ve drafted a remediation plan I’d like to walk through with you.”

Why this works: You’ve come with data, legal context, and a solution. You’re not raising a vague concern --- you’re presenting a risk assessment with a recommended action. When someone proposes collecting data you believe is unnecessary:

“Before we add this data field, can we run through the data minimization checklist? I want to make sure we can answer three questions: Do we need this specific data to provide the service? How long do we keep it? And what’s our plan if it’s included in a breach or a GDPR deletion request? If we can answer all three clearly, I’m on board.”

Why this works: You’re not blocking --- you’re asking for due diligence that any responsible organization should already be doing. If the answers exist, great. If they don’t, you’ve surfaced a gap without making it personal. When you’re told “just build it, we’ll deal with ethics/compliance later”:

“I understand the timeline pressure, and I want to ship on time too. But in my experience, ‘we’ll deal with it later’ becomes ‘we shipped a liability and now we’re in reactive mode.’ Can we take 30 minutes to identify the top three risks and decide which ones we’re genuinely willing to accept vs. which ones need to be addressed before launch? That way we’re making a deliberate decision rather than an accidental one.”

Why this works: You’re acknowledging the business constraint (timeline) while reframing “later” as “risk acceptance” --- which forces an explicit decision rather than letting ethical concerns slide by default.

​

Escalation Paths --- When Pushback Isn’t Enough

Sometimes your direct manager disagrees with you. Sometimes the PM overrules you. Sometimes you’ve raised the issue and been told to build it anyway. Here’s how to escalate without torpedoing your career. Level 1: Document and Propose (You’ve already done this)

• Put your concerns in writing (email, not Slack --- you want a permanent record)
• Include specific risks, affected populations, and regulatory exposure
• Propose at least one alternative approach
• Set a clear ask: “I’d like us to [specific action] before proceeding”

Level 2: Expand the Audience

• If your manager dismisses the concern, bring it to the next level or to a peer leader
• Loop in someone from legal, compliance, or security --- frame it as “I want to make sure we’re covered”
• Raise it in a design review or architecture review where multiple senior engineers are present
• Use the framing: “I want to make sure the right people have visibility into this decision”

Level 3: Formal Channels

• If your company has an ethics board, ombudsperson, or anonymous reporting mechanism, use it
• Document that you’ve raised the concern through informal channels first
• Be specific: “I raised this with [person] on [date], and the decision was to proceed without addressing [risk]”
• Keep copies of all documentation outside of company-controlled systems (personal email, personal cloud storage)

Level 4: External Channels (Last Resort)

• If internal channels are exhausted and the harm is serious, consider regulatory reporting (many jurisdictions have whistleblower protections)
• Consult a personal attorney before taking external action
• Understand your employment agreement, NDA, and any non-disparagement clauses
• Organizations like the Government Accountability Project, the Electronic Frontier Foundation, and the Whistleblower Network News provide guidance and legal referrals

​

Documentation Strategies --- Creating a Paper Trail

In ethical disputes, the person with documentation wins. Not in a legal sense (though that too), but in the sense that documented concerns cannot be retroactively minimized or denied. What to document:

• The concern: What you believe is wrong, who is affected, and the potential severity
• The evidence: Specific data, metrics, user reports, or regulatory citations that support your concern
• Who you told: Names, dates, and the substance of each conversation
• The response: What was decided, by whom, and the reasoning given
• Your recommendation: What you proposed as an alternative and why

How to document:

• Email over Slack. Emails are harder to delete, easier to forward, and create clearer timestamps. After a verbal conversation where an ethical concern was discussed, send a follow-up email: “Per our conversation today, I want to confirm my understanding that we’ve decided to [decision] despite [risk]. I’ve documented my recommendation to [alternative] for our records.”
• Personal copies. Keep copies of your documentation outside company systems. If you’re ever let go, you lose access to company email immediately. (Check your employment agreement --- some companies prohibit removing company data, so document your personal observations and concerns rather than copying company data.)
• Design review records. If you raise an ethical concern in a design review, ensure it’s captured in the meeting notes or review document. If notes aren’t being taken, volunteer to write them.
• Commit messages and code comments. For technical decisions with ethical implications, document the reasoning in the code. A comment like // Using differential privacy with epsilon=2.0 per privacy review PR-1234 creates a permanent record of deliberate decision-making.

​

When to Refuse a Task

There are times when pushback, escalation, and documentation are not enough --- when the right answer is simply “No, I will not build this.” This is the nuclear option, and it should be reserved for genuinely serious situations. But it is always available to you. Criteria for refusal:

1. The system’s primary purpose is to cause harm --- surveillance of civilian populations, tools designed to deceive or manipulate vulnerable people, weapons systems that violate international humanitarian law
2. You have raised the concern through all available channels and been overruled --- refusal is not a first move; it’s a last resort
3. The potential harm is severe and irreversible --- denial of fundamental rights, risk to physical safety, enabling of persecution or discrimination
4. Compliance would violate your professional obligations --- the ACM Code of Ethics (Section 1.2: “Avoid harm”) and the IEEE Code of Ethics both establish that engineers have a professional obligation to refuse work that causes unjustified harm

How to refuse:

• State clearly and professionally: “I’m not able to work on this project because [specific reason]. I’ve documented my concerns in [specific document/email]. I understand if this affects my role, and I’m prepared to discuss alternatives.”
• Do not be dramatic. Do not make it about your moral superiority. Make it about professional judgment, the way a structural engineer would refuse to approve a building they believed was unsafe.
• Have a plan for what comes next. Talk to a lawyer. Update your resume. Lean on your network. This is not defeatist --- it’s pragmatic.

​

Building Your Ethical Support Network

You don’t want your first ethical escalation to be the first time you’ve ever talked to someone in legal, someone senior in another org, or another engineer who cares about these issues. Build relationships before you need them.

• Know your company’s ethics infrastructure. Does your company have an ethics board? An ombudsperson? A chief privacy officer? An anonymous reporting hotline? Find out now --- not when you’re in crisis.
• Build cross-functional relationships. Having a friendly contact in legal, compliance, and HR means you can get informal advice before formally escalating. A five-minute “Hey, can I bounce a hypothetical off you?” conversation is worth more than a formal complaint.
• Join professional communities. The ACM’s Special Interest Group on Computers and Society (SIGCAS), the Partnership on AI, and communities like the Responsible AI Meetup provide peer support and frameworks for ethical decision-making.
• Find your ethical allies on the team. You almost certainly aren’t the only person who notices when something feels wrong. Having even one ally who will co-sign your concern transforms “one person complaining” into “a pattern of concern.”

---

​

9. Interview Questions

---

​

10. Real-World Case Studies

​

The Facebook Mood Experiment (2014)

What happened: Facebook’s Core Data Science team manipulated the News Feed of 689,003 users to study emotional contagion. Users shown more negative content posted more negatively; users shown more positive content posted more positively. The study was published in PNAS without obtaining informed consent beyond Facebook’s generic Terms of Service. Why it matters: This demonstrated that tech companies had both the power and the willingness to manipulate users’ emotional states at scale. It triggered a global conversation about research ethics in technology companies and led Facebook to establish an internal research ethics review process. It also revealed a gap in existing regulations --- the Common Rule (which governs academic research ethics) doesn’t apply to corporate research. The lesson for engineers: Just because you can run an experiment doesn’t mean you should. The bar for human experimentation in medicine requires informed consent, ethics review, and the ability to withdraw. The bar for human experimentation in technology should be at least as high.

​

Google’s Project Dragonfly (2018)

What happened: Google secretly developed a censored search engine for China that would filter results for terms like “human rights” and “student protest,” and would link search queries to users’ phone numbers --- enabling the Chinese government to identify and track dissidents. The project was leaked by an employee, sparking a massive internal revolt. Over 1,400 employees signed a protest letter. Several resigned publicly. Why it matters: It showed that even companies with explicit ethical principles (“Don’t be evil”) can pursue projects that contradict those principles when the business opportunity is large enough ($600B+ Chinese search market). It also showed that employee activism can work --- Google ultimately cancelled the project. The lesson for engineers: Ethical principles are only real if they’re applied when it’s costly to do so. Saying “we value human rights” while building surveillance tools for authoritarian governments is not having principles --- it’s having a marketing strategy.

​

Apple’s Privacy Stance (2016-Present)

What happened: When the FBI demanded Apple create a backdoor to unlock the San Bernardino shooter’s iPhone, Apple refused. CEO Tim Cook published an open letter explaining that creating a backdoor for one phone would compromise the security of every iPhone. Apple has since made privacy a core product differentiator: on-device Face ID processing, App Tracking Transparency (which cost Facebook an estimated $10 billion in ad revenue), Private Relay (VPN-like service), and Mail Privacy Protection. Why it matters: Apple proved that privacy can be a viable business strategy, not just a compliance cost. By making privacy a feature, they gained competitive advantage while genuinely protecting users. App Tracking Transparency alone was one of the most impactful privacy protections ever deployed --- it gave 1.5+ billion iPhone users the ability to opt out of cross-app tracking with a single tap. The lesson for engineers: You don’t have to choose between business success and ethical behavior. The companies that figure out how to align the two --- where doing the right thing is also the profitable thing --- build the most durable competitive advantages.

---

​

11. Resources and Further Reading

​

Codes and Frameworks

• ACM Code of Ethics --- the foundational ethical code for computing professionals. Short enough to read in 15 minutes, comprehensive enough to guide a career
• IEEE Ethically Aligned Design --- a comprehensive framework for ethical AI development, more detailed and prescriptive than the ACM code
• Google AI Principles --- influential industry principles published after the Maven and Dragonfly controversies. Worth reading alongside the criticisms of how consistently Google applies them

​

Privacy and Civil Liberties

• Electronic Frontier Foundation (EFF) --- the leading digital civil liberties organization. Their blog covers privacy, surveillance, and free expression with both legal and technical depth
• NIST Privacy Framework --- a practical, structured approach to managing privacy risk. Less legalistic than GDPR, more actionable for engineers
• Differential Privacy by Dwork & Roth --- the foundational academic text on differential privacy. Free PDF. Dense but essential for anyone building privacy-preserving systems

​

Bias and Fairness

• Gender Shades (Joy Buolamwini & Timnit Gebru) --- the landmark study that exposed racial and gender bias in commercial facial recognition. The video presentation is accessible and compelling
• Fairness and Machine Learning (Barocas, Hardt, Narayanan) --- free online textbook covering the mathematical foundations of algorithmic fairness. The definitive academic reference
• AI Fairness 360 (IBM) --- open-source toolkit with 70+ fairness metrics and 10+ bias mitigation algorithms. Practical and well-documented

​

Algorithmic Auditing and Fairness Tools

• Aequitas --- open-source bias audit toolkit from the University of Chicago’s Center for Data Science and Public Policy. Generates visual audit reports that are accessible to non-technical stakeholders. Pairs well with the five-phase audit process in Section 2.5
• Microsoft Fairlearn --- assessment and mitigation toolkit with an interactive dashboard. Strong scikit-learn integration and excellent documentation for teams new to fairness evaluation
• Google What-If Tool --- interactive model exploration tool for probing behavior across data slices. Best for exploratory analysis before a formal audit

​

AI Safety and Governance

• EU AI Act Full Text --- the complete regulation with annotations and practical guides
• Model Cards for Model Reporting (Mitchell et al.) --- the original paper proposing model cards. Short and practical
• OWASP Top 10 for LLM Applications --- security risks specific to LLM-powered applications, including prompt injection, data poisoning, and model theft

​

Accessibility

• WebAIM (Web Accessibility In Mind) --- practical guides, training, and the WAVE evaluation tool
• The A11y Project --- community-driven, beginner-friendly accessibility resources and checklist

​

Green Software

• Green Software Foundation --- principles, patterns, and the SCI specification for measuring software carbon intensity
• Principles of Green Software Engineering --- free course covering carbon-aware, energy-efficient software development

---

​

12. Quick Reference: The Ethical Engineering Checklist

​

Before Building

• What data are we collecting? Is all of it necessary? (data minimization)
• Have we defined data retention policies and deletion procedures?
• Have we conducted a privacy impact assessment?
• Have we checked our training data for demographic representation and bias?
• Have we defined which fairness metric is appropriate for this use case?
• Is our feature accessible (WCAG 2.1 AA)?
• Have we considered who could be harmed and how?

​

During Development

• Are we testing across demographic groups, not just aggregate metrics?
• Are defaults set to maximum privacy (opt-in, not opt-out)?
• Can users understand and control how their data is used?
• Have we avoided dark patterns in our UI?
• Is there a human override for automated decisions?
• Are we logging only what we need and not logging sensitive data?

​

After Launch

• Is demographic-segmented monitoring in place?
• Do we have alerts for fairness metric drift?
• Is there a process for users to report harm and appeal automated decisions?
• Are we conducting regular bias audits?
• Are we responding to deletion requests within GDPR’s 30-day window?

​

When Things Go Wrong

• Treat ethical failures with the same urgency as production outages
• Quantify the harm: who is affected, how many, how severely?
• Stop the bleeding: rollback, disable, or patch immediately
• Communicate transparently with affected users
• Conduct a blameless postmortem focused on systemic failures
• Implement systemic fixes, not just patches for the immediate issue

---

​

Interview Deep-Dive Questions

These questions go beyond surface-level ethics knowledge. They test whether you can navigate the messy, ambiguous, high-stakes ethical decisions that arise in production systems at scale --- the kind where there is no clean answer, only trade-offs you need to reason about clearly.

​

Q1: You are the tech lead on a health-tech product. Your data science team wants to use patient diagnostic data collected for one purpose (treatment recommendations) to train a model for a different purpose (predicting insurance risk). The business case is strong. Walk me through how you evaluate this.

​

Follow-up: What if the data science team argues that the data is “already anonymized” and therefore not subject to these constraints?

​

Follow-up: The CEO overrules you and says to proceed. What do you do?

---

​

Q2: You are designing a hiring algorithm. How do you handle the mathematical impossibility of satisfying all fairness metrics simultaneously?

​

Follow-up: A hiring manager argues that any fairness constraint on the model will reduce “the best candidates getting through.” How do you respond?

​

Going Deeper: How would you validate that your fairness-constrained hiring model actually produces better outcomes?

---

​

Q3: Your company uses a third-party LLM API for a customer-facing feature. A user discovers that their sensitive input data appeared in another user’s LLM response. Walk me through the incident response and the architectural lessons.

​

Follow-up: After this incident, your team proposes building an in-house LLM to avoid third-party risk. What are the ethical trade-offs of that decision?

---

​

Q4: Explain the tension between model explainability and model performance. When is a less accurate but explainable model the right choice?

​

Follow-up: Your product team says “users don’t care about explainability, they just want accurate results.” How do you respond?

​

Going Deeper: How would you implement a real-time explanation system for a high-throughput ML pipeline without destroying latency?

---

​

Q5: Your company wants to deploy facial recognition for building security at your offices. As the senior engineer, what questions do you raise before writing a single line of code?

​

Follow-up: Leadership decides to proceed. How do you design it to minimize harm?

---

​

Q6: Differential privacy sounds great in theory. What are the practical engineering challenges of implementing it in a real analytics pipeline?

​

Follow-up: Your product team says the noise from differential privacy makes the analytics “useless.” How do you handle that?

---

​

Q7: You are building an AI content moderation system for a global platform. How do you handle the fact that what constitutes “harmful content” varies dramatically across cultures, legal jurisdictions, and political contexts?

​

Follow-up: A government requests that you remove content criticizing its policies, citing local law. How do you evaluate that request?

---

​

Q8: How do you design an A/B testing framework that is both statistically rigorous and ethically sound?

​

Follow-up: Your growth team says that requiring ethics review for A/B tests will “kill velocity.” How do you make the case for it?

---

​

Q9: You are on a team that discovers a critical vulnerability in your product. Fixing it properly will take 3 weeks, but a “good enough” patch can ship in 2 days. 50,000 users are currently exposed. Walk me through the decision.

​

Follow-up: After shipping the patch, your manager says not to notify users because “it’ll cause panic and we’ll lose customers.” How do you handle this?

---

​

Q10: How would you build an ethical framework for using generative AI in your company’s products --- not just a policy document, but an actual engineering system that enforces it?

​

Follow-up: A team argues that the gateway adds 200ms of latency and they need to bypass it for their real-time feature. What do you do?

​

Going Deeper: How do you handle the problem that your output guardrails themselves might have biases --- for example, a toxicity classifier that flags African American Vernacular English at higher rates?

---

​

Q11: An engineer on your team raises a concern that a feature you designed has potential for misuse by abusive partners (e.g., a location-sharing feature). You did not consider this during design. What do you do?

​

Follow-up: The PM says these safety features will reduce engagement metrics because they add friction. How do you make the case for shipping them?

---

​

Q12: What does “ethical debt” look like in practice, and how do you convince leadership to prioritize paying it down when it is not causing visible problems yet?

​

Follow-up: How do you measure the ROI of ethical engineering investments when the returns are primarily “bad things that did not happen”?

---

​

Advanced Interview Scenarios

These questions are designed to expose the gap between theoretical ethics knowledge and battle-tested engineering judgment. Several of them are deliberately constructed so that the “obvious” ethical answer is wrong, incomplete, or dangerously naive. Real ethical engineering is not about having clean principles --- it is about making defensible decisions in the mud.

---

​

Q13: You join a new company and inherit a recommendation algorithm that has been in production for 3 years. Nobody who built it still works there. There is no model card, no documentation of training data provenance, no fairness audit. It serves 8 million users daily. What do you do?

​

Follow-up: During your shadow audit, you discover the model is performing significantly better for a minority group than the majority group. Is that a problem?

​

Follow-up: The VP of Engineering says “we don’t have budget for an 8-week audit, just add a disclaimer and move on.” How do you respond?

---

​

Q14: Your company is deciding between two cloud regions for a new data-intensive service. Region A runs on 90% renewable energy and costs 40% more. Region B runs on a coal-heavy grid and is the cheaper option. The service will process 500TB monthly. How do you think about this?

​

Follow-up: An engineer argues that our 788 tons of CO2 is a rounding error compared to global emissions, so this is performative. How do you respond?

​

Follow-up: How would you build carbon awareness into the engineering culture without making it burdensome?

---

​

Q15: You are building a GDPR-compliant consent management system. Your legal team says “just add a cookie banner.” Why is that answer dangerously incomplete, and what would you actually build?

​

Follow-up: How do you handle consent for data that has already been processed before the user revoked consent?

​

Follow-up: Your product team wants to use “legitimate interest” instead of consent as the legal basis, arguing it avoids the consent UI entirely. What is your response?

---

​

Q16: Your company’s accessibility audit reveals that your core product is at WCAG 2.1 AA compliance level of approximately 30%. Fixing everything would take an estimated 6 engineering-months. Product leadership wants to “get to it next quarter.” You are the senior engineer. What do you do?

​

Follow-up: A designer argues that accessibility constraints “ruin the aesthetic” of the product. How do you handle this?

---

​

Q17: You are the tech lead on a team building a “safety score” for an insurance company. The model uses publicly available data (social media activity, neighborhood crime stats, consumer purchase data) to predict risk --- no traditional actuarial data at all. The model is more accurate than traditional actuarial methods. Is there an ethical problem?

​

Follow-up: The data science team says “we’re not using race, so it can’t be racial discrimination.” Dismantle that argument.

---

​

Q18: A whistleblower on your team leaks to a journalist that your company’s content moderation system has been systematically under-moderating hate speech in non-English languages. You are the engineering manager. The CEO is furious and wants to find and fire the leaker. How do you handle this?

​

Follow-up: How would you design an internal escalation system that reduces the likelihood of external leaks?

---

​

Q19: Your team ships a feature using a large language model. Six months later, a copyright holder discovers that their copyrighted training manual --- priced at $500 per copy and sold to 200 enterprise clients --- can be reproduced nearly verbatim by prompting your product in a specific way. They send a cease-and-desist. Walk me through the technical and ethical response.

​

Follow-up: How do you distinguish between a model that has “learned” from content versus “memorized” it? Where is the ethical line?

---

​

Q20: You are asked to design an age verification system for a social media platform to comply with new child safety legislation. The obvious approach --- requiring government ID upload --- has serious problems. Walk me through the trade-offs.

​

Follow-up: Privacy advocates argue that any age verification is surveillance. Child safety advocates argue that any platform without verification enables child exploitation. How do you navigate this?

---

​

Q21: Your company’s AI chatbot is deployed in a mental health support context. A user tells the chatbot they are planning to harm themselves. The chatbot is not designed for crisis intervention. What happens, and what should have been built?

​

Follow-up: How do you handle the privacy tension --- you need to log crisis conversations for safety review, but the content is among the most sensitive personal data imaginable?

​

Follow-up: A competitor launches a mental health AI with no safety guardrails and gains rapid market share. Your CEO says “we’re being too cautious.” What do you say?