I have a puzzle for the hacker in you: The font HarfBust.ttf is an offshoot of Anton Regular, with a twist:

  - On software using HarfBuzz (as far back as you go, back to the 2000s) and HarfBuzz only, it will ligate "HarfBuzz" to the HarfBuzz logo.

  - On software using HarfRust and HarfRust only, it will ligate "HarfRust" to the HarfBuzz logo.

  - On software using HarfBuzz, HarfRust, or DirectWrite, but not CoreText, it will ligate "HarfBust" to the HarfBuzz logo.

How does this work? The font does not use any non-standard OpenType features like `HARF`/`Harf`/`BUZZ`/`Buzz` (which HarfBuzz / HarfRust apply).

Enjoy, --behdad

We’re the maintainers of HarfBuzz, the open-source text shaping engine used by browsers, operating systems, and applications to render all text, including supporting scripts like Arabic, Devanagari, Khmer, CJK, and more.

HarfBuzz is known for being fast, portable, and complete. But it’s also sometimes seen as hard to understand or work with. We’re working on a Developer FAQ and Design Notes to clear up misconceptions and explain the "why" behind our more unusual design decisions (yes, the macros are intentional).

So we’re asking:

What was your biggest WTF moment reading or using HarfBuzz?

Other things we’d love to hear about:

* Which parts felt like magic or a black box? * What do you think we could explain better? * Have you run into performance or integration surprises? * Are there features you only discovered by reading the source? * What do you wish the documentation had told you?

Anything else you want to know about the project?

We'll answer questions on Reddit, here, and also open a GitHub Discussion afterward to collect and respond to feedback more formally and integrate into our documentation.

Thanks in advance for your curiosity, stories, or frustration—we’re listening!

I'd like to know what is the future of font rendering (according to you) as far the as the quality of the result is concerned (iow, my question is not about speed). For example, are there new way to handle antialiasing or is it a solved problem ?

Thank you for the question. Rasterization is not my specialty. There definitely is still immense amount of research going into rasterizing fonts and 2D graphics on the GPU efficiently. Here's the latest from Raph Levien's research for example:

  https://www.youtube.com/watch?v=_sv8K190Zps

Thanks, so that video (wasn't much impressed, just some "tile compression").

My question was more about the quality of the rendering (or other challenges) than about the speed of rendering.

The page fights against zooming by reducing the text size to compensate.

I can zoom in somewhat only if I press Ctrl + fast enough many times in succession, but then it is easy to overshoot.

Interesting, when I zoom in to 300% the T in TLDR is exactly 3x taller than when at 100%. Seems to be an embedded Google Doc though so the canvas does a weird recentering jerk on viewport size changes.

Zoom works until the page width is about the browser width. After that it starts fighting your zoom level.

Hi. As mentioned, I'll expand on my motivations in a future paper. -behdad

While this presentation is extremely interesting, it would have been far more useful if you would have exported this view into a downloadable PDF file, instead of giving access to just this ephemeral preview.

How does that work with new grads?

Grads have written software.

If a grad has written no software, or has no capacity to talk software development with you, then the interview is over.

There's no rule saying you need to hire new grads. I'd even suggest that if you care about hiring "the best engineers", hiring new grads is just idiotic.

One of the counter-points of original question is that it is hostile to people with experience, aka didn’t do much also since uni, now you’re hostile against new grads.

Assuming that the dictionary is arbitrary as well, just comparing the string to the strings in the dictionary (or hashing it) it takes O(n), regardless of the data-structure you use.

Is that relevant to real-world use? You mention Python in TFA - I'm no expert but I believe it does string interning, and caches the results of string hashes, which would suggest real-world performance should be constant over time in both cases.

Imagine the string "there is", and the dictionary {"the", "there", "is"}.

T isn’t a word, next

Th isn’t a word, next

The is a word, look up ‘reis’, not a word, next

Ther isn’t a word, next

There is a word, look up ‘is’ it is a word, return true

If you don’t want to ignore whitespace, than I’m not sure what behavior you want, you want “there is” to return false?

If whitespace is the delimiter the whole thing is trivial, you split on space.

I am now more confused.

> The is a word, look up ‘reis’, not a word, next

This is where the wrong greedy solution from TFA, which the author claims some candidates reach, stops. So it's wrong.

Note that if you do not stop, and continue as in your own example, your solution isn't "greedy"!

That is a correct solution. The one I was talking about would stop after just trying "The" and "reis".

Anyway, don’t you get a savings by using some data structure that indexes the dictionary by word length first?

Or at least sorting by.

Ok

This guy has a massive ego. Glad I do not work at Google.

I beg to differ, this is exactly the opposite of a manhole problem, which I tried to explain, which I clearly failed.

You'd be surprised.. but we're trying to distinguish between someone who can code simple algorithms versus one who can't.

No, you are not. You have a terribly unbalanced expectation that someone who was just presented with this question will achieve the same depth that you have. But you have been on this question for a long time now, know it deeply, and from the comments on this thread, you still got half of it wrong anyway.

Typically candidates are scored on a scale. And there are multiple interviews. The final hire / no-hire is decided based on the scores and written feedback from all interviews.

Thanks for the answer.

Realistically, what are the chances of someone who solved everything up to the half-way point?

My mid-mark would be where someone could write the code for the brute-force answer for both parts but couldn't get the memoize / dynamic-programming solution. That would be where I'd say "I'm not sure, look at other interviews". Otherwise I'll make a hire / no-hire recommendation.

Interesting. Thanks for the honest answer. (For the record, I'd do fine with brute-forcing both parts but would struggle with memoization in an interview context).

Depends on role and level as well. SRE or junior SWE might get a “hire” for that but a senior SWE probably would go back to the other interviews as mentioned above.