Informatica Interview Questions

ETL stands for Extract, Transform, Load, the process of pulling data from source systems, transforming it into the right shape and quality, and loading it into a target system like a data warehouse. Informatica is a tool built specifically to design, automate, and manage that ETL process visually rather than writing custom scripts for every pipeline.

A mapping is the core object in Informatica that defines the flow of data from source to target, including every transformation applied along the way. It's built visually by connecting a source, a series of transformations, and a target within the Designer or IICS mapping tool.

A transformation is an object within a mapping that performs a specific operation on data as it moves through the pipeline, such as filtering rows, joining data from two sources, aggregating values, or looking up related data. Chaining transformations together builds the full logic needed to reshape source data into the target format.

An active transformation can change the number of rows passing through it, such as a Filter transformation removing rows or an Aggregator transformation reducing rows through grouping. A passive transformation never changes row count, it only modifies or passes through the same number of rows it receives, like an Expression transformation.

The Source Qualifier is the default transformation Informatica automatically creates when you add a relational source to a mapping. It represents the rows read from the source and lets you define a custom SQL query, filter condition, or join if the data needs some preparation before entering the rest of the mapping.

The Expression transformation performs row-level calculations, like concatenating fields, converting data types, or applying conditional logic, without changing the number of rows. It's one of the most commonly used transformations since almost every mapping needs some field-level manipulation.

The Filter transformation removes rows from the data flow that don't meet a specified condition. Only rows that satisfy the filter condition pass through to the next transformation or the target, making it a straightforward way to exclude unwanted records early in a mapping.

The Aggregator transformation performs calculations across groups of rows, like SUM, COUNT, AVG, MIN, or MAX, similar to a GROUP BY in SQL. It's used whenever a mapping needs to summarize detail-level data into aggregated results before loading it to the target.

The Joiner transformation combines data from two different sources, similar to a SQL join, and is used when the sources can't be joined directly at the database level, such as joining a relational table with a flat file. It supports normal, master outer, detail outer, and full outer join types.

A Lookup transformation retrieves related data from another table, file, or source based on a matching condition, similar to a VLOOKUP in Excel. It's commonly used to bring in a reference value, like fetching a customer's name from a customer table based on a customer ID present in the main data flow.

A connected Lookup sits directly in the data flow of the mapping pipeline, receiving input and passing output to the next transformation for every row. An unconnected Lookup is called conditionally from within an Expression transformation using a special lookup function, only executing when explicitly invoked, which can improve performance when the lookup isn't needed for every row.

A workflow is a set of instructions, called tasks, that tells Informatica how and when to run one or more sessions (which execute mappings). It defines the execution order, dependencies, and scheduling for the ETL processes a mapping needs to actually run.

A session is a task within a workflow that actually executes a specific mapping, reading from the defined source and writing to the defined target based on the mapping's logic. It's where runtime configuration like connection details and performance settings are specified.

PowerCenter's architecture includes the Repository Service, which stores metadata about mappings and workflows, the Integration Service, which actually executes workflows and sessions, and client tools like Designer, Workflow Manager, and Workflow Monitor used to build and manage these objects.

A Router transformation tests rows against multiple conditions and routes each row to a different output group based on which condition it satisfies, similar to a series of IF/ELSE branches. Unlike a Filter, which only keeps or discards rows against a single condition, a Router can split data into several parallel paths in one pass.

The Sorter transformation orders rows based on one or more specified key fields, either ascending or descending. It's often used before an Aggregator or Joiner transformation, since sorted input can significantly improve the performance of those downstream transformations.

A target is the destination where transformed data is loaded at the end of a mapping, such as a relational database table, a flat file, or a cloud data warehouse. Target definitions specify the structure the incoming data must match before it can be written.

A mapping is a complete, standalone definition of a full ETL data flow from source to target. A mapplet is a reusable set of transformations that can be embedded inside multiple mappings, useful for standardizing common logic, like a data cleansing routine, that many mappings need to apply consistently.

Informatica supports a wide range of formats including relational databases through native or ODBC connections, flat files like CSV and fixed-width text, XML, JSON, and various cloud storage and application connectors in IICS, like Salesforce, Amazon S3, and Snowflake.

A task is a single step within a workflow. Common types include a Session task (runs a mapping), a Command task (runs an external shell script or command), a Decision task (branches workflow logic based on a condition), and an Email task (sends a notification, often on success or failure).

Workflow Monitor is the PowerCenter client tool used to view and track the execution status of workflows and sessions, whether running, succeeded, or failed. It provides logs and run statistics useful for troubleshooting when a workflow doesn't behave as expected.

The repository is a relational database that stores all the metadata about Informatica objects, mappings, transformations, workflows, sessions, and connections. It's the central store the Designer and Workflow Manager tools read from and write to when building and managing ETL logic.

Designer is the PowerCenter client used to build the actual data integration logic. It contains several workspaces, including Source Analyzer for importing source definitions, Target Designer for defining targets, and Mapping Designer for building the mappings that connect them with transformations.

A flat file source is a delimited or fixed-width text file, like a CSV, used as a data source. Informatica reads it using a flat file definition that specifies the column structure, data types, and delimiter, letting it be treated much like a relational source within a mapping.

A fact table stores measurable, quantitative data, like sales amounts or transaction counts, typically at a high volume and grain. A dimension table stores descriptive attributes, like customer or product details, used to filter and group facts. ETL processes typically load dimension tables first, since fact tables usually reference dimension keys.

The Normalizer transformation converts a single row containing repeating columns, like a COBOL record with multiple occurrences of a field, into multiple rows in a normalized format. It's most commonly associated with processing mainframe or COBOL copybook-based source data.

The Rank transformation selects the top or bottom N rows from a group based on a specified field, similar to using ROW_NUMBER or RANK in SQL with a filter. It's used when a mapping needs to identify, for example, the top five highest-value transactions per customer.

The Transaction Control transformation defines commit and rollback points within a mapping based on a specified condition, giving control over how rows are grouped into database transactions during a load, rather than relying solely on session-level commit settings.

A session log records detailed information about a single session's execution, including rows read, written, and rejected, along with any errors specific to that mapping run. A workflow log records higher-level information about the overall workflow's execution, including which tasks ran and their success or failure status.

In Designer, you use the Source Analyzer or Target Designer to import a definition directly from a database by connecting to it and selecting tables, or by importing a flat file's structure using a file wizard that reads the header and sample rows to infer column definitions.

The Stored Procedure transformation calls a stored procedure that already exists in the source or target database from within a mapping, useful for executing pre-defined business logic, validation, or lookups that already live in the database rather than duplicating that logic in Informatica.

A connected Stored Procedure transformation runs for every row in the pipeline, receiving input and returning output as part of the main data flow. An unconnected one runs independently, typically called before or after the session runs, or invoked conditionally from an Expression transformation, rather than processing every row automatically.

A mapping parameter holds a constant value for the entire duration of a session run, set before the session starts and unchanged throughout. A mapping variable can change its value during the session's execution, and it can also retain its value across separate session runs if configured to do so.

Pre-session and post-session commands or SQL are actions configured to run automatically before or after a session's main data load, such as truncating a staging table before load, or sending a notification after a load completes. They're useful for automating setup and cleanup steps around the core ETL logic.

The Union transformation requires all input groups to have the same number of ports with matching data types, similar to a UNION ALL rather than a plain UNION, meaning it doesn't automatically remove duplicate rows the way a SQL UNION would. Deduplication has to be handled separately, typically with an Aggregator or Sorter with distinct options, if it's needed.

A Slowly Changing Dimension (SCD) handles how a dimension table tracks changes to attribute values over time. Type 1 overwrites the old value with no history kept, Type 2 inserts a new row with effective-dated columns to preserve full history, and Type 3 keeps limited history in additional columns. Informatica implements these using a combination of Lookup, Expression, and Router transformations, or with the SCD wizard/mapping templates available in some versions.

Errors can be handled by routing rejected or invalid rows to a separate error table or file using a Router transformation based on validation logic, rather than letting the session fail entirely on bad data. Session-level settings also control error thresholds, allowing a session to tolerate a certain number of row errors before stopping, and PowerCenter logs rejected rows to a bad file by default.

A reusable transformation is defined once in the repository and can be used across multiple mappings, ensuring consistent logic and reducing duplicate work. It's worth creating when the same transformation logic, like a specific data cleansing rule or a standard lookup, needs to be applied identically in several different mappings.

Session partitioning splits a single pipeline's data processing across multiple parallel threads, which can significantly speed up large data loads by processing chunks of data concurrently rather than sequentially. Partition types include pass-through, key-range, hash, and round-robin, chosen based on how the data needs to be distributed for correctness and performance.

A static cache is built once at the start of a session and doesn't change during execution, meaning it won't reflect any inserts made to the target during that same session. A dynamic cache updates itself as rows are processed, useful when a mapping needs to check for and avoid inserting duplicate rows within the same run, since it 'sees' rows already inserted earlier in the session.

A parameter file lets you externalize values, like connection names, folder paths, or filter conditions, from the mapping or session itself, so the same mapping can run against different environments or configurations without being edited. It's referenced at session or workflow run time and is a standard practice for promoting mappings across dev, test, and production environments.

I'd check the session log and performance details for bottleneck indicators, like a low throughput reader or writer thread, and review the mapping for expensive operations, unindexed lookups, unnecessary sorting, or an Aggregator processing more rows than needed. Adding partitioning, tuning cache sizes for Lookup and Aggregator transformations, and pushing filtering logic as early as possible in the pipeline are common fixes.

Pushdown optimization converts some or all of a mapping's transformation logic into SQL that's executed directly by the source or target database instead of the Informatica engine, which can significantly improve performance for large volumes since the database often processes set-based operations faster than row-by-row engine processing.

The Update Strategy transformation explicitly marks each row for insert, update, delete, or reject before it reaches the target, giving fine-grained control over how the target table is modified. It's essential when a mapping needs to handle a mix of new and existing records differently rather than treating every row as a simple insert.

CDC can be implemented by comparing source data against a previous snapshot using Lookup and Expression logic to detect new, changed, or deleted rows, or by using database-native CDC features (like Oracle GoldenGate or SQL Server CDC) that Informatica can consume directly, avoiding full-table scans on every run for large source tables.

The Sequence Generator produces a sequence of unique numeric values, commonly used to generate surrogate keys for dimension tables. It can start at a specified value and increment by a defined step, and it maintains its current value across sessions if configured to persist.

NULL handling typically uses functions like IIF combined with ISNULL, or the NVL/COALESCE-style functions available in the Expression transformation, to substitute a default value or apply conditional logic when a field is NULL. Explicitly deciding how each field should handle NULLs prevents unexpected downstream errors or incorrect aggregations.

PowerCenter is Informatica's traditional on-premise ETL tool, installed and managed on a company's own infrastructure. IICS is the cloud-native version, offering similar mapping and transformation capabilities through a browser-based interface, with built-in connectors for cloud applications and services, and a subscription-based, serverless-leaning operating model rather than managed infrastructure.

Workflows can be scheduled directly within Workflow Manager (or the IICS scheduler) using recurring schedules based on time intervals, or triggered by an external scheduler like Control-M or Autosys through command-line utilities (pmcmd for PowerCenter). Event-based triggers, like a file arrival, are also common for kicking off a workflow.

The Union transformation combines rows from multiple input sources with the same structure into a single output, similar to a SQL UNION ALL. It's used when data from several sources with matching schemas needs to be merged into one pipeline before further processing.

The Debugger tool in Designer lets you step through a mapping row by row, inspecting transformation outputs at each stage to pinpoint exactly where data goes wrong. For production issues, reviewing session logs closely, checking for data type mismatches, truncation errors, or constraint violations at the target, is usually the first step before reaching for the interactive debugger.

A mapping can include multiple target instances, and Informatica determines the load order based on target load plan settings or key relationships unless explicitly configured. For targets with dependencies, like a parent table needing to load before a child table with a foreign key, the target load order needs to be explicitly set to avoid constraint violations.

Session recovery lets a failed session resume from the point of failure rather than reprocessing all data from the beginning, using recovery data Informatica tracks during the run when recovery is enabled. This is especially valuable for very long-running sessions where restarting from scratch after a late failure would waste significant time.

I'd consolidate lookups against the same table where possible, since each separate Lookup transformation builds and holds its own cache, duplicating memory usage unnecessarily. Combining related lookup logic into a single Lookup transformation returning multiple columns, rather than several separate lookups against the same source, reduces both cache overhead and processing time.

A bulk load uses the target database's native bulk loading utility to insert data faster by bypassing certain logging and constraint checks, at the cost of some flexibility, like limited support for update or reject handling. A normal load inserts rows through standard SQL, which is slower but supports the full range of insert, update, delete, and reject operations.

I'd use a Lookup transformation against the target table to check whether a matching key already exists, followed by an Update Strategy transformation to mark each row as insert or update based on that lookup result. This combined pattern, often called an upsert, is a standard way to keep a target table synchronized with changing source data.

The commit interval determines how many rows are processed before Informatica issues a database commit during a session's load. A smaller interval commits more frequently, reducing the amount of work lost if a session fails partway through, while a larger interval can improve throughput at the cost of a larger rollback if something goes wrong mid-session.

User-defined groups in a Router each have their own condition, and a row can pass into any number of them whose condition it satisfies. The default group catches any row that doesn't match any of the user-defined conditions, which is useful for capturing and separately handling records that don't fit an expected pattern.

I'd focus on pushing as much processing as possible to the database through pushdown optimization or SQL overrides, applying partitioning aligned with how the source data is naturally distributed, sizing Lookup and Aggregator caches appropriately for available memory, and eliminating unnecessary transformations or sorts that add overhead without adding value. I'd also verify target-side factors, like whether indexes or constraints are slowing bulk loads, and consider disabling them temporarily during large loads.

I'd design for either true partition-based isolation, where each mapping loads a distinct, non-overlapping subset of data, or use database-level locking and transaction control carefully if overlap is unavoidable. Sequencing dependent loads through workflow dependencies rather than relying purely on database locking tends to be more predictable and easier to troubleshoot when something goes wrong.

I'd build a shared error-handling mapplet or common logic pattern that every mapping incorporates, capturing rejected rows with contextual metadata (source mapping, timestamp, error reason) into a centralized error table rather than scattering ad hoc error logic across individual mappings. This gives operations teams one consistent place to monitor and triage data quality issues across the whole platform.

I'd start with an inventory and complexity assessment of existing mappings, since some PowerCenter-specific transformations or custom logic don't map one-to-one to IICS equivalents and need redesign rather than a direct lift-and-shift. Migrating in phases, starting with simpler, lower-risk mappings to validate the process and build team familiarity with IICS, reduces risk compared to attempting a full cutover all at once.

I'd build a generic mapping template driven by a parameter or configuration table that defines source, target, and transformation rules for each entity, so one parameterized mapping handles many structurally similar loads instead of needing a near-duplicate mapping per source table. This significantly reduces maintenance overhead, though it adds complexity to the framework itself, which needs to be weighed against how many similar patterns actually exist.

I'd embed validation rules directly into mappings using Expression and Router transformations to catch issues like missing required fields, invalid formats, or referential integrity violations before data reaches the target. For more sophisticated profiling and rule management, Informatica Data Quality (IDQ) integrates directly with PowerCenter and IICS mappings for centrally managed, reusable quality rules.

I'd rely on the repository's version control and deployment groups (or IICS's asset export/import) to move validated mappings and workflows between environments, paired with parameter files that externalize environment-specific values like connection names. A consistent, automated deployment process rather than manual object copying reduces the risk of environment drift or a missed configuration change.

I'd evaluate whether the Lookup cache can be persisted across sessions rather than rebuilt every run, since rebuilding a large cache repeatedly is often the actual bottleneck. If the lookup table is genuinely large, I'd also consider restructuring it as an unconnected Lookup called only when needed, or pushing the join down to the database entirely if pushdown optimization applies cleanly to that portion of the mapping.

I'd benchmark current session run times and resource utilization against expected data growth, and model where CPU, memory (especially for caching), and I/O bottlenecks are likely to emerge first. Partitioning strategy and grid/high-availability configuration decisions get revisited as volumes grow, since a configuration that performed fine at a smaller scale often needs rearchitecting rather than simply adding more hardware.

I'd evaluate whether Informatica's real-time capabilities, like PowerExchange CDC or message queue-based session triggers, genuinely fit the latency requirement, since a true real-time pattern requires rethinking session design, error handling, and monitoring compared to batch. A micro-batch approach running frequent, smaller incremental loads is often a more practical middle ground than a fully event-driven architecture if sub-second latency isn't actually required.

I'd look closely at resource contention first, whether multiple concurrent sessions are competing for the same database connections, cache memory, or target table locks, since intermittent failures under load often point to a resource ceiling rather than a logic bug. Reviewing session and Integration Service resource allocation, and staggering or partitioning concurrent workloads more deliberately, is usually more effective than trying to reproduce the failure in isolation.

I'd parameterize the load type as a session or mapping variable that controls the filter condition and target load strategy, so the same mapping logic serves both modes rather than duplicating nearly identical mappings. Keeping the core transformation logic shared and only the load-boundary condition variable reduces long-term maintenance significantly compared to maintaining parallel full and incremental versions.

I'd establish mandatory standards for the things that create real risk if inconsistent, naming conventions, error handling patterns, security and connection management, while giving teams flexibility over mapping-specific business logic within their own domain. A review process for production deployments, paired with reusable, centrally maintained mapplets for common patterns, keeps quality consistent without requiring every mapping to be centrally built.

I'd quantify the current cost of maintaining on-premise infrastructure, licensing, and the growing difficulty of finding PowerCenter-specific expertise, against the tradeoffs of a cloud migration, including migration effort and any capability gaps. Framing this around risk reduction and long-term total cost of ownership, rather than modernization for its own sake, tends to land better with stakeholders focused on near-term budget impact.

I'd design around Informatica's grid and high-availability configurations for automatic failover of the Integration Service, paired with regular repository backups and a documented, tested recovery runbook rather than an assumption that failover configuration alone is sufficient. Testing the actual recovery process periodically, beyond just the failover mechanism, is what actually validates whether the plan works under real conditions.

I'd account for licensing and infrastructure cost, but weigh those against the platform's maturity, existing organizational investment in trained staff and built mappings, and the migration cost and risk of switching. A newer tool that looks cheaper on paper can end up costing more once migration effort, retraining, and lost institutional knowledge from years of Informatica-specific development are factored in.

I'd start by auditing what exists across the acquired environments to understand the real scope of divergence before proposing a single standard, since forcing immediate conformity without understanding why each implementation diverged often creates more disruption than value. A phased consolidation, prioritizing the highest-risk or highest-duplication areas first, tends to be more realistic than a single big-bang standardization effort across every acquired system at once.

I'd balance investing in deep Informatica expertise, since the platform remains genuinely central to critical data flows, against making sure the team also builds broader data engineering skills that transfer to newer tools and paradigms. An organization that's entirely dependent on a shrinking pool of narrow Informatica specialists carries real long-term hiring and succession risk, even if the platform itself remains strategically sound.

I'd weigh the cost and effort of building and maintaining centralized quality rules against how much genuine value inconsistent, low-quality data is currently costing the business, which tends to be concentrated in a smaller number of critical domains like customer or financial data rather than spread evenly everywhere. Starting with the highest-impact domains and expanding only once clear value is demonstrated tends to build more sustainable adoption than mandating IDQ everywhere at once.

I'd track Informatica's own roadmap and market position as part of ongoing vendor risk assessment, while making sure critical business logic isn't so tightly coupled to Informatica-specific implementation details that a future migration, however unlikely, would become prohibitively expensive. Maintaining clear documentation of what each mapping actually does at a business logic level, independent of the tool, helps reduce that lock-in risk somewhat.

I'd rely on Informatica's own metadata and lineage capabilities where they cover the estate adequately, supplemented by a metadata management or data catalog tool for a more complete, cross-platform view when data also flows through non-Informatica systems. Investing in this pays off directly when assessing the impact of a source system change or planning a migration, since guessing at downstream dependencies in a large estate is both slow and risky.

I'd avoid a blanket, ideological answer and instead weigh it per use case, factors like the complexity of governance and connector requirements, the skill set of the team actually building it, and how well each option fits the target architecture. Forcing every new pipeline through a single tool for the sake of consistency alone often costs more in friction than it saves in standardization, especially once teams have genuinely divergent needs.

I treat that concentration as a genuine business continuity risk, beyond just a staffing inconvenience, since a single departure or unavailability at the wrong moment can stall critical data flows the business depends on. Deliberately building documentation, cross-training, and shared ownership of the highest-criticality pipelines well before it becomes urgent is far cheaper than reconstructing that knowledge after the fact.

I'd periodically review actual feature usage, connector needs, and processing volume against what the current licensing tier provides, since organizations often stay on a tier chosen years earlier without revisiting whether it still fits. A mismatch either direction, paying for capability that goes unused, or hitting limits that force workarounds, is worth surfacing to whoever owns the vendor relationship before it becomes a bigger cost or capability problem.

I'd frame the strategy around where each tool genuinely fits best rather than a wholesale replacement narrative, Informatica for governed, enterprise-scale integration with strong connector and compliance needs, newer tools for more agile, engineering-driven workloads. Revisiting that strategy on a regular cadence against how both the tooling landscape and the organization's needs actually evolve keeps the plan grounded rather than locked into assumptions that may not hold years out.

I'd build the case around concrete, demonstrated pain points already visible in the current environment, licensing cost growth, hiring difficulty, or genuine capability gaps versus what the business now needs, rather than chasing a newer technology for its own sake. A pilot migrating a meaningful but contained portion of the workload gives real data on cost, risk, and capability before committing to a full platform transition.

I try to get them involved early in decisions with organization-wide impact, like reviewing a proposed reusable mapplet or weighing a partitioning strategy for a shared high-volume pipeline, rather than only working within the scope of their own mapping. Asking them to explain the downstream consequences of a design choice, beyond just whether it works, builds the broader architectural instinct over time.

I favor a small number of firm, high-impact standards, security and connection management, error handling patterns, naming conventions, paired with real flexibility everywhere else, like how a team structures its own mapping logic for its specific domain. Over-standardizing low-stakes decisions burns organizational goodwill that's better spent enforcing the handful of things that genuinely protect the platform as a whole.

I look for the smallest safe shortcut rather than either blocking the urgent need entirely or abandoning good practice altogether, sometimes that means a temporary, well-documented mapping outside the standard framework, with an explicit commitment and timeline to bring it in line once the immediate pressure passes. Being transparent with stakeholders about exactly what corner is being cut, and why, tends to preserve trust even when the honest answer is 'not the ideal way, for now.'

Signals include recurring production incidents traced back to inconsistent mapping practices, growing difficulty onboarding new engineers because there's no documented standard to point them to, or teams routinely working around the platform team because it's become a bottleneck. Rather than waiting for a major incident to force the issue, I'd rather introduce structure incrementally as the organization's complexity genuinely demands it.

I'd quantify the current cost of the status quo, time lost to recurring production issues, duplicated effort across teams building similar logic independently, and project that cost forward against expected growth in data volume and team count. Pairing that with a concrete example, a specific incident or duplication of effort that a shared framework would have prevented, makes the investment tangible rather than an abstract argument about best practices.

I weigh how someone reasons about tradeoffs, like when to build a shared framework versus letting teams solve a problem independently, over how many transformations they can name. I ask about a real architectural decision they made that didn't pan out as expected, since how someone talks through a genuine setback and what they'd do differently tells me far more than a rehearsed success story.

I weigh the ongoing maintenance risk of an undocumented, poorly understood mapping against the cost and risk of touching it at all. If it's stable and low-impact, I'd rather document it properly and leave it alone than risk destabilizing something working purely for the sake of tidiness. If it's a recurring source of incidents, that's when the cost of leaving it alone finally outweighs the risk of redesigning it.

I lead with business impact in plain language, what data is delayed or incorrect and for how long, before getting into technical root cause. Detailed technical explanation belongs in a follow-up postmortem for those who want it. Overloading an in-the-moment update with implementation detail usually adds confusion rather than the clarity stakeholders actually need in the moment.

I push for that knowledge to become documentation, runbooks, and shared ownership of the riskiest pipelines well before it becomes urgent, rather than staying locked in one or two people's heads. Pairing a senior engineer with someone earlier in their career on the trickiest production issues, rather than always having the expert handle it solo, spreads the knowledge naturally instead of relying on a single point of failure remaining available indefinitely.

Standardization earns its place where inconsistency creates genuine risk or cost, security, error handling, naming conventions that affect cross-team troubleshooting. Beyond that, I'd rather let teams move quickly within their own domains than impose uniformity that mostly serves aesthetic consistency. The test I use is whether a given standard is protecting something concrete or just making the environment look tidier.

I try to lead with specific, observable consequences rather than a general critique, pointing to the performance or maintenance cost the current approach is actually producing rather than framing it as a judgment on the original decision. Most engineers respond well to being shown a concrete problem and invited to help solve it together, rather than being told after the fact that their original design was wrong.