Coder Legion - Recent posts tagged algorithms

Twenty-Six Thousand Families and a Nationality Field: The Dutch Benefits Algorithm Overdrew Trust

Thu, 15 Oct 2026 09:23:18 +0000

Originally published at vibeagentmaking.com.

The Dutch childcare-benefits scandal drew 6.45 million euros in fines and has passed 7.2 billion to repair. The review that was meant to catch it ran thousands of times and affirmed every decision, because each one was correct.

A parent in the Netherlands underpays their share of a childcare bill by a small sum, or files a contract a few weeks late, or leaves one signature off one form. Months later a letter arrives from the Tax Administration. It does not ask for the small sum. It sets the entire year's childcare benefit to zero and demands all of it back, tens of thousands of euros, at once. The parent appeals. A court reviews the file, confirms that the paperwork was indeed incomplete, and upholds the demand. Everything in that sequence is correct. The parent is still ruined.

Run that sequence about twenty-six thousand times, roughly 26,000 being the count the parliamentary inquiry carried for 2005 to 2019 (a broader figure of at least 35,000 is a different count, not a correction of it), and you have the toeslagenaffaire, the Dutch childcare-benefits scandal: the affair that brought down a government, produced the largest fines the country's data-protection regulator had ever issued, and is still generating fresh repayment demands to the same families in 2026. It is usually told as a story about a racist algorithm. That version is true and it is adjudicated, so I am going to spend the words elsewhere. The more useful story, especially if you build systems that make decisions at volume, is an accounting story. Trust in an administrative system is a balance. A risk score can overdraw it silently, for a decade, while every single withdrawal clears.

The check that ran, and affirmed the thing it was meant to catch

The load-bearing fact of this whole affair is not the algorithm. It is a rule with a name: alles of niets, all-or-nothing.

Under the rule as it stood, if a parent could not fully document their required personal contribution to childcare costs, the Tax Administration was obliged to set the entitlement to zero and reclaim the entire benefit, not the shortfall. A co-payment short by a little, a late contract, a missing page: the same maximal outcome every time. And here is the part that matters. That was not a rogue caseworker exceeding their authority. It was the law as the highest administrative court read it. The Administrative Jurisdiction Division of the Raad van State, the Council of State, established the all-or-nothing line in 2011 and 2012 and did not abandon it until 2019. In a remarkable self-reflection published in 2021, the Division apologized: it had held too long that full recovery was legally required even for very small defects, and it should have offered these parents better legal protection.

Sit with what that means for anyone who has ever relied on a review step to catch a bad outcome. The check that was supposed to catch the aggregate harm was judicial review, and judicial review was not absent. It ran. It ran thousands of times. And it affirmed each decision, because each decision was correct under the rule the court itself had written.

An appeal is a per-file instrument. Point it at one case and it answers accurately: was this benefit correctly reclaimed given this file? Yes. It has no question inside it that can be asked about twenty-six thousand files at once. There is no place on the form for "is a rule that produces this result at this scale defensible?" The instrument was working perfectly and measuring the wrong unit.

If you write software, you have met this failure. It is the codebase where every unit test passes and production is on fire. It is the distributed store where each node is internally consistent while the invariant that spans the nodes quietly breaks. It is the dashboard that is green per request while the thing users actually experience, the aggregate over a day, degrades past the point of usefulness. A system can be locally correct at every point and globally indefensible, and if your only instrument asks the local question, you will not merely miss the global failure. You will accumulate a paper trail of affirmations that proves, case by case, that nothing went wrong. The overdraft is not drawn by the fraud model. It is drawn by a correct rule applied correctly, at volume, by everyone, including the institution whose job is to say no.

The nationality field, priced by the regulator

The algorithm did its own damage, and by 2021 that damage had a price tag written by the state itself. The Dutch data-protection authority, the Autoriteit Persoonsgegevens, fined the Minister of Finance 2.75 million euros in a decision dated 25 November 2021 and announced on 7 December. What makes the fine worth reading is that it is itemized, and the itemization shows that "the nationality field" was really three separate practices.

The regulator charged 750,000 euros for retaining applicants' dual nationality with no lawful purpose, a practice that touched roughly 1.4 million citizens between 2014 and 2020. It charged a million euros for using nationality as an indicator in the risk-classification model itself, from March 2016 to October 2018. And it charged another million for querying nationality in fraud detection between 2013 and early 2019, including targeted sweeps: 6,074 Ghanaian applicants in one, 363 Bulgarian applicants in another. The regulator deliberately escalated the second and third charges to its highest penalty band, citing the discriminatory character of the processing, the size and dependent position of the affected population, and false statements that had obstructed its investigation.

A second fine followed on 7 April 2022, 3.7 million euros, then the largest the authority had ever levied, for a fraud-signaling blacklist called FSV that held some 270,000 people, recorded characteristics including ethnicity and origin, rested on no lawful basis, and in several cases simply held data that was wrong. Together the two fines come to 6.45 million euros. Hold that number.

I am stating the discrimination as a fact rather than arguing it, because a parliamentary inquiry and a regulator already did the arguing. The inquiry report is Ongekend onrecht, a title English-language coverage quotes as "Unprecedented Injustice." It landed on 17 December 2020 with a finding that was constitutional rather than technical: the parents did not receive the protection they were owed, and group penalties violated fundamental principles of the rule of law. The third Rutte cabinet resigned on 15 January 2021. And underneath the fines and the resignations sits a number that appears on no balance sheet and has no compensation line: more than two thousand children were removed from their homes in families caught by the scandal.

The repayment costs a thousand times the fine, and it is not a repayment

Here is why 6.45 million is the wrong number to remember, and why I asked you to hold it anyway.

The operation to repair the scandal was first budgeted at around 310 million euros in 2020 and 2021. By 2024 reporting the tally had passed 7.2 billion, with a worst-case projection up to 14 billion and 9.3 billion reserved for the compensation scheme alone. The average payout per victim under the revised method had climbed to roughly 128,000 euros, well above the 30,000-per-parent figure the scheme opened with. Set the penalty against the repair and the ratio is stark: the regulatory fine is about one one-thousandth of what the failure costs to fix.

That ratio is the whole thesis in a fraction. If you thought the fines were the price of the overdraft, look again. The state paid a token of interest and is still servicing the principal six years on. The fine is a price signal, and a useful one, but it is paid out of the same treasury that is paying the billions, which makes it closer to moving money between two of your own accounts than to a penalty that changes behavior.

And the repair has reproduced the original defect in mirror image. The scandal was a machine that demanded exhaustive documentation from people who could not produce it and defaulted to the harshest outcome. The compensation scheme is a machine that demands exhaustive documentation from the same people and defaults to delay, a "light assessment" followed by a "full assessment," precise and slow enough that a Dutch university's public explainer is titled, plainly, why the settlements are so slow. De Correspondent has described a compensation affair forming inside the benefits affair. None of this is history. In February 2026 families in the scandal were reported as shocked by fresh repayment demands, and in March 2026 the new cabinet was reported brushing off the children's ombudsmen again. Write it in the present tense or you will get it wrong.

Which reforms bought control, and which bought the look of it

The brief that sent me here asked the right question: after a failure like this, which reforms restore the actual control, meaning a human who can see the whole model and stop it, and which restore only the appearance? The Dutch record answers with unusual clarity, because the reforms are far enough along to audit.

The visible reform is the Algorithm Register, a public catalog of government algorithms launched on 21 December 2022, meant to make their use "accessible and understandable." Publication is the reform everyone can point to. It is genuinely worth having. It is also not a brake, and the register itself demonstrates why in a single number. As of September 2026 it holds about 1,542 algorithm descriptions, up from its thousandth entry in July 2025, against a ministry target of 1,600. The obvious analysis is coverage: what fraction of government algorithms are registered? You cannot compute it. The total number of algorithms in use across Dutch government is not known to anyone, including the ministry that runs the register. At the municipal level someone did check, and found that 18 of 47 councils said they use algorithmic systems while having no entries in the register at all.

A register reports what was entered into it. Absence from it is not evidence of absence in the world, and a rising count is not rising coverage when nobody holds the denominator. That is precisely the error that started the scandal: an instrument's output, in that case a risk score, read as a fact about the world. The 1,542 is the register's reading of itself, not the government's algorithm count, and if you let it stand in for coverage you are repeating the original mistake in a nicer font.

The reform that actually produces control is duller and it works. The Netherlands Court of Audit, the Algemene Rekenkamer, keeps auditing government algorithms and keeps publishing what it finds. In 2022 it examined nine and reported that three met the basic requirements and six did not. In 2024 it looked across 69 organizations and found most public bodies using AI without a clear understanding of the risks. And in its 2024 annual audit it examined three risk-prediction algorithms, one of which delivers the finding this entire essay is built to reach.

Dienst Toeslagen, the benefits service rebuilt after the scandal, now runs a risk-prediction algorithm to find parents who need help repaying childcare benefit. It works: nearly 8,000 parents have been offered that help, and 80 to 90 percent of them were surfaced by the algorithm. The auditors also found that sensitive data about this vulnerable group is not protected, because the algorithm was not compliant with the GDPR. Read it slowly. The organization created to repair a scandal caused by unlawful profiling of a vulnerable group is itself profiling that same group unlawfully, this time to help them. Benign intent, same defect. Publication did not prevent it. The algorithm is known, named, registered, aimed at a kind outcome, and still processing sensitive data about vulnerable people outside the law. What caught it was not the register and not an appeal. It was an auditor with a statutory mandate who could look at the whole system and write, in public, "this does not comply."

That is the closest thing in the record to the human who can see the whole model and stop it, and it is worth naming its one weakness rather than papering over it: the auditor's output is a report, not a stop button. It can see the portfolio, which the appeals court could not, and it can say so where everyone can read it, which the register's own count cannot. But it does not halt the system. The brake is still missing. What exists is an eye, wired to a printer, not to a switch. The most underrated reform in the whole story is quieter still and lives in the law: abandoning the all-or-nothing rule and letting proportionality back into administrative decisions removed the rule that made each harsh outcome individually correct. That is the fix that drains the overdraft at its source, because it changes what "defensible per file" means.

What to take back to your own systems

You are not running a national tax administration, but you are almost certainly running something that decides at volume and gets reviewed one case at a time, and the failure mode transfers exactly.

First, ask what unit your review instruments measure. If everything that reviews your decisions, the appeal, the exception queue, the on-call runbook, the manager sign-off, asks only "is this individual case correct?", then you have no instrument for "is the aggregate defensible?", and the two can diverge with no individual error anywhere. Build the portfolio question in on purpose. Sample outcomes across a protected group, chart how often the harshest outcome fires, watch the ratio and not just the instances. The all-or-nothing rule would have been visible in ten minutes to anyone who plotted the share of claimants hit with a full clawback over time. Nobody owned that plot.

Second, treat every count as a reading until you can name its denominator. A dashboard that shows 1,542 of something is telling you what it ingested, not what exists, and a number that only goes up is not progress if the thing it is a fraction of is unknown and possibly growing faster. Before you report a count as coverage, write down what it is a count of and what it is not.

Third, wire the eye to a switch. Visibility, audits, and registers are all necessary and none of them is a brake. The Dutch record shows an auditor who could see the whole model, say it was unlawful, and watch it keep running, because saying so was the end of that person's authority. Decide before you ship who can see the aggregate and whether that same person or process can halt it. If the one who can see it can only file a report, you have built the appearance of control, and the balance can still be overdrawn while every withdrawal clears.

Figures and dates in this piece are drawn from the public record of the Dutch childcare-benefits scandal and are dated where they move with the reporting. The two data-protection fines (2.75 million euros, decision 25 November 2021, announced 7 December 2021; 3.7 million euros, 7 April 2022) and their itemization are as reported by NL Times and the decision aggregator thedpo.eu against the regulator's own decisions; the recovery-cost tally (past 7.2 billion euros by 2024, up to a 14 billion projection) and the compensation figures are from NOS and De Correspondent reporting through 2024; the 2026 status is from Dutch News and Erasmus Magazine.

Sources:

Parliamentary inquiry report Ongekend onrecht ("Unprecedented Injustice"), Dutch House of Representatives, 17 December 2020.
Administrative Jurisdiction Division of the Raad van State, self-reflection on the childcare-benefits case law, 2021; NOS report, nos.nl/l/2406259; Lessen uit de toeslagenaffaire, NTB 2021/60.
Autoriteit Persoonsgegevens, fine of the Minister of Finance for discriminatory and unlawful data processing (nationality), decision 25 November 2021; decision record via thedpo.eu; regulator announcement, autoriteitpersoonsgegevens.nl.
Autoriteit Persoonsgegevens, FSV fraud-blacklist fine, 7 April 2022; NL Times, 12 April 2022; AP decision PDF (besluit_boete_belastingdienst_fsv).
NOS, "de toeslagenaffaire: van een miljoenen- naar een miljardenoperatie," and "herstel toeslagenaffaire dreigt ongekende strop te worden."
De Correspondent, compensation-scheme series ("gierend uit de hand"; "onuitlegbaar, onuitvoerbaar, onbetaalbaar").
Netherlands Court of Audit (Algemene Rekenkamer), "An audit of 9 algorithms used by the Dutch government" (2022) and "Focus on AI in central government" (2024); EUROSAI IT Working Group summary of the 2024 annual audit of algorithms.
Algorithm Register, algoritmes.overheid.nl; Dutch IT Channel on the 1,000th entry (July 2025); OECD.AI, Algorithmic Transparency in the Public Sector (2025).
Dutch News, "families in tax office scandal shocked by repayment demands" (February 2026); Erasmus Magazine, on the new cabinet and the children's ombudsmen (March 2026).

An eye wired to a printer is not a brake

The auditor in this story could see the whole model, say in public that it did not comply,

    and watch it keep running. The same gap opens wherever an agent decides at volume and the
    only record of what it did is the record it writes about itself. Chain of Consciousness keeps
    a provenance record of what an agent actually did, over traffic someone else can check, so
    the person who can see the aggregate is looking at evidence rather than at a summary.

pip install chain-of-consciousness
npm install chain-of-consciousness

Or start without installing anything: Hosted Chain of Consciousness.

Demystifying Greedy Algorithms: How Local Choices Solve Global Problems in Node.js

Thu, 15 Oct 2026 08:35:56 +0000

What is a Greedy Algorithm?

A greedy algorithm is an algorithmic strategy that solves a problem by making the most optimal decision at each individual step. Instead of looking ahead to long-term consequences or evaluating every possible combination, it focuses exclusively on immediate, short-term gain. If local choices logically compound into the ideal final result, the greedy strategy succeeds with maximum computational efficiency.

The Cashier’s Coin Trick

Imagine you are a cashier at a grocery store, and you need to give a customer 41 cents in change using the fewest coins possible. You look at your cash register, which contains quarters (25¢), dimes (10¢), nickels (5¢), and pennies (1¢).

Instead of calculating every conceivable combination of coins, you naturally make the "greedy" choice at each step:

Grab the largest coin that does not exceed 41 cents: a Quarter (25¢). You now owe 16 cents.
Grab the largest coin that does not exceed 16 cents: a Dime (10¢). You now owe 6 cents.
Grab the largest coin that does not exceed 6 cents: a Nickel (5¢). You now owe 1 cent.
Grab the largest coin that does not exceed 1 cent: a Penny (1¢). You now owe 0 cents.

You solved the problem instantly by picking the biggest immediate payoff at every step. That is precisely how a greedy algorithm operates in software.

Why Greedy Algorithms Matter in Tech

In software engineering, computing the mathematically perfect solution for massive datasets can sometimes take hours—or even years—if an application tries to test every possible outcome. Software developers intentionally use greedy algorithms when a guaranteed quick answer that is optimal saves massive amounts of CPU memory and processing time.

For instance, network routing protocols use greedy choices to route internet data packets along the shortest immediate paths between routers. Database query engines, file compression utilities like ZIP tools, and job schedulers in operating systems all rely on greedy strategies to keep web software responsive and performant under heavy traffic loads.

Code Example: Making Change in Node.js

Here is a plain Node.js implementation showing how a greedy approach quickly calculates coin change for any given amount:

// Function to give change using the minimum number of coins
function makeChange(amount, coins = [25, 10, 5, 1]) {
  const result = {};
  let remaining = amount;

  // Iterate through available coins sorted from highest to lowest
  for (const coin of coins) {
    if (remaining <= 0) break;

    // Calculate how many coins of this denomination fit
    const count = Math.floor(remaining / coin);
    if (count > 0) {
      result[`${coin}c`] = count;
      remaining -= count * coin;
    }
  }

  return result;
}

// Example usage: Change for 87 cents
const change = makeChange(87);
console.log('Change breakdown:', change);
// Output: Change breakdown: { '25c': 3, '10c': 1, '1c': 2 }

In this code, the algorithm loops through sorted coin values and takes as many of the highest denomination as possible before moving to smaller coins.

The Takeaway

Greedy algorithms trade exhaustive foresight for immediate speed, proving that making the best local decision at every step can often yield the best global outcome. While they do not work for every single problem—especially when early sacrifices yield better long-term rewards—understanding when to apply a greedy strategy is a fundamental skill for building high-performance backend systems.

Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!

Originally published on my blog. You can read the alternative breakdown here.

The Magic of Branchless in FinTech: How to Tame the NASD 30/360 Financial Standard and Solve the IRR Equation Without a Single IF

Sun, 11 Oct 2026 04:34:52 +0000

Calendar and interest calculations are a hidden "landmine" of the global financial system. Regulators and financiers have been unable to devise a simple date-calculation formula for several centuries. The US 30/360 NASD standard has been criticized multiple times and rewritten by various countries, while the built-in functions of Excel are completely frozen with February bugs, breaking the continuity and monotonicity of time at month boundaries.

The production-grade programmatic core, source files, and clean VBA modules for this framework are officially published and open-sourced on my GitHub repository: [GitHub: branchless-continuous-time-irr].

This article performs a complete mathematical and hardware deconstruction of this chaos. I will guide the reader through a rigorously verified chain of branchless discoveries: from computing the commercial NASD 30/360 standard to the complex mathematical framework that forms the basis of my peer-reviewed scientific paper published by Lomonosov Moscow State University, available for verification via direct link: https://www.elibrary.ru/item.asp?id=49514570 .

As an independent researcher, alumnus of Gubkin University, and the primary author of the accompanying fundamental research registered in the international scientific repository in Geneva (CERN Zenodo, DOI: 10.5281/zenodo.5007170, direct link: https://zenodo.org/record/5007170) and on the eLIBRARY platform (direct link: https://www.elibrary.ru/item.asp?id=46584125), I will deconstruct the integer calendar core with a precision limit up to the year 487,621, and detail a highly successful solution already developed by me within realistic operational environments that accomplished the impossible: differentiating the non-differentiable.

To avoid superficial insinuation regarding the demonstration environment, I emphasize 4 strategic reasons why this algorithm is implemented strictly via pure Excel and VBA:

1. Universal Accessibility and Verification: Microsoft Excel is installed on the workstation of every quantitative analyst, financier, and systems engineer globally. Verification of the algorithm requires no heavy IDE deployments or compiler configurations — the formula is pasted directly into a spreadsheet cell and instantly computes half a million years of astronomical time with 100% precision.
2. A Living Pseudocode: The concise syntax of Excel cells and VBA provides absolute transparency. Stripped of platform-dependent syntactic sugar, this layout acts as a universal mathematical invariant that any engineer can effortlessly port line-by-line into C, Rust, Go, Python, Java or bare-metal Verilog/VHDL description layers.
3. Maximum Portability and Accessibility: Given that logical operations in VBA function exclusively as bitwise operations, I deliberately excluded all idiosyncratic features of this specific language from the codebase. The algorithm is engineered to be fully platform-agnostic, first to guarantee an entirely trivial transfer process into absolutely any other programming language, and second to remain intuitive to a wide audience who may not possess highly specialized software engineering credentials.
4. The Ideal Invariant for Silicon Synthesis: The reality that this framework runs equally fast and with absolute accuracy even within an Excel/VBA scope utilizing a standard 32-bit Long datatype without a single logical conditional expression holds the highest priority for hardware professionals. This demonstrates that synthesizing and baking such FinTech compute engines directly into hardware layers (at the level of FPGA / ASIC microchips) is a fundamentally simple and trivial engineering task.

Part 1. The Core Milestone: Branchless Computation of the NASD 30/360 Standard

The 30/360 NASD standard was originally introduced to serve two distinct objectives:

To eliminate the irregularity of months and years using elementary formulas.
To ensure that time intervals between dates separated by an exact integer number of months via the EDATE methodology always yielded precisely: months / 12.

Neither task has been resolved over centuries of application, perpetually triggering endless legal and commercial disputes. I implement the core mechanics of the NASD standard as pure, end-to-end branchless arithmetic. Conditional IF-ELSE bifurcations are no longer required; the NASD logic maps seamlessly onto the mathematical axis using basic Boolean algebra (where TRUE = 1, FALSE = 0).

If cell A1 contains the start date (D₁) and cell B1 contains the end date (D₂), the following unified analytical formula evaluates the precise financial interval under the NASD 30/360 convention without a single conditional IF operator:

=YEAR(B1)-YEAR(A1)+((DATE(YEAR(B1),3,0)=B1)*((DAY(A1)>29)+(DAY(B1)=28)*(DAY(A1)>28))+DAY(B1)-(DAY(B1)=31)-DAY(A1)+(DAY(A1)=31)+(MONTH(B1)-MONTH(A1))*30)/360

The Branchless Compensation Mechanics:

-(DAY(B1)=31) and +(DAY(A1)=31): The logical equality returns 1 or 0. If the day coordinate is 31, the chronological weight of the date is automatically adjusted to the 30th day arithmetically.
The "Zero March" Trigger (DATE(YEAR(B1),3,0)): In spreadsheet engine logic, this configuration (March 0) evaluates to the terminal day of February for the respective year (day 28 or 29). Multiplying this structural trigger by the weight coefficients (DAY(A1)>29) and (DAY(B1)=28)*(DAY(A1)>28) arithmetically Hack-neutralizes the non-linear operational shifts of February.

Part 2. The Foundation: A Branchless Calendar Decoder, Normalization, and Stress-Testing the `GetDays(y, m, d)` Core

To feed the NASD equation and surrounding analytical operations with flawlessly structured data, a high-speed mechanism is required to translate absolute serial day integers back into a Year/Month/Day layout without logical branching steps.

I deployed an analytical method of integer approximations of real periodic variations utilizing tailored numerical constants (derived from the theory of continued fractions). The foundational paradigm shift relies on shifting the chronological epoch anchor to March 3rd. This repositions the erratic boundary behavior of February to the absolute end of the annual compute cycle, converting a volatile Gregorian month sequence into a smooth, predictable mathematical continuum.

Below is the original integer branchless engine written in universal standard VBA syntax (Long), containing the function GetDays(y, m, d) developed by me:

Function DecodeYearMonthDay(ByVal G As Long) As Long()
  Dim y400 As Long, y100 As Long, y4 As Long, y As Long, m As Long
  G = G - 3
  y400 = Int(G / 146097)
  G = G - y400 * 146097
  y100 = Int((G + 1) * 10 / 365243)
  G = G - y100 * 36524
  y4 = Int(G / 1461)
  G = G - y4 * 1461
  y = Int((G + 1) * 10 / 3653)
  G = G - y * 365
  m = Int((G * 10 + 5) / 306)
  
  Dim numbers(5) As Long
  numbers(0) = y400
  numbers(1) = y100
  numbers(2) = y4
  numbers(3) = y
  numbers(4) = m
  numbers(5) = G
  DecodeYearMonthDay = numbers
End Function

Function GetYear(ByVal G As Long) As Long
  Dim a() As Long
  a = DecodeYearMonthDay(G)
  GetYear = 400 * a(0) + 100 * a(1) + 4 * a(2) + a(3) + Int((a(4) + 2) / 12)
End Function

Function GetMonth(ByVal G As Long) As Long
  Dim a() As Long
  a = DecodeYearMonthDay(G)
  GetMonth = ((a(4) + 2) Mod 12) + 1
End Function

Function GetDay(ByVal G As Long) As Long
  Dim a() As Long
  a = DecodeYearMonthDay(G)
  GetDay = a(5) - Int((306 * a(4) - 5) / 10)
End Function

Function GetDays(ByVal y As Long, ByVal m As Long, ByVal d As Long) As Long
  Dim my As Long
  my = m + y * 12 - 3
  GetDays = d + Int((367 * my + 31) / 12) - 2 * Int(my / 12) + Int(my / 48) - Int(my / 1200) + Int(my / 4800)
End Function

Function GetWeekDay(ByVal y As Long, ByVal m As Long, ByVal d As Long) As Long
  Dim my As Long
  my = (m + y * 12 - 3) Mod 4800
  GetWeekDay = (d - Int(my / 1200) + Int(my / 48) - 2 * Int(my / 12) + Int(31 * (my + 1) / 12)) Mod 7
End Function

Native Input Data Normalization Within the `GetDays` Core

An exceptional asset of the engineered GetDays(y, m, d) algorithm is its absolute mathematical parity with native spreadsheet DATE evaluations, yet achieved completely independent of conditional validation blocks. It accepts out-of-bounds, zero, or negative constraints natively — the underlying polynomial matrix performs an immediate, hidden normalization across time coordinates:

Executing GetDays(2024, 3, 0) (March 0) smoothly maps onto the real absolute index of February 29, 2024.
Executing GetDays(2023, 1, -10) dynamically decrements the coordinate timelines to resolve precisely as December 21, 2022.
Executing GetDays(2023, 25, 1) cleanly standardizes overflowing month structures to track as January 1, 2025.

Empirical Validation Bounds and Architectural Integrity

To cross-examine the symmetrical precision of this mathematical matrix, a bidirectional subtraction verification loop was executed: =ABS(Original_Year - Decoded_Year) + ...

Governed by perfectly balanced fixed-point scaling properties (integer divisors `365243`, `3653`, and `306`), the execution kernel yields an absolute zero-bit error rate over staggering historical epochs. The verified operational envelope spans seamlessly from January 1, 0001, through April 30, 487,621.

⚡ Part 3. Bare-Metal Domination: The Strategy of the 32-bit Signed Long

The entire calculation loop and mathematical constant matrix are intentionally designed to execute within a standard 32-bit signed integer space (Long / int32_t). This unlocks mission-critical architectural advantages at the micro-architecture level:

Instruction Cycle Efficiency: The operations compile into raw single-cycle integer arithmetic, running natively on basic 32-bit embedded microcontrollers (ARM Cortex-M, RISC-V cores).
L1 Cache Optimization and Bandwidth Reduction: A standard Long variable commands exactly 4 bytes of system memory, contrasting with the 8 bytes demanded by a Double. When parsing multi-terabyte financial transaction streams (Big Data), the L1 Data Cache localization capacity is immediately doubled, entirely mitigating performance loss from Cache Misses.
SIMD Vectorization Parallel Output: A singular 512-bit wide CPU vector processing lane (AVX-512) can natively hold and process 16 chronological calculations simultaneously. Moving data within a 32-bit integer boundary inherently doubles parallel batch processing speeds over standard 64-bit data pipelines.
Direct Silicon Synthesis (FPGA / ASIC): This engine can be directly synthesized into a network controller's hardware layer, completing multi-century financial time transformations at raw fiber-optic line rate.

Part 4. The Scientific Core: Smoothing and Resolving the Actual/Actual Timeline Constraints (MSU Proceedings)

The analytical frameworks detailed within Parts 4 and 5 represent the core mathematical breakthroughs of my research paper officially published in the Proceedings of the Lomonosov Moscow State University International Conference (eLIBRARY ID: 49514570).

To resolve the strict astronomical calendar standard (Actual/Actual), we must acquire a perfectly continuous and differentiable time coordinate. The overarching barrier to this is the step-wise, jumping behavior of annual calendar lengths ($D_i$, fluctuating between 365 and 366 days). This fluctuations split the time coordinate into a non-linear, fragmented, and non-differentiable space at leap-year boundaries.

Throughout my research, this computational barrier was shattered with extraordinary success: I accomplished the task of smoothing and differentiating the non-differentiable. I derived and mathematically established a continuous real value time-in-years coordinate, which maps fragmented chronological milestones into a smooth, perfectly differentiable continuum:

\[ G_i = y_i + \frac{\Delta_i}{D_i} \]

Where $y_i$ represents the calendar year of the i-th date, $\Delta_i$ defines the strict sequential day index inside that year, and $D_i$ reflects the absolute day length of that year. The values are decomposed using an analytical day distribution polynomial derived by me without using conditional IF switches:

\[ \Delta_i = d_i + \lfloor 30.56 m_i \rfloor - 30 - \lfloor 0.1 m_i + 0.7 \rfloor \cdot (367 - D_i) \]

\[ D_i = 365 + \left(\lfloor \frac{y_i}{4} \rfloor - \lfloor \frac{y_i - 1}{4} \rfloor\right) - \left(\lfloor \frac{y_i}{100} \rfloor - \lfloor \frac{y_i - 1}{100} \rfloor\right) + \left(\lfloor \frac{y_i}{400} \rfloor - \lfloor \frac{y_i - 1}{400} \right) \]

Critical Scientific Insight: The absolute calculation of this fractional year value can be performed within pure rational numbers with zero rounding error, bypassing the need for the classical Euclidean algorithm entirely. Because 365 and 366 are mathematically coprime, the entire sequence maps flawlessly into a unified integer fraction sharing a constant common denominator of 365 ⋅ 366.

Deploying this continuous chronological vector space $G_i$ yields the mathematical infrastructure necessary to definitively solve the Internal Rate of Return (IRR) equation under irregular transaction patterns. The central IRR equation is reshaped into a continuous, non-disrupted function:

\[ f(\text{IRR}) = \text{ДП}_0 + \sum_{i=1}^{n} \frac{\text{ДП}_i}{\prod_{j=1}^{i} \left(1 + \frac{\text{IRR}}{100\%} \cdot (G_j - G_{j-1})\right)} = 0 \]

Exploiting the mathematical smoothness achieved across the input timeline, I extract its exact analytical first derivative f'(IRR), completely bypassing the crude numerical step-approximations that break down on non-linear data boundaries:

\[ f'(\text{IRR}) = -\sum_{i=1}^{n} \frac{\text{ДП}_i \cdot \sum_{k=1}^{i} \frac{G_k - G_{k-1}}{1 + \frac{\text{IRR}}{100\%} \cdot (G_k - G_{k-1})}}{\prod_{j=1}^{i} \left(1 + \frac{\text{IRR}}{100\%} \cdot (G_j - G_{j-1})\right)} \]

This mathematical framework guarantees absolute convergence. The Newton-Raphson loop resolves the exact root of the equation in exactly 3 iterations, maintaining a precision scale down to one-millionth of a percent even when mapping highly volatile, non-periodic transaction schedules under strict operational constraints!

Below is the production-grade programmatic implementation of this analytical model, written in standard VBA:

Function AmIRR(CashFlows As Range, Dates As Range, Optional Guess As Double = 0) As Variant 
  If CashFlows.Count <> Dates.Count Then 
    AmIRR = "#DIMENSIONS OF CASH FLOWS AND DATES DO NOT MATCH" 
    Exit Function
  ElseIf CashFlows.Count = 1 Then 
    AmIRR = "#INSUFFICIENT VALUES" 
    Exit Function
  End If 

  Dim AmIRR0 As Double, f As Double, diff As Double, t As Double, df As Double
  Dim i As Long, j As Long, k As Long
  AmIRR = Guess 
  AmIRR0 = AmIRR + 0.00001 
  j = 1 
  
  Dim DatesInYears() As Double 
  ReDim DatesInYears(Dates.Count) 

  If Dates(1) > 366 Then 
    For i = 1 To Dates.Count 
      DatesInYears(i) = DateInYears(Dates(i)) 
    Next 
  Else 
    For i = 1 To Dates.Count 
      DatesInYears(i) = Dates(i) 
    Next 
  End If 

  While Abs(AmIRR0 - AmIRR) >= 0.000000000000001 And j < 100 
    f = CashFlows(1) 
    diff = 0 
    t = 1 
    For i = 2 To CashFlows.Count 
      t = t * (1 + AmIRR * (DatesInYears(i) - DatesInYears(i - 1))) 
      f = f + CashFlows(i) / t 
      df = 0 
      For k = 2 To i 
        df = df + (DatesInYears(k) - DatesInYears(k - 1)) / (1 + AmIRR * (DatesInYears(k) - DatesInYears(k - 1))) 
      Next 
      diff = diff - CashFlows(i) * df / t 
    Next 
    AmIRR0 = AmIRR AmIRR = AmIRR - f / diff j = j + 1 
  Wend 

  If j = 100 Then 
    AmIRR = "#SERIES DID NOT CONVERGE:" & AmIRR & ";" & AmIRR0 
  End If 
End Function

️ Part 5. Conclusions

This phenomenal success within complex practical environments, validated by Lomonosov Moscow State University and archived via eLIBRARY, can and absolutely must be exported to global engineering practices. This shift is fundamentally dictated by the strict runtime demands of ultra-high-speed streaming data pipelines operating over massive, enterprise-scale real-time datasets (Big Data), where ensuring absolute mathematical correctness is the only mechanism to guarantee a total elimination of endless legal, regulatory, and corporate financial disputes.

While it is currently premature to formally elaborate on the underlying algebraic intersections linking my newly discovered field of a,b-Romanions to this specific application, I am already standing on the precipice of an even more impactful paradigm shift that will comprehensively reconstruct contemporary perspectives on high-speed technologies of the future. Effectively, I am on the verge of formulating a universal, ultra-fast programming paradigm for the next generation of computing architecture. The established doctrine of dialectical materialism — stating that "everything in the universe is interconnected and interdependent" — has found its ultimate empirical realization right here within this body of work. This architecture, even when evaluated completely independent of the broader Romanion field, already stands as a comprehensive, independent super-technological breakthrough.

References

Романенко Р. В. Формула полной стоимости кредита // Инновационная экономика и менеджмент: методы и технологии : сборник статей участников VI Международной научно-практической конференции, Москва, 26–27 октября 2021 года. – Москва : Издательский Дом (типография) Московского государственного университета имени М. В. Ломоносова, 2021. – С. 238–244. – EDN: ZKMPWF. – eLIBRARY ID: 49514570. – URL: https://www.elibrary.ru/item.asp?id=49514570 .
Романенко Р. В., ПАВЛОВ В. А. Решение класса диофантовых уравнений вида: $x^2-y^2=z^n$ // Инновационные научные исследования. – 2021. – № 5-1 (7). – С. 6–14. – УДК: 511.52. – eISSN: 2713-0010. – EDN: EUQQTF. – eLIBRARY ID: 46584125. – DOI: 10.5281/zenodo.5007170. – URL: https://www.elibrary.ru/item.asp?id=46584125 .

Building aegis-filter: Why Standard Kalman Filters Fail in Adversarial Environments

Fri, 09 Oct 2026 05:45:50 +0000

When building telemetry filters for autonomous drones or robotics, the textbook recommendation is always the same: “Just slap a Kalman Filter on it.”

In theory, the linear Kalman filter is mathematically optimal under Gaussian white noise. In the real world, however, physical sensors do not live in textbook conditions:

Adversarial GPS/Baro Spoofing: A rogue transmitter or RF jammer injects sudden, massive delta jumps (e.g., +150 meters in a single millisecond).
Numerical Covariance Degeneracy: Floating-point round-off errors over millions of iterations cause the error covariance matrix $P$ to lose its positive-definiteness ($P \not\succ 0$), producing negative variances and exploding state estimates.
Severe Non-Linearities: Radar range calculations ($r = \sqrt{x^2 + y^2}$) and orientation quaternions break linear assumptions; Extended Kalman Filters (EKF) require calculating brittle analytical Jacobian matrices that drift rapidly.

To solve these mission-critical vulnerabilities, we built and open-sourced aegis-filter under Exploidus—a cyber-resilient, #![no_std], hard real-time estimation engine written from scratch in pure Rust.

Here is the engineering breakdown of how it works and what the simulation numbers prove.

1. The Core Architecture

aegis-filter is engineered with three core defenses:

A. Joseph-Stabilized Covariance Update

Standard Kalman filters update covariance using $P_k = (I - K_k Hk) P{k|k-1}$. In finite-precision IEEE 754 floating-point arithmetic, subtraction can yield asymmetric, non-positive-definite matrices.

aegis-filter enforces the Joseph Stabilized Form:
\[P_k = (I - K_k H_k) P_{k|k-1} (I - K_k H_k)^T + K_k R_k K_k^T\]

Because both terms are quadratic forms ($A P A^T + B R B^T$), positive-definiteness is mathematically guaranteed across infinite operational lifetimes.

B. Chi-Square / 3-Sigma Outlier Rejection Gating

Before any raw measurement is allowed to alter the state vector, the innovation $\tilde{y}_k = z_k - Hk \hat{x}{k|k-1}$ is evaluated against the innovation covariance $S_k = Hk P{k|k-1} H_k^T + R_k$:
\[\text{Reject if } |\tilde{y}_k| > \gamma \sqrt{S_k}\]

If an adversary transmits a spoofed altitude or an IMU glitches, the reading is gated at line-rate. The filter falls back safely to its physical state propagation without corrupting the state.

C. Unscented Kalman Filtering (UKF) & $H_\infty$ Robust Minimax

UKF (Merwe Scaled Sigma Points): Replaces brittle Jacobian derivations by propagating $2n + 1$ deterministic sigma points through non-linear observation closures.
$H_\infty$ Minimax: Optimizes state estimation against the worst-case disturbance rather than assuming well-behaved Gaussian noise.

2. Flight Telemetry & Spoofing Resilience Simulation

To prove real-world resilience, we simulated a quadcopter ascending at $1.5\text{ m/s}$ subjected to atmospheric turbulence, normal sensor noise, and deliberate adversarial spoofing:

Step 12: Instantaneous $+150\text{m}$ GPS spoofing attack.
Step 22: Severe $-80\text{m}$ sensor hardware dropout glitch.

Here is the telemetry log produced by running cargo run --example flight_telemetry:

===============================================================================
  AEGIS-FILTER :: FLIGHT TELEMETRY & ADVERSARIAL RESILIENCE SIMULATION
  Developed under Exploidus (https://github.com/Exploidus)
===============================================================================

Step   | True Alt (m) | Sensor Raw (m) | Aegis Est (m)  | Abs Error    | Status    
-------+--------------+----------------+----------------+--------------+-----------
1      | 1.50         | 1.79           | 1.75           | 0.254        | VALID     
2      | 3.00         | 3.22           | 3.24           | 0.238        | VALID     
3      | 4.50         | 3.46           | 4.31           | 0.187        | VALID     
4      | 6.00         | 6.74           | 6.06           | 0.057        | VALID     
5      | 7.50         | 7.67           | 7.58           | 0.081        | VALID     
6      | 9.00         | 8.90           | 9.04           | 0.045        | VALID     
7      | 10.50        | 9.68           | 10.39          | 0.113        | VALID     
8      | 12.00        | 12.98          | 12.08          | 0.075        | VALID     
9      | 13.50        | 13.41          | 13.55          | 0.047        | VALID     
10     | 15.00        | 14.69          | 14.99          | 0.009        | VALID     
11     | 16.50        | 16.04          | 16.42          | 0.080        | VALID     
12     | 18.00        | 168.00         | 17.92          | 0.080        | SPOOF REJECT
13     | 19.50        | 19.08          | 19.36          | 0.138        | VALID     
14     | 21.00        | 20.65          | 20.83          | 0.172        | VALID     
15     | 22.50        | 22.43          | 22.34          | 0.156        | VALID     
16     | 24.00        | 24.93          | 24.01          | 0.012        | VALID     
17     | 25.50        | 24.79          | 25.40          | 0.099        | VALID     
18     | 27.00        | 26.78          | 26.88          | 0.116        | VALID     
19     | 28.50        | 28.76          | 28.44          | 0.060        | VALID     
20     | 30.00        | 30.64          | 30.04          | 0.044        | VALID     
21     | 31.50        | 30.61          | 31.41          | 0.095        | VALID     
22     | 33.00        | -47.00         | 32.91          | 0.095        | SPOOF REJECT
23     | 34.50        | 34.96          | 34.50          | 0.003        | VALID     
24     | 36.00        | 36.25          | 36.04          | 0.036        | VALID     
25     | 37.50        | 36.60          | 37.39          | 0.110        | VALID     
26     | 39.00        | 39.34          | 38.96          | 0.041        | VALID     
27     | 40.50        | 40.99          | 40.54          | 0.039        | VALID     
28     | 42.00        | 41.84          | 42.01          | 0.009        | VALID     
29     | 43.50        | 42.78          | 43.40          | 0.100        | VALID     
30     | 45.00        | 45.60          | 45.00          | 0.003        | VALID     

-------------------------------------------------------------------------------
  SIMULATION SUMMARY:
  - Total Steps Processed      : 30
  - Valid Readings Fused       : 28
  - Adversarial Spikes Blocked : 2 (100% Gated)
  - Final Variance Confidence  : 0.1185
===============================================================================

Key Takeaways from the Data:

Millimeter Tracking Precision: Under normal noisy conditions (Step 10, Step 30), estimation error dropped to 0.003–0.009 meters (3–9 mm).
Flawless Spoof Rejection: When the raw altitude leaped to $168\text{m}$ at Step 12, the filter isolated the anomaly, kept the aircraft altitude at $17.92\text{m}$ (error: $0.080\text{m}$), and prevented a fatal motor cut.

3. Quick Start (Rust)

Add aegis-filter to your Cargo.toml:

[dependencies]
aegis-filter = "0.1.0"

For bare-metal Cortex-M/RISC-V embedded targets:

[dependencies]
aegis-filter = { version = "0.1.0", default-features = false }

1D Outlier-Gated Fusion Example:

use aegis_filter::{ScalarKalmanFilter, FilterError};

fn main() -> Result<(), FilterError> {
    // Initial state: 0.0m, Initial variance: 5.0, Process noise: 0.02, Measurement noise: 0.8
    let mut filter = ScalarKalmanFilter::new(0.0, 5.0, 0.02, 0.8)?;

    let sensor_stream = [1.5, 3.1, 4.4, 168.0 /* Spoofed spike */, 6.0];

    for &raw_reading in &sensor_stream {
        filter.predict(1.5)?; // Predict forward by 1.5m climb

        match filter.update(raw_reading, Some(3.0)) { // 3-sigma gate
            Ok(estimated_alt) => println!("Estimated Altitude: {:.2}m", estimated_alt),
            Err(FilterError::MeasurementGated) => {
                println!("Spoofed sensor reading ({:.1}m) rejected! Holding state.", raw_reading);
            }
            Err(e) => return Err(e),
        }
    }

    Ok(())
}

4. Open Source Links

The engine is open-source under dual MIT/Apache-2.0 licenses:

Crates.io: crates.io/crates/aegis-filter
GitHub Repository: Exploidus/aegis-filter
Documentation: docs.rs/aegis-filter

Feedback, issues, and PRs from control engineers and systems developers are warmly welcome!

The adaptive threshold that deleted the thing we were looking for

Mon, 28 Sep 2026 05:03:07 +0000

Finding the four corners of a page in a phone photo is the step that turns a picture of a document into a copy of one. Everything downstream — the perspective warp, the flattening, the PDF — is easy once you know where the page is.

We do that client-side, in a browser tab, on a grayscale copy of the photo scaled to a long edge of 640 px. The pipeline is the textbook one:

grayscale → blur → Sobel → adaptive edge map → Hough lines → best convex quad

Two near-horizontal lines, two near-vertical lines, score every candidate quadrilateral, keep the best. Disclosure up front: this is from LensUp, which is ours. What follows is the part where the textbook pipeline quietly failed, and the one-line change that nearly doubled how often it works.

The failure: the page fills the frame and detection gets worse

The adaptive edge threshold is the standard trick. Take the histogram of Sobel magnitudes, pick the 90th percentile, call everything above it an edge. It adapts to lighting, exposure and camera noise for free.

It also has a property nobody mentions: it is set by whatever has the strongest gradients in the image. On a photo of a document, that is not the page border. It is the letter strokes. Printed text is black-on-white at high spatial frequency — it produces the sharpest gradients in the frame by a wide margin.

The paper-to-desk step, meanwhile, is weak. Measured on SmartDoc 2015, a page lying on light wood clears the surrounding surface by roughly 14 luma levels. That is the signal you actually need, and it is an order of magnitude quieter than the text sitting in the middle of it.

So the adaptive threshold, doing exactly what it was designed to do, sets itself by the text and prices the page border out of the edge map. And it does this worst in the case you most want to work: when the user fills the frame with the page, so text dominates the histogram and there is barely any desk left to argue for a lower threshold.

The fix is not clever. Cap it:

edgePercentile: 0.9,     // gradient magnitudes above this percentile are edges …
minEdgeMagnitude: 14,    // … but never below this …
maxEdgeThreshold: 30,    // … and never above this: print must not price the page edge out

Measured on 300 real frames, with every other guard unchanged:

threshold cap	pages located
220	23.3 %
30	41.0 %

An adaptive threshold with a hard ceiling is no longer fully adaptive, which felt wrong when we wrote it. It is also the single highest-value line in the file.

Telling paper from a block of printed text

Capping the threshold gets the page border back into the edge map. It also lets a lot of rectangles in that are not pages — and the most dangerous one is a dark block of printed text, because it is genuinely a bright-surrounded rectangle with strong edges.

The first instinct is a contrast magnitude: require the inside of the quad to be meaningfully brighter than the outside. We had that set at 14 gray levels, which is the median paper-on-light-wood step from above.

That was the wrong knob. A threshold at the median of true pages rejects about half of the true pages. What actually discriminates is not how big the step is but which way it points:

minContrast: 8,   // 40th percentile of (inside − outside) across each side, in gray levels.
                  // A page on light wood measures 14 at the median, so 14 rejected half of them;
                  // the polarity rule is what keeps text blocks out, not this magnitude.

The polarity rule is the actual test: a quad is a page only if it is brighter inside than outside, sampled at two depths, on all four sides. A text block fails that on the sides where more text continues past it. A page on a desk passes it everywhere.

There is still a case that beats local evidence: a large dark region of print can look like "the desk" if you only sample a few pixels out. So before applying a detection automatically — as opposed to just pre-positioning the handles — we probe farther outside, looking for the page continuing past that edge. If the page continues, the edge was not the page edge.

The guards that are product decisions wearing algorithm clothes

Three of the constants in that file are not computer vision. They are decisions about what to do when we are unsure, and they are the ones I would port to any similar project:

borderMargin: 0.02,        // a side within 2% of the frame edge is "on the border"
applyMinAreaRatio: 0.25,   // a smaller page is only proposed, never applied
minSideSupport: 0.42,      // every side needs this much edge support to be applied

A quad with a side lying on the image border is rejected. If the "page edge" is the edge of the photo, the page is not fully inside the frame, and the honest default is the whole frame rather than a crop that silently cuts off whatever was outside it.

The largest well-supported quad wins. This sounds like a tie-breaker and is actually a correctness rule: it makes an inner rectangle — a photo printed on the page, a bordered table — lose to the page around it.

Below a quarter of the frame, a detection is only a proposal. It pre-positions the four draggable handles and waits. Auto-applying a small quad is how you produce the single worst outcome in this whole category: a confident crop that removes two thirds of somebody's passport.

That last one generalises. The result of this module is a proposal and never the truth; every handle stays draggable, and the caller decides from a confidence value whether to apply it silently. When detection fails outright it returns null, and null means keep the entire original image. A scanner that crops wrong is worse than a scanner that does not crop.

Two features that ship turned off

weakEdgeRecovery: 0,   // Experimental: desktop cost is not yet justified by coverage gains.
contourRecovery: 0,    // Correct proposals improved, but the measured latency gate failed.

Both of these work. Both improve the numbers. Both are disabled in the shipped defaults because they did not clear a latency budget on the hardware people actually hold. Leaving them in the file at 0, with the reason written next to them, has been more useful than deleting them — the next person to look at this does not have to rediscover that the idea was tried and why it is not on.

What I would take away from this

The general shape of the bug is worth more than the specific fix: an adaptive parameter adapts to the strongest thing in your input, and the strongest thing is often not your signal. Text beats page borders. Specular highlights beat document edges. The loudest object in the frame sets your threshold, and if your target is quiet, it gets deleted.

When an adaptive method underperforms, it is worth checking whether it is adapting to something you did not intend before reaching for a better algorithm. In our case the better algorithm was a ceiling of 30.

If you want to watch this run on your own photo, it is at a browser-based document scanner — the detection happens in the tab and your files are never uploaded, so the Network panel is a fair way to check that claim.

Behavior Trees, A Star Pathfinding And Where LLM NPCs Actually Fit

Wed, 23 Sep 2026 16:25:23 +0000

Most of us are writing agent code all day now, and it is worth knowing that game developers solved a version of the same decision problem twenty years ago without using machine learning for any of it. This is the architecture side of game AI, written for developers who have built decision systems before but have never looked at how games structure theirs.

Why Finite State Machines Stop Scaling

A finite state machine gives an NPC one active state at a time and a set of transition rules. A guard patrols, hears something, investigates, confirms the player, chases, attacks, loses sight, goes back to patrol. It is easy to draw, easy to test, and cheap at runtime, which is why it survived so long.

The problem is that every new state needs transitions defined to and from every existing state it can reach, so transitions grow roughly with the square of the state count. A combat NPC that handles melee, ranged, grenades, cover, retreating, healing, calling for reinforcements and surrendering ends up with dozens of states and hundreds of transitions. At that size nobody can change one behavior without breaking another. Hierarchical state machines help by nesting machines inside states, but they only push the wall further out.

Behavior Trees Took Over For A Reason

A behavior tree is evaluated from the root every tick and execution flows down through the branches. Composite nodes control flow, where a Sequence runs children in order and succeeds only if all succeed, and a Selector tries children in order and succeeds as soon as one does, which is how you express fallback chains. Decorators wrap a single child to invert it, repeat it, or gate it behind a cooldown. Leaves are the actual actions and conditions.

The reason it won is modularity. Each subtree is self contained, so a melee enemy and a ranged enemy share the same perception and navigation subtrees and differ only in the combat branch. Adding a behavior means inserting a branch at the right priority instead of wiring transitions to everything else. Unreal pairs its trees with a blackboard, a shared key value store for things like last known player position, which keeps state out of the tree structure.

The cost is debuggability. What runs depends on the state of every node above it, and since the tree re-evaluates from the root each tick, two branches that keep swapping priority make the NPC thrash between behaviors mid animation. Cooldown decorators, hysteresis on conditions, or letting a committed action finish before re-evaluating are the standard fixes.

Pathfinding Is A Graph Problem, Not A Geometry Problem

A star is still the backbone. It combines the known cost to reach a node with a heuristic estimate of the remaining distance, and explores in order of total estimated cost, which stays optimal as long as the heuristic never overestimates.

The engineering trick is what it runs on. Running A star against raw 3D geometry is hopeless, so levels get baked into a navigation mesh, a set of convex polygons covering everywhere an agent can walk. The search then runs on a polygon graph that is orders of magnitude smaller. On top of that sit the refinements: funnel algorithm string pulling to straighten paths through polygon corridors, hierarchical pathfinding between regions before pathing inside them, and flow fields when thousands of units head for the same destination and you want one precomputed direction field instead of thousands of searches. The full breakdown of the game AI toolkit walks through the steering layer that sits under all of this, the flocking rules that make group movement look natural, and the enemy patterns that get built from these pieces.

Where LLM NPCs Actually Fit

Classic game AI is deterministic, and that is a feature. Designers can author the experience, tune difficulty precisely, test every path, and know the NPC will never say something that breaks the fiction. The cost is that NPCs feel scripted, because they are.

Language models buy freeform dialogue, memory of past conversations and reactions to things no designer anticipated. They also bring latency measured in hundreds of milliseconds, per interaction cost, content safety work, and nondeterminism, which means you cannot guarantee a story beat or a difficulty curve. That last one is the real blocker for anything load bearing.

So the shipping pattern is hybrid. Classic systems run combat, navigation and world simulation, and generative models handle dialogue, quest text and reactive narration, the places where surprise is worth more than control.

The Takeaway

If you are building agent systems, the useful transfer is not the algorithms, it is the discipline. Games decided decades ago that predictable behavior beats clever behavior wherever failure is visible to the user, and they kept the unpredictable parts at the edges. That is a reasonable default for agents too.

Building Process Mind: A Deterministic Operating System Algorithm Simulator

Tue, 22 Sep 2026 11:29:23 +0000

I built Process Mind because I wanted a better way to practice Operating System algorithms.

When preparing for exams, I often found myself solving the same types of scheduling, page replacement, disk scheduling, and memory allocation problems repeatedly. The problem wasn't finding explanations of these algorithms. There are plenty of them.

The problem was verification.

For a manually solved problem, it is easy to make a small mistake somewhere in the calculation and only realize it much later. I wanted something where I could enter the same problem, run the algorithm, and immediately compare my result with a deterministic implementation.

That idea became Process Mind.

What is Process Mind?

Process Mind is an interactive web platform for practicing Operating System algorithms.

The current implementation covers four major areas:

CPU Scheduling — FCFS, SJF, SRTF, Priority, Preemptive Priority, Round Robin
Page Replacement — FIFO, LRU, Optimal, Second Chance, LRU Counter
Disk Scheduling — FCFS, SSTF, SCAN, C-SCAN, LOOK, C-LOOK
Memory Allocation — First Fit, Best Fit, Worst Fit, Next Fit

The goal isn't to simply display the final answer.

The application takes the user's input, validates it, runs the corresponding algorithm, and produces structured results such as calculated metrics, process details, Gantt blocks, and execution steps.

The basic flow is:

User Input
    ↓
Validation
    ↓
Algorithm
    ↓
Structured Result
    ↓
Metrics + Gantt + Process Details + Execution Steps
    ↓
UI

This separation became one of the most important design decisions in the project.

The Core Idea: Deterministic Results

There are already many tools that can explain Operating System concepts using AI or generate solutions dynamically.

I wanted Process Mind to solve a different problem.

If I enter a problem, I should get the same result every time.

For algorithm practice, determinism is useful. The application isn't trying to interpret what I meant or generate a plausible explanation. The algorithm implementation processes the input according to its defined rules.

That makes it useful for checking manually solved questions.

For example, with a CPU scheduling problem, Process Mind can calculate:

Process	Arrival	Burst	Completion	Turnaround	Waiting	Response
P1	0	7	7	7	0	0
P2	1	1	8	7	6	6
P3	2	7	15	13	6	6

It can also calculate average turnaround, waiting, and response times and represent execution using a Gantt chart.

The exact numbers depend on the input, but the important part is that the result comes directly from the algorithm.

The Difficult Part Wasn't Writing the Algorithms

Implementing FCFS or SJF isn't particularly difficult once the algorithm is understood.

The harder question was:

What information should the algorithm return?

Initially, it would have been easy to return something like:

completionTime
waitingTime
turnaroundTime

But that isn't enough for an educational tool.

If the purpose is practice and verification, users may also want to understand why a process was selected.

So the result structure evolved to contain more information:

ScheduledResult
├── processes
├── metrics
├── blocks
└── steps

The steps data became particularly useful.

Each execution step can contain information such as:

current time
ready processes
selected process
waiting queue
processes that arrived during execution
queue after execution
execution window
whether the CPU was idle
reason for selecting the process

This allows the UI to show not only what happened, but also some of the state behind the decision.

Handling Preemptive Scheduling

Preemptive algorithms introduced another layer of complexity.

For algorithms such as SRTF and Preemptive Priority Scheduling, a process can be interrupted when another process becomes eligible.

Instead of treating a process as simply "running" or "finished", the implementation needs to maintain its remaining execution time.

For example:

Process
├── arrivalTime
├── burstTime
└── remainingTime

At each relevant point, the algorithm can determine which process should run based on the current state.

Round Robin has a different challenge because execution is controlled by a time quantum. Processes that don't finish within their allocated quantum need to be placed back into the ready queue.

These differences meant that I couldn't force every scheduling algorithm into exactly the same internal implementation.

Instead, I kept the implementations independent while giving them a consistent output structure.

That gave me a useful balance:

different algorithms internally, consistent results externally.

Validation Matters More Than It Looks

Since users can enter arbitrary values, validation is an important part of the application.

I'm using React Hook Form with Zod for form handling and validation.

Inputs such as arrival time, burst time, priority, and quantum have appropriate constraints. Duplicate process IDs are also rejected.

Random input generation is included as well.

Instead of manually creating a new set of processes every time, users can generate random inputs and immediately practice with them.

This fits the original reason I started building the project: generate a problem, solve it yourself, and verify the result.

Building the Interface Around the Algorithm

One thing I learned while building Process Mind is that an algorithm implementation and an educational interface are two different problems.

The algorithm knows what happened.

The UI needs to decide how that information should be understood by a human.

For CPU scheduling, I currently use a combination of:

input forms
result metrics
process tables
Gantt charts
expandable execution steps

The Gantt chart gives a quick overview of execution, while the execution-step section exposes more detailed information when needed.

I deliberately kept the current visualization relatively simple. The larger goal is to eventually make Process Mind feel more like a simulation, but I don't want to add visual complexity just for the sake of having animations.

What I Learned

The biggest lesson from Process Mind wasn't about Next.js or TypeScript.

It was about designing data around the problem domain.

When building a normal CRUD application, the data model is often fairly obvious.

With algorithms, it isn't.

You have to decide what intermediate state matters, what information helps explain a decision, which metrics are useful, and how that information can be represented consistently across different algorithms.

I also learned that implementing an algorithm in code forces you to understand it differently.

Writing SRTF, for example, isn't the same as memorizing that "the process with the shortest remaining time executes." You have to think about arrivals, remaining time, preemption, completion, ties, queues, and every state transition.

That was one of the reasons I wanted to build Process Mind in the first place.

What's Next?

Process Mind is still evolving.

The current focus is making the existing algorithms reliable and useful for practice rather than continuously adding features.

The longer-term direction is to make the experience more simulation-oriented, with better visualization and interaction around algorithm execution.

But the core idea remains the same:

Practice the problem yourself. Run it through the algorithm. Verify your result. Understand where the execution came from.

That's what Process Mind is trying to become—a practical bridge between studying an algorithm and actually understanding how it executes.

Try Process Mind

Data Structure & Algorithms

Sat, 05 Sep 2026 07:27:46 +0000

https://github.com/asimayazmrd0987-glitch/Data-Structures-and-Algorithms
This is my github repo where I work on DSA, and I am Still working on it.
It is Open Source, get it free.

The Engineering Behind ShiftSync: Turning Workforce Rostering Into a Constraint-Optimisation Problem

Wed, 02 Sep 2026 01:40:09 +0000

How 20+ scheduling algorithms, a privacy-first local architecture, and zero mandatory registration combine to make free AI-powered shift scheduling actually work.

Workforce scheduling looks like a UI problem until you try to automate it correctly.

Then the real engineering begins.
A calendar is trivial to draw. An accurate, fair, legally compliant roster for a 60-person hospital ward covering a 28-day planning period — that is a non-trivial constraint-satisfaction problem that has been forcing managers to stay late with spreadsheets for decades.
ShiftSync is my attempt to solve this properly. It is a browser-based, offline-capable, privacy-first workforce scheduling application with 20+ mathematical algorithms, full leave management, fatigue enforcement, and PDF/Excel export — free, no registration required.
Source code: github.com/validivar/ShiftSync Live application: www.shiftsync.world
This article is about the engineering decisions that made it work — and the ones I had to revisit when my first approach turned out to be wrong.

Start With Constraints, Not the Interface
The most seductive mistake in scheduling software is starting with the UI.
You build the staff table. You build the weekly grid. You add colour-coded shift indicators. It looks impressive. Then someone asks: how does it automatically generate a valid schedule?
That is when you discover you have been building the wrong thing first.
Before any interface code, a scheduling system requires a precise constraint model. ShiftSync's constraint model distinguishes between two fundamentally different types of rules:
Hard Constraints — Inviolable

An employee on approved leave cannot be assigned to any shift
during their leave period.
No employee may exceed their defined maximum consecutive shift count.
A minimum rest interval (default: 11 hours, EU Working Time
Directive aligned) must separate the end of one shift
and the start of the next.
Any shift designated as requiring a specific skill (ICU, ACLS,
Forklift, etc.) must receive an employee who holds that
certification.
Soft Constraints — Optimised, Not Mandated
Employees' stated shift preferences should be honoured when
coverage allows.
Total working hours across the planning period should be
distributed equitably across the team.
Night shift assignments should rotate across the full team
rather than concentrating on a subset.
Individual weekly hours should approach (not necessarily
reach) the configured minimum.

The distinction is load-bearing. An algorithm that treats all constraints identically either refuses to generate a roster (too many collisions between hard rules) or generates one that is technically valid but practically awful (maximises compliance metrics while ignoring everything a human manager actually cares about).
The correct model is validity plus optimisation — not just assignment.

Why 20 Algorithms Instead of One
My first instinct was to build a single generalised scheduling algorithm that could handle any pattern.
This was wrong.
Different industries use shift patterns with fundamentally incompatible structures. The Panama Plan's 2-2-3 cycle is not a generalisation of the Dupont rotation's 28-day sequence. A 24-hour call duty schedule has completely different rest constraint arithmetic than a standard 4x4 eight-hour pattern.
Trying to represent all of these inside a single algorithm produces either a combinatorial explosion of special cases or a lowest-common-denominator system that handles none of them well.
The correct approach is a dispatch table — separate, cleanly implemented algorithms for each pattern, each with full knowledge of its own cycle structure and timing requirements.
const algorithms = {

'4x4':   generate4x4Schedule,    // 8hr 3-shift rotation
'panama': generatePanamaSchedule, // 12hr 2-2-3 cycle
'pitman': generatePitmanSchedule, // 12hr 4-on-4-off
'dupont': generateDupontSchedule, // 12hr 28-day complex rotation
'ddnnoo': generateDDNNOOSchedule, // 12hr D-D-N-N-O-O cycle
'4-10':  generate4_10Schedule,   // 10hr 4-day week
'8hour': generate8HourSchedule,  // 8hr standard 5/2
'12hour':generate12HourSchedule, // 12hr 3-on-3-off
'24hour':generate24HourSchedule, // 24hr call duty
'48hour':generate48HourSchedule, // 48hr weekend call
'mixed': generateMixedSchedule   // hybrid 8hr+12hr extended nights

};

const fn = algorithms[config.shiftType] || generateFairSchedule;
return fn(startDate, period, staffMembers.length, config);
Each function receives: start date (Luxon DateTime), planning period in days, staff count, and the full config object. Each independently implements its cycle logic before calling checkStaffLeave on every staff-date combination to enforce leave constraints.

Deep Dive: The Dupont Algorithm
The Dupont is the most complex pattern to implement correctly because its cycle is 28 days long and mixes night shifts, day shifts, and rest in a non-obvious sequence.
The canonical Dupont sequence is:
N N N N O O O D D D O N N N O O O D D D D O O O O O O O
Where N = Night, D = Day, O = Off.
The critical implementation challenge is assigning teams to positions in this cycle such that:
1.All shifts are covered on all days
2.No team is assigned the same position in consecutive cycles
3.Employee preferences shift the assignment within the cycle without breaking coverage
function generateDupontSchedule(startDate, days, staffCount, config) {

const schedule = [];
const dp = [
    'N','N','N','N','O','O','O',  // 4 nights, 3 off
    'M','M','M','O',               // 3 days, 1 off
    'N','N','N','O','O','O',       // 3 nights, 3 off
    'M','M','M','M',               // 4 days
    'O','O','O','O','O','O','O'   // 7 off
];

for (let day = 0; day < days; day++) {
    const currentDate = startDate.plus({ days: day });
    const dayEntry = { 
        date: currentDate.toFormat('yyyy-MM-dd'),
        dayOfWeek: currentDate.toFormat('EEE'),
        formattedDate: currentDate.toFormat('MMM dd'),
        shifts: {}
    };
    
    staffMembers.forEach((staff, i) => {
        // Offset each staff member's position in the cycle
        // to ensure continuous coverage
        const cyclePos = (day + Math.floor(i * dp.length / staffCount)) 
                         % dp.length;
        let shift = dp[cyclePos];
        
        // Hard constraint: leave always wins
        const leave = checkStaffLeave(staff, currentDate);
        if (leave) shift = 'L-' + leave;
        
        dayEntry.shifts[staff.id] = { 
            type: shift, 
            staffName: staff.fullName, 
            staffRank: staff.rank, 
            hours: shift === 'O' ? 0 : 12 
        };
    });
    
    schedule.push(dayEntry);
}
return schedule;

}
The Math.floor(i * dp.length / staffCount) offset distributes team members across the cycle such that all 28 cycle positions have coverage on every day of the planning period.

The Objective Function
Two schedules can both satisfy every hard constraint. Which one is better?
ShiftSync's compliance scoring function evaluates quality across four dimensions:
function calculateRosterStats(schedule) {

const stats = {
    totalHours: 0,
    shiftCount: { M:0, A:0, N:0, O:0, C:0 },
    staffHours: {},
    minHours: Infinity,
    maxHours: 0,
    avgHours: 0,
    compliant: true
};

// Accumulate per-staff hours
schedule.forEach(day => {
    staffMembers.forEach(staff => {
        const s = day.shifts[staff.id];
        if (s) {
            const t = s.type.charAt(0);
            if (stats.shiftCount[t] !== undefined) stats.shiftCount[t]++;
            stats.totalHours += s.hours || 0;
            stats.staffHours[staff.id] += s.hours || 0;
        }
    });
});

// Evaluate compliance bounds
const arr = Object.values(stats.staffHours);
stats.minHours = Math.min(...arr);
stats.maxHours = Math.max(...arr);
stats.avgHours = arr.reduce((a,b) => a+b, 0) / arr.length;

const wks = schedule.length / 7;
const maxW = parseInt(document.getElementById('maxHoursWeek').value) || 48;
const minW = parseInt(document.getElementById('minHoursWeek').value) || 36;

stats.compliant = stats.maxHours <= maxW * wks 
               && stats.minHours >= minW * wks * 0.5;

return stats;

}
The compliance flag (PASS / REVIEW) surfaces in the roster display panel. It is not a gate — the manager receives the roster regardless — but the flag ensures that borderline cases are visible rather than buried.

Local-First Architecture: A Deliberate Privacy Stance
Workforce scheduling data is operationally sensitive. It reveals staffing levels, employee identities, capability distributions, and leave patterns — information that many organisations in healthcare, security, and government are legitimately concerned about transmitting to third-party cloud infrastructure.
ShiftSync's response to this is architectural, not policy-based. The application has no server-side component. There is no API endpoint receiving scheduling data. There is no cloud database. There is no authentication layer that could become a breach surface.

Traditional SaaS: Browser → API → Database → Application → Browser
ShiftSync: Browser ← localStorage → Browser
All data is stored in localStorage. All scheduling computation happens in the browser. All export (PDF, Excel) is generated client-side by jsPDF and SheetJS respectively. The application works entirely offline after the initial HTML page load.
This architecture has real limitations for large enterprise deployments that require multi-user collaboration, centralised audit logs, and cross-device synchronisation. Those are genuine trade-offs, not ignored problems.
But for the target audience — small to medium organisations, NGOs, community hospitals, SMEs — this architecture is not a limitation. It is an advantage. It eliminates an entire category of data management risk.

The Fatigue Management System
EU Working Time Directive requires a minimum 11-hour rest period between shifts. Many clinical governance frameworks require maximum consecutive shift limits. ShiftSync enforces both.
The consecutive shift counter runs during algorithm execution. After generation, the conflict detection system evaluates whether the staff count is sufficient to satisfy the configured limits:
function checkConflicts() {

const maxC = parseInt(document.getElementById('maxConsecutive').value) || 5;
const alertEl = document.getElementById('conflictAlert');

if (staffMembers.length > 0 && staffMembers.length < maxC) {
    alertEl.classList.add('show');
    document.getElementById('conflictMsg').textContent = 
        `Warning: Only ${staffMembers.length} staff for patterns 
         requiring ${maxC}+ members. Some may exceed consecutive 
         shift limits.`;
} else {
    alertEl.classList.remove('show');
}

}
The warning surfaces before generation, giving the manager the option to add staff or adjust the consecutive limit before committing to a roster that will need manual correction.

Stack Decisions and Why

The absence of a framework is a deliberate choice. A scheduling tool used by a ward manager in Lagos, a factory supervisor in Manila, and an NGO coordinator in Nairobi needs to load fast on 3G and work when the connection drops. A React bundle adds seconds to the load time and introduces a dependency on JavaScript delivery infrastructure.
Single-file HTML with CDN dependencies loads in under two seconds on a mobile connection. It works offline. It deploys by dragging a file into a hosting panel.

What the Open Source Invitation Is Really For
ShiftSync is on GitHub not primarily as a portfolio item, but because scheduling logic is domain-specific in ways that a solo developer building from first principles will get wrong.
The DDNNOO algorithm is straightforward. But is the implementation correct for the specific variant used in ICU environments where one of the two "day" slots has different skill requirements from the other? I do not know. A developer who has worked scheduling in that environment might.
The Panama Plan cycle is mathematically clear. Does it interact correctly with a 14-day planning period where the cycle straddles the boundary? The tests should tell us. They might not cover all cases.
Open source is the mechanism for closing those gaps. If you work in scheduling, healthcare technology, workforce management, or HR software — the codebase is readable, the algorithms are individually separated, and issues are open.

Build It. Try It. Improve It.
ShiftSync is live at www.shiftsync.world.
No signup. No email. No credit card. Open the page. Add staff. Select a pattern. Generate. Export.
If you find a constraint the algorithm mishandles, open an issue: github.com/validivar/ShiftSync
If you use it in a production scheduling environment and find something wrong, tell me. That feedback is the most valuable contribution the project can receive.
And if you know an organisation — a clinic, an NGO, a small manufacturer, a security firm — still building rosters in Excel at midnight, send them the link. The better schedule is the product. Help us build it.
The immediate goal to sustaining ShiftSync is maintaining its website. You could help towards website renewal subscription using the donation buttons on the live site.

🌐 Live app: www.shiftsync.world | ⭐ GitHub: github.com/validivar/ShiftSync |
Mikhail Ikpoma — Founder, ShiftSync

Ada Lovelace: The Countess Who Programmed the Future 100 Years Before Computers Existed

Mon, 24 Aug 2026 17:42:03 +0000

In 1843, a 27-year-old mother of three and Countess of Lovelace published a technical appendix of notes three times longer than the original text she intended to translate. In those manuscript pages penned with quill and ink, in the heart of Victorian England's age of coal and steam, Augusta Ada King, Countess of Lovelace, did not merely write the first computer algorithm in history designed to be processed by a machine. She accomplished something infinitely more revolutionary: she conceived the very concepts of software and general-purpose computing.

While her mentor and collaborator, the brilliant inventor Charles Babbage, remained obsessed with building a massive mechanical calculator of brass and gears to eliminate human errors in astronomical and maritime navigation tables, Ada Lovelace saw what no one else in the 19th century could perceive. She understood that if a machine could manipulate numbers, and those numbers could represent any real-world entity — musical notes, alphabet letters, or visual pixels —, the machine could manipulate symbols and generate art, language, and knowledge.

In the pantheon of pioneers who laid the foundations of our data-driven civilization — alongside Florence Nightingale and healthcare statistics, Thomas Bayes and probabilistic inference, Claude Shannon and information theory, and Abraham Wald and the analysis of missing data —, Ada Lovelace occupies the foundational place: she was the first person to grasp that hardware is merely the mechanical body, but the algorithm is the thinking soul of the system.

The Princess of Parallelograms: Education Against Madness

Ada Lovelace was born in London in December 1815 as the only legitimate child of the famed Romantic poet Lord Byron and the aristocratic mathematician Annabella Milbanke. The marriage was a volcanic catastrophe: Byron left England mere weeks after Ada's birth never to return, leaving behind a wake of scandals, debts, and tempestuous genius.

Terrified that her daughter might inherit her father's erratic temperament and "poetic madness," Lady Byron subjected young Ada to an unusually rigorous educational regime for Victorian women. She banished poetry from their home and enforced an intensive diet of rigorous mathematics, logic, geometry, astronomy, and Latin. Annabella, whom Lord Byron himself had ironically dubbed in his letters as “the Princess of Parallelograms,” hired the finest private tutors in the British realm, including the renowned logician and mathematician Augustus De Morgan (famous for De Morgan's Laws of Boolean algebra) and the astronomer and science writer Mary Somerville.

De Morgan quickly recognized that young Ada's mind was extraordinary: she possessed an abstract ability to connect mathematical concepts with a philosophical and poetic intuition that he confessed he had never witnessed in any student. Ada herself coined her intellectual approach as “Poetical Science”: an integrative philosophy that applied metaphorical imagination to explore the deepest mathematical truths and discover practical applications where others saw only sterile figures.

Meeting Babbage: From Mechanical Calculator to Universal Computer

On June 5, 1833, at a London high-society salon, seventeen-year-old Ada was introduced to Charles Babbage, the Lucasian Professor of Mathematics at the University of Cambridge (the chair once held by Isaac Newton and later by Stephen Hawking). Babbage demonstrated to his guests a working partial prototype of his Difference Engine: a complex mechanical machine of brass gears designed to tabulate polynomials using the method of finite differences.

While most attendees viewed the contraption as a mechanical curiosity or an expensive scientific novelty, Ada was captivated by the underlying logical beauty of the mechanism. Thus began an epistolary correspondence and an intellectual partnership that spanned nearly two decades.

Soon, Babbage abandoned the Difference Engine to embark upon an incomparably more ambitious venture: the Analytical Engine. The difference between both machines is, in essence, the exact difference between a pocket calculator and a modern general-purpose computer:

The Difference Engine was a single-purpose calculator: it could only add and subtract to compute pre-determined polynomial tables.
The Analytical Engine was a programmable, general-purpose computing machine: it featured a central processing calculation unit Babbage called "the Mill," a data storage memory unit called "the Store," and an input/output control mechanism based on punched cards, inspired directly by Joseph Marie Jacquard's 1804 automated textile loom.

Babbage designed the machine. But it was Lovelace who truly understood what it meant.

The 1843 "Notes" and the First Algorithm (Note G)

In 1842, Babbage traveled to Turin to deliver a series of lectures on the Analytical Engine. Italian military engineer and mathematician Luigi Menabrea (future Prime Minister of Italy) took detailed notes and published a French paper describing the engine's operational principles in a Swiss journal.

Charles Wheatstone suggested that Ada Lovelace translate Menabrea's paper into English for the academic journal Taylor's Scientific Memoirs. Babbage, delighted with the prospect, encouraged her to add her own explanatory notes and commentaries. Ada worked relentlessly for nine months between 1842 and 1843, expanding the original text into a seminal work. Her annotations — labeled alphabetically from Note A to Note G — were more than three times longer than Menabrea's original treatise.

In Note A, Ada articulated the technical and philosophical distinction separating mere calculation from universal computing. She wrote one of the most visionary sentences in scientific history:

“The Analytical Engine weaves algebraical patterns just as the Jacquard loom weaves flowers and leaves.”

Yet the climax of her masterpiece lies within the legendary Note G. In this section, Ada designed a complete, structured operational diagram to compute the Bernoulli numbers (a complex sequence of rational numbers fundamental to number theory and mathematical analysis).

This was not a simple table of arithmetic steps: it was a formal computer algorithm. Lovelace designed with clockwork precision:

State variables and memory registers: She allocated specific memory addresses in the engine's "Store" to track intermediate variables ($V_1, V_2, V_3 \dots$).
Loops and iteration: She structured instructions allowing the machine to repeat sequences of punched cards automatically until an arithmetic condition was fulfilled.
Conditional branching: She defined how the control flow of the program could divert based on the outcome of a prior calculation.
Parallel execution and resource optimization: She analyzed how to minimize calculation cycles within the Mill to maximize computational efficiency.

Because of Note G, the international scientific community unanimously recognizes Ada Lovelace as the world's first computer programmer.

The Leap to Symbolic Computation: Software Before Hardware

For Babbage, the Analytical Engine was a number-crunching apparatus: its goal was to accelerate astronomical calculations, ballistics tables, and financial ledger computation.

For Lovelace, numbers were merely the medium, not the ultimate destination. In Note A, Ada made the monumental conceptual leap that would take another century for John von Neumann and Alan Turing to rediscover:

“Supposing that the fundamental relations of pitched sounds in the science of harmony and of musical composition were susceptible of such expression and adaptations, the engine might compose elaborate and scientific pieces of music of any degree of complexity or extent.”

This insight is breathtaking. In 1843, in a world devoid of electricity, vacuum tubes, and silicon semiconductors, a mathematician realized that any information system capable of being formalized through logical rules can be manipulated, transformed, and generated by an algorithmic machine.

Ada envisioned software, digital audio synthesis, natural language processing, and computer graphics before the incandescent light bulb had even been invented. She decoupled symbolic content from physical hardware, exactly as Claude Shannon would decouple human meaning from the mathematical entropy of the bit a century later.

"Lady Lovelace's Objection": The Original AI Debate

In Note G, Ada contemplated the metaphysical and operational boundaries of intelligent machines, offering a cautionary observation that would shape the philosophy of artificial intelligence forever:

“The Analytical Engine has no pretensions whatever to originate anything. It can do whatever we know how to order it to perform. It can follow analysis; but it has no power of anticipating any analytical relations or truths.”

A century later, in 1950, the father of theoretical computing and AI pioneer Alan Turing published his landmark paper "Computing Machinery and Intelligence" (introducing the Turing Test). In that paper, Turing dedicated an entire section to examining what he formally named “Lady Lovelace's Objection”.

Turing debated whether machines are truly incapable of surprising us or whether apparent creativity is simply an emergent property of extraordinarily complex deterministic rules executed at massive scale.

In 2026, in the midst of Large Language Models (LLMs) and autonomous reasoning agents powered by Gemini 2.5, Claude 3.7, and DeepSeek, Lovelace's Objection remains at the very core of modern technological debate:

When an agentic pipeline using CrewAI and Tool Calling autonomously resolves a complex supply chain crisis in our Obsolescence Radar, is it "creating" novel insight, or simply executing with statistical precision the trillions of conditioned parameters from its training?
When we compare Fine-Tuning vs Prompt Engineering vs RAG, we are recognizing the practical validity of Lovelace's postulate: the model does not conjure your company's truth out of thin air; it requires injected deterministic context through tools and curated data to deliver dependable results.

The question Ada posed in 1843 remains the technical and ethical benchmark through which the EU AI Act mandates human oversight (Article 14): machines execute with unprecedented speed, but purpose, responsibility, and ultimate judgment remain human prerogatives.

The Legacy: From Steam Power to Mission-Critical Systems

Ada Lovelace tragically passed away from uterine cancer in November 1852 at just 36 years of age — the exact age at which her father, Lord Byron, had died — and was buried, per her wish, beside him at the Church of St. Mary Magdalene in Hucknall, Nottinghamshire.

Babbage's Analytical Engine was never constructed during their lifetimes due to lack of government funding and the mechanical tolerance limits of Victorian metallurgy. For nearly a century, Lovelace's work lingered as an obscure bibliographic footnote in British scientific annals.

Yet history ultimately rendered mathematical justice to her vision:

The Ada Programming Language: In the late 1970s, the United States Department of Defense (DoD) commissioned a high-reliability, strongly typed programming language to manage mission-critical aerospace, defense, and infrastructure systems. In 1980, the DoD officially named the language Ada (military standard MIL-STD-1815, honoring her birth year). Today, Ada continues to control European air traffic management systems, French TGV high-speed trains, and commercial avionics flight control software worldwide.
Ada Lovelace Day: Every second Tuesday of October, the global technology and scientific community celebrates Ada Lovelace Day to champion and elevate women's leadership and achievements across STEM fields (Science, Technology, Engineering, and Mathematics).
NVIDIA's GPU Architecture: NVIDIA named its flagship GeForce RTX 40-series microarchitecture Ada Lovelace, paying tribute to the mathematician who first conceived of parallel algorithmic execution.

Thinking Like Ada: The Synthesis of Poetry and Engineering

If there is an enduring lesson Ada Lovelace bequeathed to software engineers, data scientists, and AI architects in our era, it is the power of Poetical Science.

Engineering devoid of imagination yields merely faster calculators; poetry without mathematical rigor produces fragile dreams with no practical foundation. But when rigorous mathematical discipline aligns with the bold imagination to envision how data reshapes human capability, revolutions occur.

Ada did not merely calculate polynomial series: she envisioned our digital future when the world still traveled on horseback. Two hundred years after her birth, every time we write a Python function, orchestrate an intelligent agent, or transform data pipelines into industrial decisions, we are walking along the pathway that a young Victorian mathematician charted on paper with ink, genius, and unmatched foresight.

Sources of Interest:

Procedural Generation Is A Rules Problem, Not A Randomness Problem

Fri, 21 Aug 2026 13:17:26 +0000

Most procedural generation threads turn into algorithm shopping lists, and the algorithm is rarely what went wrong. This is a writeup on the part that actually decides output quality, which is the structure you wrap around the random number generator.

Randomness Is Not Generation

A random number generator placing blocks at arbitrary positions produces visual noise. A procedural system that builds elevation from noise, runs erosion over it, assigns biomes from moisture and temperature gradients, then places vegetation by ecological rule produces something a player reads as a landscape.

The difference is that the rules encode design intent and the randomness only supplies variety inside them. When generated output feels wrong, the fix is almost always a missing constraint rather than a better noise function.

The Trade Has Not Changed Since 1984

Rogue generated dungeon layouts in 1980 so that each run was a new arrangement of rooms, corridors and monsters. Elite fit an entire galaxy of star systems into a few kilobytes in 1984 using mathematical seeds.

Both are the same bargain you make today: spend computation to save storage. What has grown is the pipeline, from a single RNG call to layered systems combining noise, grammars, constraint solvers and now models.

Determinism Is A Debugging Feature

The thing teams skip until it hurts is reproducibility. If a player reports that the world at seed 8815 was unwinnable and you cannot load exactly that world, you are debugging by guesswork.

That means every source of randomness has to run through the seeded generator, including the ones that sneak in later: hash iteration order, floating point differences across platforms, anything reading the wall clock. One unseeded call and the seed stops meaning anything.

Where Hand Built Content Still Wins

Generated content has a distribution and the bad tail ships too. Hand built content has no tail. That is why most shipped games run a hybrid: generated layouts assembled from hand made rooms, or a generated world with authored regions dropped into it, so the pieces are always good even when the arrangement is new.

Pacing is the other thing generators do not know. A generator cannot tell that the corridor before the boss should feel long.

Longer version covering the specific algorithms, noise functions, dungeon and level generation, wave function collapse, seeds and determinism, and where AI fits into this now: procedural generation for games

When Algorithms Take Sides: Bias, Legitimacy and Intelligent Systems in Contested Spaces

Thu, 06 Aug 2026 13:05:44 +0000

The proliferation of algorithms and intelligent systems in contested spaces has fundamentally altered the dynamics of power, governance, and decision-making. These systems, designed to process vast amounts of data and generate predictions or recommendations, are increasingly embedded in domains where competing interests, values, and claims about justice are at stake. From law enforcement to social media platforms, algorithms now mediate critical interactions, shaping how individuals and communities navigate complex social realities.

However, their deployment in these environments is not neutral; the design choices, data inputs, and operational frameworks of these systems often reflect underlying biases, assumptions, and priorities. As such, algorithms do not merely execute tasks, they actively participate in shaping the contours of legitimacy, often reinforcing existing inequities or amplifying marginalized voices in ways that are difficult to trace. The integration of these systems into contested spaces has thus raised urgent questions about their role in perpetuating or challenging power structures, and how their influence can be scrutinized to ensure they serve the public interest rather than entrench systemic disadvantages.

One of the most pressing concerns in this context is the potential for algorithmic bias to distort outcomes in ways that disproportionately affect certain groups. The Chicago crime prediction algorithm, for instance, has been scrutinized for its role in reinforcing racial disparities in policing. Relying on historical crime data to forecast where crimes are likely to occur (University of Ottawa: Rethinking Algorithmic Bias), such systems inadvertently replicate patterns of over-policing in communities of color.

This is not merely a technical issue but a structural one, as the data itself reflects historical biases in resource allocation and law enforcement practices. The result is a feedback loop in which algorithmic predictions justify further surveillance and intervention in already marginalized areas, deepening cycles of exclusion and discrimination. These examples underscore how algorithmic bias is not an incidental flaw but a systemic feature of intelligent systems operating in contexts where power imbalances are already entrenched.

The consequences of such biases extend beyond individual cases, shaping broader social narratives and institutional practices that affect the lives of entire communities.

Addressing algorithmic bias is therefore essential to preserving the legitimacy of the systems that govern contemporary society. Legitimacy, in this context, is not a given but a contested concept that depends on how individuals and groups perceive the fairness, transparency, and accountability of decision-making processes. When algorithms are perceived as opaque, unchallengeable, or aligned with the interests of dominant groups, their authority is undermined.

The Chicago case illustrates how the absence of clarity about how these systems operate can erode public trust, particularly when their outputs have real-world consequences for individuals’ freedoms and safety. Similarly, the integration of AI into decision-making processes across sectors, from hiring to healthcare, has highlighted how biases embedded in these systems can perpetuate gender and ethnic inequalities. These instances reveal that the legitimacy of intelligent systems is inextricably linked to their ability to operate in ways that are perceived as just and equitable, rather than as tools of exclusion or control.

The need for transparency and accountability in the development of these systems is therefore not just a technical or ethical imperative but a foundational requirement for their acceptance and effectiveness. The complexity of algorithmic decision-making, combined with the opacity of many machine learning models, has made it difficult to trace the sources of bias or hold developers and implementers accountable for their consequences. However, the growing recognition of these challenges has spurred calls for greater openness in how algorithms are designed, tested, and deployed. This includes efforts to audit systems for fairness, involve diverse stakeholders in their development, and establish mechanisms for challenging or correcting biased outcomes. Such measures are critical not only to mitigating harm but also to ensuring that intelligent systems contribute to, rather than undermine, the principles of justice and equity in contested spaces.

Ultimately, the legitimacy of algorithms and intelligent systems in contested environments hinges on their ability to balance efficiency with fairness, and their capacity to adapt to the diverse and often conflicting values of the societies they serve. As these systems continue to shape the contours of governance and social interaction, their design and operation must be guided by a commitment to transparency, accountability, and the recognition of human agency. Only through such an approach can intelligent systems avoid reinforcing existing power imbalances and instead foster environments where justice, inclusion, and public trust can coexist.

Definition of contested spaces and their significance

Contested spaces are environments where competing interests, beliefs, or ideologies generate disputes over control, access, or interpretation of a particular area. These spaces can manifest in physical locations, such as border regions or urban neighborhoods, or in digital environments, such as social media platforms or online forums. The defining characteristic of contested spaces is the presence of multiple, often conflicting, claims about their purpose, ownership, or significance.

This dynamic often results in power struggles, where dominant groups seek to impose their narratives while marginalized communities resist or redefine the space’s meaning. The tension inherent in contested spaces is not merely about physical or territorial control but also about the cultural, political, and social values that shape how the space is used and understood. Understanding these spaces is essential for analyzing the role of algorithms and intelligent systems, as these technologies are increasingly embedded in environments where human conflict and negotiation are central.

The interplay between algorithmic systems and contested spaces reveals how technology can both reflect and reshape existing power imbalances, often amplifying divisions rather than resolving them.

The significance of contested spaces lies in their ability to expose the vulnerabilities of algorithmic systems to human conflict and ideological polarization. Algorithms, which are designed to process data and make decisions based on patterns, do not operate in a vacuum. Instead, they are deployed within contexts where competing agendas, historical grievances, and social hierarchies are already in place. In such environments, the design and deployment of algorithms can either mitigate tensions or exacerbate them.

For instance, in online platforms where hate speech and misinformation thrive, algorithms that prioritize engagement metrics may inadvertently amplify divisive content, reinforcing existing biases and deepening societal fractures. Similarly, in geopolitical regions marked by territorial disputes, automated systems used for surveillance or resource allocation may be perceived as tools of domination, further fueling resistance or conflict. The challenge, therefore, is to recognize how algorithms interact with contested spaces not as neutral mechanisms but as active participants in shaping the outcomes of these disputes.

This interaction underscores the need for critical scrutiny of algorithmic processes to prevent their unintended reinforcement of injustice.

Contested spaces also provide critical insight into the socio-technical dimensions of algorithmic bias. The concept of counterpublics, spaces where marginalized groups articulate alternative narratives when excluded from dominant discourse, illustrates how contested environments can challenge the homogenizing effects of algorithmic systems. In such cases, algorithms may fail to account for the diverse perspectives and needs of different communities, leading to the exclusion or misrepresentation of certain groups. For example, a social media platform dominated by mainstream narratives may marginalize counterpublics by limiting their visibility or suppressing their voices, thereby perpetuating systemic inequities. This exclusion is not merely a technical issue but a reflection of broader power dynamics that shape the design and implementation of algorithms. The contested nature of these spaces highlights the tension between algorithmic efficiency and social equity, as systems that prioritize data-driven decision-making may overlook the contextual and cultural nuances that define human interactions.

The debate over algorithmic bias further complicates the relationship between contested spaces and intelligent systems. While some argue that bias in algorithms stems from flawed data or design, others contend that the very concept of bias is contested, with differing perspectives on what constitutes fairness or discrimination. This disagreement reflects the broader ideological clashes that occur in contested spaces, where competing definitions of justice and legitimacy shape how technology is perceived and used. For instance, in environments where marginalized groups advocate for algorithmic accountability, the absence of inclusive design processes may be framed as a systemic failure, whereas dominant groups may dismiss such concerns as overreach. This divergence in interpretation underscores the importance of situating algorithmic analysis within the specific contexts of contested spaces, where the same technology can be viewed as either a tool for empowerment or a mechanism of control.

Finally, the integration of socio-technical typologies of bias into the study of contested spaces reveals how algorithmic systems are shaped by and contribute to the dynamics of these environments. By categorizing biases as arising from data, design, or deployment, it becomes evident that contested spaces are not just passive backdrops for algorithmic operations but active sites where these systems are influenced by human agency and social structures. This framework allows for a more nuanced understanding of how algorithms can both reflect and challenge existing power dynamics, offering pathways for addressing bias through deliberate design choices and inclusive engagement with contested communities. Ultimately, the significance of contested spaces lies in their capacity to illuminate the complex interplay between technology, power, and society, necessitating a critical approach to algorithmic systems that acknowledges their embeddedness in human conflict and negotiation.

Importance of understanding bias and legitimacy in algorithms

The significance of algorithmic bias and legitimacy in intelligent systems lies in their capacity to shape societal norms, reinforce existing power structures, and influence the perception of fairness in decision-making processes. As artificial intelligence becomes embedded in critical domains such as law enforcement, healthcare, and employment, the design and training of these systems often reflect historical inequities embedded in data sets.

For example, the integration of AI into decision-making processes has repeatedly demonstrated how gender and ethnic biases can be reproduced within algorithmic systems, perpetuating systemic inequalities. This underscores the necessity of addressing biases at the foundational stage of development, as highlighted by researchers who emphasize the importance of sociotechnical approaches to bias mitigation. By acknowledging the interplay between technological design and societal values, developers can create systems that not only minimize harm but also align with principles of justice and equity.

However, the absence of such considerations risks embedding discriminatory patterns into the fabric of automated decision-making, thereby entrenching disparities that are difficult to rectify once operationalized.

Unidentified biases in algorithms can have far-reaching consequences, particularly in contexts where decisions carry significant social and economic weight. The failure to recognize these biases often results in outcomes that disproportionately disadvantage marginalized groups, reinforcing cycles of exclusion and inequity. For instance, algorithms used in predictive policing or loan approvals may inadvertently prioritize certain demographics over others, leading to discriminatory practices that are difficult to trace back to their origins.

The complexity of these systems further complicates accountability, as opaque decision-making processes obscure the mechanisms through which biases are perpetuated. This opacity not only undermines public trust but also erodes the legitimacy of AI systems in the eyes of those affected. The consequences of such failures extend beyond individual harm, influencing broader societal perceptions of fairness and justice. When algorithmic decisions are perceived as arbitrary or unjust, they can fuel skepticism toward technological systems and deepen divisions within communities, particularly in contested spaces where competing values and interests are already in tension.

Transparency plays a critical role in addressing algorithmic bias and legitimacy issues by enabling scrutiny of the decision-making processes that underpin AI systems. A transparent approach allows stakeholders to examine the data, methodologies, and assumptions that shape algorithmic outputs, fostering accountability and facilitating the identification of embedded biases. The sociotechnical approach to bias mitigation (Frontiers in Artificial Intelligence) underscores the importance of integrating diverse perspectives into the development lifecycle, ensuring that systems are designed with inclusivity and fairness in mind.

However, transparency alone is insufficient; it must be accompanied by mechanisms for continuous evaluation and correction. The growing recognition of AI’s influence on legitimacy, as demonstrated by empirical analyses of Government Accountability Office reports, highlights how algorithmic decisions can reshape societal values and institutional norms. This dynamic underscores the need for transparency not only as a technical requirement but as a foundational element of ethical governance in automated systems.

By making the inner workings of AI systems accessible, developers and policymakers can build trust and ensure that these technologies align with the public interest.

The need for continual monitoring and updating of AI systems is essential to maintaining fairness in the face of evolving societal contexts and data landscapes. Algorithms are not static entities; they interact with dynamic environments where social norms, demographic shifts, and emerging challenges continuously reshape the conditions under which they operate. The reshaping of values and goals through algorithmic processes, as observed in long-term studies of governmental oversight (Technology in Society), illustrates how the legitimacy of AI systems is not predetermined but rather contingent on their ability to adapt to changing expectations.

This necessitates an ongoing commitment to auditing and refining algorithms to address newly uncovered biases or unintended consequences. Without such vigilance, systems risk becoming obsolete or increasingly disconnected from the realities they are intended to serve. The challenge lies in balancing the efficiency of automated decision-making with the imperative to remain responsive to societal needs, ensuring that intelligent systems do not become tools of entrenching inequity but rather mechanisms for fostering inclusive and equitable outcomes.

Ultimately, the interplay between bias, legitimacy, and intelligent systems demands a proactive and iterative approach to their design and deployment. The integration of AI into contested spaces requires not only technical solutions but also a reimagining of the ethical frameworks that guide their development. By prioritizing transparency, inclusivity, and adaptability, stakeholders can mitigate the risks of algorithmic harm while reinforcing the legitimacy of these systems in diverse and evolving contexts. The lessons drawn from empirical analyses of algorithmic impacts serve as a reminder that the success of intelligent systems hinges on their ability to navigate the complexities of human society without replicating its inequities. This necessitates a collective responsibility to ensure that algorithms do not merely reflect existing biases but actively contribute to a more just and equitable future.

Conclusion

The integration of intelligent systems into contested spaces has fundamentally reshaped the dynamics of power, legitimacy, and decision-making. These systems, often designed to optimize efficiency and scale, operate within environments where competing narratives, interests, and values collide. Their deployment in domains such as law enforcement, political discourse, and resource allocation has amplified both their utility and their vulnerabilities. The opacity of algorithmic processes, combined with the complexity of data inputs, creates a landscape where bias can emerge not only from flawed design but also from the historical and social contexts embedded within datasets.

This duality, where intelligent systems are simultaneously tools of governance and potential sources of inequity, underscores the necessity of scrutinizing their role in shaping contested outcomes. The challenge lies in reconciling the promise of technologically driven solutions with the ethical imperative to ensure fairness, transparency, and accountability. Without deliberate intervention, the risks of algorithmic bias can entrench existing power imbalances, marginalize vulnerable populations, and erode public trust in institutions.

Thus, the legitimacy of these systems in contested spaces hinges not on their technical capabilities alone but on their capacity to align with principles of justice (Journal of Human Development and Capabilities) and equity.

The manifestations of algorithmic bias in contested spaces reveal a spectrum of consequences that extend beyond mere technical errors. When biased data or flawed assumptions underpin decision-making processes, the outcomes can disproportionately affect marginalized groups, reinforcing systemic inequities under the guise of objectivity. For instance, predictive policing algorithms trained on historical crime data may perpetuate over-policing in already over-policed communities, while automated hiring tools might systematically disadvantage candidates from certain demographic backgrounds.

These examples illustrate how algorithmic bias is not an abstract concept but a tangible force that shapes real-world power dynamics. The entanglement of bias with institutional authority further complicates its impact, as decisions made by these systems are often perceived as neutral, despite their embedded prejudices. This paradox, where algorithms are trusted to mediate disputes yet may exacerbate them, highlights the need for a critical examination of the values and priorities that inform their design.

The stakes are particularly high in contested spaces, where the stakes of decision-making are not just procedural but deeply political, affecting access to justice, representation, and social cohesion.

Looking ahead, the implications of algorithmic bias in contested spaces demand a reimagining of how technology is developed, deployed, and governed. The growing reliance on intelligent systems necessitates a shift from passive acceptance of their outputs to active engagement with their underlying mechanisms. This requires fostering interdisciplinary collaboration between technologists, policymakers, and ethicists to address the complex interplay between bias, legitimacy, and power.

It also calls for the establishment of robust frameworks that prioritize transparency, audibility, and participatory oversight, ensuring that affected communities have a voice in shaping the systems that impact their lives. However, the path forward is fraught with open questions: How can we balance innovation with accountability without stifling progress? What role should public institutions play in regulating algorithmic decision-making?

And how can we cultivate a culture of critical literacy around technology to empower individuals to challenge unjust outcomes? These questions underscore the urgency of addressing algorithmic bias not as an isolated technical problem but as a multifaceted challenge that demands sustained attention, ethical vigilance, and collective responsibility. The future of contested spaces will depend on our ability to navigate these tensions and reimagine the role of intelligent systems as tools for justice rather than instruments of division.

Sources

Tandfonline. Available at: https://www.tandfonline.com/doi/full/10.1080/19452829.2025.2518313 [Accessed: 23 July 2026].
Sciencedirect. Available at: https://www.sciencedirect.com/science/article/pii/S0160791X26000539 [Accessed: 23 July 2026].
Uottawa. Available at: https://www.uottawa.ca/recherche-innovation/toutes-nouvelles/rethinking-algorithmic-bias-problem-evidence-policy [Accessed: 23 July 2026].
Frontiersin. Available at: https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1562095/full [Accessed: 23 July 2026].
Springer. Available at: https://link.springer.com/article/10.1007/s00146-025-02312-y [Accessed: 23 July 2026].

This article was originally published on the TechEthics website. Read the original here. You can also explore our disinformation detection and analysis tools, Veritas.

Mastering the Two Pointers Technique in Python (With Easy Examples)

Tue, 04 Aug 2026 17:55:59 +0000

Mastering the Two Pointers Technique in Python (With Easy Examples)

Tags: Python • Programming • DSA • Algorithms

Author: Annet A

When I first started solving coding problems, I noticed that many array and string questions looked different but could actually be solved using the same approach: Two Pointers.

Instead of using nested loops and checking every possible pair of elements, the two pointers technique allows us to solve many problems efficiently in O(n) time.

In this blog, I'll explain what the Two Pointers technique is, when to use it, and some common patterns with examples.

What is the Two Pointers Technique?

The Two Pointers technique uses two indices (pointers) that move through a data structure such as an array or string.

Instead of processing one element at a time, we use two positions that move based on certain conditions until we reach the desired result.

This often reduces the time complexity from O(n²) to O(n).

When Should You Use Two Pointers?

The technique is useful when working with:

✅ Sorted arrays
✅ Strings
✅ Palindromes
✅ Removing duplicates
✅ Pair sum problems
✅ Reversing arrays
✅ Sliding window variations

Whenever you see words like:

Pair
Sorted
Remove duplicates
Reverse
Palindrome

think about whether the Two Pointers approach can simplify the solution.

Types of Two Pointer Patterns

There are several common patterns.

1. Opposite Direction Pointers

One pointer starts from the beginning and the other starts from the end.

Left                          Right
 ↓                              ↓

[1, 2, 3, 4, 5]

The pointers move toward each other.

Common Problems

Valid Palindrome
Two Sum II
Reverse String
Container With Most Water

Example

s = list("hello")

left = 0
right = len(s) - 1

while left < right:
    s[left], s[right] = s[right], s[left]
    left += 1
    right -= 1

print("".join(s))

Output

olleh

Time Complexity: O(n)

Space Complexity: O(1)

2. Same Direction Pointers (Fast and Slow)

Both pointers move from left to right.

The fast pointer explores every element while the slow pointer keeps track of the correct position.

Slow   Fast
 ↓      ↓

[1, 1, 2, 2, 3]

Common Problems

Remove Duplicates from Sorted Array
Move Zeroes
Remove Element

Example

nums = [1, 1, 2, 2, 3]

left = 0

for right in range(1, len(nums)):
    if nums[left] != nums[right]:
        left += 1
        nums[left] = nums[right]

print(nums[:left + 1])

Output

[1, 2, 3]

Time Complexity: O(n)

Space Complexity: O(1)

3. Slow and Fast Pointer

This is another variation where one pointer moves slower than the other.

Usually,

slow += 1
fast += 2

Common Problems

Detect Cycle in Linked List
Find Middle of Linked List
Happy Number

Note: This pattern is primarily used with Linked Lists rather than arrays.

Example: Two Sum II

Given a sorted array, find two numbers whose sum equals the target.

numbers = [2, 7, 11, 15]
target = 9

left = 0
right = len(numbers) - 1

while left < right:
    current = numbers[left] + numbers[right]

    if current == target:
        print(left, right)
        break
    elif current < target:
        left += 1
    else:
        right -= 1

Output

0 1

Notice how we never use nested loops.

Advantages

✅ Easy to understand
✅ Reduces time complexity
✅ Often converts O(n²) solutions into O(n)
✅ Uses constant extra space

Limitations

Works best with sorted data.
Doesn't apply to every array problem.
Choosing pointer movement correctly is important.

Tips to Identify Two Pointer Problems

Ask yourself these questions:

Is the array sorted?
Am I searching for a pair?
Can I avoid nested loops?
Can I process elements from both ends?
Can one pointer track the answer while another explores?

If the answer is Yes, the Two Pointers technique is worth considering.

Final Thoughts

The Two Pointers technique is one of the most important problem-solving patterns in Data Structures and Algorithms. Once you understand when and how to move the pointers, many coding interview problems become much easier.

I recently practiced this technique by solving problems like Remove Duplicates from Sorted Array, Merge Sorted Array, Valid Palindrome, and Two Sum II. Each problem helped me recognize different pointer movement patterns and improved my confidence in solving array and string problems efficiently.

Mastering this technique is a great step before learning more advanced patterns like Sliding Window, which builds upon similar ideas while handling subarrays and substrings.

⭐ If you found this article helpful, consider sharing it with fellow developers.

Happy Coding! 🚀

— Annet A

Loop Engineering, Not Loop Running: What Agent Loops Can Learn from Parcae

Tue, 21 Jul 2026 08:21:30 +0000

Translating Parcae's Stability Questions into an Agent-Level Control Loop

💡TL;DR — Across three fresh seeds on the same 42-fact development benchmark, an offline-informed two-sample fallback cap moved four or five facts per seed from fail to pass under our deterministic contract verifier, with zero pass-to-fail regressions on any of the three, clearing a gate we'd committed to before we ran it.

On the two seeds with direct uncapped comparisons, sampling fell 13–21% and regressions fell from one to zero, while raw repairs also fell by two on each — we don't yet know whether that repair loss is caused by the smaller cap or by benchmark variance this exact set of facts has already burned us on once before.

More importantly: fitting the stopping law exposed a survivor-conditioning bug in our own evaluator before release, one that had been quietly lying to us for a while.

1. Story

I read the Parcae paper on a night I probably should have been doing something else, and by the second pass through the stability section I had that specific, slightly dangerous feeling of this is the missing piece — a feeling I've learned to be suspicious of and ignored anyway. I went looking for whatever already existed. I checked repo after repo. None of them were it, and why they weren't takes most of the next section to explain.

The paper isn't actually where this started, and I want to be honest about that rather than let it read cleaner than it was. We'd already been circling loop discipline from a different angle — ai-slop-detector runs a bounded, mechanical self-calibration loop over static code review, deliberately not an inference loop, because at the time we didn't trust one to hold still.

Its own published limit says as much: it doesn't catch runtime bugs, a clean structural score is not proof anything actually works. That limitation sat there, honest and slightly uncomfortable, shaped exactly like the question Parcae later gave us sharper language for — what state carries forward, what counts as instability, when does another recurrence stop paying for itself.

Before anyone connected any of this to a paper about residual streams, our own refinement loop already had defects we'd caught and written down. We'd documented four:

the orchestrator instantiated a refinement object it never called, sitting dormant with nothing downstream depending on it
the loop that did run called the proposer fresh every iteration and never fed the previous best answer back in, so it wasn't refining, it was re-rolling
the evolution layer meant to learn per-domain model weights was fed hardcoded placeholder scores, learning to fit constants instead of measurements
and halting was a free-form string with no enforced vocabulary, meaning in practice it meant whatever the last person to touch that code felt like.

Parcae didn't hand us a fix for any of this. It handed us sharper questions to point at a mess we already knew we had.

Here's the actual stakes, and I want to be careful how I say it. Parcae's own introduction motivates layer-looping partly as a way to buy quality without buying more parameters, citing edge deployment and memory-constrained inference as part of why that matters — which is convenient, because that's also our stakes.

The control logic below is now sitting inside an on-device inference stack, ported over, not yet proven there. Everything measured in this piece was measured server-side, and it's what justified spending the effort to make that port at all — it is not evidence any of it survives on-device latency, memory pressure, or a battery actually draining while the loop thinks. That test is running separately, right now.

2. Why Loop Running Is Not Loop Engineering

2.1 — Same Recurrence, Different State Space

Parcae is about recurrent-depth transformers — the same block of layers, passed through repeatedly, inside training.

It has nothing to do with calling an API endpoint ten times and hoping the tenth call knows something the first didn't. Every comparison from here forward, including ours, is a structural translation to a different layer of the stack, not a claim the paper itself makes.

The generic agent loop, stripped down, is:

while not done:

 response = LLM(prompt + previous_results)

 execute_tools(response)

 done = evaluator(response)

That's a repeated-execution device, not yet a stable looping system.

Vercel Labs' ralph-loop-agent documents itself, honestly, as an outer orchestration loop around generateText; its built-in safety limits are iteration count, token budget, and cost, and the semantics of "done" are delegated entirely to a user-supplied verifyCompletion function.

That's a clean abstraction. It just doesn't, on its own, supply a convergence model.

2.2 — Repetition Is Not Convergence

Repetition does exactly one of three things: real improvement, re-expression of the same error, or amplification of it, and you don't get to pick which just because you asked for more of it.

The same model, same context, same evaluator producing the second answer means that answer is conditioned on the first one's mistake, not independent of it — a wrong assumption produces a wrong implementation, tests get written against that wrong implementation, the tests pass, the loop reports done. It converged. Just to the wrong fixed point, and nothing in the architecture noticed the difference.

Parcae observes something that rhymes with this at a completely different layer — without adequate depth sampling, late recurrences make large residual jumps and never settle into a stable fixed point, producing loss spikes.

I don't want to overstate the connection: Parcae's is a vector-state training dynamic, an agent stuck on a wrong-but-verifier-satisfying answer is an evaluation-design problem. What's shared is only the underlying question, whether recurrence reduces a measured error or just moves it around.

Most agent loops also lack authoritative state. They operate on transcripts, lossy summaries, and task artifacts that can silently disagree — the conversation says done, the file was never touched. A scheduler-theoretic position paper describes the resulting failure modes as implicit dependencies nobody wrote down, unbounded recovery loops, and a next-action policy hidden entirely inside opaque inference.

And termination limits keep getting confused with convergence conditions. Ten calls, max. A hundred thousand tokens. Five dollars. A string match on "DONE." Every one of these is a resource cutoff, not a convergence condition, which needs something like an observable progress potential — call it V, over remaining defects and verification failures — where the ideal direction is V(s_{t+1}) < V(s_t), though in a system this non-deterministic that inequality is something you approximate through measurement rather than assume. An iteration that neither improves the retained best state nor produces new admissible evidence should count against a bounded stagnation budget, not silently trigger another identical call.

2.3 — "Done" Needs Evidence, and Calling Three Agents Isn't Multi-Party Verification

omplete: result.text.includes("DONE") is the first example in Ralph's own docs. PageAI-Pro/ralph-loop does considerably more around this — tests, lint, type checking, Docker sandboxing — genuinely more rigorous.

But the terminal signal is still a promise tag the agent writes into its own output. Proof-or-Stop names this precisely, backed by a 9,240-cell ablation reporting ten of ten scenarios with zero false-DONE — worth being precise that their "proof" is operational, not semantic correctness, evidence admissible under an explicit trust model.

What still holds at a smaller scale: the agent says the tests passed is a sentence; a runner executed the suite against a known commit and produced a signed receipt can change what state the loop is in, and only one of those should.

Naming one model the coder and another the reviewer doesn't manufacture independence between them if they're close enough in family that their failure modes correlate.

A survey of fifty real loop implementations draws the line between a plain loop and a genuine external loop specification — trigger, goal, verification, stopping rule, memory — and names model-as-judge fragility and reward hacking as the risks that actually bite.

Calling three agents instead of one is multi-agent invocation, not automatically multi-party verification. This is why the better-built repos in this category, PageAI-Pro/ralph-loop included, still land, correctly, as a good harness rather than a generalized loop stability engine: none establish state-transition soundness, verifier independence, or regression-free monotonicity. "It works" and "it's stable" are different sentences.

3. What We Built

Parcae recasts a looped transformer as a non-linear time-variant dynamical system over the residual stream: h_{t+1} = Ā h_t + B̄ e + R̄(h_t, e).

Drop the non-linear term R̄ and what's left is a linear time-invariant surrogate — Ā, B̄ fixed across every step — whose stability is decided entirely by the spectral radius ρ(Ā). Parcae forces ρ(Ā) < 1 by a negative-diagonal parameterization, by construction, and separately fits a saturating test-time law, L(T) = L∞ + Z·e^(-zT).

None of that applies literally to an agent — ρ(Ā) is defined over a single vector-valued hidden state, and agent state is code, memory, tool output, environment, policy, evidence, non-stationary in ways a residual stream isn't. What carries over is the discipline: define the stability condition, the state transition, the convergence property, the saturation limit, before trusting a system to repeat itself.

3.1 — What the Control Layer ContainsThe progress-preservation row deserves the actual code, because the docstring used to overstate it:

The progress-preservation row deserves the actual code, because the docstring used to overstate it:

if not 0.0 <= carry_lambda < 1.0:
    raise ValueError(f"carry_lambda must be in 0, 1) for bounded EMA carry, got {carry_lambda}")

That guarantees the scalar ema_ds summary can't amplify its own prior value — nothing stronger. It used to say "contractive carry," which was more than the constructor actually proves; I went back and fixed it. k consecutive worsening steps still trip FORGE_DIVERGED, with the best-so-far proposal preserved rather than discarded.

The saturation row is worth being careful about, because it's easy to blur two different things:

@property

def usable(self) -> bool:
    # If global fit error is at least as large as the model's maximum
    # possible gain, the fitted curve has no practically resolvable
    # improvement signal at this scale.
    return self.fit_error < abs(self.amplitude)

Offline, we ran this against stored trajectories to derive a fixed configuration change — that's 3.2 below. At runtime, refine() can also accept a fitted decay curve and stop sampling a live trajectory early, or route a saturated domain to a different model — both built, both unit-tested, neither active in the confirmatory run below. What that run tested is a static, offline-informed cap, not live adaptive stopping.

3.2 — What the Experiment Actually Showed

Re-running the stored, uncapped three-seed benchmark passes through the new saturation-fit machinery, offline, surfaced a real bug — worth its own section (3.3), because it's the actual finding of this piece. The resulting fit — floor at 2.94, negative amplitude, negative predicted gains — still passed the usable check above. A fit can clear its own resolvability gate and be structurally wrong at the same time.

Fixing the collector brought the fitted floor to 0.481, closely tracking the observed unresolved-at-horizon share of 59/126 = 0.468 — forty-two facts, three seeds, unresolved meaning it didn't converge inside the tested sample budget, not that it never will.

That same offline pass showed every observed full-context-fallback repair, across all three stored seeds, resolving within the fallback's first two samples. That's what informed capping the fallback at two samples instead of five — a static configuration change, decided once, offline.

We pre-registered a confirmatory gate for that capped configuration — committed before running anything — and reran it on three fresh seeds, live, against a real model. "Repaired" means a fact that failed the pre-loop contract check and passed after; "regressed" means the reverse.

All three capped seeds cleared the pre-registered bar on its own terms — that gate never required beating the uncapped run, and it passed cleanly.

The paired comparison against uncapped, on the two seeds run under both, is messier. Samples dropped 21.1% and 12.8%. Regressions dropped from one to zero on both. But raw repair count also dropped, from six to four on seed 17 and from seven to five on seed 27, so net repair fell by one on each paired seed — +5 → +4, +6 → +5 — rather than improving.

With only four to seven repair events per run, a swing this size sits inside the same self-consistency variance this benchmark has already burned us on once before, in an earlier round where the whole premise of "does this loop help at all" briefly fell apart because reruns weren't reproducing each other.

I don't know, right now, whether the smaller cap cost one real repair per seed or whether it's noise. I could write a sentence that resolves that cleanly and I'm choosing not to.

3.3 — Where the Parcae Analogy Breaks, and What the Break Taught Us

Two problems showed up here that Parcae has no reason to ever run into. Both trace back to the same mistake — assuming things true inside a recurrent transformer are automatically true one layer up.

An LTI system can take a time-varying input without ceasing to be LTI — the mere fact that input changes over time doesn't by itself break anything, and I want to be precise here since I got this wrong in an earlier pass at this piece.

What actually happens in our loop is more specific than that: a short-view-to-full-view switch also moves what the verifier checks against and how much sampling budget remains, not just which text gets read. It's an intervention between two operating regimes, not one more recurrence continuing under an unchanged process — closer to a regime-switching process, two different operating dynamics wearing the same variable name.

Our first implementation fit one cumulative decay curve across both phases anyway, and once the regime changes, the assumption that every sample belongs to one stationary gain process stops being justified. We rewired the collection to fit curves per domain:view instead.

The second problem embarrasses me more, because it's obvious in hindsight and genuinely wasn't while I was staring at plausible-looking numbers. Parcae fits its saturation law to loss measured at every recurrence depth — the value exists at every T. Our outcome doesn't work that way: consensus is absorbing. Once a fact resolves, its unresolved indicator is known, with certainty, to be zero at every later iteration — not missing information, information we had and failed to use.

The first collector dropped resolved trajectories out of later averages instead of carrying that known zero forward, which isn't classical right-censoring — that description applies to runs that hit the sample budget without ever resolving, where the future is genuinely unknown.

Dropping already-resolved runs is a narrower mistake, closer to survivor conditioning. It quietly swapped the quantity being estimated: we wanted the population-level unresolved curve, U(t) = P(unresolved at iteration t), every trajectory counted at every t — instead, by dropping the resolved ones, the average increasingly conditioned itself on the shrinking pool of stubborn survivors, a different and more pessimistic quantity.

Neither was a failure on Parcae's part. Its recurrent block doesn't switch retrieval regimes mid-pass, and its loss observations don't disappear on an absorbing success. Both failures were entirely in our translation layer. That, more than any number above, is the actual result here.

Importing the functional form was a couple of afternoons. Finding which background assumptions quietly stopped holding, and rebuilding the collection and fitting boundaries around that instead of the equation as written, was the work.

4. Limitations and Roadmap

The 42 facts underneath everything above got iterated against for weeks before these fresh-seed runs, so this is seed-held-out evidence, not task-held-out — the next real gate is new facts, not new seeds on the same forty-two.

The live run tested a static cap, not the adaptive saturation control described above; the runtime decay-fit stopping and cross-domain escalation both exist in code with unit tests and neither has been switched on live yet. The carry/divergence mechanism is proven against synthetic fixtures, not a live multi-arm ablation that could isolate which piece is earning which part of the result.

The paired repair-count drop is still unresolved. The saturation gate rejects fits whose maximum modeled gain is no larger than their global fit error; it does not yet compare against a null baseline or report parameter uncertainty. And everything measured sits inside one fact-repair benchmark, one small model family — whether any of it holds on-device is the test running right now, separately.

Conclusion

I don't think we solved agent-loop stability, and I'd rather say that directly than let the numbers above imply it by accident. What actually exists is a bounded carry and divergence controller checked so far only against synthetic failure; a saturation-fit machinery that, used offline, informed a smaller, cheaper sampling configuration for the repair loop later ported into an on-device stack, and that, used live, hasn't been turned on; and an escalation path that's never run outside a test fixture.

Building and dogfooding that machinery surfaced a real measurement defect in our own evaluator before it shipped, turned several previously diagnosed defects into explicit named controls, and — on the one configuration change the offline analysis actually informed — cut sampling cost on both seeds with direct paired comparisons and drove regressions to zero across all three capped seeds, at the cost of fewer raw repairs on the two paired seeds, a cost I'm reporting rather than rounding down because it's inconvenient.

That's the shape of loop engineering instead of loop running: not a system claiming to be stable, but one built to make it possible to find out precisely where it isn't — and one instance of it finding exactly that, inside its own evaluator, before anyone downstream had to. What Parcae is worth here was never a proof that transfers across two different kinds of system. It's a discipline that transfers, if you redo the work instead of copying the equation.

Whether this set of controls survives task-held-out facts, another model family, live adaptive stopping actually switched on, and a real on-device runtime isn't settled by anything above. That's the next gate, and I genuinely don't know yet what it says.

References

Prairie, H., Novack, Z., Berg-Kirkpatrick, T., & Fu, D. Y. (2026). Parcae: Scaling Laws For Stable Looped Language Models. arXiv:2604.12946. https://arxiv.org/abs/2604.12946
Huang, J., Hsia, J., Sun, J., Shi, F., Huang, W., & White, I. H. (2026). Proof-or-Stop. arXiv:2607.14890. https://arxiv.org/abs/2607.14890
Wei, H. (2026). From Agent Loops to Structured Graphs. arXiv:2604.11378. https://arxiv.org/abs/2604.11378
Macedo, S. (2026). Stop Hand-Holding Your Coding Agent. arXiv:2607.00038. https://arxiv.org/abs/2607.00038
Vercel Labs. ralph-loop-agent. https://github.com/vercel-labs/ralph-loop-agent
PageAI-Pro. ralph-loop. https://github.com/PageAI-Pro/ralph-loop
Flamehaven. (2026). AI-SLOP Detector v3.5.0 and the Self-Calibration Loop. https://flamehaven.space/writing/it-gets-smarter-every-scan-ai-slop-detector-v350-and-the-self-calibration-loop/
Flamehaven-LEDA repository. https://github.com/flamehaven01/LEDA-Engine

Two Sum in C# Explained Like You're Just Getting Started

Mon, 06 Jul 2026 19:24:40 +0000

The Two Sum problem sounds complicated, but it's actually very simple.

Imagine you have a list of numbers:

int[] numbers = { 2, 7, 11, 15 };

And someone asks you:

"Can you find two numbers that add up to 9?"

Looking at the list, you can see that:

2 + 7 = 9

So the answer is the first two numbers in the array.

The Code

public static (int, int) TwoSum(int[] arr, int target) 
{
     var seen = new Dictionary<int, int>();

     for (int i = 0; i < arr.Length; i++) { 
           int need = target - arr[i];

          if (seen.TryGetValue(need, out int index)) { 
                  return (index, i); 
               } 
               seen[arr[i]] = i;
     }
    return (-1, -1);

}

Let's Break It Down

Step 1: Create a Dictionary

var seen = new Dictionary<int, int>();

Think of a dictionary as a notebook.

Every time we see a number, we write it down together with its position in the array.

This lets us quickly check whether we've seen a number before.

Step 2: Look at Every Number

for (int i = 0; i < arr.Length; i++)

We go through the array one number at a time.

Step 3: Figure Out What's Missing
int need = target - arr[i];

Suppose our target is 9.

If the current number is 2, we ask:

"What number do I need to reach 9?"

9 - 2 = 7

So now we're looking for 7.

Step 4: Have We Already Seen It?
if (seen.TryGetValue(need, out int index))

We check our notebook.

If 7 is already there, we've found our pair!

We return both positions

Step 5: If Not, Save the Current Number
seen[arr[i]] = i;

If we didn't find the missing number, we simply remember the current number for later.

Then we move on to the next one.

Example

Array:

[2, 7, 11, 15]

Target:

9
First number: 2

Need:

9 - 2 = 7

Have we seen 7?

No.

Store:

2 → index 0

Second number: 7

Need:

9 - 7 = 2

Have we seen 2?
Yes!

We stored it earlier.

Return: (0, 1)

Done!

Why Is This Fast?

A beginner might try this:

Compare the first number with every other number.
Then compare the second number with every other number.
Then the third...

This works, but it repeats a lot of work.

Our solution is smarter.

Instead of searching over and over, we simply remember the numbers we've already seen.

It's like meeting people at a party. Instead of asking everyone their name every time, you remember the names as you meet them. The next time you see someone, you recognize them immediately.

Complexity
Time: O(n) — we only go through the array once.
Space: O(n) — we store the numbers we've seen in a dictionary.
Final Thoughts

The trick to solving the Two Sum problem isn't doing more work—it's remembering what you've already seen.

That's why a Dictionary is the perfect tool for the job. It lets us check for numbers almost instantly, making the algorithm both simple and efficient.

Algorithmic Audits: Inside Meta's Real-Time NLP Caption Checks & The "Link Exit" Penalty

Thu, 18 Jun 2026 05:39:15 +0000

For developers, SaaS builders, and indie hackers, shipping a great product is only half the battle. The other half is distribution. But if you are still relying on traditional social sharing pipelines to drive traffic to your repositories or landing pages, a major architectural shift on Meta’s platforms is quietly crushing your organic reach.

Meta has recently automated its zero-tolerance policy for link-stuffing and hashtag spam, introducing real-time Natural Language Processing (NLP) auditing at the edge.
If you have noticed a sudden decline in your organic page or profile distribution, here is a technical breakdown of what is happening under the hood and how to engineer your way around it.

The Tech: Real-Time NLP Caption Auditing

Historically, social media algorithms crawled posts for metadata—specifically relying on hashtag matching—to determine topical relevancy. In 2026, that architecture has fundamentally changed:
Context Over Tags: Meta's AI models now read captions semantically, much like a human editor. It scans the actual words, sentence structures, and semantic context of your text the millisecond you hit publish.

The "Link Exit" Penalty: Meta’s engineering roadmap is heavily focused on keeping users inside their ecosystem to maximize ad exposure and watch-time metrics. When the NLP engine catches an outbound URL inside your main caption, it immediately flags the post as a "Link Exit" risk and dynamically restricts its organic reach.

The 7-Day Rolling Restriction: Triggering this penalty doesn't just hurt one post. It places your account into an automated, rolling 7-day restriction window, severely limiting your entire page's distribution until your publishing habits are audited as "clean."

The Solution: The "Comment-Loop" Architecture

To maintain organic traffic pipelines without triggering the Link Exit penalty, technical founders must transition to a decoupled distribution pattern:

Write Clean, Native Captions: Treat your caption purely as an educational micro-blog. Write high-value, semantic sentences optimized for NLP parsing, and keep it completely free of outbound links.
Decouple Your Links: Place your primary destination URL exclusively in the first comment of your post. This removes the link from the audited caption container entirely.

Optimize Your Hashtags: The era of the 30-hashtag block is over. Limit your posts to 0 to 3 hashtags max, and format them strictly in CamelCase (e.g., #SocialSEO, #B2BMarketing) to satisfy Meta's W3C accessibility ranking factors.

I have published a complete architectural analysis and step-by-step implementation guide covering how this update works and how to protect your organic reach:
👉 Read the Full Social SEO Playbook on SEOSiri

I'd love to hear from other developers and SaaS founders here:

Are any of you running automated post-deployment pipelines to your social channels? If so, how are you modifying your webhooks or API requests to handle first-comment link placement and dynamic DM triggers? Let's discuss!

Smart multifacet filters in JS using Bitmaps

Wed, 10 Jun 2026 09:18:41 +0000

Introduction

Modern frontend applications are starting to look less like simple view layers and more like small databases running directly in the browser.

Think about an e-commerce catalog, an analytics dashboard, or an admin panel. In all of these cases, the UI isn’t just rendering data—it’s constantly slicing it, recombining it, and reacting to user input in real time. Filtering becomes one of the most common operations, and the most natural way to express it in JavaScript is still the familiar chain of Array.filter() calls:

const filtered = products  
 .filter(p => p.category === selectedCategory)  
 .filter(p => p.inStock)  
 .filter(p => p.price < maxPrice);

It reads well and does exactly what you expect: take a list, narrow it down step by step. For small datasets, there’s nothing wrong with this approach. The problem starts when the data grows or when filtering becomes part of a tight interaction loop—every checkbox toggle, every slider movement, every keystroke.

The point is that filters are rarely applied once: they are run over and over again, often across tens or hundreds of thousands of items, and each step in that chain quietly walks the entire array again.

This is not a new problem on the backend: databases ran into it decades ago and solved it with a different mental model by replacing scanning records with precomputed indexes, turning the filtering into fast set operations. One of the most effective techniques they use is bitmap indexing, where filters become simple bitwise combinations rather than repeated object traversal.

In this article, we’ll bring that idea into JavaScript and see what happens when you treat your frontend data layer a bit more like a database engine. You can find the fully working code on the GitHub repository. The interactive example on the repository contains a time comparison of traditional array filtering and the techniques described here.

The core idea behind bitmap indexes

Bitmap indexes work by precomputing binary representations for attributes.

Imagine this dataset:

Product	Red	Blue	Size M	In Stock	Description
P1	1	0	1	1	P1 is Red, Size M and in stock
P2	0	1	1	0	P2 is Blue, Size M and is not in stock
P3	1	0	0	1	P3 is Red, and is in stock
P4	1	0	1	0	P4 is Red, Size M and is not in stock

Each attribute becomes a bitmap:

red      = 1000  
blue     = 0100  
sizeM    = 0010  
inStock  = 0001

Filtering becomes a bitwise operation:

red AND sizeM AND inStock

1000  
0010  
0001  
----  
1011

Only the first product matches all filters.

Instead of repeatedly scanning arrays, we combine compact binary structures using highly optimized CPU operations.

This is one of the reasons bitmap indexes are widely used in analytical databases and search engines.

Example of use

Generating a realistic dataset

The demo starts by constructing a synthetic—but stable—product catalog. Instead of hardcoding data or relying on an API, the implementation uses a seeded pseudo-random generator to ensure reproducibility across page loads:

let _seed = 42;

function rng() {  
 _seed = (_seed * 9301 + 49297) % 233280;  
 return _seed / 233280;  
}

This small detail matters more than it seems. Because the dataset is deterministic, performance comparisons between runs are consistent—something you don’t get with Math.random().

The dataset itself is built via Array.from, producing 10,000 products (you can vary this by modifying the PRODUCT_COUNT constant) with attributes like color, size, inStock, and price:

const products = Array.from({ length: PRODUCT\_COUNT }, (\_, i) \=\> ({  
 id:      i,  
 name:    `${pick(ADJS)} ${pick(NOUNS)}`,  
 color:   pick(COLORS),  
 size:    pick(SIZES),  
 inStock: rng() > 0.38,  
 price:   Math.floor(rng() * 90) + 9,  
}));

Each product is intentionally simple and categorical. That’s not a limitation—it’s exactly what makes this dataset ideal for bitmap indexing. Faceted search systems (like e-commerce filters) are dominated by discrete attributes, and this structure mirrors that reality.

From `Array.filter` to bitmap filtering

At a glance, the traditional approach uses chained Array.filter calls:

let arr = products;  
if (colors.length > 0) arr = arr.filter(p => colors.includes(p.color));  
if (sizes.length > 0) arr = arr.filter(p => sizes.includes(p.size));  
if (inStockOnly) arr = arr.filter(p => p.inStock);

This is intuitive and expressive: each filter step narrows down the dataset. But under the hood, it repeatedly scans the array—O(n) per filter—leading to cumulative cost as filters stack.

The bitmap approach flips the perspective entirely. Instead of filtering objects, it filters indices using precomputed bitsets.

First, we build indexes:

const idx = {  
 color: Object.fromEntries(COLORS.map(c => [c, new FastBitSet()])),  
 size: Object.fromEntries(SIZES.map(s => [s, new FastBitSet()])),  
 inStock: new FastBitSet(),  
};

products.forEach((p, i) => {  
 idx.color[p.color].add(i);  
 idx.size[p.size].add(i);  
 if (p.inStock) idx.inStock.add(i);  
});

Each bitset represents a subset of product indices. For example:

idx.color.red → all indices of red products
idx.size.M → all medium-sized products
idx.inStock → all available products

This transforms filtering into set algebra.

The core logic starts from a “universe” of all indices and then refines it by applying intersection and union operations:

let result = universe.clone();

Then applies constraints using bitwise operations. In the following code, we map the logical “or” operator by using the .union operation:

const colorSet = new FastBitSet();  
colors.forEach(c => colorSet.union(idx.color[c]));

This corresponds to:

color = red OR blue OR green

In the same way multiple selections within the same facet are merged via union, we map the logical “and” operator by using the .intersection operation:

result.intersection(colorSet);

This corresponds to:

(color condition) AND (size condition) AND (stock condition)

Each additional filter reduces the result set via intersection.

Putting it together:

if (sizes.length \> 0\) {  
 const sizeSet = new FastBitSet();  
 sizes.forEach(s => sizeSet.union(idx.size[s]));  
 result.intersection(sizeSet);  
}

if (inStockOnly) {  
 result.intersection(idx.inStock);  
}

Conceptually, this translates the array pipeline:

products  
 .filter(color condition)  
 .filter(size condition)  
 .filter(stock condition)

into:

universe  
 ∩ (color.red ∪ color.blue)  
 ∩ (size.M ∪ size.L)  
 ∩ inStock

The key shift is that instead of iterating over objects repeatedly (this happens with the filter function on arrays), we manipulate compact bitmaps where each operation is vectorized and CPU-efficient.

Finally, the matching indices are materialized:

const matchedIds = result.array();

and mapped back to actual product objects only at the end:

matchedIds.map(i => products[i])

This last operation maps the remaining matchedIds to the products to update the UI, and that is another subtle but important optimization by pushing back this operation just on the final set of matched identifiers.

Production considerations

In production, bitmap-based filtering is typically implemented as an index-first strategy: instead of repeatedly scanning objects, you precompute compact index structures and combine them efficiently at query time. On the server, this pattern is often handled by specialized libraries or search engines—using structures like compressed bitmaps (e.g., RoaringBitmap) that allow fast unions and intersections at scale, even across millions of records. On the client, the same idea can be applied to moderate in-memory datasets to deliver instant, zero-latency filtering for common facets, while delegating heavier or high-cardinality queries back to the backend. The main tradeoffs to manage are index maintenance (keeping bitmaps in sync with data updates) and memory usage, but when filters are frequent and latency matters, this approach provides a significant and predictable performance advantage.

Conclusion

Bitmap indexes are a good example of how ideas traditionally associated with database engines are increasingly relevant in frontend engineering.

Instead of repeatedly scanning arrays of objects, we can transform filtering operations into compact bitwise computations that scale much more efficiently as datasets grow.

For small applications, standard filtering techniques are usually simpler and perfectly sufficient. But for large client-side datasets, analytics dashboards, faceted search interfaces, and local-first applications, bitmap indexes can dramatically improve responsiveness while keeping implementation complexity relatively manageable.

Modern frontend applications increasingly resemble miniature data systems running directly in the browser. Techniques like bitmap indexing show that many optimizations once reserved for databases can now directly improve frontend user experiences as well.

I Solved 80 Tree Problems Before Binary Tree Recursion Clicked

Tue, 26 May 2026 16:09:31 +0000

I'd solved around 80 tree problems by the time my second on site interview wrapped up. Most were mediums. Preorder, inorder, postorder, level order felt like second nature. Tree height and BST validation, written from scratch, half a dozen times each. But the medium I'd just bombed had a stateful postorder shape I didn't see in the moment, and 20 of the 35 minutes went to patching the wrong recursion.

On the train home I traced the solution by hand. It clicked in 90 seconds. The problem wasn't tree knowledge. What was missing was the skill of predicting how a recursive function would flow through the call stack, frame by frame, before writing any code.

What changed for me

Mental simulation of the call stack is a separate skill from knowing traversal types.

The six tree patterns split cleanly along one axis: which direction information flows.

Stateful postorder problems look right at every node and wrong overall when you confuse the return value with the answer.

BST validation looks structurally fine and is logically broken when you check only direct children.

Practicing tree problems without simulating the call stack is what kept me stuck for months.

Where the recursion kept breaking

The approach had been treating tree problems the same way you'd treat array problems. Read the statement, sketch one small example, write code, test against the example, debug. On arrays that loop works fine because the traversal is linear and the bugs show up immediately. On trees the loop fails silently. The recursion executes, the values look plausible at every node, the test case passes on a small input, and a deeper tree from the interview question produces the wrong answer.

The symptom looked like a knowledge problem, so for a while the response was reading. Reread the postorder explanation. Try more medium problems. Next interview, freeze on something with the same shape. The reading wasn't the gap. The simulation skill was.

The fix turned out to be simpler than expected. Before writing any code for a tree problem, ask one question: which direction does information have to flow to get the answer? Down through parameters? Up through return values? Sideways with a queue?

That single question puts you into the right pattern category before you've written a line of code. It also forces you to predict what's going to happen on the call stack before running anything.

What I started doing differently

The protocol ran something like this. It was deliberately slower than the old read-and-code habit, and it was the part that closed the gap.

Read the problem. Sketch a small concrete tree on paper. Not the example from the problem statement, a tree you make up.
Ask the direction question. Does the answer for a node depend on what's above it, what's below it, or what's beside it?
Pick a pattern. Down means preorder. Up means postorder. Sideways means level order. Stateful versions of each split off by whether a global accumulator is involved.
Write one sentence describing what f(node) returns. If you can't write the sentence, you've misidentified the pattern.
Walk through the call stack on the sketched tree. Predict the order of recursive calls. Predict what each call returns. Note where global state changes if any.
Only then start coding.

The whole protocol took 5 minutes the first few times. It saved 20 in debugging. After running it on 30 problems, the first five steps collapsed into about 60 seconds of thinking before any code got written.

What that looked like on diameter

The first problem I ran this protocol on was tree diameter. The diameter of a binary tree is the longest path between any two nodes, measured in edges.

Sketch a small tree. Root with a left subtree of depth 2 and a right subtree of depth 3.

Direction question: does the diameter at the root depend on what's above it (impossible, it's the root), what's below it (yes, the depths of the subtrees), or sideways (no)?

Information flows up. Postorder.

Sentence describing what f(node) returns: the height of the subtree rooted at node. The diameter accumulates globally.

That last detail is where stateful postorder lives. The return value is the local thing the parent needs (subtree height). The actual answer is a global thing updated at each node (the maximum of left_height + right_height seen anywhere in the tree).

def diameter(root):
    longest = 0

    def height(node):
        nonlocal longest
        if not node:
            return 0
        left = height(node.left)
        right = height(node.right)
        longest = max(longest, left + right)
        return 1 + max(left, right)

    height(root)
    return longest

Walking the call stack:

height(left_child) runs first. Recurses down to the leaves, returns heights from the bottom up. At each node, updates longest with left + right.
height(right_child) runs next. Same behavior on the right subtree.
height(root) runs last. Gets left subtree's height (2) and right subtree's height (3). Updates longest with 2 + 3 = 5. Returns 1 + max(2, 3) = 4 (which is the tree's total height, not the answer).

The diameter is longest = 5. The return value of the top call is 4 (the height) and it isn't the answer. That separation between return value and answer is the entire pattern.

Earlier attempts at diameter kept trying to make the return value carry the answer directly. It doesn't work, because the diameter at a node combines information from two siblings, not from a single root-to-leaf path. The global accumulator is what handles that combination.

Why this works

The mechanism isn't deep, once you see it. Tree recursion is two recursive calls per node. The call stack pushes the parent frame, pushes the left child's call chain, pops back to the parent, pushes the right child's call chain, pops back to the parent. Two branches per frame.

What makes tree problems feel hard is that you have to predict this branching in your head before writing code. Once you can predict it, the choice between preorder, postorder, and level order falls out of the prediction itself. Down means the answer accumulates on the way down. Up means it accumulates on the way back. Sideways means the call stack is the wrong tool entirely and you should use a queue.

The maximum path sum lesson on Codeintuition was the one where this pattern finally became obvious to me, because it's stateful postorder with a meaner set of edge cases (negative values, single node paths, paths that pass through the root rather than ending at it). Watching the call stack trace through that problem frame by frame was what made the structure click for everything after it.

What I'd tell someone in the same spot

If you've solved 50+ tree problems and still freeze on unfamiliar ones, the gap is almost always the simulation skill, not the knowledge. More problems won't close it.

The shortest practice that helped me: take a tree problem you've solved before. Cover the solution. Sketch a small tree. Predict the order of recursive calls and what each call returns. Open the solution in a debugger and step through. Note where your prediction diverged from what actually happened.

Three rounds of that and the call stack stops feeling abstract. Five rounds and you can read a new tree problem, decide direction in 30 seconds, and start coding from a correct mental model.

Worth doing on every pattern category at least once. Stateless preorder. Stateless postorder. Stateful postorder. Root to leaf path. The BST inorder pattern. Level order with a queue. Once each of those patterns has a call stack trace burned into your head, the rest of the variants are small adaptations.

There's a longer version on my own blog that walks through the four BST-only patterns and the heap variants in more depth.

What's a tree problem that finally made the call stack visible to you in your head, where reading the textbook explanation hadn't? For me it was diameter. The protocol I built around it is what made every subsequent stateful postorder problem feel mechanical.

What 40 Binary Tree Problems Didn't Teach Me Before My FAANG Interview

Mon, 25 May 2026 12:09:46 +0000

The tree round on my first onsite was Root to Leaf Paths. Enumerate every root-to-leaf path in a binary tree. Looked easy. The recursion took about four minutes to write. Running it on the sample input came back with a list where every path ended at the leaf of the last branch the function had visited. The earlier paths had been contaminated. The interviewer watched the screen for two full minutes before the cause clicked: the shared list parameter never got cleaned up between recursive calls. That technique had shown up in practice twice before, but the conditions for when it was required had never internalised. What was missing was the framing that root-to-leaf problems are a class with their own boundary handling, separate from the other recursive tree patterns.

What changed afterwards:

Tree problems aren't a single skill. They are six distinct mechanisms (preorder, postorder, root to leaf, level order, LCA, simultaneous traversal), each with its own boundary cases.

Fifteen problems chosen by pattern coverage beat forty random problems sorted by acceptance rate.

The single biggest mistake on root-to-leaf problems is forgetting to backtrack the shared accumulator after each recursive call.

Practice in pattern order, not difficulty order. Each pattern's mechanism transfers to its variants but not to other patterns.

Where the tree prep was breaking

The grinding approach is what most onlines recommend. Open LeetCode's tree tag. Sort by acceptance rate or popularity. Work through the top forty. After about a week the easy ones feel reflexive, after two weeks the mediums start landing more often than not, and by week three the assumption is that tree rounds will be fine.

That assumption broke on the Root to Leaf Paths bug. The problem wasn't hard. It was a class of problem that had been practiced before. What was missing was the recognition that root-to-leaf is its own pattern with its own boundary behaviour, distinct from the postorder problems on the list and distinct from the preorder problems that felt most confident. Forty problems sat behind that interview, and there was no grouping that would have made the root-to-leaf class visible as a class.

The deeper diagnosis was this. What was missing wasn't more problems. It was the grouping that would let problem 1 in a class prepare a candidate for problem 2 in the same class. Forty problems organised by popularity give no transfer. Two problems per pattern, organised by mechanism, give coverage of every interview-grade tree question that's likely to show up.

What started working differently

The rebuild happened pattern by pattern. Each session, pick one of the six patterns. Work through the direct application first (the problem that teaches the mechanism cleanly). Then work through one variant (the problem that proves the mechanism transferred). Two problems per pattern, no more. If the mechanism hadn't clicked after problem two, the answer wasn't to add a third problem in the same pattern. The answer was to go back to problem one and trace it on paper until the mechanism became obvious from the structure of the recursion.

The change in approach looked like this:

Before (grinding random problems)	After (two per pattern, in pattern order)
Sort LeetCode tree tag by frequency, do top 40	Pick six patterns, do two problems each, in pattern dependency order
Treat each problem as a separate puzzle to solve	Treat each problem as an instance of one of six known mechanisms
Practice difficulty order (easy, then medium, then hard)	Practice pattern order, with the direct application before each variant
Recognise solutions you've already seen	Recognise which pattern a new problem needs, then derive the solution
Freeze on root-to-leaf backtracking under pressure	Walk into root-to-leaf knowing the path parameter is shared and needs cleanup

The key was that the six patterns gave the practice a vocabulary. Preorder. Postorder. Root to leaf. Level order. Lowest common ancestor. Simultaneous traversal. Every binary tree problem that came up, the first question became "which of the six is this?" That single question reorganised everything. Problems that previously felt random started feeling like instances of techniques already met.

What that looked like on the next problem

Three weeks into the rebuild, a friend ran a mock interview and the prompt was Root to Leaf Paths. The exact problem that had broken the onsite.

The framing was different this time. Root to leaf problems share a single accumulator (the path list) across all recursive branches. That sharing is what makes them fast (no per-call allocation), and it is what creates the bug if the accumulator doesn't get cleaned up after each child returns. Recognise the pattern first, write the recursion with the cleanup built in.

def root_to_leaf_paths(root):
    paths = []

    def walk(node, current):
        if node is None:
            return
        current.append(node.value)
        if node.left is None and node.right is None:
            paths.append(list(current))
        else:
            walk(node.left, current)
            walk(node.right, current)
        current.pop()

    walk(root, [])
    return paths

Two things to notice in the code. First, current is a single list that gets passed down through every recursive call. There's no copy at each call, which is what makes the algorithm O(n) plus the cost of producing the output. Second, the current.pop() at the end of walk is the cleanup. After the recursion returns from a child, the appended value gets removed so the sibling subtree sees the path as it was when the parent called it. Without that line, the bug from the original onsite shows up.

The mechanism transfers to the variant. Equal paths asks whether any root-to-leaf path sums to a target. Same skeleton (descend, accumulate, check at leaf, backtrack), different terminal check. Once root to leaf paths is solid, equal paths is a five-minute extension. The root to leaf paths lesson walks the backtracking explicitly, which is the part that gets glossed over in most textbook reading.

Why this works (pattern based practice)

The reason pattern grouping holds up under interview pressure has a name in learning science: near transfer versus far transfer. Practicing forty random problems builds a lot of near transfer skill (the ability to handle problems that look like the ones already practiced) and almost no far transfer (the ability to reliably handle a new problem with a slightly different surface).

Practicing two problems per pattern, in pattern order, inverts that ratio. The first problem teaches the mechanism. The second forces a variation that confirms the mechanism transferred, not the surface form. Past two problems per pattern, the marginal value drops fast, because the third is rehearsing the same mechanism with diminishing returns.

The six patterns also explain why difficulty order is the wrong sequencing. A medium postorder problem can be easier than a hard preorder problem, if postorder is already understood and preorder hadn't been met yet. Difficulty is a function of "has this mechanism been seen before?" not a function of the problem's intrinsic complexity. Pattern order respects that dependency. Postorder builds on preorder's recursive structure. Root to leaf reuses postorder's return mechanism plus the backtracking subtlety. Level order is a paradigm shift to a queue-based approach. LCA introduces multi node reasoning. Simultaneous traversal scales LCA's reasoning to two trees.

What I'd tell someone starting tree prep

If you're three weeks into tree practice and tree rounds still feel random, the shift to make is to stop grinding and start grouping.

A protocol that worked for the rebuild:

Before each session, name the pattern you'll practice (preorder, postorder, root to leaf, level order, LCA, or simultaneous traversal). Pick one. Don't mix patterns within a session.
Solve the direct application first (the problem that teaches the mechanism cleanly). For postorder, that's height of binary tree. For root to leaf, that's root to leaf paths. For LCA, that's the canonical lowest common ancestor problem.
Trace the solution on paper after writing it. If you can't narrate why each step preserves the mechanism, the mechanism hasn't clicked. Go back to the recursion and walk it variable by variable.
Solve the variant second. Diameter after height. Equal paths after root to leaf paths. Distance between nodes after LCA. If the variant feels like a fresh problem instead of an extension, the first problem hadn't internalised.
Move to the next pattern only after the current pattern's variant feels like a five-minute job. The transfer signal is "the pattern got recognised first, then the solution wrote itself," not "it took careful work to get there."

The protocol slowed things down at first. Two problems per session felt like less practice than four problems per session. The payoff was that the slower practice transferred. When the next mock interview surfaced a tree problem that hadn't been seen, the pattern recognition kicked in first and the recursion followed. That sequence was what was missing from the original forty-problem grind.

The grouping is what got built into Codeintuition's tree course, because watching engineers grind through forty problems with no transfer was the failure mode that kept showing up across every prep cohort. Pattern-first practice changed how trees felt to walk into, and the course now teaches the same restructure that made the difference.

Originally posted on my own blog, with the full fifteen-problem list grouped by pattern and a recursion-bug catalogue.

What's a tree problem that finally made a pattern click for you, where the textbook explanation hadn't?

What I Wish I'd Known About Binary Search Trees Before Interviews

Mon, 25 May 2026 09:11:56 +0000

Three months of practicing binary search trees on paper. Search procedure memorised. Insertion procedure memorised. Three deletion cases memorised. Then came the onsite. The interviewer drew a tree on the whiteboard, asked for an insertion walkthrough, and the recall worked fine. Then she asked for a deletion of a node with two children, and the freeze lasted almost a full minute before the inorder successor steps came out without any real understanding of why they preserved the ordering. She let the explanation finish, then asked one followup: why does the inorder successor specifically work? There was no answer beyond "because the textbook says so." That was the moment the gap became obvious. The months spent memorising procedures had skipped the part the interview was actually testing.

What changed afterwards:

BST search, insert, and delete are not three procedures. They are the same recursive walk with three different terminal conditions.

The two child deletion case is the one interviewers probe because it is the only case where the invariant has to be explained out loud.

Memorising the inorder successor trick doesn't transfer. Being able to say why the inorder successor specifically works does.

Once the invariant becomes the unit of memory, every operation that preserves it becomes derivable on the spot.

Where the approach was breaking

What had been getting practiced wasn't the data structure. It was a list of procedures the invariant could have handed over for free.

The recall pattern looked like this. Open a BST problem. Recognise it as a BST problem. Try to recall the right procedure for whatever the question asked. Search? Walk down comparing target to current. Insert? Same walk, create a leaf at the bottom. Delete? Three cases, pick the matching one, run the steps. The recall worked fine for problems that matched the textbook exactly. It fell apart the moment the problem deviated, because there was no deeper rule available to derive a new procedure from.

The specific failure on that first interview was treating the two child deletion case as a separate procedure rather than a question about the invariant. The procedure said "find the inorder successor, copy its value, delete the original successor." Those steps executed fine. What didn't execute was the reason behind them, which was the actual signal the interviewer was checking.

The gap is small in concept and load bearing in practice. If you can recite the steps but can't explain why each one preserves the rule, you will lose the thread whenever the interview adds a constraint that doesn't appear in the textbook version. And interviews almost always add a constraint.

What started working differently

After that interview, the practice rebuild was small in shape and large in effect. Instead of "memorise the procedure, then run it," the new approach was "start from the invariant, then derive what has to happen to preserve it." Same problems, same operations, completely different relationship to the material.

The contrast looked like this:

Before (procedure first)	After (invariant first)
Memorise search as a walk down comparing values	Start from `left < node < right` and derive the walk as the consequence
Memorise insert as "find null pointer, create leaf"	Notice that insert is the same walk, only the terminal action changes
Memorise three deletion cases	Ask "what value can sit in this slot without breaking the invariant?"
Recall the inorder successor as a step	Derive the inorder successor as the answer to the slot question
Stall on novel problems	Answer novel problems by reasoning forward from the rule

The shift was to remember fewer things, more carefully. There is exactly one rule for a BST: every node's left subtree contains only smaller values, every right subtree contains only larger values. Every operation either preserves the rule or is incorrect. That framing made the procedures fall out naturally, because the question "what do I do here?" reduced to "what action keeps the rule intact?"

What that looked like on the next problem

A month later came a phone screen at a different company. The interviewer gave a tree with [8, 3, 10, 1, 6, 14] and asked for a search for 6 and then an insertion of 7.

Search started at the root. 6 < 8, so go left to 3. Then 6 > 3, so go right to 6. Found it.

def search(node, target):
    if node is None or node.value == target:
        return node
    if target < node.value:
        return search(node.left, target)
    return search(node.right, target)

Then inserting 7 was the same walk. From the root, 7 < 8, go left. Then 7 > 3, go right to 6. Then 7 > 6, go right again. Right pointer is null. Create node 7 there.

def insert(node, value):
    if node is None:
        return Node(value)
    if value < node.value:
        node.left = insert(node.left, value)
    elif value > node.value:
        node.right = insert(node.right, value)
    return node

What was different this time was the framing said out loud after the code finished. Search and insert are the same recursive walk. Search stops when the value matches or the pointer is null. Insert stops at a null pointer and writes a new leaf there. The walk is what the invariant requires. The terminal action is the only thing that changes between operations. The interviewer asked a few more questions and then moved on. The framing was the part that mattered, not the code.

The same shift made deletion easier too. Instead of three cases, the new mental model was one question: what value can sit in this slot without breaking left < node < right? For a leaf, the answer is no value. Drop the pointer. For a one child node, the answer is the child's value, because the child's subtree already satisfies the invariant against the parent. For a two child node, the answer is the smallest value larger than the deleted node (the inorder successor), which is what the slot requires after deletion. Three procedures collapsed into three answers to the same question.

Why this works (the invariant doing the heavy lifting)

The reason the invariant first framing holds up under interview pressure has a name in learning science: near transfer versus far transfer. Memorising a procedure builds a near transfer skill. The procedure applies to problems that look exactly like the one that got practiced. It doesn't apply to problems that look slightly different, because the procedure is tied to the specific form of the original.

Deriving a procedure from a rule builds a far transfer skill. The rule applies to any problem that respects the rule, regardless of how the form changes. The rule is what generalises. The procedure is what gets generated for the specific case.

BSTs make this concrete because there is exactly one rule and there are dozens of variant problems that ask you to apply it. BST validation. Conversion to sorted array. Conversion to sorted doubly linked list. Range queries. Kth smallest element. Lowest common ancestor in a BST. BST iterator. All derivable from "left subtree smaller, right subtree larger." None easy to memorise as individual procedures, because there are too many of them and they shade into each other.

The inorder successor lesson walks the two child deletion case from the invariant down, which is the framing that most first practice resources skip. The procedure becomes the easy part once the question is framed as "what value belongs in this slot?"

What I'd tell someone in the same spot

If your BST practice is at the point where the procedures feel memorised but the mock interviews aren't going well, the shift to make is to stop quizzing yourself on the steps and start quizzing yourself on the rule.

A practice protocol that worked for the rebuild:

Before solving any BST problem, write the invariant at the top of the page. left < node < right for every node, applied recursively to every subtree. Look at it for ten seconds.
Read the problem and ask: what action does the invariant require here? Not "what procedure do I run." What does the rule say has to happen.
Trace one example by hand on paper, narrating each step as "this preserves the rule because..." If that sentence won't finish, what's running is a memorised procedure, not a derivation from the rule.
Code it up. If the code falls out naturally from the narration, you have it. If a procedure shows up that you can't justify, stop and go back to step 2.

The protocol slows things down at first. Adding a thirty second pause to write the invariant and narrate the reasoning feels expensive under time pressure. The payoff is that the slow practice transfers. When the interview adds a constraint, the procedure that would have been recalled is wrong, but the rule still applies and the new procedure derives in real time.

That gap, between solving a BST problem and recognising why an operation works, is the thing that pushed me to build Codeintuition. Watching engineers grind through hundreds of tree problems without the invariant first framing was the pattern that wouldn't stop showing up. The tree courses now lead with the rule and let the procedures fall out, which is the ordering that would have saved months on the first attempt.

Originally posted on my own blog, a slightly longer version with the inorder traversal proof and the balanced construction algorithm.

What is a data structure that started making sense for you only after you stopped memorising the operations and started re-deriving them from the rule?

Big O Notation: What I Wish I'd Known Before My First Interview

Sat, 23 May 2026 11:29:05 +0000

The Big O table was memorised before the first onsite. Binary search logarithmic, merge sort linearithmic, hash insert constant amortised. All recitable. Then a senior engineer wrote a recursive function on the whiteboard, asked for an analysis, and almost a minute went by trying to match what was on the board to something on the cached table. The function was a naive recursive Fibonacci, seen before, implemented before. The freeze still happened, because nothing about the table told anyone how to count the recursive calls.

What I figured out afterwards

The table is the answer, not the method. Memorising it never builds the ability to derive complexity from code you haven't seen.
The thing the table hides is the counting. How many times the dominant operation runs as a function of input size.
Once four or five derivations have been traced by hand, the shape generalises. Unfamiliar code stops feeling opaque.
Space complexity has the same derivation shape, plus the call stack that's easy to forget.
The drill that actually builds the skill is deriving complexity on problems whose answer you don't already know.

Where the approach was breaking

The Fibonacci moment exposed the gap. The function had been seen. The function had been implemented. What hadn't happened was counting what the recursion actually does.

def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

The interviewer was patient. "How many calls does fib(5) make?" The whiteboard got a tree. fib(5) calls fib(4) and fib(3). fib(4) calls fib(3) and fib(2). fib(3) shows up twice. fib(2) shows up three times. The tree grew faster than the page it was being drawn on. The answer wasn't in cached memory because no one had asked for the count before. The answer is O(2ⁿ), roughly, and the reason is that each call branches into two and the depth is about n.

Big O had been treated as a label to attach after solving. The interview was treating it as a derivation to perform on unfamiliar code. Those are different skills, and the wrong one had been practiced.

What started working differently

The fix wasn't reading more articles. It was changing the drill. The new prompt was "given this code you haven't seen before, what's the complexity, and how would you justify it" instead of "what's the complexity of merge sort." Once the prompt changed, the way unfamiliar code reads changed with it.

Here's the shape that worked, side by side with the old habit:

Then	Now
Match the code to a memorised complexity.	Identify the dominant operation, the one that runs most.
Look up the answer when the match wasn't obvious.	Count how many times that operation runs, as a function of `n`.
Move on once a label was attached.	Sum the work across levels (loops, recursion depth, branching factor).
Forget about space until reminded.	Track space the same way: auxiliary memory plus the call stack.

The change is a habit, not a piece of knowledge. The Big O table doesn't get more correct over time. The way unfamiliar code gets read does.

What that looked like on the next problem

A few weeks after the Fibonacci interview, the same function came back out for re-derivation from scratch. No looking up the answer. Just the dominant operation and counting.

The dominant operation in fib(n) is the recursive call. fib(n) calls fib(n-1) and fib(n-2). Treat both as roughly fib(n-1) for the upper bound. So the call count T(n) ≈ 2 × T(n-1). That recurrence solves to T(n) = 2ⁿ. The depth of the tree is about n. The branching factor is 2. Total work is roughly the number of nodes in a binary tree of depth n, which is 2ⁿ.

That's why naive Fibonacci is unusably slow even at moderate n. fib(40) makes more than a billion calls.

Adding memoisation changes the shape entirely:

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n < 2:
        return n
    memo[n] = fib(n - 1, memo) + fib(n - 2, memo)
    return memo[n]

Now each subproblem fib(k) for k from 0 to n is computed exactly once. There are n distinct subproblems. Each one does constant work after its two subcalls return. Total: O(n) time, O(n) space from the memo plus the call stack.

The complexity went from O(2ⁿ) to O(n) because the structure of the work changed, and the derivation made that visible in a way the table never did. (For the longer walkthrough of how memoisation becomes the gateway to dynamic programming, the DP interview blog covers the recurrence-to-table-to-bottom-up progression.)

Why this works (the science behind it)

The learning science term for the swapped drill is elaborative interrogation. Asking yourself why each operation contributes the work it does, rather than accepting the labelled answer at face value. The literature on it is consistent: forcing yourself to construct the reason produces a more durable, more transferable understanding than reading the reason already constructed.

The other piece is near transfer versus far transfer. The old drill was near transfer practice (the same complexity question on the same code already memorised). The interview was a far transfer test (different code, same skill). Near transfer practice doesn't reliably move far transfer scores. Once that lands, the right drill picks itself: derive complexity on code you haven't seen.

What to tell someone in the same spot

Three things, in the order they mattered.

Stop quizzing yourself on named algorithms. "What's the complexity of merge sort" trains memory, not derivation. Quiz yourself on an unfamiliar function instead, and force yourself to count the dominant operation explicitly. If you have to count it out loud, that's the right intensity.
Trace at least one recursive call tree by hand per week. The first few feel slow. The fifth or sixth is where the shape generalises. Branching factor times depth gives nodes, nodes times work-per-node gives total work. The arithmetic is the same on every problem.
Track space the same way you track time. Auxiliary memory plus call-stack frames. Most engineers in interviews get time right and space wrong, and the difference is purely habit.

Before this shift, a solution would read as that looks fast and the analysis would stop there. After, the same solution reads as O(n log n) because the divide step and the merge step can be pointed at independently. Adding a hash map to a nested loop visibly drops the complexity from quadratic to linear, with the derivation right there in the code. Unfamiliar code becomes analysable because the analysis is something you do, not something you recall.

Originally posted on my own blog, with the amortised analysis derivation for hash-map resize and the space-complexity traps skipped over in this retrospective.

What's a piece of complexity analysis that finally clicked for you only after deriving it by hand, where the textbook label had never really stuck?

BFS vs DFS? The Question That Fixed My Graph Solutions

Fri, 22 May 2026 20:01:47 +0000

For a long time I treated BFS and DFS as interchangeable. Two ways to visit every node, pick whichever came to mind first. Then an interview handed me a grid that wanted the minimum number of steps, and a recursive DFS felt faster to type, so that's what went down. The path that came back was valid and far too long. No error. Just an answer that passed the small cases and fell apart on the one that mattered, with no obvious reason why.

What finally clicked:

The two traversals hold different invariants. They don't just visit in a different order.
The queue gives BFS its shortest path guarantee. The stack makes DFS commit to one branch.
"Minimum" in an unweighted graph turns out to be a reliable signal for BFS.
"Detect", "order", and "all paths" point to DFS.
Once edges carry weights, neither applies, and Dijkstra's algorithm takes over.

Where my approach was breaking

The mistake wasn't picking the slower traversal. It was reaching for whichever traversal got practiced most recently instead of reading what the problem actually asked for.

A grid that wants the fewest steps is asking for a distance guarantee, and DFS doesn't offer one. It happily commits to a branch and walks 30 cells deep before it would ever consider the 8 cell route, then stops the moment it touches the goal, satisfied with a path that happens to be valid. The wrong choice there has nothing to do with DFS being worse. It comes from never asking what kind of answer the problem needed.

The one question that changed it

Before writing any code now, the question is always the same: does this problem need a distance guarantee or a structural property? If the answer is distance, that's BFS. If it's structure, meaning cycles, ordering, or which nodes connect to which, that's DFS.

It sounds almost too simple, and that's the point. The decision was never about which algorithm you can implement faster. It's about which guarantee the problem is quietly demanding.

What that looked like on the same six node graph

The clearest way to feel the difference is to run both on one small graph and watch the order. Take six nodes with edges 0→1, 0→2, 1→3, 1→4, 2→4, 2→5, starting from node 0.

from collections import deque

graph = {0: [1, 2], 1: [3, 4], 2: [4, 5], 3: [], 4: [], 5: []}

def bfs(start):
    order, seen, q = [], {start}, deque([start])
    while q:
        node = q.popleft()
        order.append(node)
        for nxt in graph[node]:
            if nxt not in seen:
                seen.add(nxt)
                q.append(nxt)
    return order

def dfs(start):
    order, seen, stack = [], set(), [start]
    while stack:
        node = stack.pop()
        if node in seen:
            continue
        seen.add(node)
        order.append(node)
        for nxt in reversed(graph[node]):
            if nxt not in seen:
                stack.append(nxt)
    return order

print(bfs(0))  # [0, 1, 2, 3, 4, 5]
print(dfs(0))  # [0, 1, 3, 4, 2, 5]

BFS visits in exact distance order: everything one hop from the source (1, 2) before anything two hops away (3, 4, 5). DFS visits 3 before it ever gets back to 2, even though 3 sits further from the source. It cares about depth, not distance. Swapping the queue for a stack is the only structural change between the two functions, and it produces the entire difference in behaviour.

Why this works (the part that took digging)

A queue is first in, first out, so the nodes you discover at distance d always come out behind the remaining d-1 nodes and ahead of the d+1 ones. That ordering is the shortest path guarantee, with no explicit distance tracking needed. A stack is last in, first out, so the most recent branch always gets expanded next, which is depth first by construction.

There's a memory split that follows from the same fact. BFS holds the full frontier, so its peak memory tracks the widest level of the graph. DFS holds only the current path, so its memory tracks the deepest one. Tracing both algorithms frame by frame in the graph course, watching the queue and stack contents change at every step, is what makes the distance ordering stop feeling abstract.

What to do when you're still guessing

If you're staring at a graph problem and reaching for habit, run it through this instead:

If the problem asks for	Reach for
Shortest path or fewest moves, equal cost edges	BFS
Level by level processing	BFS
Nearest target	BFS
Cycle detection	DFS
Topological order	DFS
Connected components	DFS
All paths or backtracking	DFS
Shortest path with weighted edges	Neither, use Dijkstra

I originally posted this on my own blog, a slightly longer version with a directed cycle detection walkthrough.

What's a graph problem that finally made the BFS versus DFS choice click for you, the one where guessing wrong actually cost you in an interview?

Sorting Wars: Benchmarking Selection, Insertion, Gnome e Bubble Sort em 5 Linguagens

Fri, 22 May 2026 14:58:16 +0000

Algoritmos quadráticos são lentos — isso todo mundo sabe. Mas o quão lentos? E a linguagem escolhida importa mais do que o algoritmo em si? Foi exatamente isso que nossa turma de Algoritmos e Estruturas de Dados I do CEFET-MG decidiu testar empiricamente.

Implementamos Selection Sort, Insertion Sort, Gnome Sort e Bubble Sort em C, C++, Rust, JavaScript e Python, rodamos benchmarks com até 1 milhão de elementos e coletamos os dados. Esse post resume o que encontramos — incluindo alguns resultados que nos surpreenderam bastante.

Por que estudar algoritmos O(n²) em 2025?

Antes de mergulhar nos números, vale responder a pergunta óbvia. Três razões principais:

Didática — a lógica é direta, ideal para aprender análise de complexidade e invariantes de laço.
Entradas pequenas — para N ≤ ~50, o overhead reduzido pode torná-los mais rápidos que algoritmos sofisticados.
Adaptatividade — Insertion Sort e Bubble Sort com parada antecipada chegam a O(n) em entradas quase ordenadas. É por isso que o TimSort (usado em Python e Java) usa Insertion Sort internamente para subconjuntos pequenos.

Os Algoritmos

Selection Sort — O inflexível

Seleciona o mínimo do subarray não ordenado e o move para a posição correta com uma única troca.

PARA i DE 0 ATE N - 2 FACA
  MIN_IDX <- i
  PARA j DE i + 1 ATE N - 1 FACA
    SE VETOR[j] < VETOR[MIN_IDX] ENTAO
      MIN_IDX <- j
  SE MIN_IDX != i ENTAO
    TROCA VETOR[i] COM VETOR[MIN_IDX]

Característica marcante: sempre realiza exatamente n(n-1)/2 comparações, independente da entrada. Não existe melhor caso em comparações — é Θ(n²) em todos os cenários.

Caso	Comparações	Complexidade
Melhor (ordenado)	n(n−1)/2	O(n²)
Médio (aleatório)	n(n−1)/2	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ❌ Não estável · ❌ Não adaptativo

Insertion Sort — O adaptativo

Mantém um subarray ordenado à esquerda e insere cada novo elemento na posição correta via shifting.

PARA i DE 1 ATE N - 1 FACA
  CHAVE <- VETOR[i]
  j <- i - 1
  ENQUANTO j >= 0 E VETOR[j] > CHAVE FACA
    VETOR[j + 1] <- VETOR[j]
    j <- j - 1
  VETOR[j + 1] <- CHAVE

Em entradas já ordenadas, o laço interno nunca executa: complexidade O(n) no melhor caso. Isso ficou claro nos nossos dados — até 10⁶ elementos, o cenário crescente terminou em microssegundos.

Caso	Comparações	Complexidade
Melhor (ordenado)	n − 1	O(n)
Médio (aleatório)	n(n−1)/4	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ✅ Estável · ✅ Adaptativo

Gnome Sort — O excêntrico

Opera como um "gnomo organizando vasos": avança comparando adjacentes, e ao encontrar desordem, troca e recua uma posição.

INDICE <- 0
ENQUANTO INDICE < N FACA
  SE INDICE = 0 OU VETOR[INDICE] >= VETOR[INDICE - 1] ENTAO
    INDICE <- INDICE + 1
  SENAO
    TROCA VETOR[INDICE] COM VETOR[INDICE - 1]
    INDICE <- INDICE - 1

Funcionalmente equivalente a um Insertion Sort por trocas — mas com movimento local em vez de shifting. Também adaptativo: O(n) no melhor caso.

Caso	Comparações	Complexidade
Melhor (ordenado)	n − 1	O(n)
Médio (aleatório)	(A DEPENDER)	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ✅ Estável · ✅ Adaptativo

Bubble Sort — O clássico (com parada antecipada)

Realiza passagens comparando pares adjacentes. A variável swapped permite encerramento antecipado quando o vetor já está ordenado.

PARA i DE 0 ATE N - 1 FACA
  SWAPPED <- FALSO
  PARA j DE 0 ATE N - i - 2 FACA
    SE VETOR[j] > VETOR[j + 1] ENTAO
      TROCA VETOR[j] COM VETOR[j+1]
      SWAPPED <- VERDADEIRO
  SE SWAPPED = FALSO ENTAO
    RETORNE  // Encerramento antecipado

Caso	Comparações	Complexidade
Melhor (ordenado)	n − 1	O(n)
Médio (aleatório)	n(n−1)/4	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ✅ Estável · ✅ Adaptativo (com parada antecipada)

Metodologia

Tamanhos de entrada: N ∈ { 10², 10³, 10⁴, 10⁵, 10⁶ }
Cenários: crescente (melhor caso), aleatório (caso médio), decrescente (pior caso)
Repetições: 5 execuções; média das 3 centrais (descartando menor e maior)
Otimizações testadas: -O0 e -O3 para C/C++/Rust
Medição: apenas tempo de ordenação (I/O descartado)

Cada linguagem usou sua estrutura de dados nativa:

Linguagem	Estrutura	Tipo
C	`double[]` com `malloc`	`double` 64-bit
C++	`std::vector<double>`	`double` 64-bit
Rust	`Vec<f64>`	`f64` 64-bit
JavaScript	`Array` (V8 float64)	`Number`
Python	`list` (refs a PyObject)	`float`

Resultados — Selection Sort

O Selection Sort foi o mais previsível: tempos quase idênticos nos três cenários, confirmando a não-adaptatividade.

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	2.0500	3.5188	1.9618
C++ (-O3)	2.1247	3.5188	1.9089
Rust (-O3)	2.3265	4.2560	2.1320
JavaScript (V8)	3.5835	6.6564	3.5851
Python	93.164	164.890	98.378

Python para N = 10⁶ foi descartado — tempo estimado superior a 10 horas.

Hierarquia: C -O3 ≈ C++ -O3 < Rust < JavaScript ≪ Python

Resultados — Insertion Sort

Aqui a adaptatividade brilhou. No cenário crescente com N = 10⁶, todas as linguagens terminaram em menos de 12 ms. Já no cenário decrescente, o pior caso quadrático foi brutal:

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	0.000055	0.615683	1.188966
C++ (-O3)	0.0000634	0.587483	1.183000
Rust (-O3)	0.000079	0.897895	1.774292
JavaScript (V8)	0.000809	1.525250	3.033301
Python	0.005321	136.295	226.560

Para N = 10⁶ no pior caso sem otimização, C++ chegou a 3670 s (~1 hora). Com -O3, caiu para 119 s — speedup de ~30×.

Resultados — Gnome Sort

O Gnome Sort trouxe a maior surpresa da série: Rust superou C e C++ no caso médio.

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	0.000179	15.19068	28.90668
C++ (-O3)	0.000159	13.96807	28.25787
Rust (-O3)	0.000049	3.94810	8.27646
JavaScript (V8)	0.001584	13.90908	27.45163
Python	0.019030	21.28324	257.00624

Por quê? O padrão de acesso do Gnome Sort — muitos acessos locais e trocas adjacentes — se beneficia especialmente das otimizações do compilador LLVM (backend do Rust), que gera código de swap em registrador sem acesso intermediário à memória.

Resultados — Bubble Sort

O Bubble Sort entregou o resultado mais inesperado de todo o projeto:

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	0.000042	20.489569	23.568626
C++ (-O3)	0.000045	21.165759	23.919268
Rust (-O3)	0.000051	13.513529	9.231813
JavaScript (V8)	0.001753	15.012168	6.905683
Python	0.003504	312.509064	403.412438

JavaScript bateu C e C++ no pior caso. O motor V8 identificou o padrão repetitivo de trocas adjacentes e gerou código de máquina altamente especializado via JIT. É um caso raro onde a compilação dinâmica supera a compilação estática.

Principais Aprendizados

1. Otimização de compilador importa muito mais do que parece

O impacto de -O3 vs -O0 para Rust no Bubble Sort chegou a 23× para N = 10⁴. Em modo debug, o Rust mantém verificações de bounds checking em todo acesso ao array — correto para desenvolvimento, devastador para performance.

2. Adaptatividade é real e mensurável

Insertion Sort com N = 10⁶ no cenário crescente: < 1 ms. No cenário decrescente: até 3670 s (sem otimização). Isso é uma diferença de mais de 10 ordens de magnitude no número de operações.

3. Python tem overhead estrutural, não só de interpretador

A list do Python armazena referências a objetos PyObject — cada acesso e comparação envolve uma indireção de ponteiro. Isso multiplica o custo por operação mesmo para tipos simples como int e float.

4. JIT pode superar código estático em padrões repetitivos

O V8 observa o comportamento em runtime e especializa o código gerado. Para algoritmos com padrões de acesso altamente previsíveis (como Bubble Sort), isso pode ser mais eficiente que otimizações estáticas conservadoras de um compilador AOT.

5. A hierarquia não é fixa

A ordem geral foi C ≈ C++ < Rust < JS < Python, mas exceções importantes existem — Rust venceu todos no Gnome Sort, JS venceu todos no Bubble Sort em pior caso. O melhor resultado depende do algoritmo, tamanho de entrada e padrão de acesso.

Conclusão

Algoritmos simples ensinam mais do que complexidade assintótica. Ensinam sobre a relação entre padrões de acesso à memória e otimizações de compilador, sobre como compilação JIT funciona na prática, e sobre por que constantes importam tanto quanto expoentes para tamanhos reais de entrada.

Se você quiser explorar o código completo, estrutura de Makefiles, geradores de dataset e scripts de benchmark, o repositório está público no GitHub.

{% embed https://github.com/Bernardo-Lebron/simple_sort_algorithms %}

Trabalho prático da disciplina de Algoritmos e Estruturas de Dados I — CEFET-MG Campus V, Divinópolis. Orientação: Prof. Michel Pires.

Backtracking Finally Clicked When I Fixed One Habit

Thu, 21 May 2026 16:14:14 +0000

For a long stretch, backtracking was the topic I quietly dreaded. The recursion was easy enough to write. The code ran. It even returned answers. They were just wrong, and not in a way that threw an error you could chase. A Combination Sum solution would spit out duplicate-looking results with no obvious culprit line. The fix, when it came, had nothing to do with understanding recursion better. It was one habit that kept getting skipped.

Here's what changed once backtracking stopped being a clever trick and became a fixed loop.

What changed

Backtracking is a depth first walk over a state space tree, and the tree is the part worth drawing first.
The loop is always the same: choose an option, check the constraint, undo the choice on the way back up.
The undo step is the easiest to drop, and dropping it silently corrupts later branches.
Pruning before you recurse, not after you reach a leaf, is where the speed lives.
Once the same partial state repeats across branches, the whole thing becomes top down DP.

Where my backtracking kept breaking

The mistake was always the same, and naming it took embarrassingly long. You build a partial solution by mutating a shared list, recurse, then move on to the next option without ever putting the list back the way you found it. So branch two starts with branch one's leftovers still inside it.

What broke wasn't the recursion. It was that the path never got restored on the way back up.

The reason it's so hard to catch: nothing crashes. A forgotten undo doesn't raise an exception. It quietly hands stale state to the next branch, and the answers look plausible until you check them by hand. That single omission costs more debugging time than any actual algorithmic concept.

Picture it concretely on a small Combination Sum case, candidates [2, 3] and target 5. The first branch explores [2, 2, ...], overshoots, and returns. If that branch left a stray 2 in the shared list, the next branch starts from [2] when it should start from []. Now the [3, ...] branch is really exploring [2, 3, ...], and the result set fills with combinations that were never asked for. Reading the function top to bottom, every line looks reasonable. The bug only shows up when you trace the shared list across two sibling branches and notice it isn't the same length going in as coming out.

What I started doing differently

The shift was to stop writing backtracking freehand and write the same three line frame every time, then fill it in. Choose, check, undo, in that order, with the undo non negotiable. Here's the before and after, once it became a fixed habit:

Then	Now
Recursion written ad hoc, undo when remembered	Choose, check, undo written as a fixed frame first
Constraints checked at the leaf	Constraint checked before recursing, so dead branches die early
Debugged by re-reading the whole function	Trace one branch, confirm state is restored after the call
Each problem treated as new	Slot the problem into one of three known shapes

The "check before recurse" row mattered more than expected. Pruning at the leaf still gives correct answers, it's just slow, and on a tight time limit slow is the same as failing.

What that looked like on Combination Sum

Combination Sum is the problem that finally made it click for me. Given a list of candidates and a target, find every combination that sums to the target, where a number can be reused. It's a conditional enumeration problem, so you prune any branch whose running sum overshoots.

Here's the frame, filled in:

def combination_sum(candidates, target):
    result = []

    def backtrack(start, path, remaining):
        if remaining == 0:
            result.append(path[:])      # finished combination
            return
        if remaining < 0:
            return                      # overshot, prune this branch
        for i in range(start, len(candidates)):
            path.append(candidates[i])                       # choose
            backtrack(i, path, remaining - candidates[i])    # explore (reuse allowed)
            path.pop()                                       # undo

    backtrack(0, [], target)
    return result

The line that used to go missing is path.pop(). Without it, every combination after the first carries elements from the previous one. The path[:] matters too, it copies the list into the result instead of storing a reference that later pop calls would mutate out from under you. Two small lines, and they're the entire difference between a function that works and one that lies to you.

The start index is the other quiet detail. Passing i rather than i + 1 into the recursive call is what allows a number to be reused. Pass i + 1 and you've written a different problem, combinations without repetition. Same frame, one parameter changes the meaning.

Why undoing state is the whole game

With the frame in hand, the three problem shapes read as one idea seen from different angles:

Unconditional enumeration, like all subsets, has no constraint, so you walk the whole tree and every node is an answer.
Conditional enumeration, like Combination Sum or valid parentheses, prunes branches that break a rule mid build.
Backtracking search, like N-Queens or Sudoku, looks for configurations under a global constraint and prunes hardest.

All three run the same choose, check, undo loop. The undo is what lets one mutable structure stand in for every node of the tree without the nodes contaminating each other. That's the thing I ended up rebuilding my own approach around.

It also reframes how the three shapes relate. They aren't three separate algorithms to learn. They're one loop with the constraint check dialled from off (subsets) to mid build (Combination Sum) to every level (N-Queens). Seeing them as one thing meant a new problem stopped being a blank page. The question became which shape it was and what the constraint was, and the frame handled the rest.

What I'd tell someone stuck on this

If you're losing time to backtracking that returns wrong answers, the fix is almost never more practice on harder problems. Grinding ten more search problems with the same blind spot just produces ten more silently wrong solutions. The thing standing between you and reliable backtracking is usually one missing line, not a missing concept. It's two habits. First, write the undo line at the same moment you write the choose line, as a pair, before anything else in the loop. Second, trace one full branch on paper and confirm the shared state looks identical before and after the recursive call.

And if the recursion itself still feels unstable underneath all this, that's worth shoring up first, because backtracking is just recursion with the choose, check, undo wrapper on top. Going back through the recursion lessons before touching backtracking again is what makes the wrapper feel mechanical instead of magical.

I originally posted this on my own blog, a slightly longer version with the N-Queens trace and a few more worked examples.

What's a bug that taught you more than the algorithm itself? For a lot of people backtracking is the one where a missing undo quietly breaks everything.

Most Candidates Memorize Merge Intervals. Few Actually Understand It.

Thu, 21 May 2026 12:13:33 +0000

Recently while practicing interval problems, I noticed something interesting:

A lot of interview questions are actually small twists of the same underlying pattern.

Take the classic Merge Intervals problem:

intervals = [[1,3], [2,5], [6,8], [7,9]]

The first important step is almost always:

intervals.sort(key=lambda x: x[0])

Once intervals are sorted, overlap decisions become local.

Then the core logic becomes:

if start <= merged[-1][1]:

which simply means:

current interval overlaps with previous interval

and we merge them.

Final result:

[[1,5], [6,9]]

Pretty straightforward.

But interviewers often twist the same idea into a different question.

One famous variation is:

“Given meeting intervals, find the minimum number of meeting rooms required.”

Example:

[[1,10], [2,7], [3,19], [8,12]]

Now the goal is no longer merging.

Instead, while processing intervals, we need to figure out:

how many meetings are active simultaneously at any moment.

Because that directly tells us:

how many rooms are required.

At one point here:

[1,10]
[2,7]
[3,19]

are all active together.

So answer becomes:

3 rooms

That’s what makes interval problems interesting in interviews.

The pattern stays similar:

sort,
process left to right,
reason about overlaps,

but the objective changes completely.

I wrote a detailed article around this covering:

Merge Intervals intuition,
Meeting Rooms II,
sweep-line thinking,
Python templates,
and how to recognize interval patterns during interviews.

You can read detailed article here.

AVL Trees Explained: The Rotation Patterns Most People Memorise Wrong

Wed, 20 May 2026 19:57:13 +0000

The first time an interviewer asked me to walk through an LR rotation on a whiteboard, the four-case table was memorised cold. LL, RR, LR, RL. The interviewer drew three nodes, asked which case it was, and the answer came out fast. Then they asked: "predict what a single right rotation would do to that tree, and tell me why it fails." That part hadn't been drilled. The grade went out as "knows the table, didn't internalise the invariant."

What I figured out

The four rotation cases are not four things. They're two atomic moves applied once or twice.
The balance factor is the rule being protected, not a check. Every rotation is a local repair on the rule |left_height - right_height| <= 1.
Insertion needs at most one rotation. Deletion can need O(log n). That asymmetry is the answer to every "what's the tradeoff" question.
The double-rotation cases exist because a single rotation on an "inside" imbalance shifts the heavy side without reducing the depth.
Knowing the two atomic moves is enough to derive both LR and RL cases. Memorising the table on top is the wrong study target.

Where my approach was breaking

Three failure modes showed up on those rounds, and they show up in most engineers preparing for the same kind of question.

The four-case table got memorised without anyone tracing why each fix works. The table is a lookup. Interviewers test for the derivation. When a tree shows up on the board and the question is "what's the imbalance shape here," pattern matching against a remembered picture fails when the tree is rotated or relabelled.

Insertion got drilled, deletion didn't. Insertion is the cleaner operation. Almost every textbook walks insertion. Few walk deletion with the upward rebalance loop. Knowing "deletion is harder" as a phrase is not the same as knowing what concretely makes it harder.

Wrong rotations never got sketched. When an interviewer asks "what happens if you apply a single right rotation to an LR case," the answer has to come from a drawing, not a memory. Engineers who've never traced a failed rotation can't answer this on the spot.

What I started doing differently

Then	Now
Memorise LL / RR / LR / RL as four rotations	Internalise two atomic rotations and derive the four cases from balance factor signs
Practice insertion only	Practice deletion with the upward loop, including the worst-case `O(log n)` rotation chain
Treat balance factor as a check	Treat balance factor as the invariant being protected, with rotations as the local repair
Draw rotated trees from memory	Draw the pointer assignments explicitly and recompute heights before moving on
Skip wrong-rotation traces	Sketch what each wrong rotation does on an LR case, so the trap is recognisable under pressure

The "now" column is what interviewers actually probe. The "then" column is what most prep material asks you to drill.

The first rule that locks in is this. If you see a node with balance factor +2, the next look is at the left child's balance factor, not at the rotation table. If the left child is +1 or 0, single right rotate the parent. If the left child is -1, left rotate the left child first, then right rotate the parent. The decision is two questions, not a memorised table.

What that looked like on the next problem

Six months later, a different round asked for AVL insertion implementation. The sequence used to motivate the walk-through was [5, 3, 4], which fires an LR rotation. Here's the primitive:

def right_rotate(z):
    y = z.left
    T3 = y.right
    y.right = z
    z.left = T3
    z.height = 1 + max(height(z.left), height(z.right))
    y.height = 1 + max(height(y.left), height(y.right))
    return y

And the insertion function:

def insert(node, key):
    if not node:
        return Node(key)
    if key < node.key:
        node.left = insert(node.left, key)
    else:
        node.right = insert(node.right, key)

    node.height = 1 + max(height(node.left), height(node.right))
    bf = balance_factor(node)

    if bf > 1 and key < node.left.key:
        return right_rotate(node)
    if bf < -1 and key > node.right.key:
        return left_rotate(node)
    if bf > 1 and key > node.left.key:
        node.left = left_rotate(node.left)
        return right_rotate(node)
    if bf < -1 and key < node.right.key:
        node.right = right_rotate(node.right)
        return left_rotate(node)

    return node

Tracing [5, 3, 4]:

Insert 5. Single node, balance factor 0.
Insert 3. Goes left of 5. Node 5's balance factor is +1. Within the rule.
Insert 4. 4 < 5, go left. 4 > 3, go right of 3. Node 4 lands as 3's right child.

Walking back up: node 4 is balance factor 0, node 3 is -1, node 5 is +2. Rule broken at node 5, with its left child right-heavy. That's LR.

First rotation: left rotation on node 3. Node 4 moves up, node 3 becomes 4's left child. Node 5 still has balance factor +2, but its left subtree is now left-heavy. That's LL.

Second rotation: right rotation on node 5. Node 4 becomes the root, node 3 is 4's left child, node 5 is 4's right child. All balance factors back to 0. Height is 1.

The interviewer asked what a single right rotation would have done to the original tree. Sketched it out: node 3 becomes the root, node 5 is 3's right child, but node 4 ends up as 3's right child too, with node 5 displaced. The tree depth does not decrease. That's why the double rotation exists.

Why this works (the height theory behind it)

The choice of ±1 as the balance factor cap is not arbitrary. It's the tightest constraint that's still cheap to maintain locally.

An AVL tree with n nodes has height at most about 1.44 * log2(n). For a million nodes that's roughly 29 levels. A perfectly balanced tree would be 20 levels. The constant factor is small enough that you get the lookup speed of a balanced tree without paying the cost of full rebalancing on every insert.

Red-Black trees relax the constraint to allow heights up to about 2 log(n). That's roughly 40 levels for a million nodes. In exchange, at most 2 rotations per insertion or deletion. Looser balance, fewer rotations, faster writes.

When Adelson-Velsky and Landis named the AVL tree in 1962, the workload they had in mind was read-heavy. Lookups dominated. The strict balance was worth the rebalancing cost because every lookup was faster. Modern systems insert and delete more than they search-only, which is why Java's TreeMap, C++'s std::map, and Linux's CFS process scheduler all picked Red-Black instead. Different workload, different tradeoff. Neither tree is "better."

That's the answer the OS interviewer was looking for. AVL is read-optimised. Red-Black is tuned for mixed workloads. Picking between them is a workload question, not a theory question.

What I'd tell someone in the same spot

Three things to drill before either interview round:

Master the two atomic moves. Write left_rotate and right_rotate from memory, with the height updates in the right order. Three pointer reassignments, two height updates. Everything else builds on these.
Trace deletion at least three times. Pick at least one trace where the rebalance propagates two levels up. That's the answer to every "what's the tradeoff of stricter balance" question.
Sketch what a wrong rotation does on an LR case. Once you've drawn the broken tree, the LR / RL trap stops being a memory test.

Codeintuition's Binary Search Tree course is structured this way. The balance invariant comes before the rotation code, and the rotation code comes before the four-case table. Doing it in that order is what made the table feel mechanical instead of memorised.

I originally posted this on my own blog, a slightly longer version with the worked example for the original [3, 2, 1, 4, 5] insertion sequence and the AVL vs Red-Black tradeoff matrix.

What's the AVL or rotation question that finally made the rule click for you, where the textbook explanation had not?

How Diff Algorithms Work: Myers Algorithm Explained Simply

Sun, 17 May 2026 19:23:18 +0000

Introduction: The Hidden Engine Behind Code Collaboration

Every time you execute git diff or review a pull request on GitHub, a clever algorithm runs silently in the background. It calculates the exact, minimum sequence of additions and deletions needed to change your old file into your new file.

A bad diff algorithm would tell you that you deleted an entire function and rewrote it, just because you added a single space. A good algorithm, however, understands the logical way humans write code.

In this guide, we will explore the Myers Diff Algorithm—the standard tool behind Git—in plain English.

Section 1: The Core Problem - "Edit Distance"

At its heart, comparing text is about finding the "edit distance." Imagine you have two versions of a document. Your goal is to find the absolute shortest list of edits (inserting or deleting lines) that turns Version A into Version B.

If a computer simply guessed every possible combination of edits, it would take centuries to compare two large code files. We need a smarter shortcut.

Section 2: The Magic Shortcut (Longest Common Subsequence)

The best shortcut is finding what hasn't changed. This is called the Longest Common Subsequence.

If we can find the longest list of lines that exist in both files in the exact same order, then everything else is just a simple addition or deletion.

A Simple Example

Imagine two short grocery lists:

List A (Old): ["apple", "banana", "cherry", "date"]
List B (New): ["apple", "blueberry", "cherry", "elderberry"]

The longest sequence they share is: ["apple", "cherry"].

Because we know these lines match perfectly, we easily know what happened to the rest:

"banana" is only in List A -> Deleted
"blueberry" is only in List B -> Inserted
"date" is only in List A -> Deleted
"elderberry" is only in List B -> Inserted

Section 3: The Genius of the Myers Algorithm

Finding that shared sequence can still be slow. In 1986, computer scientist Eugene Myers invented a brilliant way to speed this up. Instead of comparing text line-by-line in a massive, slow table, he turned the problem into a game of finding the shortest path on a map.

The Grid Map System

Imagine a grid where:

Moving Right means adding a line from the new file.
Moving Down means deleting a line from the old file.
Moving Diagonally means keeping a matching line.

The "cost" of moving diagonally is zero—it's a free move because the lines match perfectly! The Myers algorithm simply looks for the fastest path from the top-left of the map to the bottom-right, taking as many "free" diagonal moves as possible.

Because it prioritizes these free moves, it skips doing unnecessary calculations and runs almost instantly, even on massive project files.

Section 4: Why Git Uses Myers (and When It Struggles)

The Myers algorithm is incredibly fast, which is why Git uses it by default. However, because it is purely mathematical, it doesn't understand programming languages.

Sometimes, it gets confused by closing brackets } and matches them incorrectly, creating a messy view. If you ever see a weird diff full of brackets, you can tell Git to use a slightly different approach:

git diff --diff-algorithm=patience : This forces Git to focus on unique lines (like function names) rather than common symbols (like brackets), making the output much easier for humans to read when code has been heavily moved around.

Conclusion

The efficiency of our daily code reviews relies on the elegant logic of the Myers Diff Algorithm. By turning a massive text comparison problem into a simple path-finding game, it allows developers to collaborate quickly and seamlessly without ever noticing the complex math happening behind the scenes.

FAANG Coding Interviews Aren’t the Same: The DSA Patterns Each Company Actually Tests

Tue, 12 May 2026 15:44:03 +0000

After treating every FAANG company like the same interview, Amazon exposed the gap in about twenty minutes.

I'd built FAANG prep around a small set of pattern families that looked highest-frequency: predicate search, sliding window, hash table fundamentals, and a few graph traversals.

The mental model was that these were the patterns "every big tech round" sampled from.

The first Amazon round asked about Randomised Set design followed by a Queue Design follow up.

Neither was in the deep set the plan covered.

I solved the first one with effort and improvised the second one badly.

The interview went south in the last 20 minutes.

The thing missing wasn't a specific pattern.

It was that Amazon's pattern footprint is meaningfully wider than Google's, and the prep allocation behind every hour was treating every FAANG company as if they sampled from the same bag.

Here's what came out of mapping company tags across 450+ handpicked FAANG problems:

Seven patterns are universal across 6+ major companies. Skipping any of them is a structural hole.
Amazon spans 11+ pattern families, the broadest in the data. "Study three patterns deeply" doesn't work there.
Google has narrower coverage but a distinctive emphasis on predicate search (binary search on the answer space).
Meta wants hash table depth and design fluency in a tighter pattern band.
Prefix Sum is the single most undertrained pattern relative to its 8-company tag count.

Where the old approach was breaking

The old plan looked roughly like this:

Pick five or six pattern families that look universal-ish, drill them to the point you can write the canonical solution from memory, then trust that volume on adjacent problems will generalise to whatever the interview throws.

The implicit bet was that every FAANG company is a sample from roughly the same distribution, and the mean of the drilled patterns covers the mean of the question pool.

The data didn't support the bet.

The surprising part wasn't that companies differed.

It was how much they differed.

Across the company tags:

Google's distribution skewed toward predicate search and graph reasoning. Narrower set, harder reasoning per problem.
Amazon's distribution was the flattest of any company in the set. Eleven plus pattern families, none dominant.
Meta's distribution clustered tight: sliding window, prefix sum, counting, design.
Microsoft had a quietly distinct cluster: 2D binary search and staircase search, multi-dimensional patterns most plans skip.
Apple's distribution was the inverse of Amazon's: deep on fundamentals (especially counting), almost no advanced design.

The mistake wasn't drilling the wrong patterns.

It was applying the same allocation across companies that didn't share the same allocation.

The shift that worked

The shift was small in description and large in practice.

Instead of one prep plan, the move was to build a per-company allocation, anchored to the universal patterns underneath.

Concretely:

Then	Now
Drill 5–6 patterns deeply, hope coverage generalises	Cover 7 universals first, then add 2–4 patterns specific to the target company
Pick problems by data structure (Hash Table, Tree, Graph)	Pick problems by pattern, then filter by company tag
Treat all FAANG rounds as the same problem distribution	Allocate by the company’s actual tag profile
Practise at uniform intensity across pattern families	Front load the universals, then go deep on company-specific gaps

The 7-pattern universal layer never moved:

LRU Cache
Counting
Backtracking
Prefix Sum
Binary Search
Fixed Sliding Window
Variable Sliding Window

What changed was what came after.

For an Amazon round, the next four patterns to drill were:

Randomised Set
Queue Design
2D Binary Search
Staircase Search

plus dedicated time on the Bar Raiser follow up format.

For Google, the next two patterns were:

Predicate Search
Graph reasoning

drilled deeper.

For Meta:

Design depth (LRU Cache from scratch, Randomised Set from scratch)
Maximum Predicate Search

The total prep time stayed roughly the same.

The allocation was different.

What that looked like on the next problem

The clearest example was LRU Cache.

The canonical solution had been in the toolkit for years:

hash map + doubly linked list
O(1) per operation
head and tail sentinels

What I'd never done was rebuild it under a constraint shift.

Which is exactly what the Amazon Bar Raiser round likes to test.

The setup is the standard one:

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.map = {}
        self.head = ListNode()                    # most recently used end
        self.tail = ListNode()                    # least recently used end
        self.head.next = self.tail
        self.tail.prev = self.head

    def get(self, key):
        if key not in self.map:
            return -1
        node = self.map[key]
        self._remove(node)
        self._add_to_front(node)
        return node.value

    def put(self, key, value):
        if key in self.map:
            self._remove(self.map[key])

        node = ListNode(key, value)
        self._add_to_front(node)
        self.map[key] = node

        if len(self.map) > self.capacity:
            lru = self.tail.prev
            self._remove(lru)
            del self.map[lru.key]

The constraint shift Amazon likes to ask:

“Now each entry has a TTL. A read on an expired entry returns -1. The cache still operates at expected O(1) per call.”

That's the moment the canonical answer stops being enough.

The candidate who memorised LRU starts redesigning from scratch.

The candidate who built the original from the invariant asks one question first:

Which invariant did the doubly linked list maintain, and does that invariant still hold under TTL?

The list maintained an ordering:

Nodes near head were used more recently than nodes near tail.

The eviction criterion changes from:

“Least recently used”

to:

“Expired or least recently used.”

The list ordering by recency is still useful for the second clause.

The first clause needs a different signal.

That's where lazy expiry (timestamp checked on read) and eager expiry (min heap on TTL) diverge.

The canonical LRU sits in most candidates' heads.

The constraint flip doesn't.

Once practising the follow up explicitly becomes part of the loop, on every design problem in the universal set, the conversion rate on Amazon-style rounds shifts noticeably.

The pattern that's underrated for years

Looking back at the tag data, the single biggest miscalibration in the old plan was Prefix Sum.

Eight companies tag it.

That's the same as Backtracking.

More than almost every classic searching variant except the basic one.

Most prep plans treat it like a minor utility pattern because it doesn't have a flagship problem the way LRU Cache does.

In the data, it punches above its weight:

Subarray Sum Equals K
Equilibrium Index
Count Subarrays Divisible by K

especially in Meta and Amazon variants.

The fix took less than a weekend.

Prefix Sum's mechanic is small enough that two evenings of focused drilling cover it.

The composite version (prefix sum + hash map of seen sums) is the FAANG-shaped one, and it's the one most prep plans bury under a miscellaneous heading.

What works for someone in the same spot

Three rules from the retrospective:

1. Cover the seven universals first

No exceptions.

LRU Cache
Counting
Backtracking
Prefix Sum
Binary Search
Fixed Sliding Window
Variable Sliding Window

No matter the target company.

2. Specialise second

But specialise to the company’s actual tag profile.

For Amazon:

breadth
constraint-flip follow ups

For Google:

predicate search
graph reasoning depth

For Meta:

design depth
sliding window fluency

For Microsoft:

2D + staircase search

For Apple:

fundamentals depth

3. Cut what doesn't match

Targeting Google and not Amazon?

Queue Design can wait.

Targeting Meta and not Microsoft?

Staircase Search can wait.

Prep time is finite.

The data tells you where the false-priority work lives.

The biggest shift, though, wasn't any one pattern.

“FAANG prep” isn't one allocation problem.

It's five separate ones with a shared seven-pattern foundation.

The company determines which 2–4 patterns sit on top of it.

Every hour spent assuming the foundation was all that mattered was an hour that could've gone to the layer above.

Originally posted in a longer form on my own blog, with the per-company FAQ and a fuller breakdown of what each company quietly deemphasises.

If you've interviewed at more than one FAANG, what was a pattern that came up where the company’s reputation hadn't prepared you for it?

Building a Deterministic Governance Kernel: Separating Custody from Truth

Tue, 12 May 2026 06:13:46 +0000

A governance engine should not pretend to know the truth of every domain.

That was the architectural lesson behind CGF.

At Flamehaven Labs, we build B2B governance engines for highly regulated environments. Over the past year, we developed specialized deterministic systems for different review contexts:

CareChainGovernanceEngine (CCGE): a fail-closed clinical-governance engine for enforcing safety-oriented review gates in bio-AI workflows.
The Analyst's Problem Framework (TAP): a “Proof Custody” engine designed to package and audit mathematical proof candidates.

Both worked inside their own domains. But both also exposed the same architectural problem: reusable custody mechanics were mixed with domain-specific decision semantics.

We needed to audit new targets — such as external open-source intake, RAG retrieval receipts, and AI evolution proposals. If we did not extract a common, domain-neutral kernel, we would be doomed to rewrite the entire scanning, hashing, and reporting pipeline for every new vertical.

The result was the Custody Governance Framework (CGF): a domain-neutral custody kernel for B2B technical review workflows.

This is an architecture extraction note on how we decoupled domain truth from custody mechanics, the API design that powers it, and why we specifically rejected the modern trend of “LLM-agentic” governance.

The Problem with “Agentic” Governance

Many emerging AI governance workflows are becoming document-shaped or agent-shaped: a YAML file, a Markdown policy, or an LLM prompt that says, “check whether this is safe.”

The problem is not that LLMs are useless. The problem is that they can produce compliance-shaped language without producing verifiable compliance artifacts.

In a strict B2B handoff — where auditability, legal review, and future regulatory mapping to frameworks such as the EU AI Act or NIST AI RMF may matter — you cannot rely on non-deterministic evaluations.

CGF takes the opposite approach: strict determinism.

The framework does not own domain-truth semantics. It owns the custody mechanics around findings, profiles, evidence, approvals, and artifacts.

The Architecture: A Deterministic Data Flow

To enforce this separation, we designed CGF as a deterministic pipeline with a narrow side-effect boundary.

The core engine takes a normalized review input and a GovernanceProfile, transforming them into immutable artifact dataclasses. The writer layer then materializes those objects as files, manifests, and release artifacts.

Here is what the end-to-end flow looks like:

The API Boundary

At the core boundary, the framework does not evaluate whether a finding is “bad” by its own logic.

It relies on a StatusDeriver driven by the injected profile.

A simplified sketch of the boundary looks like this:

# Simplified sketch, not the full implementation
@dataclass(slots=True)
class GovernancePipeline:
    profile: GovernanceProfile
    status_deriver: StatusDeriver

    def build_packet(self, result: ScanResult) -> GovernancePacket:
        # 1. Inject profile-specific requirements, such as mandatory surfaces
        governed_result = self._with_profile_requirements(result)

        # 2. Derive deterministic status via the profile
        status_result = self.status_deriver.derive(governed_result)

        # 3. Assemble the immutable packet
        return GovernancePacket(
            target=governed_result.target,
            profile_id=self.profile.profile_id,
            status=status_result.status,
            status_reason=status_result.reason,
            findings=list(governed_result.findings),
            evidence=list(governed_result.evidence),
            compliance_score=_compute_compliance_score(governed_result.findings),
        )

The exact implementation also handles timestamps, approval bridges, validation, artifact writing, and manifest verification.

The important point is architectural: the core does not decide domain truth. It records how a profile interpreted the evidence.

Architecture Highlight 1: Inspectable Artifacts Over Silent Mutation

A major risk in governance automation is the engine silently mutating the target repository, for example by automatically injecting compliance boilerplate.

Many tools solve this with a --dry-run flag that prints logs to stdout.

In a B2B audit, stdout logs are not enough. You need an auditable, verifiable artifact.

CGF implements a preview-first artifact flow. When the pipeline runs, it does not mutate the target repository by default. Instead, it consumes a normalized review input and emits a deterministic custody bundle:

$ cgf run --profile proof_custody.json --scan target_scan.json --out audit/

In real deployments, target_scan.json may be produced by a vertical adapter, repository scanner, RAG receipt processor, or customer-specific intake layer.

The output is an inspectable custody bundle:

audit/
├── governance_packet.json       # Machine-readable audit state
├── preview_report.md            # Human-readable summary
├── chain_ribbon.md              # Markdown tag for custody-chain review state
└── manifest.json                # Artifact manifest with file hashes

The important point is not that CGF edits the repository.

It does not.

The important point is that the review state, findings, proposed next actions, and artifact hashes become inspectable before any external system decides what to do next.

Architecture Highlight 2: The Reality of Audit Chains

In B2B handoffs, customers often ask for tamper-resistance.

CGF supports a GovernanceAuditChain, an append-only JSONL ledger where packet records can be linked through SHA-256 hashes.

But we need to be honest about the tradeoff:

Local hash chains are tamper-evident, not tamper-resistant.

If a bad actor has write access to the filesystem, they can delete the audit directory and regenerate the entire chain from scratch.

CGF does not use a blockchain. The cost and complexity of a distributed ledger would outweigh the benefits for local repository scanning.

Instead, CGF provides local tamper-evidence.

To achieve true tamper-resistance, the deployment environment still matters: CI/CD artifact signing, external timestamping, identity providers, or customer-controlled archival systems.

For example, an external identity token can be wired into an approval bridge:

# Wiring an external identity token into the local chain
bridge = ApprovalBridge(
    state="approved",
    approved_by="compliance_lead_JWT_subject",
    notes="Cryptographic signature from Identity Provider XYZ",
)

approved_packet = GovernancePipeline.apply_approval(packet, bridge)

The framework provides the cryptographic hooks and chronological integrity.

The deployment environment provides the immutability.

Current Limitations

This post is not a release announcement or a regulatory certification claim.

It is an architecture note about the extraction pattern: how we separated reusable governance mechanics from domain-specific truth semantics.

CGF is still early. It is not a compliance platform, not a hosted governance service, and not a regulatory certification product.

That distinction matters.

CGF does not prove that a medical system is safe. It does not prove that a mathematical argument is true. It does not certify legal compliance. It does not replace domain experts, auditors, clinicians, lawyers, or reviewers.

What it does is narrower, but more concrete:

It makes the custody surface inspectable.

There are also practical limitations.

As mentioned, local hash chains are tamper-evident, not tamper-resistant. True immutability still has to come from the deployment environment: CI/CD signing, external timestamping, identity providers, or customer-controlled archival systems.

CGF is also not yet a complete enterprise governance platform. Authentication, RBAC, multi-tenant profile registries, async approval workflows, and regulatory citation mapping are still roadmap items, not solved infrastructure.

Each domain still needs adapters, profiles, thresholds, and human review policies.

The kernel provides the custody mechanics. The domain owner still has to define what evidence matters.

That is intentional.

A generic governance kernel should not pretend to know the truth of every field.

Roadmap

The roadmap is not to turn CGF into a giant all-knowing compliance agent.

The roadmap is to keep the kernel small, deterministic, and inspectable while adding stronger boundaries around the places where real B2B workflows need them.

The next layers are:

Regulatory mapping: mapping finding codes to frameworks such as the EU AI Act, NIST AI RMF, and ISO/IEC 42001 without turning CGF itself into a legal authority.
Approval policy hardening: adding stronger policy checks around ApprovalBridge so approvals can be scoped, expired, and externally verified.
Async approval workflows: allowing human review, compliance sign-off, or customer approval to arrive after the initial custody packet is generated.
Profile registries: supporting versioned, tenant-scoped governance profiles so different customers can use different policies without changing the kernel.
Signed external receipts: allowing RAG systems, technology scanners, quality engines, and external tools to produce receipts that CGF can verify and attach.
Vertical adapters: binding existing domain systems back to the kernel without importing their domain-specific truth semantics into the core.

Every roadmap item has to preserve the same rule:

The kernel may govern custody, but it must not absorb domain truth.

The direction is deliberately conservative: more custody, more verification, more explicit boundaries — not more autonomous magic.

Why This Matters

A lot of AI governance today is still document-shaped.

A policy lives in Markdown. A checklist lives in YAML. A prompt says the system should be safe, transparent, aligned, compliant, or human-reviewed.

Those documents are not useless. They are often necessary.

But they are not governance by themselves.

Governance becomes real only when it has an execution surface:

a typed input boundary
normalized findings
profile-owned status derivation
explicit evidence references
generated review artifacts
manifest hashes
approval metadata
release bundles
verification commands
clear non-goals

That is the difference CGF is trying to make.

It is not another Markdown file describing how governance should work.

It is a deterministic custody pipeline that turns review inputs into inspectable artifacts.

The goal is not to make governance sound more sophisticated.

The goal is to make it harder to fake.

A governance system should leave behind more than confidence.

It should leave behind artifacts.

Conclusion

Extracting the Custody Governance Framework taught us that governance architecture has to separate process from truth.

Truth belongs to domains:

medicine
mathematics
law
security
finance
science

Process belongs to the governance kernel:

what was reviewed
which profile was applied
which findings fired
what evidence was attached
what status was derived
who approved it
whether the resulting artifacts can be verified later

That separation is the reason CGF exists.

It does not try to be an AI judge. It does not ask an LLM to guess whether a system is compliant. It does not hide governance inside a prompt, a policy document, or a YAML file.

It creates custody artifacts that can be inspected.

For us, that is the real boundary between governance as language and governance as infrastructure.

The Making of a 10x Engineer in AI Era: Why Big-O Thinking Changes Everything

Mon, 11 May 2026 17:39:53 +0000

Introduction

Some code works. Some code lasts.

The difference rarely comes down to typing speed, syntax mastery, or how many nights you're willing to push through. It comes down to how you think about a problem before you write a single line.
Exceptional engineers don't start with code. They start with understanding: visualizing the shape of the problem, weighing trade-offs, and asking how a solution will hold up when the data grows, the users multiply, or the pressure mounts.
At the center of that mindset is a tool every serious engineer learns to trust: Big-O notation.

What Big-O Actually Does ?

Big-O notation is a mathematical framework that describes how an algorithm performs as its input grows. In plain terms, it answers one question:

"How well will this solution scale?"

It strips away the noise machine specifications,compiler differences,network latency and gives you a high-level measure of efficiency. Specifically, it describes the worst-case growth rate of an operation relative to input size n.

This is what lets you compare approaches and choose the one that stays reliable as your data grows from hundreds to millions.

The Big-O Hierarchy: From Best to Worst

Below is the spectrum of common complexity classes, ordered from most to least efficient with examples.

1. O(1) — Constant Time

The gold standard. Input size is irrelevant.
Whether your dataset has 10 items or 10 million, the operation takes the same time. Build for O(1) wherever you can.

a. Accessing an Array Element by Index

arr = [10, 20, 30, 40]
value = arr[2]
print(value)

b. Inserting and Accessing a Value into a Hash Map (Dictionary)

my_dict = {"firstName":"William","age":54}
my_dict["country"]="Kenya"
#accessing
value = my_dict["firstName"]

c. Stack Operations (Push / Pop)

stack.append(10)   
stack.pop()

d. Queue Operations (Enqueue / Dequeue)

from collections import deque
q = deque()
q.append(1)     
q.popleft()

e. Checking the Length of a List

print(len(arr))

Judgement: O(1) is acceptable

2. O(log n) — Logarithmic Time

Each step dramatically shrinks the remaining problem.

Searching 1,000,000 items takes roughly 20 comparisons. That's not a typo. Logarithmic algorithms are extraordinarily efficient at scale.

Binary Search

def binary_search(arr, target):
    left, right = 0, len(arr) - 1
    while left <= right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid - 1

Judgement: O(log n) is acceptable

3. O(n) — Linear Time

Proportional growth. Double the data, double the work.

# Scanning every item once to find the maximum
def find_max(numbers):
    maximum = numbers[0]
    for num in numbers:       # visits every element exactly once
        if num > maximum:
            maximum = num
    return maximum

Judgement: O(n) is acceptable

4. O(n log n) — Linearithmic Time

The sweet spot for sorting. Far better than quadratic.
a. Merge Sort

def merge_sort(arr):
    if len(arr) <= 1:
        return arr
    mid = len(arr) // 2
    left = merge_sort(arr[:mid])  
    right = merge_sort(arr[mid:])
    return merge(left, right)

def merge(left, right):

result = []
i = j = 0
while i < len(left) and j < len(right):   
    if left[i] <= right[j]:
        result.append(left[i]); i += 1
    else:
        result.append(right[j]); j += 1
return result + left[i:] + right[j:]

print(merge_sort([38, 27, 43, 3, 9, 82, 10]))

Result : [3, 9, 10, 27, 38, 43, 82]

Python's native `sort()` runs at O(n log n). When you see a well-built sorting algorithm, you're almost certainly looking at this class.

####Judgement: O(n log n) not Badly off. 

---

### 5. O(n²) — Quadratic Time 

> *Nested loops are a red flag. Performance falls off a cliff.*

```python
def find_duplicates(arr):
    duplicates = []
    for i in range(len(arr)):              # O(n)
        for j in range(i + 1, len(arr)):   # O(n) again
            if arr[i] == arr[j]:
                duplicates.append((arr[i], arr[j]))
    return duplicates
print(find_duplicates([1, 3, 4, 2, 3, 1, 5]))
# [(1, 1), (3, 3)]

Judgement: O(n²) if you can avoid it the better.

6. O(n³) — Cubic Time

Rarely acceptable outside academic settings.

def three_sum_brute(arr):
    n = len(arr)
    triplets = []

    for i in range(n):                  
        for j in range(i + 1, n):     
            for k in range(j + 1, n):  
                if arr[i] + arr[j] + arr[k] == 0:
                    triplets.append((arr[i], arr[j], arr[k]))
    return triplets
print(three_sum_brute([-3, -1, 0, 1, 2, 3, -2]))
# [(-3, 1, 2), (-3, 0, 3), (-1, 0, 1), (-2, 0, 2), (-2, -1, 3)]
}

Judgement: O(n³) if you can avoid it the better.

7. O(2ⁿ) — Exponential Time

Each added input doubles the workload. A design smell.

# Naive recursive Fibonacci — the most famous exponential trap
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)  # Recalculates the same values endlessly

# The fix: memoisation collapses this to O(n)
from functools import lru_cache

@lru_cache(maxsize=None)
def fibonacci_fast(n):
    if n <= 1:
        return n
    return fibonacci_fast(n - 1) + fibonacci_fast(n - 2)

fibonacci(50) without memoisation makes over 2 trillion calls. The memoised version makes exactly 50. This is the power of understanding why complexity matters, not just what it is.

Judgement: O(2ⁿ) if you can avoid it the better.

8. O(n!) — Factorial Time

Computationally prohibited for almost everything.

# Brute-force Traveling Salesman Problem
from itertools import permutations

def traveling_salesman_brute(graph, start):
    cities = list(graph.keys())
    cities.remove(start)
    best = float('inf')

    for perm in permutations(cities):   # n! permutations
        route = [start] + list(perm) + [start]
        cost = sum(graph[route[i]][route[i+1]] for i in range(len(route)-1))
        best = min(best, cost)

    return best

Judgement: O(n!) avoid it.

Why This Changes How You Think

Big-O is not an academic exercise. It's a mode of thinking.

Once it becomes second nature, something shifts in how you approach problems:

You anticipate bottlenecks before they reach production
You design systems that scale rather than systems that survive
You make deliberate trade-offs between time complexity and space complexity
You read code differently — a nested loop is no longer "just syntax", it's a question mark

Most importantly, you stop asking "does this work?" and start asking "how does this behave at scale?"

Found this useful? Drop a ❤️ and follow for more pieces on engineering thinking, systems design, and the habits that separate good engineers from great ones.

What Amazon’s Bar Raiser Actually Tests in Coding Interviews

Mon, 11 May 2026 14:47:38 +0000

I thought solving the problem was the round. The last ten minutes turned out to be the part that counted.

I'd put close to four months into Amazon prep by the time my onsite landed. Two coding rounds went fine. The third started fine too.

I solved the initial problem in about twenty minutes, walked through the test cases, and felt the round was already mostly won.

Then the interviewer asked one follow up.

The constraint they changed was small, the kind of thing I'd have called "minor" if I'd been describing it on paper.

It exposed that I'd been preparing for the wrong half of the round, and I spent the next ten minutes recovering ground I should never have lost.

That round was a Bar Raiser round.

I didn't know it at the time (Amazon doesn't tell you), but the debrief came back with the kind of feedback only the Bar Raiser writes:

"Strong initial solution, struggled to adapt under constraint change, did not demonstrate the structural reasoning we look for."

The phrasing is almost word for word from how Bar Raisers grade.

The follow up after the working solution is the round.

What I figured out

The Bar Raiser is one of the four or five interviewers on the loop, but you won't know which one. Treat every round as if it's them.
Amazon's pattern coverage is wider than Google's or Meta's, so going deep on three families isn't enough.
The grade often lives in the last ten minutes after your first working solution, not in the first solution itself.
Adapting after a constraint flip is a specific skill that grinding more problems doesn't build.
The fix is interleaved practice plus an explicit constraint flip rep on every problem.

Where my approach was breaking

My prep model was the standard FAANG one.

Pick the two or three pattern families that show up most for the company. Go deep on those. Time myself on company tagged problems. Repeat until recall got fast.

For Google that worked well enough.

Google leans heavily on predicate search, counting, and graph traversal. If you're solid on those three, the round usually lands in your zone. I'd interviewed at Google with that exact prep and it had been fine.

Amazon's pattern set is wider.

Across the problems Amazon actually tests, you'll see:

counting
fixed and variable sliding window
prefix sum
LRU-style design
randomized set design
plain binary search
2D and staircase binary search variants
queue design
backtracking

That's roughly eleven distinct families against Google's seven or eight.

The depth strategy that worked for Google had a worse hit rate at Amazon, and on the round that turned into the Bar Raiser slot, the problem landed in a family I'd given less time to.

The deeper issue was something the wider pattern coverage just made more visible.

Even on patterns I had practised, my fluency was template recall, not invariant construction.

As long as the problem looked enough like a textbook example, I produced the standard solution quickly.

The moment the constraint shifted, I tried to retrieve a different template instead of modifying the one I had.

The Bar Raiser format is built to expose that gap.

The follow up after the working solution is the round.

What I started doing differently

After the rejection landed, I went back through every coding round I'd done in mock interviews, including the ones I'd thought went well.

Two patterns showed up across roughly half of them:

I'd produced a correct solution within the time budget, but I couldn't have explained which invariant the data structure I picked was maintaining. The hash map worked. I couldn't have said cleanly what would break if I'd used an array instead.
When the mock interviewer changed a constraint at the end (which the better mocks always did), I either started from scratch or stalled. I almost never reached for the original solution and asked which part of it depended on the constraint that had moved.

Both were habits I'd built by drilling for speed against template problems.

Neither was a coding skill I lacked.

They were prep habits.

I shifted two things.

First, every problem I solved got a constraint flip rep.

Whatever the original constraint was, I changed one piece of it and reimplemented.

Second, I started reading my old solutions out loud as if explaining them to an interviewer, naming the invariant the structure maintained on every line.

The first felt like more work for the same problem count.

The second felt like wasted time.

Both turned out to be the gap.

Here's what changed in practice:

What I used to do	What I started doing
Solve the problem, check the answer, move on	Solve the problem, then write down the constraint change that would invalidate the solution most
Drill problems within one pattern family per week	Rotate between three or four pattern families inside a single session
Recall the optimal solution before writing any code	Get a correct `O(n²)` working first, confirm edge cases, then improve
Treat the follow up question in mocks as a bonus	Treat the follow up as the main rep
Explain the solution by walking through the code	Explain the solution by naming the invariant first

What that looked like on the next Word Search follow up

A few weeks later I ran a mock that landed on Word Search.

Standard backtracking on a grid:

Given a board of characters and a target word, return whether the word can be formed by a path of adjacent cells, with no cell reused.

The solution is a depth first search from each starting cell with a visited mark.

def exist(board, word):
    rows, cols = len(board), len(board[0])

    def dfs(r, c, idx):
        if idx == len(word):
            return True
        if r < 0 or r >= rows or c < 0 or c >= cols:
            return False
        if board[r][c] != word[idx]:
            return False

        tmp = board[r][c]
        board[r][c] = '#'

        found = (
            dfs(r+1, c, idx+1)
            or dfs(r-1, c, idx+1)
            or dfs(r, c+1, idx+1)
            or dfs(r, c-1, idx+1)
        )

        board[r][c] = tmp
        return found

    for r in range(rows):
        for c in range(cols):
            if dfs(r, c, 0):
                return True

    return False

The invariant the in-place marking maintains:

At any point in the recursion, the cells along the current path are marked #, every other cell is restored.

Backtracking by restoring on the way out keeps the invariant true at depth zero, which is what makes:

“No cell reused along this path”

hold.

Then came the follow up.

Instead of a single word, you now have a list of k words to find on the same board.

Same constraint.

No cell reused along a single word's path.

The old me would've started writing:

for w in words:
    exist(board, w)

taken the cost of:

O(k * rows * cols * 4^L)

and gone home.

The interviewer would've asked the obvious question:

“Can you do better than the naive loop?”

Which is exactly what had happened in the real round.

This time I asked a different question first:

Which part of the original solution depended on the constraint that just changed?

The DFS was doing the same prefix walk repeatedly for every word sharing a prefix.

So instead of changing the traversal:

Change what the traversal checks against.

Compose the DFS with a trie of all k words.

Every board walk now checks against all words simultaneously.

The invariant doesn't change.

The base case changes.

The grid traversal stays.

The constraint changed.

Not the structure.

def find_words(board, words):
    root = build_trie(words)
    rows, cols = len(board), len(board[0])
    found = set()

    def dfs(r, c, node):
        ch = board[r][c]

        if ch == '#' or ch not in node.children:
            return

        nxt = node.children[ch]

        if nxt.word:
            found.add(nxt.word)
            nxt.word = None

        board[r][c] = '#'

        for dr, dc in ((1,0), (-1,0), (0,1), (0,-1)):
            nr, nc = r + dr, c + dc

            if 0 <= nr < rows and 0 <= nc < cols:
                dfs(nr, nc, nxt)

        board[r][c] = ch

    for r in range(rows):
        for c in range(cols):
            dfs(r, c, root)

    return list(found)

I got there in roughly four minutes.

Not because I'd drilled Word Search II as a separate template.

Because I'd been practising one question repeatedly:

Which part of the original depended on the constraint that changed?

The change was in what the DFS checked.

Not in the DFS itself.

Why interleaving works for breadth

The other half of the gap was simply pattern coverage.

Three families deep wasn't enough for Amazon's surface area.

But I also couldn't realistically go equally deep on eleven families in the time I had left.

What I could do was rotate between them.

Research on interleaved practice consistently shows that mixing problem types improves your ability to identify which pattern applies to a new problem.

Mixed practice feels harder.

Blocked practice feels easier.

That's exactly why it works.

Blocked practice gives you:

“This week is sliding window.”

The Bar Raiser gives you:

“Figure out what this is.”

The added friction during practice was the same identification work the round required.

Practically, that meant:

A session of four problems became:

four different families

not:

four sliding window problems.

What I'd tell someone in the same spot

A few rules I wish I'd had four months earlier.

1. Get a working solution before chasing the optimal one

Twenty-five minutes thinking before writing leaves no room for the follow up.

A correct O(n²) solution that gets improved beats a half-written O(n) attempt every time.

2. Treat the follow up as the round

When the interviewer changes a constraint:

Ask which part of your solution depended on that constraint.

Modify only that part.

The instinct to redesign from zero is expensive.

3. Practise the constraint flip explicitly

Every problem gets a second pass with one constraint changed.

Implement the modified version.

That rep builds adaptation.

And adaptation is what the round grades.

If someone had explicitly taught me how to identify which part of a solution depends on a changing constraint, it would've shortened the loop considerably. The closest thing to the work I had to build for myself later was a pattern-identification lesson I eventually added inside Codeintuition.

I originally posted a longer version on my own blog with the per-pattern breakdown across all eleven families and how the rest of Amazon's interview loop factors into the Bar Raiser grade.

What’s a constraint flip from an interview that exposed a solution you thought you understood?

How to Know If You’re Ready for FAANG Interviews

Sat, 09 May 2026 12:57:37 +0000

After 280 LeetCode problems, I realised “feeling ready” wasn’t a metric. A diagnostic was.

I'd solved around 280 problems by the time the FAANG readiness question got serious, and the answer changed every week. Some weeks felt close after a clean batch of trees. Most weeks the next unfamiliar medium would freeze cold and the confidence would evaporate by Tuesday. The pattern repeated for months without resolving.

It took longer than it should have to notice the question itself was the issue.

"Do I feel ready" wasn't a question with a stable answer.

The threshold was real. The measurement of it was a mood read on a moving session.

What I figured out

Self assessed readiness drifts every session. A clean morning of trees and a frozen afternoon of graphs both produced wrong answers.
The interview wasn't testing the same skill that practice on familiar problems trains. It was testing what holds up on shapes you haven't seen.
Problem count flatlined as a useful signal somewhere around 100 problems. Past that, more volume on familiar shapes added count without moving the threshold.
The fix was a measurable test, not more prep. An unseen medium, a hidden title, a real timer, repeated across three different families.
The diagnostic was more useful than the score. "Two passed, one failed on graphs" was an action plan. "Feeling 70 percent ready" was anxiety.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. This post is the retrospective on what someone should have handed me earlier, not a pitch for the product.

Where the approach was breaking

The first thing that broke was the belief that the count was the metric.

The tracker said 280, on its way to 350. The tracker also didn't predict any individual interview performance. Open a medium you haven't seen, freeze for ten minutes, and the count number sits there grinning at you, useless.

The second thing that broke was the topic completion checkmark.

Sliding window finished in February. By June the recall on a sliding window medium you hadn't seen was unreliable. The completion checkmark didn't decay.

Recall did.

The third thing that broke was speed on familiar problems.

Two Sum in two minutes feels like fluency. It's actually retrieval of a stored solution. The first time you hit a problem that looks like Two Sum but has a different constraint structure, the speed disappears and you're back to staring.

The fourth thing was peer comparison, which broke quietly because it had never worked in the first place.

Someone else got into Google in six months. That said nothing about your readiness. Background, family coverage, how they'd practised, the level they interviewed for, none of it generalises.

What was actually happening is that all four signals were measuring the wrong thing.

The interview gives you a problem you haven't seen. The four signals all measured behaviour on problems you had seen.

They were diagnostically useless for the question they were being asked to answer.

The diagnostic that ended up working

The version that worked was small and strict.

Two hours. Three problems. Three different families. Real interview conditions.

The shape:

Pick a pattern family genuinely studied (sliding window, tree traversal, graph BFS, DP subsequence)
Find a medium difficulty problem in that family that has never been solved, hinted, or read about
Cover the problem name so the title can't reveal the family
Twenty minute timer, hard cap on failed code execution attempts, no peeking
Identify the family from the constraints, build the solution from the family's invariant, trace it before running

A pass was:

solved within the timer
fewer than two failed runs
family identified from the constraints

Anything else was data.

Three passes across three families was a strong readiness signal. Recognition was firing on shapes you hadn't seen, the construction was following the family's invariant rather than recall, and the conditions were close enough to a real round that the result generalised.

Two passes and one failure told you precisely which family to work on. No need for more random volume.

Depth in one specific place.

All three failed was the most useful diagnostic of the three.

It said the prep method had been building near transfer without far transfer, which is the gap described in the idea of Transfer of Learning.

Method gap, not talent gap.

The fix was correspondingly narrower than:

“Grind more problems.”

What that looked like on the third pass

The pass that taught the most was a DP subsequence problem run cold.

The family had been studied. The canonical examples had been worked through. It hadn't been ground the way sliding window or trees had been ground, so it was a fair test of recognition rather than recall.

The constraints described a longest increasing subsequence variant.

With the title hidden, the recognition still happened in the first three minutes because the constraints fit the DP subsequence shape:

A one dimensional input, not two.
An output asking for the longest sub structure satisfying a condition.
The absence of two pointer or sliding window triggers that would have applied if the answer had been contiguous.

The skeleton came from the family's invariant, not from a remembered problem:

dp[i] is the length of the longest valid subsequence ending at index i.

def length_of_lis(nums):
    if not nums:
        return 0

    dp = [1] * len(nums)

    for i in range(1, len(nums)):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)

    return max(dp)

Trace on a five element array by hand. Verify the recurrence on the trace. Then run.

It passed.

Five minutes still on the timer.

The check that mattered wasn't getting it right.

It was how:

Family identified from the constraints inside three minutes
Skeleton written from the invariant rather than retrieval
Verified by tracing

That's what pattern recognition holding under pressure looks like in practice.

If any of those three steps had broken, the pass would have been a memory pass, not a recognition pass, and the family wouldn't actually have been ready yet.

The protocol the earlier version of me needed

The change that mattered most was switching what practice was for.

Up to about month four practice was for a problem set. After running the diagnostic for the first time, practice changed shape to feed the diagnostic.

Before the diagnostic	After
Solve next problem on the list	Pick a family, work through three problems with the title hidden
Read editorial when stuck	Read the foundational material on the family's invariant when stuck
Track problem count	Track families where the diagnostic passes cleanly
Do problems in order of difficulty	Do problems in order of how shallow recognition was on the family
Speed up by recognising problems	Speed up by recognising the family from constraints with the title hidden
"How many problems before I'm ready"	"How many families pass the diagnostic before I'm ready"

Three rules ended up doing most of the work in the after column.

1. One unseen medium per family per week

Title hidden.

Timer running.

Not as a substitute for the rest of practice.

As the diagnostic that anchored what to practise next.

2. Foundational material on the family's invariant before more volume

When a family failed the diagnostic, the next thing to read wasn't a new problem.

It was the page on what made the family applicable.

Volume came after.

That distinction between solving a problem and recognising a family from constraints is exactly what eventually shaped how I built Codeintuition.

3. Don't retest with the same problem

A retest on a problem already seen, even one that was failed, measured recall instead of reasoning.

The whole point of the diagnostic was novel problem performance.

What the failure modes told me

Most engineers running a version of this diagnostic don't pass three for three on the first attempt.

The first attempt for me wasn't clean either.

The diagnoses to read off the result:

One family failed

The pattern was understood at a surface level but the identification triggers and the construction skeleton hadn't been internalised.

Fix:

revisit foundational material
retest with a different unseen problem

Two families failed

Usually:

One strong area with over practised volume, shallow gaps everywhere else.

Common for engineers who spent months on one topic because the work felt productive.

Fix:

broaden coverage
spend focused time on the families where the depth is thin

All three failed

Method gap, not talent gap.

Too much:

solving familiar problems
repetition
memorisation

Not enough:

recognition
transfer
unseen problems
interview shaped conditions

The fix is narrower than:

"Work harder."

What I wish someone had handed me earlier

The difference between the score and the diagnostic was the difference between an opaque feeling and an action plan.

"Maybe 70 percent ready" was anxiety.

"Two passed, the DP subsequence family failed because the invariant for non contiguous selections wasn't internalised yet" was what to do on Wednesday.

If family coverage is the bottleneck rather than conditions, the algorithms learning path on Codeintuition is one place to fill the gap before retesting.

The diagnostic itself doesn't depend on it.

The point is the test, not the source of the problems.

I originally wrote a longer version on my own blog that includes the per family signal breakdowns and diagnosis trees for the most common failure modes.

What was the moment that made the readiness question itself feel like the wrong question, and what did you start measuring instead?

How to Recognize Which Algorithm a Coding Interview Problem Needs

Thu, 07 May 2026 12:47:24 +0000

I'd solved around 300 problems by the time my third senior screen wrapped up. The medium that had just bombed the call was something I could explain back to myself in 90 seconds once it ended. The constraints were familiar. The technique was one anyone with my problem count had implemented before. The thing that wouldn't fire, in the moment, was the connection between the constraints and the technique.

The instinct, when that happens, is to grind more problems. That instinct cost me about two months. The thing that actually moved the needle was something else.

What I figured out

Volume practice was building memory of specific problems. It wasn't building the skill that recognises which technique applies to a problem you haven't seen before.
The default LeetCode loop trains around recognition, not at it. Reading the tag before attempting skips the part of the work that interviews actually test.
The fix is small and unglamorous. Read the problem for two or three observable features before any code. Name the technique. Then code.
Conditions matter as much as content. The LeetCode UI is friendlier than any phone screen, and it takes conscious effort to practise under conditions that resemble the real thing.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. The story above is the version of this realisation that keeps showing up across engineers prepping for senior screens, almost verbatim. The closing link goes to the longer version on my own blog.

Where the approach was breaking

For most of the prep arc, every stuck problem got handled the same way. Attempt for fifteen or twenty minutes, hit a wall, glance at the tag, read a solution, move on. The progression chart said the weekly count was climbing. The interview chart said the bar wasn't moving.

Tracing what was actually being learned per problem made the picture clearer. The implementation got learned each time. The shape of the solution got learned. What didn't get learned was the answer to a question nobody was asking: why is this problem the kind of problem that takes this technique? The tag and the solution skipped that step every single time.

In a real interview, the tag is gone. So the thing that came for free in practice (which technique to use) becomes the thing the candidate has to figure out from scratch under a clock. The freeze makes sense in retrospect. Nothing in the practice loop had trained for it.

What started working

The shift was small. Before opening the editor, the rule was: spend 30 to 60 seconds reading just the problem statement, trying to name the technique and the reasons. No code, no guessing. The output of the pass is a sentence: "this is a [technique] problem because [feature one], [feature two], [feature three]." If you can't write that sentence, you don't start coding. Go back to the constraints with a checklist of features for each technique and try again.

Concretely:

What used to happen	What started happening
Open problem, attempt for 20 minutes, glance at tag if stuck	Read constraints first, name the technique in 60 seconds, only then attempt
Read solutions to learn the implementation	Read solutions only after attempting, and look for which features in the statement point at the technique
Practise one technique in batches (15 sliding window problems back-to-back)	Mix techniques in each session so the constraints had to be read before knowing what to use
Practise with the title and difficulty visible	Cover the title with a sticky note, ignore the difficulty tag

The first time, this protocol feels slow. The second week, it feels slow but useful. By the fourth week, the features start firing on their own as the problem statement is read.

What that looked like on the next problem

The problem that finally landed for me was Longest Increasing Subsequence. The O(n^2) version was familiar. The patience-sorting O(n log n) version was familiar too. What wasn't trustworthy was the read of when LIS was the right tool versus when something else was.

The session with the new approach started with the constraints. Three features fell out:

A single sequence, not two. That ruled out edit-distance-family techniques right away.
The optimisation target was the length of an ordered subsequence. Order of the original sequence had to be preserved.
The transition between elements was a comparison, not a sum or a count. "Strictly greater than the previous kept element" is a binary check.

Once those three features were written down, the technique was obvious. The simpler O(n^2) version was enough because the problem didn't require the faster one:

def lis(nums):
    if not nums:
        return 0
    dp = [1] * len(nums)
    for i in range(len(nums)):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)
    return max(dp)

The implementation wasn't new. The change was that the technique got reached for because the features matched, not because the exact problem had been memorised.

A second problem the same week

The same week brought Russian Doll Envelopes, which usually trips people up because it doesn't look like an LIS problem on the surface. The problem asks for the maximum number of nested envelopes given pairs of width and height.

Reading for features: a single sequence (after sorting), a length to maximise, a strict comparison between consecutive kept elements (one envelope must fit inside the next). That's LIS, run on the heights after sorting by width with a tiebreak rule. The reframe took two minutes once the read was for features instead of surface details.

That was the moment the recognition drill paid for itself. Two surface-different problems, same three features, same technique. Far transfer.

Why this works (the science to dig into later)

The learning sciences have language for this. Transfer of learning splits into near transfer (a problem that resembles one already practised) and far transfer (a problem that doesn't resemble anything practised, but whose structure can be read).

Volume practice mostly trains near transfer. Whether far transfer is reliably teachable is a debate the research hasn't fully settled. What the evidence does support is the specific intervention this protocol is built around. Explicit instruction in when and why a method applies, not just how to execute it, produces more transfer than practice alone.

In retrospect, the "how" was everywhere on the internet. The "when" and "why" were the parts no resource in the practice loop bothered to teach explicitly.

What to try if you're in the same spot

If problem 200 feels harder than problem 50, the bottleneck probably isn't volume. It's a recognition skill that volume alone doesn't build for everyone. A few things worth trying:

For each technique you've practised, write down two or three observable features that signal it applies. Sliding window: contiguous range, condition across the window, optimisation on length. Two pointers: sorted array, search for a pair or triple, pointers move from the ends. Monotonic stack: per element answer, directional search, comparison. Keep the checklists short.
On every new problem, run the 60 second feature pass before any code. Write a sentence: "this is a [technique] problem because [features]." If you can't write the sentence, don't code yet.
Mix techniques across sessions. Three problems from three different techniques will train recognition in a way that fifteen problems from one technique won't.
Cover the title and the difficulty before reading the constraints. Many problem names give away the technique, and the assistance is exactly the kind of help that disappears in an interview.

This is a practice protocol, not a product. It runs against any problem bank.

Where it's still hard

The recognition drill doesn't fix everything. There's a separate axis prep tends to skip, which is the conditions the practice runs under. The default LeetCode loop has the tag, the difficulty, the discussion thread, and no clock. None of those are present in a real interview. Even with recognition trained, the first time the tag disappears the read gets harder. So the last few weeks of any prep cycle, run every practice session under interview-shaped conditions: clock running, tag covered, discussion section closed.

That's the version of the lesson worth keeping. It wasn't the problem count. It was what was happening on each problem, and what nobody had ever trained on purpose.

I originally posted this on my own blog, with the feature checklists for six more techniques and a longer worked example for variable sliding window.

What's a problem that finally made a technique click for you, where the explanations you'd read before hadn't quite landed?

How to Explain Algorithm Correctness in Coding Interviews

Wed, 06 May 2026 19:47:14 +0000

I'd written the BFS in about eight minutes. The interviewer ran the example I'd traced and said "ok, but how do you know this is right for any input?" My instinct was to point at the code. Pointing wasn't an argument. The silence stretched, and the realisation landed: nobody had ever taught me how to answer that question.

The interview ended without an offer. The post-mortem felt strange because the algorithm was correct, and there was still no way to say why in a form the interviewer could check.

What changed for me

Tracing one input is testing, not proving. Most engineers, including a past version of me, don't notice the difference.
Interviewers want a loop invariant, the property that's true at the start of every iteration.
The full method is two checks: state and verify the invariant, then check initialization, termination, and edge cases.
Different patterns produce differently shaped invariants, but the two step structure stays constant.
The skill is separate from problem solving. It needs its own practice before it becomes reflexive.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. This post is the retrospective version of the lesson that BFS interview should have taught me years earlier.

Where my approach was breaking

The default habit looks reasonable from the outside. You write the algorithm. You walk through it on the example the interviewer suggested. You get the right answer. You stop. If they ask a follow up, you trace a slightly harder example. If they push harder, you start guessing about edge cases.

None of that is an argument. It's a sequence of tests. Each test confirms one input. The interviewer's question was about every input.

The gap is small in description and large in practice. A trace shows the algorithm worked once. A correctness argument has to give the interviewer a reason it works always. That bridge is where the interview lives, and most prep material skips it.

The discrete math course you took in college covered induction proofs with formal notation. It's easy to dismiss as academic and move on. What that misses is that the idea (a property that holds every iteration) is exactly what the interview wants. The interview just asks for it as 90 seconds of clear English instead of a paper proof.

What I started doing differently

The first habit was simple. Before tracing any input, write down what's supposed to be true at the start of each iteration. One sentence.

The hard part is that for a few weeks, the sentence wouldn't always come. That alone is the diagnostic. If you can't state the invariant, you solved the problem by pattern matching, not by understanding what made the algorithm work.

The second habit, after stating the invariant, is to check the boundaries separately. What happens before the loop runs. What happens when the loop exits. What happens on an empty input. What happens on a single element. What happens on the maximum size.

The two step method is short. The change in interview outcomes is not.

Step	What I used to do	What works
Before tracing	Pick an example and run it	State the invariant in one sentence, then trace 3 to 4 iterations
At the loop end	Say "and that gives the right answer"	Confirm the invariant plus the loop's exit condition together force the right output
On boundaries	Mention "edge cases" if asked	List initialization, termination, and at least three degenerate inputs explicitly

What that looked like on the next problem

A few months later, the same kind of BFS question came up on a different graph problem. This time the invariant came first.

from collections import deque

def shortest_path(graph, start):
    distances = {start: 0}
    queue = deque([start])
    while queue:
        node = queue.popleft()
        for neighbor in graph[node]:
            if neighbor not in distances:
                distances[neighbor] = distances[node] + 1
                queue.append(neighbor)
    return distances

The argument went something like this: the invariant is that when a node is dequeued, its recorded distance equals the shortest path from the start. The reason it holds is FIFO ordering on a graph with equal edge weights. Any node enqueued later has been reached by a path of the same length or longer, so the first time you see a node is via the shortest path to it.

Then the boundaries. Initialization: only the start node sits in distances with value 0, which is the shortest path from the start to itself. Termination: the loop exits when the queue is empty, meaning every reachable node has been dequeued with its correct distance. Edge cases: a graph with one node returns {start: 0} immediately. A disconnected graph returns distances only for nodes reachable from the start. A self-loop is fine because the check if neighbor not in distances runs before enqueueing.

The interviewer didn't follow up with "but how do you know it's right for any input?" The argument had already covered that.

Why this works (the bit worth digging into later)

The two step method generalises because the structure is the same across every algorithm class. Only the shape of the invariant changes. Sliding window tracks a running variable. Two pointers tracks a search range. Binary search tracks a range too, but a different one. BFS tracks a relationship between dequeue order and shortest path. DP tracks an entire table of subproblem solutions.

The verification framework is invariant plus boundaries, in that order, regardless of pattern.

This connects to a broader idea in computer science formalism: the loop invariant is a logical statement that, combined with the loop's exit condition, gives you the postcondition you wanted to prove. The interview version drops the formal symbols and keeps the structure. Same skeleton, different vocabulary.

What I'd tell someone in the same spot

Three concrete things matter most:

Pick a problem you've solved. Set a timer for 60 seconds. Try to state the loop invariant in one sentence. If the sentence doesn't come, that's the most important diagnostic in your prep, and more problems won't fix it.
Take a correct algorithm. Write down an invariant that sounds plausible but is subtly wrong. Find the iteration where it breaks. This trains the gap between invariants that describe what the code does and invariants that guarantee correctness.
Pair correctness reasoning with mental dry running. The dry run gives you a trace. The invariant gives you the claim to verify against the trace. Practising them apart leaves a hole that interview pressure exposes.

If you want a worked walkthrough of the BFS distance invariant before solving a graph problem with it, the BFS lesson walks through why FIFO ordering plus equal edge weights forces the shortest path property to hold.

I originally posted this on my own blog, a slightly longer version that walks through the two step method on sliding window, binary search, and DP, with an FAQ on nested loops where each loop needs its own invariant.

What's a problem where you understood the algorithm but couldn't say why it was right when someone asked, and what was the missing sentence you wished you'd had?

AlgoExpert vs NeetCode: Why I Still Froze in Coding Interviews

Tue, 05 May 2026 22:40:47 +0000

A few years back I had AlgoExpert open in one tab and a NeetCode playlist queued in another, and the prep felt like it was working. Twelve weeks of disciplined viewing, two videos most evenings, the trees module rewatched twice because the postorder helpers weren't sticking on the first pass. Then a real interview opened with a fresh medium nobody had walked through, and the eight minutes spent looking at the prompt before writing anything were the slowest eight minutes of the round.

The problem looked like a graph. The candidate technique wasn't there. The videos on graphs all started after the technique had been named, and naming the technique on a fresh prompt was apparently a different skill.

What I figured out, in retrospect

The 100 polished AlgoExpert videos and the 400+ free NeetCode walkthroughs were honest about what they were teaching: how a technique works once the technique has been named.
Naming the technique on a fresh prompt was a separate skill the videos didn't claim to train.
The reps that were missing weren't more videos. The video count was already enough.
A wrong attempt written from a blank screen surfaced more about the gap than another walkthrough did.
Once the practice shape changed, both platforms became more useful, not less.

Quick disclosure before I get into this. I built Codeintuition, a structured learning platform for coding interviews. The retrospective below is from before that, when working through both AlgoExpert and NeetCode the way the platforms recommend.

Where the approach was breaking

The Number of Islands prompt was the one that finally made the gap concrete. The interviewer described a 2D grid of 1s and 0s and asked for the count of distinct islands, where an island is a region of connected 1s. The walkthroughs of this exact problem had been watched twice. The BFS variant could be written from memory if the title was handed over.

What couldn't happen, in 25 minutes against a whiteboard, was reading the prompt and arriving at "this is a connected components count, BFS or DFS from each unvisited 1, mark visited as you go." The video had given that as the starting position. The prompt expected it to be constructed. Twelve weeks of polished video walkthroughs hadn't drilled the construction work.

The pattern wasn't specific to graphs. It repeated on the next round, where the prompt was a string problem with a sliding window solution, and the candidate technique took six minutes to occur. After the round the code re-derived itself in five. The implementation was the easy part. The decision was where the time went.

What changed on the second attempt

The shift wasn't dramatic. Two changes, both unglamorous:

What had been happening	What started happening
Watching the walkthrough first, then attempting the problem with the technique already in mind.	Reading the prompt first with the title and tags hidden, naming the visible triggers that could be extracted, then either trying the technique from those triggers or giving up after 10 minutes and watching the walkthrough.
Picking the next problem from the platform's curriculum order, by topic.	Picking five problems on the same technique, drilling them with titles hidden, before moving to a different technique.
Treating the timer as a final-week thing.	Adding a 25 minute timer to the recognition work, not the implementation work, from week one of the new approach.

The change wasn't from "video led" to "problem led." Both platforms remained part of the loop. What changed was the order of operations: prompt first without the technique label, then the technique, then the implementation, then the walkthrough as a check rather than the starting position.

What that looked like on the next problem

Take Number of Islands again, after the change. Title hidden, no tags. The prompt described a grid, a definition of an island, a count. Reading it cold:

The input is a 2D grid, not a flat array. That suggests grid traversal.
The output is a count of distinct regions. That suggests connected-components reasoning.
The connection rule (4-directional adjacency on 1s) suggests BFS or DFS from each unvisited 1, marking visited as the traversal proceeds.

That's the recognition that wouldn't form on the first interview round. After ten or twelve recognition reps with titles hidden, on different graph problems, the construction came together in under three minutes on a fresh prompt.

The implementation that followed was short, and not the hard part:

def numIslands(grid):
    if not grid:
        return 0
    rows, cols = len(grid), len(grid[0])
    count = 0

    def dfs(r, c):
        if r < 0 or r >= rows or c < 0 or c >= cols:
            return
        if grid[r][c] != "1":
            return
        grid[r][c] = "0"
        dfs(r + 1, c)
        dfs(r - 1, c)
        dfs(r, c + 1)
        dfs(r, c - 1)

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == "1":
                count += 1
                dfs(r, c)
    return count

The code is six or seven lines of meaningful work. The recognition that the 2D-grid-plus-connected-region prompt is a DFS-from-each-unvisited-cell problem is the part that would have taken eight minutes on a whiteboard before. The change brought it to under three.

A second example: where the wrong attempt taught more

Later in the same week, a course scheduling problem came up. Given a list of courses with prerequisites, return whether all courses can be completed. The walkthrough had been watched. The walkthrough used Kahn's algorithm with topological sort. Reading the cold prompt, "topological sort" wasn't a candidate that surfaced. The graph was visible, the directed edges were visible, but the move from "directed graph with prerequisites" to "topological sort to detect a cycle" wasn't there.

So a wrong attempt got written. A naive DFS that didn't track visit states properly, that would have looped on a real cycle. Wrong, but written. Then the walkthrough got checked.

The wrong attempt did something the walkthrough alone hadn't done. It surfaced the specific missing piece. A directed cycle needs a three-state visit tracking (unvisited / in progress / done) or an indegree-zero queue, and that hadn't internalised. Knowing the missing piece, the walkthrough's three-state DFS clicked. The next two course-prerequisite problems resolved in eight or nine minutes each. Without writing the wrong attempt first, the walkthrough would have produced a nod of recognition, then the same stall on the next variant.

This is the generation effect doing the work nobody told me about during the watch-everything phase. Producing an answer first, even an obviously wrong one, surfaces the missing concept more reliably than reading the answer.

Why this works (the science I dug into later)

The retrospective is what surfaced the underlying reasons. Two effects from the cognitive science literature explained what was happening, both summarised in the transfer of learning Wikipedia article.

The first is the generation effect itself: producing an answer before checking the reference produces stronger encoding than reading the reference first. Watching twelve weeks of walkthroughs is the second pattern, not the first. That's why the prep felt productive (it was) and didn't transfer to fresh prompts (the encoding was recognition-shaped, not generation-shaped).

The second is a near transfer / far transfer split. Watching ten variants of expand around centre transfers reliably to variants close to what was watched. It transfers unreliably to a fresh prompt where the description is just different enough that the recognition memory misses. The prep platforms reward the watching shape. Interviews test the generating shape. One shape doesn't substitute for the other.

What I'd tell someone in the same spot

If you're working through AlgoExpert or NeetCode (or both) and the unfamiliar mediums are still freezing you, here's what would have helped earlier:

Cover the title before reading any prompt. The title is the cheat sheet the platform hands you. Hide it and the recognition becomes the work, which is what an interview tests.
Write a wrong attempt before reaching for the walkthrough. The wrong attempt surfaces the specific missing piece. Reading the walkthrough cold doesn't.
Pick five problems on the same technique before moving to the next technique. The reps on a single technique are what extract the trigger features. Topic-spread reps don't do this.
Add a 25 minute timer to the recognition work from the first day. Recognition under timed conditions is the actual interview test. Practising it without the timer doesn't transfer.
When you do watch a walkthrough, watch it as a check on the wrong attempt, not as a starting position. The walkthrough is more useful at this point in the loop than at the beginning.

The 100 polished videos and the 400+ free walkthroughs were never the bottleneck. The bottleneck was the practice shape that surrounded them, and the practice shape was something both platforms assume the engineer will construct on their own.

I wrote a longer version on my own blog that walks through how the two platforms compare on depth, breadth, and free access, plus the trigger lists rebuilt for the patterns that broke me first.

What's the platform you watched the most videos on, and what was the prompt where the recognition finally locked in for you?

I Failed My 12 Week FAANG Prep Plan Because I Skipped Recursion

Mon, 04 May 2026 21:26:26 +0000

I failed my 12 week FAANG prep plan because I skipped recursion — and it broke everything after it.

What I figured out, in retrospect

The order topics appear in a 90 day plan isn't cosmetic. It's load-bearing in a way you only notice when you violate it.
"Stay on schedule" is the worst advice for a prep plan. It treats the plan as the goal rather than the prep.
Dependency order means recursion before backtracking before DP. Skipping a layer doesn't save a week. It costs four.
The right response to a slow topic isn't to skip it. It's to extend the plan and let the next topic move faster on top of solid foundations.
Productive struggle and spinning look identical from the inside. They have opposite prescriptions.

Where the approach was breaking

The Week 7 mistake was treating recursion as a topic to cover rather than a prerequisite to internalise. The recursion videos were watched. Four or five recursion problems were solved with the explanation sitting next to them. With the explanation gone, reproducing the same trace from a blank screen wasn't possible. Arrays could be written from scratch. Recursion could only be followed.

The Week 7 plan said this was fine because the topic could be revisited later. Then Week 8 arrived, and Week 8 was backtracking. Backtracking is recursion with state restoration. The first backtracking problem stalled on the recursive structure, which had supposedly already been covered. Week 9 was graphs. Graphs use recursion for DFS. Stalled again. By Week 10, every new topic was failing on the same earlier gap, and the gap was getting harder to fix because there was less time.

The plan didn't fail at any specific topic. It failed at one decision: the moment a slow week got treated as a scheduling problem rather than as the plan signalling what needed to keep building.

What changed on the second attempt

The shift was simple to describe and slow to absorb. Two rules:

Old rule	The rule that replaced it
If a topic is slow, push through to stay on schedule.	If a topic is slow, extend the plan by exactly the time the topic needs. The total prep time often ends up the same.
If a topic is covered once, it's covered.	A topic is covered when you can produce the core pattern from a blank screen, with no reference, in roughly the time an interview gives.
Practise without a timer until you're "ready" to add pressure.	Add a timer at Week 6. The pressure is the practice, not a test of it.
Skipping a topic costs you one week.	Skipping a topic costs you four. Backtracking, graphs, and DP all sit on top of recursion.

Once Week 7 stopped being a scheduling problem and started being the plan saying to slow down on recursion, the rest of the plan started working. The total prep extended by one week. The extra week paid back twice over because backtracking and graphs moved faster, not slower, when recursion was solid.

What that looked like on the next problem

The problem that finally made it click was a simple recursive enumeration: generate all subsets of an array. The textbook solution had been seen before. Recursion with two branches at each index, include or exclude the current element, base case when the index reaches the end. Reading it was easy. Writing it from a blank screen wasn't.

I sat with the problem for a full afternoon, no walkthrough, no reference. Four wrong attempts came out. The fifth attempt looked like this:

def subsets(nums):
    result = []

    def helper(index, current):
        if index == len(nums):
            result.append(current[:])
            return
        # exclude nums[index]
        helper(index + 1, current)
        # include nums[index]
        current.append(nums[index])
        helper(index + 1, current)
        current.pop()

    helper(0, [])
    return result

The fifth attempt wasn't just correct. It was the first time the role of current.pop() made sense: the recursive call mutates current for its own subtree, and the parent frame needs the mutation undone before its own next branch fires. Once that explanation came together, every backtracking problem in Week 8 fell into place. The N Queens problem, the permutations problem, the parentheses generation problem, all the same shape with different state restoration.

That afternoon ate one of the "scheduled" study days. It also unblocked the next three weeks. Net, the plan came out ahead.

A second example: where productive struggle ends

Later in the same week, a different kind of stuck showed up. The problem was on combinations. The prompt got read three times. Nothing came to mind. The same approach as subsets didn't fit the structure. A fourth read, still nothing. Ten minutes of staring at a blank screen, then finally looking up the solution.

The reason this is a different kind of stuck is that there was no specific question to articulate. With subsets, you can say "the role of pop isn't clicking." With combinations, the screen was just blank. That's the generation effect telling you to do something you weren't doing: generate an attempt, even an obviously wrong one, before reaching for the solution. The blank screen wasn't a signal to read more. It was a signal to write something, anything, even broken, and then read.

When the rule became "write a wrong attempt first, then check the solution against it," the difference between productive struggle and spinning collapsed into a single test: can you name what's missing? If yes, more practice on that specific gap. If no, generate first, check second.

Why this works (the science I dug into later)

None of this was clear during the original Week 7 collapse. The retrospective is what surfaced the underlying reasons. Two effects from the cognitive science literature explained what was actually happening, both linked from the Wikipedia learning sciences article:

The first is the spacing effect. Practice distributed across weeks, with each week building on the last, retains better than the same volume crammed late. The dependency-ordered roadmap isn't only logical, it's also the configuration of practice that the spacing effect rewards. Skipping a week and trying to make it up later isn't just a time problem, it's a retention problem.

The second is the generation effect. Producing an answer (even a wrong one) before checking the reference produces stronger encoding than reading the reference first. Part of the Week 8 collapse was that Weeks 5 and 6 had been heavy on reading and light on writing, so when Week 7 demanded that recursive structures be generated from scratch, the muscle wasn't there. Adding the timer at Week 6 (which became standard practice on the second attempt at this plan, six months later) is what built that muscle while the material was still fresh.

What I'd tell someone in the same spot

If you're three or four weeks in and a topic is starting to feel slow, here's what would actually help:

Don't skip. Extend the plan by the days you need on the slow topic. The catch up time at the end is almost never less than the time you'd have spent doing it right the first time.
Treat recognition speed as a separate skill from solution knowledge. If you can read the solution and follow it but can't write it from a blank screen, you have a generation gap, not a knowledge gap.
Add the timer at Week 6 even if you don't feel ready. Especially if you don't feel ready. The discomfort of timed practice while the material is still fresh is the discomfort that builds retrieval speed.
Use the Recursion for the layer between the call stack and DP if you can find one with worked examples that can be attempted before reading the solution. Generation first, walkthrough second. That's the order that closes the gap.
When you hit a blank-screen moment on a problem, write a wrong attempt before looking up the solution. The wrong attempt surfaces the specific missing piece more cleanly than another round of passive reading.

This is exactly why I built codeintuition, to structure recursion → backtracking → DP as a dependency chain instead of isolated topics.

What's the week of your own prep where the order finally locked in for you, and what was the topic that broke it open?

I Solved 200 LeetCode Problems and Still Froze in Interviews

Mon, 04 May 2026 10:59:45 +0000

A few years ago I solved 200 LeetCode problems and still froze on Mediums I hadn't seen. The breakthrough wasn't another hundred problems. It was a different loop.

A problem asks for the longest substring with at most K distinct characters. You've solved sliding window before. Maximum sum subarray of size K, done. Longest substring without repeating characters, done. This third one stalls you. Twenty minutes pass. Discuss says sliding window. You'd already solved sliding window problems. The recognition didn't work on this one.

TL;DR: Practice volume builds memory of specific problems, not the recognition you have to do before you start coding. The skill that transfers to unfamiliar interview mediums is identifying which technique applies from what the problem looks like. That recognition is what most LeetCode-style prep doesn't train, and that gap is what this post is about.

What LeetCode actually does well

LeetCode is the default coding interview prep platform for a reason. The problem bank is the strongest available: 3,000+ problems across every common data structure, tagged by company and frequency. The company tagging is the most reliable public signal you can get for "what does Amazon currently ask." Nothing else is close on that dimension.

The free tier is generous, the discuss forum is open, and the weekly contests are free. If you already understand the underlying patterns and you need volume to drill them, LeetCode is the right platform. The contest system is genuinely underrated for building speed under time. Top voted discuss replies on popular problems also hold up. They often explain the reasoning more clearly than the official editorials.

So the question isn't whether LeetCode is good. It is good. The real question is whether the thing holding you back is the kind of thing LeetCode's design actually fixes.

The gap volume doesn't close

The earlier sliding window problems taught implementation on those specific problems, not the rule for when sliding window applies. The connection between "K distinct characters" and "variable sliding window" was never made explicit anywhere in your prep. You learned an implementation by example, not a recognition rule. When the visible parts of the problem change, the implementation memory doesn't carry over.

Learning research calls this near transfer versus far transfer. Near transfer means solving problems that look like ones you've already solved. Far transfer means reasoning through problems that look different but follow the same underlying pattern. The Wikipedia article on transfer of learning covers it. The short version: practice volume produces near transfer reliably and far transfer unreliably. You can grind 500 problems and still not generalise across the differences in description if no one ever taught you which features signal which pattern.

That isn't a talent gap. It's a gap in the method.

What recognition actually looks like

Recognition is reading a problem statement, naming the visible features, and matching them to a technique before any code is written. Every technique has a small set of trigger conditions, usually three to five. When all of them match, you've identified the technique.

For variable sliding window, the trigger conditions are:

The input is a contiguous range (a substring, a subarray, a window of consecutive elements).
The optimisation target is the length of that range (longest, shortest, smallest valid).
There is a condition you can check incrementally as the window expands or contracts (count of distinct characters, sum within bounds, set membership).

When all three apply, variable sliding window is the technique. K distinct characters hits all three. So does longest substring without repeating characters. So does minimum window substring. The triggers are the same. The descriptions differ.

The skill is matching problems to triggers before coding. That's what doesn't get built by grinding problems sequentially.

A code template you can adapt

Here's the variable sliding window template in Python. Once you recognise the technique, the implementation has very few moving parts.

def variable_window(arr, condition):
    left = 0
    state = init_state()
    best = 0

    for right in range(len(arr)):
        state = expand(state, arr[right])
        while not condition(state):
            state = shrink(state, arr[left])
            left += 1
        best = max(best, right - left + 1)

    return best

For K distinct characters, state is a hash map of character counts within the current window, condition is len(state) <= K, and shrink decrements counts and removes keys whose count drops to zero. The recognition step (this is variable sliding window) is the decision that matters. The code follows.

For longest substring without repeating characters, state becomes a hash set and condition is "no duplicate." Same skeleton. Same invariant.

That's the payoff of recognition trained explicitly. Write the template once. Adapt per problem in two or three lines. Stop staring at problems hoping the right approach surfaces.

How practice and interview conditions diverge

Recognition is half the gap. The other half is the conditions you practise under. LeetCode's practice environment shows you the problem name (which often hints at the technique), gives unlimited code executions, and doesn't penalise failed attempts. Real interviews give none of that.

Dimension	Practice (LeetCode default)	Real interview
Problem name	Visible, often hints at category	Not given
Code executions	Unlimited, no penalty	Limited, every failure costs
Hints / discuss	One click away	Not available
Time limit	Self set, often skipped	20 to 45 minutes hard
Reasoning	Internal	Spoken aloud

The middle column is fine for the early learning phase. Open exploration helps when you're still building the model. The problem comes when those conditions are the only conditions you ever rehearse under, and the actual test wants something the rehearsal never asked for.

Replicating interview pressure on your own takes one friend and a kitchen timer. The friend covers the problem name and reads the constraints aloud. You set the timer to 20 or 30 minutes. You don't open the IDE before stating the technique you intend to use. Two sessions a week against a friend who isn't shy about silence will do more for interview readiness than another fifty problems on the comfort setting.

A protocol you can run this week

If the K distinct characters story sounded like your last three failed problems, the move isn't more volume. It's a tighter loop on recognition first.

Pick one technique a week (variable sliding window, two pointers, prefix sum, monotonic stack, and so on).
Write down the trigger conditions for that technique. Three to five features of the problem that, when they all apply, make this technique the right tool. Write them in your own words, not from a cheat sheet.
Read five problems that use this technique without solving them. For each, name the triggers you can see in the problem statement before reading the constraints in detail.
Solve three to five problems on this technique with the problem name and tag hidden. Force the recognition step.
Once a week, do one timed pressure session: friend covers the title, you talk through your reasoning, no IDE until you've named the technique. If you can't name it inside five minutes, the problem rewinds to the recognition queue, not the implementation queue.

A pattern a week, eight to ten patterns covered, roughly ten weeks of focused work. That replaces the hundreds of mediums where the signal gets buried under details that don't matter.

The longer write up of this is on my own blog, with trigger conditions for prefix sum, two pointers, and monotonic stack alongside the variable sliding window walkthrough above, plus a worked example on minimum window substring that uses the same template.

When did the recognition click for a pattern you used to grind without seeing, and what was the specific problem that broke it open?

Disclosure: I built Codeintuition, a structured learning platform for coding interviews. The post above is about the technique, not the platform.

Swapping Array Elements With Efficiency

Wed, 15 Apr 2026 07:16:01 +0000

Most people think this is a “simple” problem.

Reverse an array.

But there are actually two very different ways to think about it

Approach 1: Let Python do the work

arr[::-1]

That’s it.

Looks clean. Works instantly.

But under the hood:

In a Python list, this creates a new array
It walks from end → start and copies elements

Time: O(n)
Space: O(n)

One interesting twist:

In NumPy, slicing often gives a view, not a full copy
→ same code, very different memory behavior

Approach 2: Swap from both ends

left, right = 0, len(arr) - 1

while left < right:
    arr[left], arr[right] = arr[right], arr[left]
    left += 1
    right -= 1

Here you’re not creating anything new.

Just swapping:

first ↔ last
then moving inward

Time: O(n)
Space: O(1)

What this really shows

Both solve the same problem.

But one is:

“just get it done”

The other is:

“do it with control”

And honestly, both are useful, depends on what you care about in that moment.

Small takeaway

Sometimes the difference in solutions isn’t about correctness.

It’s about:

how much you understand
and how much you care about what’s happening underneath

Next time something feels “too easy”…
there’s probably a deeper layer sitting right below it.

Sometimes the simplest operator solves the real problem

Fri, 13 Mar 2026 09:12:55 +0000

Recently, I had a simple coding task. I needed to split an item's quantity across multiple lines.

For example, I had Item 1 with a total quantity of 10, but that quantity could not remain on a single line. It had to be distributed across several lines, based on related sub-items.

At first, this sounded like a very small task. Still, it turned into a good reminder that many real problems are solved not by advanced patterns, but by understanding the basics well.

In this case, the solution came from remembering the modulo operator (%).

What `%` does

The modulo operator returns the remainder after division.

10 % 3 // 1

This means that if you divide 10 into 3 equal parts, each part gets 3, and 1 is left over.

That leftover value is exactly what makes % so useful when distributing quantities.

My case, splitting quantity per line

Let’s say we have:

Total quantity: 10
Number of lines: 3

int quantity = 10;
int lines = 3;

int baseQty = quantity / lines;   // 3
int remainder = quantity % lines; // 1

Now we know:

each line gets at least 3
there is 1 extra item left
that extra item can be added to the first line

for (int i = 0; i < lines; i++)
{
    int lineQuantity = baseQty + (i < remainder ? 1 : 0);
    Console.WriteLine($"Line {i + 1}: {lineQuantity}");
}

Output:

Line 1: 4
Line 2: 3
Line 3: 3

So with a very simple use of %, we can split quantities as evenly as possible.

More useful examples of `%`

1. Check if a number is even or odd

int number = 7;

if (number % 2 == 0)
{
    Console.WriteLine("Even");
}
else
{
    Console.WriteLine("Odd");
}

This works because even numbers divide by 2 with no remainder.

2. Find numbers divisible by 5

for (int i = 1; i <= 20; i++)
{
    if (i % 5 == 0)
    {
        Console.WriteLine(i);
    }
}

This is useful when you want to trigger something every 5th item, every 10th row, and so on.

3. Alternate row styles in a grid

for (int row = 0; row < 6; row++)
{
    string style = row % 2 == 0 ? "Light" : "Dark";
    Console.WriteLine($"Row {row}: {style}");
}

This is a very common use in UI, where rows alternate between two styles.

4. Cycle through a list of values

string[] colors = { "Red", "Green", "Blue" };

for (int i = 0; i < 10; i++)
{
    Console.WriteLine(colors[i % colors.Length]);
}

This lets you repeat values in a loop without going out of bounds.

5. Print a new line every 4 items

for (int i = 1; i <= 12; i++)
{
    Console.Write(i + " ");

    if (i % 4 == 0)
    {
        Console.WriteLine();
    }
}

Useful for formatting output into groups.

6. Round-robin assignment

string[] users = { "Anna", "John", "Maria" };

for (int task = 0; task < 8; task++)
{
    string assignedTo = users[task % users.Length];
    Console.WriteLine($"Task {task + 1} -> {assignedTo}");
}

This is a clean way to distribute work in rotation.

Why this matters

What I like about examples like this is that they bring us back to an important truth. We often focus on learning bigger frameworks, more advanced architectures, and more complex tools. But again and again, the real solution comes from something basic.

Operators like %, loops, conditions, and simple arithmetic are not small details. They are part of the foundation, and they solve real business problems every day.

That is why reviewing the basics is always worth it. Sometimes the cleanest solution is not hidden in something advanced, but in something we already learned a long time ago.

Key Math Concepts in Data Structures and Algorithms

Sat, 07 Mar 2026 23:13:34 +0000

At the core of data structures and algorithms are fundamental mathematical principles that guide their design and implementation. This article explores key math concepts essential for mastering data structures and algorithms, helping developers write optimized and effective code.

Number Systems

A number system is a structured way of representing numbers using specific symbols and rules. Different number systems are based on different base values (also called the radix).

We are most familiar with the decimal number system, which is used in everyday life. It uses ten digits (0 through 9) to represent all numbers. Because it uses ten distinct digits, its base is 10.

Computers, however, operate using only two digits: 0 and 1. Therefore, they use the binary number system, which has a base of 2. All data inside a computer is ultimately stored and processed in binary form.

The octal number system uses eight digits (0 to 7) so its base is 8. It is used as a more compact way to represent binary numbers, since each octal digit corresponds to a group of three binary digits (bits). Octal is still used in certain areas of computing, such as file permissions in Unix and Linux systems.

The hexadecimal number system uses sixteen symbols: the digits 0–9 and the letters A–F. Because it has sixteen symbols, its base is 16. Each hexadecimal digit corresponds to a group of four binary digits, making it a convenient way to represent memory addresses, machine code, and other low-level data in computers.

The octal number system has a base of 8, which means it uses eight symbols: 0 to 7.
Since 8 = 2³, each octal digit can represent exactly three binary digits (bits). Same goes for hexadecimal number system.

You can learn how to convert between these number systems from this detailed article.

Now, let’s talk about the binary number system. We are familiar with representing positive numbers using unsigned binary. But how do we represent negative numbers? For this, we use the two’s complement method, which is the standard way to represent signed binary numbers.

Two's complement method

Negative of any decimal number is mathematically found by subtracting that number from 0. The same applies to the binary number system. In the signed binary number system, the most significant bit (the leftmost bit) indicates the sign of the number.

See the image below if you are not familiar with the most and least significant bits in the binary representation of a number:

Let’s take the example of decimal 7 whose binary representation is 0111. Its binary number system is stored in 4 bits. Zero can be represented as 0000 (in 4 bits). In 4-bit representation, if a fifth bit is present in the leftmost position, it is discarded due to lack of space. So, we can represent zero as 10000 (the bit 1 will be discarded). Now, 10000 can be written as the sum of 1111 and 1. We can then proceed as follows:

Essentially, the negative of a binary number will be its complement added to 1. This method is called as the two’s complement method.

Bitwise Operators

In the decimal number system, we use arithmetic operators like +, -, *, and / to perform mathematical operations. In computing, numbers are represented in binary, and in addition to arithmetic operators, we also use bitwise operators like &, |, ^, ~, >>, and << to manipulate individual bits. Let’s discuss each of these operators.

AND Operator (&)

This operator performs bit-by-bit AND operation on two values. This means that for each bit in the operands, the resulting bit is set to 1 only if both corresponding bits in the operands are 1; otherwise, it is set to 0.

Observation: The AND operation of any number with 1 gives the least significant bit (LSB) of that number.
Example: 5 & 1 results in 1 because 101 & 001 gives its LSB, which is 1.

OR Operator (|)

This operator performs a bitwise OR operation between two operands, setting each resulting bit to 1 if at least one of the corresponding bits in the operands is 1; otherwise, it is set to 0.

XOR Operator (^)

XOR stands for exclusive OR. This operator performs a bitwise comparison between two operands, setting each resulting bit to 1 if the corresponding bits in the operands are different; otherwise, it is set to 0.

Observations:

The XOR operation on any number with 1, results in a number where the least significant bit (LSB) is flipped.
Example: 3 ^ 1 results in 2 because 11 ^ 01 changes the LSB to 0 in this case.
The XOR operation on any number with 0 results in the same number.
Example: 4 ^ 0 results in 4 because 100 ^ 000 gives 100, which is 4.
The XOR operation on any number with itself results in 0 because there are no differing bits.
Example: 5 ^ 5 results in 0 because 101 ^ 101 gives 0 as there are no bits that differ.

Complement Operator (~)

The complement operator gives the bitwise inverse of a number, flipping each bit from 0 to 1 and from 1 to 0.

Left Shift Operator (<<)

The left shift operator is a bitwise operator that shifts the bits of a number to the left by a specified number of positions. Example: 5 << 1 gives 10 because shifting the bits of 5 (which is 101 in binary) one position to the left results in 1010, which is 10 in decimal. If we shift twice (5 << 2), we will get 20 because shifting the bits of 5 (which is 101 in binary) two positions to the left results in 10100, which is 20 in decimal. Therefore, each left shift operation effectively multiplies the number by 2 for each position shifted. In general, if the number is shifted k times, it is multiplied by 2^k.

Right Shift Operator (>>)

The right shift operator is a bitwise operator that shifts the bits of a number to the right by a specified number of positions. Example: 8 >> 1 gives 4 because shifting the bits of 8 (which is 1000 in binary) one position to the right results in 0100, which is 4 in decimal. If we shift twice (8 >> 2), we would get 2 because shifting the bits of 8 (which is 1000 in binary) two positions to the right results in 0010, which is 2 in decimal. Therefore, each right shift operation effectively divides the number by 2 for each position shifted. In general, if the number is shifted k times, it is divided by 2^k.

Core Number Theory

Prime Number

A prime number is a natural number greater than 1 with exactly two positive divisors: 1 and itself. To determine if a number is prime, we typically check divisibility from 2 up to n−1 since it is always divisible by 1 and itself.

int n = 24;
boolean isPrime = true;
for (int i = 2; i < n; i++) {
    if (n % i == 0) {
        isPrime = false;
        break;
    }
}
if (isPrime) {
    System.out.println("Prime");
} else {
    System.out.println("Not prime");
}

The above algorithm makes a maximum of n - 2 (2 to n-1) checks. So, its time complexity is O(N). Let's see if we can optimise it. If we closely examine the factors of any number, they appear in pairs (one smaller and one larger). Mathematically, we can say that for every divisor d > √n (like d = 6), there exists a corresponding divisor $\frac {n} {d} < \sqrt n$ (like 4). Therefore, checking beyond √n is redundant.

If we look into the above possible pairs of factors of 24, we can see that we're checking divisibility of each pair twice. It is sufficient to check divisibility only up to √n since √24 ≈ 4.89, checking up to 4 is enough. Hence, we can reduce the number of computations from the order of N to √N.

int n = 24;
boolean isPrime = true;
for (int i = 2; i * i <= n; i++) {
    if (n % i == 0) {
        isPrime = false;
        break;
    }
}
if (isPrime) {
    System.out.println("Prime");
} else {
    System.out.println("Not prime");
}

The time complexity of this algorithm is now O(√N).

Prime Numbers in Range

Let's say we need to find prime numbers between two certain numbers. The simplest idea would be to check if each of the numbers between them is prime or not.

public class Main {
    public static void main(String[] args) {
        int n = 50;
        displayAllPrimes(n);
    }
    
    public static void displayAllPrimes(int n){
        for (int i = 2; i <= n; i++) {
            if (isPrime(i)) {
                System.out.print(i + " ");
            }
        }
    }
    
    public static boolean isPrime(int n){
        if (n <= 1) return false;
        for (int i = 2; i * i <= n; i++) {
            if (n % i == 0) return false;
        }
        return true;
    }
}

In the above program, the isPrime() method takes O(√N) to check whether a certain number is prime. The displayAllPrimes() method calls the isPrime() method approximately N times. So, the time complexity of the entire algorithm is O(N√N). If we carefully observe the numbers we're checking for prime, we'll notice that there are a number of redundant checks. For example, if we already know that 2 is a prime number then its multiples won't be prime.

Similarly for the rest of the numbers, the below image shows the multiples of smaller prime numbers we've checked earlier.

The unmarked numbers turn out to be the prime numbers we're finding in that range of 2 to 50. This is known as the Sieve of Eratosthenes.

public class Sieve {
    public static void main(String[] args) {
        int n = 50;
        boolean[] isComposites = new boolean[n+1]; // size is n+1 to include n 
        sieve(n, isComposites);
    }

    public static void sieve(int n, boolean[] isComposite){
        for (int i = 2; i * i <= n; i++) {
            if (!isComposite[i]) {
                for (int j = 2 * i; j <= n; j += i) {
                    isComposite[j] = true;
                }
            }
        }

        for (int i = 2; i <= n; i++) {
            if (!isComposite[i]) {
                System.out.print(i + " ");
            }
        }
    }
}

In the program above, we check for multiples up to √N because large numbers can be factored using smaller numbers' multiples. The number of times the inner loop (the loop responsible for marking the composite numbers) runs for each prime number P is $\frac {N} {P}$. Therefore, total number of times the inner loop runs will be:

Hence, the time complexity of this algorithm is O(N loglog(N)).

Newton Raphson Method

The Newton Raphson method is an iterative method of finding better approximations to the roots of a real-valued function. The best linear approximation to any differential function near the point $x = x_i$ will be its tangent with the equation:

where x_i is the ith iterative approximation of root

The root of the tangent equation will be the next iterative approximation x_{i+1} when it intercepts the x-axis (y = 0).

Now, if we want to find the square root of any number (say n), we can take f(x) = x² - n. The root of that equation will give us the closest approximation of √n.

You can view this animated image from Wikipedia, which visually demonstrates all the iteration of approximated roots of f(x).

Let's try to write a program for finding the approximate square root of any number.

public class NewtonRaphsonSqrt {
    public static void main(String[] args) {
        System.out.println(sqrt(43));
    }

    public static double sqrt(double n) {
        double x = n;
        double root;
        while (true) {
            root = 0.5 * (x + (n/x));

            if (Math.abs(root - x) < 0.5) { // Error threshold, can be adjusted for more precision
                break;
            }
            x = root;
        }
        return root;
    }
}

Reducing the error threshold, currently set at 0.5, will result in a more accurate approximation of the square root.

Modular Arithmetic

It is a system of arithmetic operations for integers where the numbers "wrap around" when exceeding a certain number called as the modulus. For a given integer m ≥ 1, it is called a modulus if the difference of two integers a and b (a - b) is an integer multiple of m i.e. a - b = k*m (where k is an integer). The integers a and b are said to be congruent modulo m and is mathematically denoted by a ≡ b (mod m).

The parentheses mean that (mod m) applies to the entire equation, not just to the right-hand side (here, b). In particular, (a mod m) = (b mod m) is equivalent to a ≡ b (mod m), and this explains why "=" is often used instead of "≡" in this context.

The congruence relation is written as *a = b + k\m**.

Source: Wikipedia

In programming, we don’t write congruences directly. Instead, we use the % operator, which computes the remainder. The % operator is the practical realization of the congruence relation. For example: ≡ (mod m) ⇔ (a % m) == (b % m) in code.

The range of (a % m) is always in the range (\[0, m-1\]) when (m > 0). This ensures the remainder is non-negative, which is crucial for consistent modular arithmetic in programming.

Properties:

Addition Property: When adding two numbers, their remainders modulo (m) add up, but if the sum exceeds (m), subtracting (m) (i.e., taking modulo again) brings it back within the valid range.
Subtraction Property: Subtraction can lead to negative results, so adding (m) before taking modulo ensures the result stays within (\[0, m-1\]).
Multiplication Property: Multiplying the remainders and then taking modulo keeps the product within the modular system, preserving equivalence.
Division Property: Division is not straightforward in modular arithmetic. For division by (b) modulo (m) to be valid, (b) must have a modular inverse modulo (m), which exists only if gcd(b, m) = 1.

Modular multiplicative inverse of an integer b is the solution (which exists only when b and m are coprime) of the equation: ax ≡ 1 (mod m).

Bézout's Identity

It is a theorem which related two arbitrary integers with their greatest common divisor (GCD). Mathematically,

where, x and y are integers.

If gcd(a, b) = d, then every integer linear combination ax + by is a multiple of d.

For example, if a = 3 and b = 16, then 3*(-5) + 16*1 = 1 = gcd(3, 16).
Let's take another example: a = 8 and b = 18. Then, 8*(-2) + 18*1 = 2 = gcd(8, 18).

The coefficients x and y can be found using the Extended Euclidean algorithm and the gcd can be calculated using the Euclidean algorithm.

Euclidean Algorithm

The Euclidean Algorithm is one of the oldest and most efficient methods to compute the greatest common divisor (GCD) of two integers. Since Bézout’s identity relies on the GCD, understanding this algorithm is essential. It's based on the principle that if

Effectively, a is reduced by multiples of b until only the remainder is left. Therefore, gcd(a, b) = gcd(b, a % b).

Let’s compute gcd(514, 106) using the Euclidean Algorithm.

We start by dividing the larger number by the smaller one and continue replacing the pair with (b, a % b) until the remainder becomes zero:

514 = 106*4 + 90 → gcd(514, 106) = gcd(106, 90)
106 = 90*1 + 16 → gcd(106, 90) = gcd(90, 16)
90 = 16*5 + 10 → gcd(90, 16) = gcd(16, 10)
16 = 10*1 + 6 → gcd(16,10) = gcd(10, 6)
10 = 6*1 + 4 → gcd(10, 6) = gcd(6, 4)
6 = 4*1 + 2 → gcd(6, 4) = gcd(4, 2)
4 = 2*2 + 0 → gcd(4, 2) = 2

Therefore, gcd(514, 106) = 2.

public static int gcd(int a, int b) {
    if (a == 0) {
        return b;
    }
    return gcd(b % a, a);
}

We can also calculate the LCM of two numbers using their GCD with the formula:
\[\text{LCM}(a, b) = \frac{|a \times b|}{\text{GCD}(a, b)}\]

public static int lcm(int a, int b) {
    return a * b / gcd(a, b);
}

Extended Euclidean Algorithm

This algorithm is an extension of the Euclidean Algorithm which computes the coefficients of the Bézout's identity. We start with the gcd of the two numbers and eventually represent that as a linear combination of those two numbers.

For example, we have found gcd(514, 106) = 2. We start with the last non-zero remainder step: 6 = 4 + 2 ⇒ 2 = 6 - 4.
Then, from previous steps, we can write 6 = 16 - 10 and 4 = 10 - 6. We'll back-substitute them in the above equation.
∴ 2 = (16-10) - (10 - 6) = 16 - 2*10 + 6 = 16 - 2*10 + (16 - 10) = 2*16 - 3*10
∴ 2 = 2*16 - 3*(90 - 16*5) = 17*16 - 3*90
∴ 2 = 17*(106 - 90) - 3*90 = 17*106 - 20*90
∴ 2 = 17*106 - 20*(514 - 4*106) = (-20)*514 + 97*106

Hence, (-20)*514 + 97*106 = 2 = gcd(514, 106). So, the coefficients (Bézout's coefficients) of Bézout's identity would be -20 and 97.

We can utilise the recursion stack to keep track of the steps performed in Euclidean Algorithm. Below is the code for this algorithm:

static int gcdExtended(int a, int b, int[] xy) {
    if (a == 0) {
        xy[0] = 0; // x
        xy[1] = 1; // y
        return b;
    }

    int[] temp = new int[2];
    int gcd = gcdExtended(b % a, a, temp);

    // Update x and y using results of recursion
    xy[0] = temp[1] - (b / a) * temp[0];
    xy[1] = temp[0];

    return gcd;
}

Conclusion

In this article, we explored fundamental mathematical concepts that are crucial for understanding and implementing data structures and algorithms. We delved into number systems, including binary, octal, and hexadecimal, and discussed how computers represent numbers using the two's complement method for signed integers. We also covered bitwise operators and their applications in manipulating individual bits of data.

⭐ Check out the DSA GitHub repo for more code examples.

Mastering FizzBuzz and Factorial Problems for Coding Interviews

Mon, 23 Feb 2026 19:37:52 +0000

In the competitive tech landscape, mastering algorithmic problems is essential for job seekers and developers alike. Here, we dive into two iconic challenges: FizzBuzz and Factorial. Not only do these tasks showcase your coding abilities, but they also reflect problem-solving acumen, which is crucial in technical interviews.

FizzBuzz

FizzBuzz is a common programming task that tests your understanding of loops and conditionals. The challenge is simple: print the numbers from 1 to 100. For multiples of three, output 'Fizz' instead of the number, and for multiples of five, output 'Buzz'. For numbers that are multiples of both three and five, output 'FizzBuzz'.

Solution

Here's a straightforward approach:

Use a loop to iterate through numbers from 1 to 100.
Check for conditions in this order: if the number is a multiple of both 3 and 5, then print 'FizzBuzz'.
If only a multiple of 3, print 'Fizz'; if only a multiple of 5, print 'Buzz'; otherwise, print the number itself.

for i in range(1, 101):
    if i % 15 == 0:
        print("FizzBuzz")
    elif i % 3 == 0:
        print("Fizz")
    elif i % 5 == 0:
        print("Buzz")
    else:
        print(i)

Performance Analysis

The time complexity here is O(n), where n is the range limit (100 in this case), as you are iterating through the loop once for each number. The space complexity is O(1), as you’re using a fixed amount of space regardless of input size. FizzBuzz is efficient and can be easily adapted for larger ranges.

Factorial

The Factorial problem is another fundamental algorithm that is often featured in interviews. The task is to calculate the factorial of a given number n (denoted as n!). The factorial of n is the product of all positive integers less than or equal to n.

Recursive Solution

One simple way to solve this problem is through recursion:

def factorial(n):
    if n == 0 or n == 1:
        return 1
    else:
        return n * factorial(n - 1)

Iterative Solution

Alternatively, you can implement it iteratively:

def factorial(n):
    result = 1
    for i in range(2, n + 1):
        result *= i
    return result

Performance Analysis

For both approaches, the time complexity is O(n). The recursive solution could face issues with deep recursion if n is large due to stack overflow, while the iterative method is safer in practice. Both solutions have a space complexity of O(n) for recursion and O(1) for the iterative version.

Conclusion

The FizzBuzz and Factorial problems are not just trivial exercises; they represent fundamental concepts in programming that are crucial for technical interviews. By mastering these problems, you show potential employers your ability to think logically and solve problems under pressure. Remember, the key to success lies in understanding the underlying concepts and being able to articulate your thought process during interviews.

Engage with these problems regularly, and soon enough, they will become second nature.

How My Worst Complexity Solution Beat 100% Runtime

Sun, 22 Feb 2026 22:53:29 +0000

I recently solved the Leetcode 868. Binary Gap problem in Go, and encountered something interesting.

My supposedly worst solution — with an O(n log n) time complexity — ended up beating 100% of submissions in runtime.

Meanwhile, the "optimal" space version used more memory.

That made me realise something important:

Big-O complexity might not always dominate — especially when input size is tightly bounded.

In this case, the maximum binary length was only 32 bits. Sorting a handful of integers becomes effectively constant time. The theory said one thing. The measurements told another story.

I wrote a short breakdown explaining:

Why does this happen
How online judges measure performance
When asymptotic complexity truly matters
And how to implement a truly optimal bitwise version

If you're into performance reasoning and algorithm trade-offs, you might enjoy this one.

https://dev.to/rezzcode/leetcode-sunday-4-1025

Implementing and Comparing Searching Algorithms for Dev Tools

Tue, 17 Feb 2026 13:40:33 +0000

Searching for elements within data structures is a common task in software development. In this guide, we will implement and compare two fundamental searching algorithms: linear search and binary search. Let’s dive in.

Linear Search

Linear search is the simplest searching algorithm. It checks each element in a list sequentially until the desired element is found or the list ends.

Implementation

Here’s how you can implement linear search in JavaScript:

function linearSearch(arr, target) {
    for (let i = 0; i < arr.length; i++) {
        if (arr[i] === target) {
            return i; // Return the index of the found element
        }
    }
    return -1; // Target not found
}

Pros and Cons

Pros:
- Simple to implement.
- No need for sorted data.
Cons:
- Time complexity of O(n), making it inefficient for large datasets.

Binary Search

Binary search is more efficient but requires that the array be sorted. It divides the array into halves and eliminates one half based on the comparison with the target element.

Implementation

Here’s the implementation of binary search in JavaScript:

function binarySearch(arr, target) {
    let left = 0;
    let right = arr.length - 1;
    while (left <= right) {
        const mid = Math.floor((left + right) / 2);
        if (arr[mid] === target) {
            return mid; // Return the index of the found element
        } else if (arr[mid] < target) {
            left = mid + 1;
        } else {
            right = mid - 1;
        }
    }
    return -1; // Target not found
}

Pros and Cons

Pros:
- Significantly faster with a time complexity of O(log n).
- Efficient for large datasets that are sorted.
Cons:
- Requires sorted data, adding an overhead if the data isn't sorted.

Practical Comparison

To help make the decision between these two algorithms, let’s look at a practical example. Imagine you are building a Dev Tools application that searches through user data.

If your dataset is small or unsorted (like a quick lookup of recently added users), linear search could be your go-to algorithm due to its simplicity. However, when dealing with a large, sorted dataset like a list of users sorted by their signup dates, binary search would save both time and resources.

Conclusion

Choosing the right searching algorithm depends largely on the size and nature of your data. While linear search is straightforward and easy to implement, its inefficiency can be a bottleneck for larger datasets. Binary search, on the other hand, shines in sorted environments, optimizing performance significantly.

In your next Dev Tools project, consider the characteristics of your dataset to choose the most suitable searching algorithm. Happy coding!

Demystifying Time and Space Complexity for Beginners

Wed, 04 Feb 2026 02:15:26 +0000

Imagine you've just created an algorithm, and it works lightning-fast on your brand-new computer. You're thrilled with the results and can't wait to share your success, so you ask your friend to give it a try. However, when your friend runs the same algorithm on his older computer, it doesn't perform as well and turns out to be quite slow. This unexpected result leaves you both puzzled and curious about what might be causing the difference in speed.

Why We Need Complexity Analysis?

As we saw in the problem mentioned earlier, the same algorithm can take different amounts of time to run depending on the machine it's on. In real-world situations, we often need to compare multiple algorithms to choose the best and fastest one. Hardware differences can lead to incorrect conclusions. That's why complexity analysis was introduced — to standardize the comparison between algorithms by ignoring hardware differences.

The concept of complexity measures how performance changes as the input size increases. We always test with large input sizes to reflect real-world scenarios where we might be dealing with vast amounts of data.

What is Time Complexity?

Time complexity measures how the running time increases as the input size grows. It focuses on the number of operations an algorithm performs, not the actual time it takes.

What is Space Complexity?

Space complexity is a measure of the amount of memory an algorithm uses as the size of the input increases, including both the input space and the auxiliary space (the extra space taken).

I want to point out that in recursion, multiple recursive calls use a certain amount of stack space, which is also considered auxiliary space.

Why do we need Asymptotic Notations?

In practical situations, we often need to compare algorithms to find the most efficient one. Remembering the exact function of time (or space) taken as the input size n changes is challenging. For instance, the time it takes for an algorithm to finish can be expressed as:

This is complex and not practical for comparison. So, we use asymptotic notations to simplify these expressions and focus on the most significant factors that affect performance (or in other words, approximate them to a simpler function), making it easier to compare different algorithms.

Big-O Notation

Big-O notation is a mathematical concept used to describe an upper bound on the growth rate of an algorithm’s time or space complexity. Formally, it means that for sufficiently large input size n, the complexity function (n) does not grow faster than a constant multiple of another function (n).

Mathematically,

if and only if the below condition is satisfied.

where, c is a constant and n0 is the threshold value above which the condition is satisfied for all large numbers.

For example, let’s say:

We need to find a suitable g(n) that will satisfy the condition. So, we can proceed as follows:

Comparing this with the given condition, we get c = 21 and g(n) = n².

If we put n as 1, we get f(1) as 21 and 21n² as 21. So, the equality holds and 1 can be a potential threshold value. We will still check for large values of n like 5 in which case the inequality holds. So, the value of n_0 turns out to be 1.

If we look at the same problem again, we can argue as follows:

This gives us g(n) as n³. We could choose other higher powers of n, but 21n² is the most accurate approximation of the original function. Therefore, we should always choose the smallest upper bound to get the closest curve fit.

Big-Omega Notation

Big-Omega notation is a mathematical way to express the asymptotic lower bound of a function (time or space complexity). It provides a formal way to describe the minimum time an algorithm will take to complete, regardless of the input size.

Mathematically, f(n) = Omega(g(n)) if and only if the below condition is satisfied.

f(n) ≥ c.g(n), n ≥ n0

where, c is a constant and n0 is the threshold value above which the condition is satisfied for all large numbers.

For example, let’s say:
f(n) = 16n⁴+13n+12

We can easily conclude that:
f(n) ≥ 16n⁴
If we put n = 1, then f(1) is 41 which is ≥ 16. Therefore, we can say:
f(n) = Omega(n⁴)
for all n ≥ 1.

Similarly, as we have seen in the case of Big-O, f(n) is ≥ n³, ≥ n², ≥ n, etc. But we should n⁴ as g(n) because 16n⁴ is the tightest polynomial that consistently under-approximates f(n) without overshooting.

Big-Theta Notation

Big-Theta notation is a mathematical way to express both the asymptotic lower and the upper bounds of a tightly bounded function (time or space complexity).

Mathematically,

f(n) = Theta(g(n))

if and only if the below condition is satisfied.

0 ≤ c1.g(n) ≤ f(n) ≤ c2.g(n), n ≥ n0

where, c1 and c2 are constants and n0 is the threshold value above which the condition is satisfied for all large numbers.

For example, let’s say:
f(n) = 16n²+12

We can proceed as follows:

Comparing this with the aforementioned inequality, we get g(n) = n².

If we set n to 1, the inequality holds true. Checking with the next number, 2, the inequality still holds. Therefore, n0 must be 1.

Hence, we can asymptotically say:

for all n ≥ 1.

Best, Average and Worst Case

There are three scenarios to consider when analyzing algorithms: the best case, the average case, and the worst case. Of these, the worst case provides the most accurate estimate of the time or space an algorithm will require in the most demanding situation, often reflecting real-world scenarios. Hence, the worst case is the most usually preferred.

How to calculate Time Complexity for iterative programs?

Let’s understand the procedure to calculate time complexity through examples.

Example 0

The below code is for printing first N natural numbers.

for (int i = 1; i <= n; i++) {
    System.out.println(i);
}

In the code snippet above, the loop runs N times (from 1 to N) and each time we are printing a number (which takes a constant amount of time). Therefore, we are performing constant amount of work N times. So, the growth rate will be linear. Hence, this algorithm has a time complexity of O(N).

Example 1

int i = 1;
int s = 1;
while (s <= n) {
    i++;
    s = s + i;
    System.out.println(s);
}

We should analyse the values of i and s to check how many times the print statement (a constant time work) is executed.

In the above table, we can observe that:

3 = 1 + 2 = (2*(2+1)) / 2
6 = 1 + 2 + 3 = (3*(3+1)) / 2
10 = 1 + 2 + 3 + 4 = (4*(4+1)) / 2

So, asymptotically, since constants don't change the growth rate of s, it grows on the order of k². Therefore, we take the values of i and s as k and k² respectively for the kth iteration.

The while loop will stop when s > n, which means k² > n. Therefore, k must be equal to √n. As a result, the constant time task of printing the value of s will happen √n times. Thus, the time complexity of this code snippet is O(√n).

Example 2

for (int i = 1; i <= n; i++) {
    for (int j = 1; j <= i*i; j++) {
        for (int k = 1; k <= n/2; k++) {
            System.out.println(k);
        }
    }
}

We need to analyze how often the constant task of printing the value of k happens. To do this, we'll create a table showing how many times the loops for i, j, and k run.

The outermost for loop (loop i) runs until i equals n. Therefore, the total time the innermost loop runs will be the sum of the times it executes for each combination of i and j values.

Therefore, the constant work is performed in the order of n⁴. Hence, the time complexity for this code snippet is O(n⁴).

Types of Recurrence Relations

There are two types of recurrence relations:

Linear Recurrence Relation: These express the next term as a linear combination of previous terms (e.g., Fibonacci sequence).
Divide and Conquer Relation: These arise in recursive algorithms where a problem is divided into subproblems, solved recursively, and combined (e.g., Merge Sort, Binary Search).

How to calculate Time Complexity for recursive programs?

There are three ways to calculate time complexity given the recurrence relation:

Back-Substitution Method
Recursive Tree Method
Akra–Bazzi Method

Let’s learn these methods in detail.

Back-Substitution Method

Let’s take the following linear recurrence relation as an example:

We'll start by finding T(n-1) and T(n-2), and then substitute them back into the equation. Next, we'll generalize the equation for the kth substitution and try to substitute the constant given for the base condition (i.e., when n = 0).

Therefore, we can write T(n) as:

Now, T(n-k) will be equal to T(0) when n-k = 0, i.e. when k = n.

Hence, time complexity of this T(n) function would be O(N).

Recursive Tree Method

Let’s take the following linear recurrence relation as an example:

We'll try to visualize the recursive calls and the constant values at each call as a recursive tree.

The total time taken for the complete recursive function will be the cumulative sum of work done at each level of recursion, with each level contributing an amount equal to its index (n). Therefore, total time = 1 + 2 + ... + (n-2) + (n-1) + n = (n*(n+1)) / 2, which is a quadratic growth of time. Hence, time complexity will be O(N²).

Let's take an example of a divide-and-conquer recurrence relation and try to solve it using this method.

We’ll again draw the recursive tree to visualise the recursive calls made.

To find the total time complexity, we simply look at the work done across the tree horizontally. At the top level, the work is n. At the second level, we have two branches doing n/2 work, which again sums to n. Surprisingly, if you sum the work across any horizontal level of this tree, it always equals n. Therefore, the total time is simply the work per level (n) multiplied by the number of levels (the height of the tree).

To find the total number of levels, we'll assume the last level is the kth level. At the ith level, the input to the function is:

So, at the last level,

which means:

leading to
Hence, time complexity will be *O(n\log n)**.

Akra-Bazzi Method

This method is a generalization of the Master Theorem for divide-and-conquer recurrences. Mathematically, if the function T(x) can be represented as

where:

p must be such that
and for all i

Then,

For example, let's consider the following recurrence relation, which has been solved using other methods:

Comparing with the standard equation, we get:

a1 = 2
b1 = 1/2
g(n) = n

We can proceed as follows, to find the value of p.

Therefore, time complexity of T(n) would be:

How to calculate Space Complexity?

For Iterative Programs

Let's look at the two code snippets below as examples 1 and 2:

// Example 1
int[] arr = {54, 26, 35, 85, 90};
int max = arr[0];
for (int i = 1; i < arr.length; i++) {
    if (arr[i] > max) {
        max = arr[i];
    }
}
System.out.println("The maximum value in the array is: " + max);

// Example 2
int[] arr = {54, 26, 35, 85, 90};
int[] revArr = new int[arr.length];
for (int i = 0; i < arr.length; i++) {
    revArr[i] = arr[arr.length - 1 - i];
}
for (int num : revArr) {
    System.out.println(num);
}

In the first example, we're finding the maximum element in the array. If we closely analyze the algorithm, it uses only a constant number of extra variables (max and the loop counter i), regardless of the size of the input array. Since the extra space needed does not increase with the input size, the space complexity is O(1).

In the second example, the algorithm reverses the array by creating a new array revArr whose size depends on the input size N. Apart from this array, only a constant number of extra variables (such as loop counters) are used. Since the auxiliary space required grows linearly with the input size, the space complexity is O(N).

We can modify the algorithm to reverse the array in place by performing swap operations between elements from the beginning and end of the array. This approach eliminates the need for an additional array. The algorithm uses only a constant number of extra variables (such as temp and the loop counter), regardless of the input size. Therefore, the auxiliary space complexity of this approach is O(1).

// Modified Example 2
int[] arr = {54, 26, 35, 85, 90};
for (int i = 0; i < arr.length / 2; i++) {
    // Swap to reverse the array in-place
    int temp = arr[i];
    arr[i] = arr[arr.length - 1 - i];
    arr[arr.length - 1 - i] = temp;
}
for (int num : arr) {
    System.out.println(num);
}

For recursive programs

In recursive programs, each recursive function call is added to the call stack, creating a stack frame (or activation record) for each call.

Call Stack is a data structure used in programming languages to manage the functions calls and their execution. It works on LIFO (Last-in, First-out) principle where the most recently called function is executed first and removed from the stack once completed.

Let’s look at the following recurrence relation, which we have already solved for time complexity:

We need to analyze the recursive calls (especially their order). So, we’ll take a look at its recursive tree:

First, the leftmost branches are called, and after they execute, each of these function calls is removed from the call stack, starting from the bottom of the recursive tree. Then, the function calls in their respective right branches are executed. Here is an image of the flow of execution of the leftmost branches:

This is how the call stack would appear until the T(1) function completes its execution:

The total space used in the call stack for executing the leftmost branches is equal to the height of the recursive tree (which is also known as maximum recursion depth), which is log n as calculated before.
This is the maximum space used in the complete execution of the program as for further calls (suppose from T(n/2²) to second T(n/2³)), the stack frames of the previous calls (the series of calls from the first T(n/2³) and T(n/2³) itself) are removed.

This is the complete view of the function calls:

Hence, space complexity would be O(log n).

Conclusion

Understanding time and space complexity is crucial for evaluating and optimizing algorithms, especially as input sizes grow. By analyzing complexity, we can make informed decisions about which algorithms are most efficient, regardless of hardware differences. Asymptotic notations like Big-O, Big-Omega, and Big-Theta provide a standardized way to express these complexities, focusing on the most significant factors affecting performance.

What is Recursion? A Comprehensive Overview

Fri, 16 Jan 2026 05:34:36 +0000

A Problem

Let’s start with a problem: I need to print first 10 natural numbers.

There are several ways to solve this problem. But let's say we need to solve it using functions without using loops or calling a function more than once. The simplest way is to call 10 functions, each printing one of the numbers from 1 to 10.

public class Problem {
    public static void main(String[] args) {
        print1();
    }

    public static void print1(){
        System.out.println(1);
        print2();
    }

    public static void print2(){
        System.out.println(2);
        print3();
    }

    public static void print3(){
        System.out.println(3);
        print4();
    }

    public static void print4(){
        System.out.println(4);
        print5();
    }

    public static void print5(){
        System.out.println(5);
        print6();
    }

    public static void print6(){
        System.out.println(6);
        print7();
    }

    public static void print7(){
        System.out.println(7);
        print8();
    }

    public static void print8(){
        System.out.println(8);
        print9();
    }

    public static void print9(){
        System.out.println(9);
        print10();
    }

    public static void print10(){
        System.out.println(10);
    }
}

Let’s try to understand how the function calls are happening internally.

I’ll try to debug that code by putting the debug pointer at the line calling print1() function.

When you start the debug window in IntelliJ IDEA, you can see the function calls in the call stack on the left side of the window.

When print1() function is called, it appears on top of the main() function in the call stack.

After print1() function displays 1 in the output, it calls print2() function and so on. Finally, print10() function gets called.

After printing 10, the print10() call finishes execution, so its stack frame is removed (popped) from the call stack and control returns to the caller (which is print9() function).

Finally, each of the stack frames are removed until the main function completes its execution.

However, the code is messy!

The Idea of Recursion

If we look closely, each of the 10 functions we defined earlier has the same structure. They each print a number and then call the next function in order. If we were given the task to print natural numbers upto a million, defining a million functions would be terrific.

To summarize, we solved the bigger problem of printing the first 10 natural numbers by breaking it down into 10 smaller parts. Each function handles the task of printing one number at a time.

Hence, we can think of recursion as breaking down a problem into sub-problems until it becomes trivial.

If we look at the code again, each function calls the next one until the last function (print10()). So, we can rewrite the function to print the current number and then call itself with the next number in sequence until it reaches number 10.

public class Problem {
    public static void main(String[] args) {
        print(10);
    }

    public static void print(int n) {
        // Base Condition: Exit when n is 0 or negative
        if (n <= 0) {
            return;
        }
        // Recursive call/relation: Calls itself by passing the next smaller element
        print(n - 1);
        // Return Flow / Work after recursion
        System.out.println(n);
    }
}

This is called as recursion, and the print() function is called as recursive function. There are three parts of any recursive function:

Base Condition: The condition where the recursion stops
Recurrence Relation: This relation defines how the problem is reduces to smaller sub-problems.
Return Relationship/Flow: This defines how the result of the smaller sub-problem is used when the function call returns.

Recursive Tree

To better understand how the function call happens, we need to know about recursive tree which is a visual representation of the recursive calls. The below image shows a recursive tree for our program.

Finding a Fibonacci number using recursion

The nth Fibonacci number is equal to the sum of the (n-1)th and (n-2)th Fibonacci numbers. So, the problem of finding the nth Fibonacci number can be broken down to smaller problems. Hence, this problem can be solved using recursion.

We got the following recurrence relation:

So, the recursive tree for Fibo(4) will be:

We know that the first 2 numbers of the Fibonacci series are 0 and 1. So, value of Fibo(1) and Fibo(0) are 1 and 0 respectively. Hence, the function must stop calling itself again when the value of n becomes 1 or 0. Therefore, this becomes the base condition.

Here’s the code for finding nth Fibonacci number using recursion:

public class Problem {
    public static void main(String[] args) {
        System.out.println(fibo(5));
    }

    public static int fibo(int n) {
        // Base Condition
        if (n < 2) {
            return n;
        }
        // Recurrence Relation and Return Relationship
        return fibo(n-1) + fibo(n-2);
    }
}

Using the recursive tree, we can better understand the order of function calls. First, Fibo(4) calls Fibo(3) (since fibo(n-1) is written first), which then calls Fibo(2). Next, Fibo(2) calls Fibo(1). Since no further function call is made, Fibo(1) returns its value as 1.

To calculate the value of Fibo(2), we need the value of Fibo(0), so Fibo(0) is called and returns 0. Then, Fibo(1) is called because it is needed to compute the value of Fibo(3).

The value of Fibo(4) depends on Fibo(2), which in turn depends on Fibo(1) and Fibo(0), leading to those function calls.

Finally, Fibo(4) computes the sum and returns the value as 3.

Tail Recursion

The most important type of recursive function is the tail recursive function. This is a recursive function where the last operation is the recursive call itself. If we rewrite the initial recursive program that prints natural numbers from 1 to 10 using the code below, we can make it a tail recursive function.

public class Problem {
    public static void main(String[] args) {
        print(1, 10);
    }

    public static void print(int current, int n) {
        // Base Condition: Exit when current exceeds n
        if (current > n) {
            return;
        }
        // Print the current value
        System.out.println(current);
        // Tail recursive call
        print(current + 1, n);
    }
}

The recursive Fibonacci function is not a tail recursive function because, after making the Fibo(n-1) and Fibo(n-2) recursive calls, it adds their returned values. Therefore, the last operation is not the recursive call itself.

Binary Search using recursion

In the binary search algorithm, we always check if the middle element is equal to the target element. If the check fails, the search space is cut in half each time. This means the task of checking for equality is done in smaller, reduced sections of the original array. Hence, the binary search algorithm can be implemented using recursion.

The binary search algorithm stops when the equality check is met, so the recursion must end when this condition is satisfied. Therefore, the equality check becomes the base condition.

As the search space of the array is halved each time, the start and end values of the search space are needed in every recursive function call. Therefore, the start and end pointer values will be included in the function parameters. The index of the middle element (mid) depends on the start and end index values, so it doesn't need to be passed to future recursive calls. Therefore, mid will be calculated within the function.

Based on whether the middle element is greater or less than the target element, the function will make its next recursive call with updated start or end pointer values. The result of this call will be the position of the target element if it exists in the array, or an indication that the element is not present.

public class Problem {
    public static void main(String[] args) {
        int[] arr = {12, 34, 54, 72, 88, 99, 101, 123, 145, 167};
        int target = 101;
        int result = binarySearch(arr, target, 0, arr.length - 1);
        System.out.println("Element found at index: " + result);
    }

    public static int binarySearch(int[] arr, int target, int start, int end) {
        if (start > end) {
            return -1;
        }
        int mid = start + (end - start) / 2; // to avoid integer overflow
        if (arr[mid] == target) {
            return mid;
        } else if (arr[mid] < target) {
            return binarySearch(arr, target, mid + 1, end);
        } else {
            return binarySearch(arr, target, start, mid - 1);
        }
    }
}

We perform two tasks:

Comparing the middle element with the target element. This takes a constant amount of time. So, time complexity of comparison is O(1).
Searching for the target element in half of the previous search space.

So, the recurrence relation would be:

where F is the binary search function and N is the size of the array.

The relation above means that when a target number is provided, a comparison is first made. Then, the number is searched for in half of the previous search space of the array.

Space Complexity

As in recursion, we are calling the function n times and each function call goes in the call stack, so space complexity of a recursive algorithm is not constant.

Conclusion

Recursion is a powerful programming concept that allows complex problems to be broken down into simpler, more manageable sub-problems. By understanding the key components of recursion—base condition, recurrence relation, and return flow—developers can effectively implement recursive solutions for various problems, such as calculating Fibonacci numbers or performing binary searches. While recursion can lead to elegant and concise code, it is important to consider its space complexity due to the call stack usage. Mastering recursion can greatly enhance problem-solving skills and lead to more efficient algorithms.

⭐ Check out the DSA GitHub repo for more code examples.

Cyclic Sort Made Simple: Learn the Basics and How It Works

Sat, 10 Jan 2026 21:20:49 +0000

Cyclic sort is an in-place and unstable sorting algorithm that is specifically designed to efficiently sort arrays where numbers are in a known range like from 1 to N.

How does it work?

Let’s take the following array as an example. We need to sort it in ascending order.

The algorithm works by choosing an element and puts it at its correct index. It starts with the first element.

In the example array, the algorithm chooses the first element 5. Its correct index is 4.

The algorithm swaps 5 with the element at the correct index of 5 i.e. element 2 present at index 4.

The algorithm now checks whether the element at the position of the control variable i is in its correct position: Is 2 in its correct position? No. So, the control variable will not increment its position.

The algorithm will swap 2 with 4 (as the correct index of 2 is index 1).

It will again check: is element 4 is at its correct index? No, it isn’t. The correct index of 4 is index 3.

So, it will swap element 4 with element 3 (as the correct index of element 4 is index 3).

Now, it will check again: is element 3 at its correct index? No, it isn't. The correct index of 3 is index 2.

So, element 3 will be swapped with element 1.

Now, the algorithm checks once again: is element 1 at its correct index? Yes, it is!
So, the algorithm will move to the next index and once again check if that element is at its correct index.

Is element 2 at its correct index? Yes, it is. The algorithm continues this process until it reaches the end of the array.

You might have already realized that the correct index for an element is its value - 1, if the range of numbers in the array is 1 to N.

Space Complexity

As this algorithm is an in-place sorting algorithm, it does not require any auxiliary space. So, its space complexity is O(1).

Time Complexity

We have two scenarios here: the worst case and the best case.

Worst Case

The worst case happens when every number is in the wrong place in an array with a known range (say, 1 to N). The sample array used above, [5, 4, 1, 3, 2], is an example of the worst case. Let's calculate how many times the algorithm performed checks.

In the example array, total 4 swaps and 5 checks were made. After all swaps were performed at the first index, the element at that index was checked once again. Therefore, there were a total of 5 checks.

In general, N - 1 swaps and N checks would be made. As in each swap, 1 check is performed. So, there would be a total of 2N-1 checks made.

Therefore, the worst-case time complexity of cyclic sort algorithm is O(N).

Best Case

The best case happens when the array is sorted in the desired order. In that case, the algorithm checks each element once and does not perform any swaps. Therefore, the best-case complexity is O(N).

Example Code

import java.util.Arrays;

public class Main {
    public static void main(String[] args) {
        int[] arr = {2, 3, 5, 1, 4};
        sort(arr);
        System.out.println(Arrays.toString(arr));
    }

    static void sort(int[] arr) {
        int i = 0;
        while (i < arr.length) {
            // Assuming range of array is 1 to N
            int correctIndex = arr[i] - 1;
            if (arr[i] != arr[correctIndex]) {
                swap(arr, i, correctIndex);
            } else {
                i++;
            }
        }
    }

    static void swap(int[] arr, int first, int second) {
        int temp = arr[first];
        arr[first] = arr[second];
        arr[second] = temp;
    }
}

Conclusion

Cyclic sort is a highly efficient algorithm for sorting arrays with elements in a known range, such as from 1 to N. It operates in-place, requiring no additional space, which makes it space-efficient with a complexity of O(1). The algorithm's time complexity is O(N) in both the best and worst cases, making it a reliable choice for sorting tasks where the range of numbers is predetermined. By understanding the mechanics of cyclic sort, you can effectively apply it to relevant sorting problems, optimizing performance and resource usage.

⭐ Check out the DSA GitHub repo for more code examples.

How Insertion Sort Works: Simplified Explanation

Sat, 29 Nov 2025 09:40:50 +0000

Insertion sort is a simple comparison-based sorting algorithm that sorts by repeatedly inserting elements into their correct position. Let's explore how it works in detail.

What is Insertion Sort?

Insertion Sort is a comparison sort algorithm. It divides the array into two parts: the sorted part and the unsorted part. It repeatedly inserts each element from the unsorted part into its correct position in the sorted part of the array.

How does it work?

Let’s take the following array as an example. We need to sort it in ascending order.

The insertion sort algorithm uses two loops: one controls the number of passes (or traversals) through the array, and the other compares adjacent elements and performs swap if needed, starting from the first element of the unsorted section. Let variable i control the number of passes and variable j control the comparison of adjacent elements. As i increases, the sorted section grows, and j helps place each element in its correct position within the sorted section.

Since we are sorting in ascending order, the sorted part of the array is on the left side.

Initially, i should start from index 0. The variable j takes the value i+1 which in the initial case is index 1.

As the sorted region lies behind the initial value of j in each pass, the algorithm compares the jth element with the j-1th element.
It will check: is 9 less than 3? No, it isn’t. So, it will get swapped.

After the swap, the value of j decreases by a unit. As the j-1th element is undefined (error will be thrown if we try to access that element), so j should always be greater than 0.

Now, in the second pass, i increases to 1. j takes the value of 2.

Now, the algorithm checks: is 9 less than 6? No, it is not. So, they will be swapped.

The value of j changes to 1. The algorithm now checks: is 3 less than 6? Yes, it is. So, no swap operation will be performed.

Now, the third pass starts. The value of i changes to 2 and j becomes 3.

Now, the algorithm checks: is 9 less than 10? Yes, it’s. So, no swap operation will be performed.

As we know, the part of the array on the left side of j is already sorted at the beginning of each pass. Therefore, it's unnecessary to check all the way to the leftmost end of the array. If the desired order is found between adjacent elements during comparison, the internal loop can exit for that pass.

Now, starting with the fourth pass, the value of i becomes 3 and that of j becomes 4.

The algorithm now checks: is 10 less than 1? No, it isn’t. So, they will be swapped.

The value of j changes to 3. Now, it checks: is 9 less than 1? No, it isn’t. So, they’ll be swapped.

j is now at index 2. It checks: is 6 less than 1? No, it isn’t. So, they get swapped.

The value of j decreases to 1. Now, it checks: is 3 less than 1? No, it isn’t. So, they get swapped.

Now, the internal loop exits. As j takes the value i+1 and index 5 does not exist, so the maximum value of i should be 3. In general, i must be less than N - 1 where N is the length of the array.

Our array is finally sorted!

Time Complexity

There are two possible scenarios: the best case and the worst case.

Worst Case

The worst case occurs when the array is sorted in the reverse order. Let’s try to find out the total number of comparisons made.

In the 1st pass, only 1 comparison is made.
In the 2nd pass, 2 comparisons are made.
…
In the N-1th pass, N-1 comparisons are made.

So, the total number of comparisons made is:

Hence, the time complexity is O(N²) as constants are cancelled, and less dominating terms are removed.

Best Case

The best case occurs when the array is already sorted in the desired order. In that case, there will be utmost 1 comparison made in each pass because the internal loop will break once it finds that the desired order is followed by the adjacent elements while comparing them. Therefore, total number of comparisons made is N-1 where N is the size of the array.

Hence, the time complexity in this scenario is O(N).

Space Complexity

As the insertion sort algorithm is an in-place sorting algorithm, it does not use any auxiliary space. Hence, its space complexity is O(1).

Stability

The insertion sort is a stable sorting algorithm as the original order of the equal elements (or the duplicate elements) is maintained in the final sorted array.

Uses of Insertion Sort

Insertion sort is the most efficient sorting algorithm for small arrays because it is adaptive. Adaptive means that for smaller values of N, the number of comparisons made are reduced and number of swaps performed is also less compared to bubble sort.

It works better when the array is nearly sorted. Hence, it is often used in hybrid sorting algorithms like TimSort and IntroSort.

Example Code

import java.util.Arrays;

public class Main {
    public static void main(String[] args) {
        int[] arr = {9, 3, 6, 10, 1};
        insertionSort(arr);
        System.out.println(Arrays.toString(arr));
    }

    static void insertionSort(int[] arr) {
        for (int i = 0; i < arr.length - 1; i++) {
            for (int j = i + 1; j > 0; j--) {
                if (arr[j] < arr[j - 1]) {
                    swap(arr, j, j-1);
                } else {
                    break;
                }
            }
        }
    }

    static void swap(int[] arr, int first, int second) {
        int temp = arr[first];
        arr[first] = arr[second];
        arr[second] = temp;
    }
}

Conclusion

Insertion sort is a straightforward and efficient algorithm for sorting small arrays. Because of its adaptive nature and its stability, it performs well on nearly sorted arrays. Understanding insertion sort provides a solid foundation for learning more complex sorting techniques.

⭐ Check out the DSA GitHub repo for more code examples.

Discovering JavaScript's Hidden Secrets: Understanding String Matching Algorithms.

Thu, 30 Oct 2025 08:30:06 +0000

Welcome to the Algorithm Series: String Matching Algorithms

Imagine trying to find a single word in a thousand-page book by flipping through every page, scanning every line, and hoping your eyes catch the right sequence of letters.
Now imagine a system that can do the same thing across millions of documents in milliseconds.

That’s the magic of String Matching Algorithms, the invisible engines making modern search possible.
They’re the hidden force behind Google’s lightning-fast searches, code editors that highlight matches as you type, plagiarism detectors that scan billions of texts, and even bioinformatics tools that compare DNA sequences.

String Matching Algorithms, also known as Pattern Matching Algorithms is the process of finding one or more occurrences of a pattern (substring) inside a text (main string). these algorithms teach computers how to “read” and recognize patterns within text.
From validating user input and parsing data to building full-scale search engines, string matching lies at the heart of how machines understand language.

In this article, we’ll peel back the curtain to understand how string matching truly works, explore the mechanics and intuition behind legendary algorithms like Naïve Search, Knuth–Morris–Pratt (KMP), Rabin–Karp, and Boyer–Moore, and implement them step by step using JavaScript — revealing how a few lines of logic can transform raw text into intelligent, searchable data.

Why String Matching Matters

String matching is used everywhere:

Search engines to find keywords in web pages
Chat filters to detect banned words
Bioinformatics to find gene sequences
Compilers to tokenize source code
AI/ML preprocessing to clean and analyze text

Common Categories of String Matching Algorithms

Naïve String Matching Algorithm
Knuth–Morris–Pratt (KMP) Algorithm
Rabin–Karp Algorithm (Hash-Based Search)
Boyer–Moore Algorithm

Naïve String Matching Algorithm

The Naïve approach (also called the Brute-Force String Matching Algorithm) operates by sliding the pattern over the text one character at a time and checking, at each position, whether the pattern matches the substring of the text beginning at that point.
This comparison continues character by character until a mismatch occurs or the entire pattern matches.

How It Works

Start at index 0 of the text and compare each character of P with the corresponding character in T.
If all characters match, record the index as a match position.
If a mismatch occurs, shift the pattern one character to the right and compare again.
Continue this process until the pattern has been aligned with every possible substring of the text.

JavaScript Implementation

function naiveSearch(text, pattern) {
  const n = text.length;
  const m = pattern.length;
  const positions = [];

  for (let i = 0; i <= n - m; i++) {
    let j = 0;
    while (j < m && text[i + j] === pattern[j]) j++;
    if (j === m) positions.push(i);
  }

  return positions;
}

console.log(naiveSearch("AABAACAADAABAABA", "AABA"));
// Output: [0, 9, 12]

Knuth–Morris–Pratt (KMP) Algorithm

The KMP algorithm is a pattern searching algorithm designed to improve upon the inefficiencies of the Naïve String Matching Algorithm.
It precomputes the Longest Proper Prefix of the pattern which is also a Suffix, allowing the search to skip redundant comparisons.

How It Works

Step 1: Preprocessing Phase (Build the LPS Array)

Before searching, KMP preprocesses the pattern to build the LPS (Longest Proper Prefix which is also a Suffix) array.
This array tells the algorithm how many characters can be skipped after a mismatch occurs.

Prefix → A substring starting at the beginning of the pattern.
Suffix → A substring ending at the end of the pattern.

The LPS value for each position indicates the length of the longest proper prefix that is also a suffix up to that point.

Step 2: Searching Phase

Using the LPS array:

Start comparing the pattern with the text from left to right.
When characters match, move both pointers (text and pattern) forward.
If a mismatch occurs:
- Instead of restarting the pattern from index 0, use the LPS value of the previous pattern index to skip ahead.
Continue this process until the end of the text.

JavaScript Implementation

function computeLPSArray(pattern) {
  const lps = new Array(pattern.length).fill(0);
  let len = 0;
  let i = 1;

  while (i < pattern.length) {
    if (pattern[i] === pattern[len]) {
      lps[i++] = ++len;
    } else if (len !== 0) {
      len = lps[len - 1];
    } else {
      lps[i++] = 0;
    }
  }
  return lps;
}

function kmpSearch(text, pattern) {
  const lps = computeLPSArray(pattern);
  const positions = [];
  let i = 0, j = 0;

  while (i < text.length) {
    if (pattern[j] === text[i]) {
      i++;
      j++;
    }

    if (j === pattern.length) {
      positions.push(i - j);
      j = lps[j - 1];
    } else if (i < text.length && pattern[j] !== text[i]) {
      j !== 0 ? (j = lps[j - 1]) : i++;
    }
  }

  return positions;
}

console.log(kmpSearch("ABABDABACDABABCABAB", "ABABCABAB"));
// Output: [10]

Rabin–Karp Algorithm (Hash-Based Search)

The Rabin–Karp Algorithm is a string-searching method that uses hashing to find a pattern inside a text.
Instead of checking each character, it converts substrings into hash values for faster comparison.

How It Works

Compute the hash of the pattern.
Compute the hash of the first window of text (same length as the pattern).
Slide the window one character at a time and update the hash using a rolling hash formula:
- If the hash of the window matches the pattern hash, check the actual substring to confirm.
- Repeat until the end of the text.

JavaScript Implementation

function rabinKarp(text, pattern, prime = 101) {
  const n = text.length;
  const m = pattern.length;
  const d = 256; // number of possible characters
  let h = 1;
  let p = 0; // hash for pattern
  let t = 0; // hash for text
  const result = [];

  for (let i = 0; i < m - 1; i++) h = (h * d) % prime;

  for (let i = 0; i < m; i++) {
    p = (d * p + pattern.charCodeAt(i)) % prime;
    t = (d * t + text.charCodeAt(i)) % prime;
  }

  for (let i = 0; i <= n - m; i++) {
    if (p === t) {
      if (text.slice(i, i + m) === pattern) result.push(i);
    }
    if (i < n - m) {
      t = (d * (t - text.charCodeAt(i) * h) + text.charCodeAt(i + m)) % prime;
      if (t < 0) t += prime;
    }
  }

  return result;
}

console.log(rabinKarp("GEEKS FOR GEEKS", "GEEK"));
// Output: [0, 10]

Boyer–Moore Algorithm

The Boyer–Moore Algorithm is one of the fastest and most efficient string matching algorithms in practice.
It compares the pattern from right to left, and when a mismatch occurs, it uses two powerful heuristics to skip over large sections of text — rather than moving just one character at a time.

This makes it especially effective for long texts and complex patterns, often outperforming other algorithms in real-world applications.

How It Works

Start Matching from the Right

The comparison starts from the rightmost character of the pattern and moves leftward.
If all characters match → ✅ Pattern found.
If a mismatch occurs → the algorithm decides how far to shift the pattern using two heuristics:
1. Bad Character Heuristic
2. Good Suffix Heuristic

1. Bad Character Heuristic

When a mismatch occurs at text character c while comparing pattern character P[j]:

If c exists to the left in the pattern, shift the pattern so that the rightmost occurrence of c in the pattern aligns with the mismatched text character.
If c does not exist in the pattern, shift the pattern beyond that character entirely.

This allows Boyer–Moore to skip text characters that could never lead to a match.

Example:

When a mismatch occurs at D, and since D does not appear in "EFG",
the algorithm shifts the pattern past D, skipping unnecessary comparisons.

2. Good Suffix Heuristic

When a mismatch occurs after part of the pattern has matched,
Boyer–Moore uses the matched suffix (called the good suffix) to determine the next shift.

If a portion at the end of the pattern matched:
- Shift the pattern so the next occurrence of that suffix aligns in the text.
If the suffix does not appear elsewhere:
- Shift so that the longest prefix matching the suffix aligns instead.

This heuristic lets Boyer–Moore reuse previously matched information efficiently and skip redundant checks.

JavaScript Implementation

function badCharHeuristic(pattern) {
  const badChar = {};
  for (let i = 0; i < pattern.length; i++) {
    badChar[pattern[i]] = i;
  }
  return badChar;
}

function boyerMooreSearch(text, pattern) {
  const badChar = badCharHeuristic(pattern);
  const n = text.length, m = pattern.length;
  let s = 0;
  const result = [];

  while (s <= n - m) {
    let j = m - 1;

    while (j >= 0 && pattern[j] === text[s + j]) j--;

    if (j < 0) {
      result.push(s);
      s += m - (badChar[text[s + m]] || -1);
    } else {
      s += Math.max(1, j - (badChar[text[s + j]] ?? -1));
    }
  }

  return result;
}

console.log(boyerMooreSearch("ABAAABCD", "ABC"));
// Output: [4]

Conclusion

String matching algorithms may seem simple, but they’re the invisible power behind search engines, code editors, and even DNA analysis.

The Naïve algorithm is easy to understand but slow for large data. KMP improves efficiency by avoiding redundant checks. Rabin–Karp shines when comparing multiple patterns using hashing, while Boyer–Moore excels in practical performance by skipping ahead intelligently.

Beyond theory, these algorithms teach a crucial engineering lesson: the right approach depends on your data and context. Whether you’re building a search feature, validating input, or analyzing text, knowing how these algorithms work gives you the power to make software faster and smarter.

In essence, string matching turns plain text into meaningful information — and understanding it turns a good developer into a great problem solver.

Overcoming Key Challenges to Machine Learning Adoption

Tue, 14 Oct 2025 21:01:11 +0000

Introduction
Machine Learning (ML) promises transformative insights and automation, but adopting it at scale is far from simple. Organizations often underestimate the complexity of operationalizing ML models. This article explores the four major challenges to ML adoption—and how to address them effectively.

1. Data Preparation

High-quality data is the foundation of any ML initiative.

Yet, most projects stall here because:

Access Issues: Data silos and compliance restrictions make it hard to gather complete datasets.

Pipeline Management: Cleaning, labeling, and maintaining data pipelines over time is resource-intensive.

✅ Actionable Solutions

Centralize Data Access: Implement a data lake or warehouse with role-based access controls.
Automate Data Quality Checks: Use tools like Great Expectations or Deequ for continuous validation.
Version Control for Data: Adopt DVC (Data Version Control) to track changes and maintain reproducibility.

Pro Tip: Invest in automated data validation tools and establish clear data governance policies early.

2. Model Development

Building accurate and interpretable models is harder than it looks:

Model Selection & Training: Choosing the right algorithm and tuning hyperparameters requires expertise. Selecting the

Deployment at Scale: Rolling out multiple models across environments introduces complexity.

✅ Actionable Solutions

Leverage AutoML: Tools like H2O.ai or Google AutoML can accelerate model selection and tuning.
Adopt MLOps Frameworks: Use Kubeflow or MLflow for streamlined training, deployment, and monitoring.
Containerize Models: Package models in Docker containers for portability and scalability.

Pro Tip: Use MLOps frameworks like Kubeflow or MLflow to streamline training and deployment.

3. Model Governance & Security

Once deployed, models need continuous oversight:

Bias & Drift Monitoring: Models degrade over time as data changes.

Adversarial Attacks: ML systems can be manipulated if not properly secured.

✅ Actionable Solutions

Bias Audits: Integrate fairness metrics using libraries like AIF360 or Fairlearn.
Drift Detection: Automate drift alerts with Evidently AI or WhyLabs.
Security Hardening: Apply adversarial testing and encrypt model endpoints using TLS.

Pro Tip: Implement automated drift detection and adversarial testing as part of your CI/CD pipeline.

4. Access to Compute Resources

Training ML models demands significant compute power:

GPU Availability: Limited GPU resources can bottleneck training.
Workload Scheduling: Efficient orchestration is essential for cost control.

✅ Actionable Solutions

Cloud GPU Clusters: Use AWS EC2 GPU instances or Azure Machine Learning Compute for elasticity.
Autoscaling: Implement Kubernetes autoscaling for dynamic resource allocation.
Spot Instances: Reduce costs by leveraging spot pricing for non-critical workloads.

Pro Tip: Explore cloud-based GPU clusters and autoscaling strategies to optimize resource usage.

5. Talent: The Hidden Barrier

Scarcity of specialized talent remains one of the biggest hurdles. Upskilling your team and leveraging community resources can bridge this gap.

✅ Actionable Solutions

Internal Bootcamps: Organize ML enablement sessions for engineers and analysts.
Mentorship Programs: Pair junior staff with experienced ML practitioners.
Community Engagement: Encourage participation in open-source projects and forums.

Conclusion

ML adoption isn’t just about algorithms—it’s about data readiness, governance, infrastructure, and talent. By addressing these challenges proactively, organizations can unlock the full potential of machine learning.

LeetCode AI Assistant: A Smarter Way to Prepare for Coding Interviews

Thu, 09 Oct 2025 18:41:23 +0000

Grinding LeetCode alone is outdated. Discover how a LeetCode AI
assistant can provide smarter hints, personalized notes, and mock
interviews to transform coding interview prep.

When you think about preparing for coding interviews, one name comes up again and again: LeetCode.
It has become the global training ground for aspiring software engineers, from college grads to senior devs making career moves.

But here’s the catch: LeetCode was never designed to be a complete learning experience. It’s a practice arena, not a teacher. You can solve hundreds of problems and still stumble in an interview because you didn’t build the right habits, or because you forgot what you learned two weeks ago.

That’s why a growing number of candidates are turning to a new kind of tool: the LeetCode AI assistant.

This isn’t just another coding bot. It’s an evolution in how people learn and prepare. Let’s break down why it matters, what it can do, and how it’s changing interview prep for good.

Why Traditional LeetCode Prep Falls Short

If you browse Reddit or Blind, you’ll see countless posts that sound like this:

“I solved 500+ problems but still bombed my interviews.”
“I keep forgetting the details after a week.”
“I know the patterns, but I panic when asked to explain.”

The pain points are remarkably consistent:

Retention → Candidates forget solutions without structured review.
Communication → Solving alone doesn’t prepare you to explain in front of an interviewer.
Feedback → Debugging in isolation wastes hours.
Focus → Constantly switching tabs to seek help breaks flow.

LeetCode is powerful, but it leaves gaps. That’s where the LeetCode AI assistant comes in.

What Exactly Is a LeetCode AI Assistant?

At its core, it’s an AI companion that lives inside your LeetCode practice environment.
Think of it like a study partner who:

Already knows which problem you’re working on.
Reads your code as you write it.
Can run, test, and even visualize your solution.
Helps you keep track of what you’ve learned.

It’s not a shortcut to answers—it’s a scaffolding system that makes practice more efficient, memorable, and realistic.

Smarter Hints: Guidance Without Spoilers

One of the worst habits in LeetCode prep is peeking at solutions too early. You go from struggling productively to memorizing passively.

A LeetCode AI assistant solves this with progressive hints:

At the start, it nudges you toward the right approach.
Midway, it identifies bottlenecks in your reasoning.
With partial code, it explains the logic gaps without dumping the full solution.

The result? You stay in control, but with safety rails. You learn how to think, not just how to copy.

Auto-Generated Study Notes: From Grind to Knowledge

Let’s face it: solving 300 problems doesn’t mean you’ll remember 300 problems. Without review, most of it fades.

A LeetCode AI assistant can turn every solved problem into a structured note automatically:

Problem summary and constraints.
Step-by-step breakdown of the solution.
Example inputs and outputs.
Time and space complexity.

Over time, this builds a personal knowledge base—a second brain you can revisit anytime, instead of relying on memory alone.

Some assistants even generate flashcards or quizzes, making spaced repetition effortless.

Mock Interviews: Practicing Performance, Not Just Problems

Interviews are not just about writing code. They test your ability to:

Communicate clearly.
Defend trade-offs.
Adapt to unexpected follow-ups.

This is where a LeetCode AI assistant shines. It can simulate a real interviewer:

Asking clarifying questions like “Why not use a hash map here?”
Pushing you when your explanation is vague.
Giving a score breakdown on clarity, efficiency, and correctness.

The first time you try it, you might even feel nervous. That’s the point—it replicates the pressure so the real thing feels less intimidating.

Beyond Chat: Tools That Act

What makes the best LeetCode AI assistants different is that they don’t just talk—they act.

Instead of wasting time writing test harnesses, you can simply ask:

“What if the array contains only negatives?”
“Can you show me how this recursion actually unfolds?”

And the assistant responds by:

Generating edge test cases and running them instantly.
Visualizing your function calls step by step.
Saving key insights into your personal notes for later review.
Search for relevant walkthrough Youtube videos so user can play them in a picture-in-picture window.

It feels less like Q&A, and more like pair programming with a senior engineer who brings their own debugger, whiteboard, and notebook to the session.

A Story: Grinding Alone vs. Training With a Copilot

Consider two candidates: Priya and Daniel.

Priya follows the traditional path. She solves 400+ problems, memorizes patterns, and spends weekends reviewing notes in Notion. But when faced with an interviewer asking her to explain trade-offs under time pressure, she stumbles.
Daniel solves fewer problems, but with a LeetCode AI assistant. Each solution is turned into notes. He practices weekly mock interviews with adaptive feedback. He reviews AI-generated flashcards to keep concepts fresh.

Who’s better prepared for the real interview? Daniel, not because he worked harder—but because he worked smarter.

What a LeetCode AI Assistant Can’t Do

It’s important to be clear:

It won’t replace fundamentals—you still need to understand data structures and algorithms.
It can’t guarantee an offer—interviews involve culture fit and communication beyond coding.
It shouldn’t become a crutch—over-relying on AI means you risk freezing when the assistant isn’t there.

Used well, it’s an amplifier, not a replacement.

Risks and Concerns

Every new tool has trade-offs. With AI assistants, the concerns include:

Cheating → Candidates might try to use them during real interviews, undermining fairness.
Overconfidence → Practicing with AI feedback is valuable, but real interviewers bring unpredictability.
Accessibility → Not all candidates have equal access, which could widen the prep gap.

These are real issues. The key is to use AI as a training partner, not as a hidden lifeline.

How Companies Might Respond

Here’s where it gets interesting: companies know candidates are using AI to prepare. Over time, this could reshape interview culture itself.

Expect more emphasis on communication and collaboration.
Expect system design and open-ended problem-solving to weigh more heavily.
Expect soft skills—like how you handle feedback or adapt to surprises—to become part of evaluation.

Ironically, this is healthy. It pushes interviews away from rote memorization and closer to what actually matters on the job.

Practical Tips: How to Use a LeetCode AI Assistant

If you’re curious how to get started, here’s a simple framework:

Daily Practice → Solve 2–3 problems. Use AI hints only when stuck beyond 15 minutes.
Structured Notes → Let the AI generate study notes. Add your own reflections to deepen understanding.
Weekly Mock Interview → Simulate a session, focusing on explaining your reasoning out loud.
Edge Case Training → Ask the AI to generate tricky test cases for past problems.
Review Cycle → Revisit AI-generated notes weekly, like flashcards, to strengthen retention.

This rhythm balances human effort with AI support.

The Bigger Picture: Learning How to Learn

At the end of the day, the real revolution of a LeetCode AI assistant isn’t in the code—it’s in how it reshapes learning.

Instead of brute force, you get:

Efficiency → Less wasted time, more targeted progress.
Retention → Notes and reviews that actually stick.
Confidence → Mock interviews that simulate real pressure.

Preparing for coding interviews used to feel like grinding through a fog. With the right assistant, the fog lifts. You see patterns faster, you remember more, and you walk into interviews with less anxiety.

Final Thoughts

The rise of the LeetCode AI assistant marks a turning point in technical interview prep. It’s no longer just about solving the most problems—it’s about learning smarter, retaining more, and performing better under pressure.

This doesn’t mean grinding is dead. You’ll still need to practice, struggle, and grow. But with an AI assistant, every hour of practice counts more.

If I were starting over today, I wouldn’t just grind problems in isolation. I’d bring along an assistant that helps me learn, remember, and perform. Because in coding interviews, the real advantage isn’t just algorithms—it’s confidence.

Ready to see it in action? Try LeetCopilot for free on Chrome and experience what it’s like to have your own LeetCode AI assistant by your side.

Coder Legion - Recent posts tagged algorithms

Twenty-Six Thousand Families and a Nationality Field: The Dutch Benefits Algorithm Overdrew Trust

The check that ran, and affirmed the thing it was meant to catch

The nationality field, priced by the regulator

The repayment costs a thousand times the fine, and it is not a repayment

Which reforms bought control, and which bought the look of it

What to take back to your own systems

An eye wired to a printer is not a brake

Demystifying Greedy Algorithms: How Local Choices Solve Global Problems in Node.js

What is a Greedy Algorithm?

The Cashier’s Coin Trick

Why Greedy Algorithms Matter in Tech

Code Example: Making Change in Node.js

The Takeaway

The Magic of Branchless in FinTech: How to Tame the NASD 30/360 Financial Standard and Solve the IRR Equation Without a Single IF

Part 1. The Core Milestone: Branchless Computation of the NASD 30/360 Standard

Part 2. The Foundation: A Branchless Calendar Decoder, Normalization, and Stress-Testing the GetDays(y, m, d) Core

Native Input Data Normalization Within the GetDays Core

Empirical Validation Bounds and Architectural Integrity

Governed by perfectly balanced fixed-point scaling properties (integer divisors 365243, 3653, and 306), the execution kernel yields an absolute zero-bit error rate over staggering historical epochs. The verified operational envelope spans seamlessly from January 1, 0001, through April 30, 487,621.

⚡ Part 3. Bare-Metal Domination: The Strategy of the 32-bit Signed Long

Part 4. The Scientific Core: Smoothing and Resolving the Actual/Actual Timeline Constraints (MSU Proceedings)

️ Part 5. Conclusions

References

Building aegis-filter: Why Standard Kalman Filters Fail in Adversarial Environments

1. The Core Architecture

A. Joseph-Stabilized Covariance Update

B. Chi-Square / 3-Sigma Outlier Rejection Gating

C. Unscented Kalman Filtering (UKF) & $H_\infty$ Robust Minimax

2. Flight Telemetry & Spoofing Resilience Simulation

Key Takeaways from the Data:

3. Quick Start (Rust)

1D Outlier-Gated Fusion Example:

4. Open Source Links

The adaptive threshold that deleted the thing we were looking for

The failure: the page fills the frame and detection gets worse

Telling paper from a block of printed text

The guards that are product decisions wearing algorithm clothes

Two features that ship turned off

What I would take away from this

Behavior Trees, A Star Pathfinding And Where LLM NPCs Actually Fit

Why Finite State Machines Stop Scaling

Behavior Trees Took Over For A Reason

Pathfinding Is A Graph Problem, Not A Geometry Problem

Where LLM NPCs Actually Fit

The Takeaway

Building Process Mind: A Deterministic Operating System Algorithm Simulator

What is Process Mind?

The Core Idea: Deterministic Results

The Difficult Part Wasn't Writing the Algorithms

Handling Preemptive Scheduling

Validation Matters More Than It Looks

Building the Interface Around the Algorithm

What I Learned

What's Next?

Data Structure & Algorithms

The Engineering Behind ShiftSync: Turning Workforce Rostering Into a Constraint-Optimisation Problem

Ada Lovelace: The Countess Who Programmed the Future 100 Years Before Computers Existed

The Princess of Parallelograms: Education Against Madness

Meeting Babbage: From Mechanical Calculator to Universal Computer

The 1843 "Notes" and the First Algorithm (Note G)

The Leap to Symbolic Computation: Software Before Hardware

"Lady Lovelace's Objection": The Original AI Debate

The Legacy: From Steam Power to Mission-Critical Systems

Thinking Like Ada: The Synthesis of Poetry and Engineering

Sources of Interest:

Procedural Generation Is A Rules Problem, Not A Randomness Problem

Randomness Is Not Generation

The Trade Has Not Changed Since 1984

Determinism Is A Debugging Feature

Where Hand Built Content Still Wins

When Algorithms Take Sides: Bias, Legitimacy and Intelligent Systems in Contested Spaces

Definition of contested spaces and their significance

Importance of understanding bias and legitimacy in algorithms

Conclusion

Sources

Mastering the Two Pointers Technique in Python (With Easy Examples)

Mastering the Two Pointers Technique in Python (With Easy Examples)

What is the Two Pointers Technique?

When Should You Use Two Pointers?

Part 2. The Foundation: A Branchless Calendar Decoder, Normalization, and Stress-Testing the `GetDays(y, m, d)` Core

Native Input Data Normalization Within the `GetDays` Core

From `Array.filter` to bitmap filtering