How to Hire Kafka Engineers in 2026

Last updated: May 17, 2026 | By Gregg Flecke

Kafka engineers in 2026 cost $135K to $185K mid-level and $190K to $260K senior in the United States, with most well-scoped searches closing in 4 to 8 weeks. The job title hides a two-track career split that almost no hiring manager names out loud: cluster operators and stream application developers rarely overlap as cleanly as the JD assumes.

The phone call usually opens with a sentence like “we need a Kafka engineer who can fix our consumer lag.” That sentence describes two different humans. One owns the brokers, the controllers, the storage tiering, the cluster policies, the upgrade path from Zookeeper to KRaft. The other writes the producer, the consumer, the Streams topology, the schema. Both could be the right hire. They rarely are the same person. We hear that opening line about once a week across the practice in 2026, and the intake call almost always restarts there.

Gregg Flecke at KORE1. Nearly thirty years placing IT and data talent across financial services, insurance, HR outsourcing, and healthcare. Kafka has been on the desk since the 0.8 days, back when Zookeeper was still part of the conversation and nobody outside of LinkedIn ran a cluster larger than a dozen brokers. The role has fragmented hard since then. We place this work through our IT staffing services and our data engineer staffing practice across the 30+ U.S. metros we serve. Our 92% twelve-month retention number on direct placements is one we earn by scoping the role honestly before sourcing starts. Fee on a close. No charge to scope the search. What follows is the conversation we run with hiring managers on the first or second intake call.

“Kafka Engineer” Hides Two Career Tracks That Rarely Overlap

Kafka has been around long enough now that the talent pool has split along two clean lines, and most of the hiring pain in this category comes from JDs that pretend the split is not there. The cluster operator and the stream application developer share a working vocabulary. They do not share a daily reality, and they do not share a comp band.

Here is how we sort the req before any sourcing call. Lock one track as the primary scope. A secondary lane is fine. The screening loop has to reflect the mix.

A staff-level Kafka operator can read a Streams topology. She has probably never shipped one to production with state stores backed by RocksDB, exactly-once semantics tuned against a real partner integration that retries on its own schedule, and an idempotent producer wrapping the upstream service. A senior Streams developer can describe what a controller failover looks like in theory. He has probably never been on the bridge call at four in the morning when one happened on a cluster the runbook claimed was operating normally. Both candidates are real, both are valuable, and the JD has to commit to which one the team is actually trying to hire before the recruiter touches sourcing.

One pattern we see often. The hiring manager wants the operator. The JD reads like the developer. The recruiter screens for the developer. The technical interview tests the operator. Three weeks in, no offers, everyone is confused. The fix is one paragraph at the top of the JD that names the primary track in writing. Honest scoping beats clever sourcing.

The Distribution Decision Reshapes the Candidate Pool

The cloud question for Terraform is not the same as the distribution question for Kafka. Cloud is which hyperscaler you sit on. Distribution is which company you write the check to. The candidate pool varies by an order of magnitude between them, and the rate band shifts by 15 to 25 percent in either direction.

The honest map for 2026 looks like this.

• Apache Kafka, self-managed. The largest pool by a wide margin and the deepest senior bench because most of the engineers who worked Kafka at real scale before 2022 grew up on this distribution. KRaft migration experience matters here more than anywhere else, and the engineers who only know the Zookeeper-era operational model are now a tier behind on senior reqs in a way that did not feel true even eighteen months ago. Candidates concentrate around banks, large payments processors, telecom carriers, and any company running its own Kubernetes platform in production. Hourly contract rates run lower than on Confluent. Ramp tends to be longer if your team has already standardized on a managed offering and the new hire has to relearn the abstraction layer.
• Confluent Platform and Confluent Cloud. Second largest pool, premium rate. The candidates who came up on Confluent know Schema Registry, ksqlDB, Stream Governance, and the Cloud RBAC model in ways the self-managed crowd usually does not. The cost conversation is real and hiring managers ask about it on the second call. Senior Confluent Cloud engineers run $15 to $25 an hour above the self-managed equivalent on contract.
• AWS MSK and MSK Serverless. Smaller pool than Apache or Confluent but growing fast, especially in the Plano-Frisco corridor, Austin, and the Atlanta financial services cluster where everything else already runs on AWS. Most MSK engineers came up AWS-first and learned Kafka as a service to consume rather than a craft to master. That is fine for application work. Less fine for staff-level platform ownership where the team will eventually wish someone could read a controller log without asking AWS support. MSK Serverless has been pulling teams off self-managed clusters since the second half of 2024 because the operations surface area shrinks dramatically and the cost predictability improves. Expect the MSK candidate to be strong on AWS IAM, KMS, and CloudWatch, and meaningfully less practiced on broker JVM tuning.
• Redpanda. Real and growing. The C-plus-plus single-binary architecture and the API compatibility with Kafka means most senior Kafka engineers can ramp inside a sprint. But the operational instincts diverge. Redpanda candidates with two production years are scarce. Expect to source from current Kafka operators with an interest in lower-latency hardware-aware systems work.
• WarpStream and the S3-direct cohort. Tiny pool. Mostly engineers who shipped a WarpStream migration at a cost-pressured startup or a midmarket logistics shop. The architecture is novel enough that a Kafka veteran needs four to six weeks to internalize the tradeoffs around zero-disk brokers and S3-as-storage. Worth interviewing if your distribution is decided. Not worth searching against if it is not.

One filter we run on every Kafka intake call is the broker question. Has the candidate owned a cluster that survived an unplanned controller failover in production? If yes, the role is materially easier to scope, because the engineer who lived through that incident has internalized a set of lessons no whitepaper transfers. If no, the candidate may still be excellent, but the senior screen has to confirm depth elsewhere.

What Five Salary Sources Report a Kafka Engineer Earns

No salary aggregator tracks “Kafka engineer” as a clean discrete title. Some bucket the role under data engineer. Some under backend or distributed systems. Some pull from job-post headlines that conflate the operator and developer tracks. The result is five sources, five different population samples, and a roughly $80,000 spread on the same title.

The KORE1 placed-base median on senior-tier Kafka engineers across the last twelve months sits at roughly $202K base. That excludes equity. It excludes signing bonuses. It reflects what midmarket and enterprise clients actually signed on a confirmed acceptance for a senior platform or streaming hire. For a hiring manager building a 2026 offer, that placed-base number is the cleanest apples-to-apples reference on the table. Use the salary benchmark assistant if you want a faster cross-check by metro.

The federal anchor is the Bureau of Labor Statistics Software Developers occupational code 15-1252, where the May 2024 median annual wage sits at $132,270 and 2023-to-2033 employment growth projects at 17%, much faster than the average for all occupations. The 90th percentile clears $208,620, which lines up cleanly with the senior tier on our placed-base table.

Salary by Track and Experience Level

Years on Kafka count for more than years in distributed systems generally. A backend engineer with eight years of microservices and a single year on production Kafka is mid-level for a Kafka-specific seat. Senior comes from the harder things. Partition strategy under uneven load. Rebalance behavior when topology shifts in the middle of a deploy. Exactly-once semantics tuned against a real downstream sink that retries idempotently sometimes and not others. Broker-side troubleshooting at three in the morning with a controller that is not behaving the way the runbook claims it will. Those are the years that price a candidate at the top of the band.

Three factors swing the offer number more than anything else we see.

The Confluent Certified Developer cert by itself adds nothing. We see it on every other resume. The Confluent Certified Administrator cert is a stronger signal because it tests broker, security, and Connect cluster knowledge that the developer exam does not, but even then it functions as a tiebreaker rather than a price floor. A public Kafka KIP contribution, a confluent-kafka client maintainer record, or a meaningful Streams or ksqlDB pull request on GitHub moves the number. So does an on-the-record streaming talk at Current, Kafka Summit, or QCon.

Stream processing depth on Flink adds a premium. We see 8% to 15% on senior seats where the role requires running Flink alongside Kafka, especially for stateful exactly-once pipelines against a relational sink. The premium has grown every quarter for the last two years as more shops realized Kafka Streams hit a ceiling on the kinds of state-heavy joins their analytics use case demanded. ksqlDB experience is interesting but no longer commands a premium on its own. Streams plus Flink is the combo that closes high.

Contract-to-hire conversions compress in this market. A senior Kafka engineer on a 1099 day rate of $175/hr will not convert to a W-2 base of $270K. The conversion math sits closer to $200K to $220K plus benefits. Write the conversion expectation into the engagement letter in week one. We watched four C2H conversions stall in the last twelve months because the math was not set at the start, and two of those candidates walked rather than accept what they read as a downgrade.

KRaft, Tiered Storage, and the Skills That Move the Needle in 2026

Three platform changes from the last eighteen months have reshaped the senior Kafka profile faster than any aggregator can track. We filter for all three on every senior intake in 2026.

KRaft, and the slow death of Zookeeper

Apache Kafka 4.0 shipped in 2024 and made KRaft the default. Zookeeper-coordinated clusters are still in production at plenty of companies. They are also visibly on the way out. The senior Kafka engineer in 2026 has either lived through a Zookeeper-to-KRaft migration or is scoping one for next fiscal. The engineer who has only run Zookeeper-era clusters and never touched controller quorum, KRaft snapshots, or the dual-write migration path is functionally a tier behind on senior reqs.

What we screen for. Hands-on experience with the migration, especially the messy parts. The dual-write mode, the metadata.version upgrade, the controller failover behavior after the cut. Cluster-level monitoring of the controller quorum. Recovery from a botched migration. These topics are not exam material. They show up on the resumes of engineers who shipped the work.

Tiered storage

Tiered storage went from preview in 3.6 to stable production in 4.x and changed the cost model for any cluster retaining more than 30 days of data. The senior candidates worth hiring in 2026 can articulate when tiered storage is the right call (long retention, cold reads acceptable, hot tier sized for active consumers) versus when it is a trap (heavy replay workloads, strict SLA reads on warm partitions). They can also talk about the partition-replica behavior during a tier hand-off and what the broker did under the hood the first time a consumer asked for a segment that had moved to S3.

An engineer who has shipped tiered storage to production in a regulated environment with the recovery story actually tested, the S3 access policies actually scoped down, the broker tail-fetch behavior actually understood under a partition leadership change, and the cost model actually defended in front of a finance partner who wanted the line item explained item by item is worth a small premium in 2026. Plenty of shops toggled the feature, watched the bill drop, and never validated the recovery path. Those clusters will surface a problem on the day no one wants to be on call.

Schema governance and the stream processing fork

The stream processing landscape forked years ago and 2026 is the year the verdict feels settled. Kafka Streams is still the right choice for embedded Java applications with modest state. ksqlDB is a niche. Flink is winning the senior portion of the market, especially anywhere a join across two state-heavy streams meets a relational sink. The candidates we are placing now talk about all three by name and can defend a choice for one over the others on a specific use case.

Schema Registry maturity has separated from the rest of the platform conversation. The senior engineer in 2026 reads a Schema Registry compatibility mode the way a senior database engineer reads an explain plan. Backward, forward, full, transitive. The candidate who treats schemas as static documentation has not lived through a breaking change incident with a consumer they did not own.

A Five-Step Process for Hiring Kafka Engineers

Five steps, in order. Each is something we walk through with hiring managers on the first or second intake call.

Step 1: Decide the track, then the distribution

Pick the primary track from the table near the top of this guide. Operator. Application developer. Connect or integration engineer. Streaming architect. Name the secondary in writing if there is one. Then decide the distribution. Apache, Confluent, MSK, Redpanda, WarpStream. Both decisions feed sourcing keywords, comp band, and the interview loop. Skip either decision and the search drags.

The deliverable for this step is a two-sentence role summary. Track plus distribution. Senior candidates self-qualify off that in twenty seconds and the wrong ones never apply, which is more than half the win.

Step 2: Set the comp band against the actual scope

Start with the salary table above. Adjust for distribution (Confluent Cloud plus 8% to 12%, MSK at the band, Redpanda plus 5% for scarcity). Adjust for stream processing depth on Flink if relevant. Adjust for region (FAANG-adjacent metros plus 10% to 15%, mid-market metros at the band, secondary metros minus 5% to 10%). Adjust for industry premium where regulated work demands depth on encryption-in-flight, mTLS, and Schema Registry RBAC. Write the number down. Get engineering and finance to sign off on the band before the role gets posted.

Roughly half the stalled Kafka searches we get pulled into involve a salary band drafted six months earlier against an aspirational JD that no longer matches the role the team actually needs. The first competing offer surfaces, the candidate counters, and the hiring manager learns in real time how far underwater the band was.

Step 3: Source against the scoped role, not the title

A Boolean string for “Kafka engineer” returns a noisy pile. A scoped Boolean returns a fraction with substantially better fit. For senior platform reqs, combine the distribution, “KRaft” or “controller quorum,” and “tiered storage” or “Cruise Control.” For Streams seats, combine “Kafka Streams,” “exactly-once,” and a real downstream like Snowflake, Postgres, or S3. For Connect seats, combine “Debezium,” “Single Message Transform,” and the source database family.

Channels matter as much as keywords. The senior platform crowd tends to surface in three places: the apache/kafka GitHub issue tracker, the Confluent Community Slack, and KIP discussion threads where the comments are longer than the proposal. Alumni networks are the other reliable vein, especially LinkedIn (the company, not the site), Confluent, Robinhood, Stripe, Block, and the original data infra team at Capital One. Mid-level developers move through LinkedIn search and a handful of streaming-data Slack and Discord servers. Juniors come from bootcamps, university coursework on distributed systems, and quiet internal promotion off backend or integration teams that spent the last two years writing Kafka clients in production.

Step 4: Interview structure that surfaces real signal

Build a four-round loop. Three is too thin for the senior reqs that touch broker-level production knowledge. Five is the wall. Past five, the candidates you actually wanted ghost for a competing offer that closed faster.

1. Recruiter screen. Twenty minutes. Confirm the distribution, the track, the seniority, the comp band, the location and remote posture, the staffing model. No technical interviewing here. Disqualify only on hard misalignment.
2. Technical conversation. Seventy to ninety minutes with the hiring manager and a senior engineer from the team. Skip the whiteboard for senior candidates. Pick one of their real production Kafka setups and stay there for the hour. Partition strategy, the worst consumer-lag incident they shipped a fix for, what the cluster runbook looks like in 2026, and what their stream-application CI does end-to-end. A few smart follow-ups will tell you more than a four-hour panel ever does.
3. Practical exercise. Optional and tight. Forty-five to ninety minutes, capped, with the prompt sent ahead. The version we like best: a small Streams topology with a known poison-pill problem and a downstream sink that keeps throwing on retries, paired with the question “what would you change in the producer that fed it.” Run the discussion live. Compensate senior candidates for the hour. The pool talks to each other and a take-home that goes unpaid spreads in a way you do not want.
4. Cross-functional round. One hour. A platform consumer (a backend service team or a data scientist who reads off Kafka), a security and compliance partner, and a senior engineer from the team. Blast-radius thinking. Cultural fit. Comfort being on the platform team’s side of a contentious change.
5. Offer alignment. Optional fifth round. Short call between the candidate and a senior leader if comp will be tight. Faster than running every back-and-forth through the recruiter.

Step 5: Close on the candidate’s clock, not yours

Senior Kafka engineers are interviewing at three to five companies at once in this market. The window between final round and a competing offer is often a week. Sometimes less. If you cannot move from final-round close to written offer inside three business days, you will lose candidates you wanted to hire.

A note that lands with hiring managers more often than not. When a candidate picks your offer over one with bigger cash, the deciding factor in the post-offer call is almost always the engineer they spoke to in the technical round. Not the brand. Not the perks. Build a technical hour that a strong candidate would walk away from energized about.

Interview Questions That Predict Production Readiness

A question like “what is a consumer group” pulls answers off the docs page. The candidate who memorized that page is not the one you want. Ask scenarios. Senior Kafka engineers earned their seniority by walking back something painful on a phone bridge with a tired teammate, and the scar tissue from those calls is what you are really hiring for.

• “Walk me through your worst consumer-lag incident.” Listening for: partition awareness, rebalance instincts, downstream-sink literacy, and whether the candidate can name the time their own change was the cause. The answer that begins “it turned out we” is the answer that tells you the most.
• “How is your topic taxonomy organized? Where does the bronze layer actually end?” Filtering for: whether the candidate has owned the model versus just used it, whether they understand idempotency at the producer, and whether they can defend tradeoffs between event-carried state transfer and lookup-on-read.
• “Where are you on the KRaft migration?” Filtering for: hands-on migration experience versus theoretical familiarity. The candidates who shipped this work talk fluently about dual-write mode and controller quorum recovery. The ones who have only read about it do not.
• “Tell me about a Streams topology you wrote that you would now design differently.” Filtering for: humility, growth, exposure to state-store sizing, RocksDB tuning, and the difference between exactly-once and the convenient version of exactly-once that breaks under partner traffic.
• “What is your read on Flink versus Kafka Streams for this team in 2026?” Filtering for: ability to talk stream processing without slipping into vendor religion. Either direction is fine. The reasoning matters.
• “Describe a cost overrun you fixed on a Kafka cluster.” Filtering for: broker-sizing literacy, partition-count discipline, tiered storage practice, retention-policy fluency, and whether the candidate has been in the room when finance asked the platform team why the cluster bill doubled.
• “How do you handle secrets and credentials for producers and consumers?” Filtering for: anyone who says “we put them in a config file” is out. Look for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or a defensible combination with rotation built in.

Senior and staff candidates get filtered well by an eighty-minute technical conversation built around any three of those questions. Junior candidates need a hands-on exercise because their production-war-story bench is too thin to read against. The mid-level tier is where I tend to ask for both. The cost of getting it wrong is a six-month learning tax on the team that took the bad signal.

Where Most Kafka Hires Go Sideways

Four mistakes account for the searches that drag past ninety days in this category, and the same four show up in the post-mortems we run after a stalled req gets unstuck.

Filtering on Java syntax instead of streaming intuition. A senior Kafka engineer who has never wrestled with consumer-rebalance storms will sink the search even if her Java is immaculate. The opposite is also true. We placed a senior Streams developer last spring with only three years of Java but six in production distributed systems at a payments processor in Charlotte. Her hiring manager understood that Java idioms compound in a sprint while the instinct for partition design, event modeling, and consumer-lag forensics takes years to form. The seat closed in five weeks. The reqs that flip those filters do not close.

Hiring “a Kafka engineer” without naming the distribution. Apache, Confluent, MSK, Redpanda, and WarpStream share an API and a working vocabulary, then diverge sharply on operations, RBAC, monitoring, and the cost surface. The engineer who only knows MSK is going to surface that gap in week three on the job if the team runs Apache on Kubernetes. Name the distribution at the JD stage and screen for hands-on production exposure on it, not just client-API fluency.

Leaving the staffing model decision for week three. The four engagement shapes (direct hire, contract, contract-to-hire, fixed-scope project) pull from four mostly-non-overlapping candidate pools. A senior platform engineer who would never go 1099 will say yes to a six-month contract staffing engagement on W-2 if the deliverable is a KRaft migration with a real end date. A $260-an-hour independent will not appear in your direct-hire pile. Pick the engagement shape on day one, write it into the JD, and tell the recruiter. Otherwise the first three weeks burn on the wrong pool.

Skipping the platform consumer round. The Kafka platform engineer’s customer is usually a backend service team, an analytics consumer, or a downstream data engineering crew. The interview loop should include at least one of those people, asking the candidate what their producer handoff looks like and what they wish the consumer side did differently. We added that round formally a few years ago and the false-positive rate on senior platform hires dropped enough that hiring managers stopped pushing back on the extra hour of load.

A second pair of eyes on a stuck Kafka req is worth the half hour. If your search has crossed sixty days without a final-round, or the JD reads like two roles got stapled together in a hurry, send us the role and a recruiter will walk through it on a call. The scope conversation does not cost anything. The placement fee only matters if you hire someone we introduced.

Things Hiring Managers Ask Us About Kafka Roles

How long does a senior Kafka engineer search take in 2026?

Four to eight weeks for a well-scoped req on Apache or Confluent. Add one to two weeks for MSK-heavy roles where AWS depth is also a hard filter. Add another two to four if the role mixes the operator and developer tracks without naming a primary.

The slow end is almost always something the company is doing to itself rather than something the candidate pool is failing at. A JD blending platform, Streams, and Connect responsibilities into a single paragraph that pretends they are one role. A pay band drafted by HR against a 2023 spreadsheet that no longer reflects what tier-1 tech is actually paying senior streaming engineers in 2026. An interview loop that grew a fifth round because two adjacent stakeholders both wanted a vote. We have closed Kafka searches in twenty-two days and we have watched others stretch into a fourth month on roles that should have closed in six weeks. The fast ones share the same shape every time: one named track, a written comp band that the finance partner already initialed before sourcing began, four rounds run with respect for the candidate’s calendar, and someone in the room on the final call who can say yes without a follow-up.

Operator or application developer, which is harder to hire right now?

Operator. The senior cluster operator pool has thinned out as managed offerings absorbed the work, and the engineers with KRaft migration and tiered storage scars in production are not in the market often.

The application developer pool is materially healthier than the operator pool because most Java backend engineers who have been writing Kafka clients for three or more years can grow into a senior Streams seat with a patient team. The operator side is where searches stall in 2026, and that has gotten more true every quarter since the major managed offerings absorbed the daily operational load that used to be the school where junior platform engineers learned the craft. If your organization runs Apache on self-managed Kubernetes, plan for a longer search and a higher rate, and screen hard on real production scars rather than certifications. If you are on Confluent Cloud or MSK Serverless, the operator load is materially lighter and the role often quietly collapses back into a senior application developer with platform leanings.

Confluent Cloud, MSK, or self-managed Apache, which closes the search faster?

Confluent Cloud and MSK both close faster than self-managed Apache because the operations surface area is smaller and the candidate ramp is shorter. Self-managed gets the strongest senior bench but takes longer to land.

If the company is pre-decided on distribution the answer follows that decision and the salary band, sourcing keywords, and interview loop all bend to match. If the company is still choosing, the staffing math tilts toward whichever managed offering aligns with the rest of the cloud footprint already in place. Confluent Cloud if Schema Registry, Stream Governance, and ksqlDB are non-negotiable for the use case. MSK if the rest of the AWS estate is already mature and the team owns enough AWS Identity, KMS, and CloudWatch surface area to absorb a streaming platform without adding new operational tooling. Apache self-managed if the team has the bench depth and cost is the constraint everything else has to bend around.

Do we need a Confluent Certified Administrator or Developer for a senior hire?

No. The cert is a tiebreaker. The Administrator cert is the stronger of the two because it actually tests broker, security, and Connect cluster topics that the Developer exam skips, but neither one is a price floor.

Real signal comes from a public Kafka KIP comment thread the candidate engaged on, a Streams or ksqlDB pull request, a confluent-kafka client maintainer record, or a recorded talk at Current or Kafka Summit. We ask the production-incident scenarios first and the cert questions almost never.

What is the most common scoping mistake on a Kafka req?

Treating the operator and developer tracks as one role. The JD that mixes broker ownership with Streams development almost always closes badly because the comp band, the screening loop, and the candidate sourcing channels only fit one of the two tracks.

The fix is the table at the top of this guide. Pick one track as primary. Name the secondary explicitly in writing. The candidates who actually live at the intersection know they are rare and price themselves there. The job description has to acknowledge that before sourcing starts.

Where do the strongest Kafka candidates come from in 2026?

Internal promotion off backend, integration, and data engineering teams that have been writing Kafka clients in production for three or more years. After that, alumni networks at LinkedIn, Confluent, Robinhood, Stripe, Block, and any company that has open-sourced a meaningful Kafka extension.

Bootcamps produce capable juniors but rarely seniors. LinkedIn search is fine for mid-level. The signal-to-noise ratio drops fast at staff-and-above. The best senior candidates often surface through GitHub apache/kafka issue threads, KIP discussion archives, Kafka Summit speaker lists, and quiet referrals from engineers your team already worked with at a previous shop. That kind of referral closes faster than any cold outbound.

How does the Kafka talent pool compare to Flink or Pulsar?

Kafka has the deepest senior bench by an order of magnitude. Flink has a smaller but growing senior pool with stronger stateful streaming credentials. Pulsar has a niche, expert pool concentrated at a few companies and is rarely the right primary skill for a non-Pulsar shop.

The overlap between Kafka and Flink at senior is high and growing. Most senior streaming engineers in 2026 can run both. The overlap with Pulsar is real but small. If the role demands cross-skill on Flink, hire for that explicitly and pay the premium. Do not assume a Kafka veteran will pick up Flink stateful operators in a sprint. Some can. Many cannot.

Most hiring managers reach out to us a week or two later than they should have. The signs are usually visible by week three of a stuck search and ignored until week seven. Our IT staffing services practice places platform, streaming, and integration engineers across more than thirty U.S. metros, and the first call costs nothing. Bring the JD. We will tell you, candidly, what is wrong with it.