_rend

* Initial candidate screening reduces the pool by 85–95% (leaving 5–15% of the initial pool) * Interview #1 reduces the pool further by 50–66% (leaving ~3–4% of the initial pool) * Interview #2 reduces the pool further by another 66–75% (leaving ~1–2% of the initial pool) * Final chat usually doesn't reduce the pool, but it's one last pass for additional signal * We choose a single candidate of whoever remains

For a position with 400 applicants, it could look like

* Initial screening leaves 40 candidates for interview #1 * Interview #1 leaves 15 candidates for interview #2 * Interview #2 leaves 4 candidates for final chat * We pick from those final 4

When I left my last job, I quit without having anything lined up, and was fortunate enough to have a bit of buffer to take some time off to recuperate and search for new work. I got some promising interviews, but none were like my interviews with the company I work for now. I rejected a number of offers while still in the process with my current company (with the full understanding that there was no guarantee of anything waiting for me). My priority at the time was finding somewhere where I knew I would love to work, and not getting back to work as soon as I could. For me, it paid off to wait.

Our interview process is pretty involved, and not for nothing — we get a lot of applicants, screen heavily, and put in a lot of time and effort into each individual candidate at every stage. We don't have dedicated recruiters, and besides our ops team, we've got individual developers, designers, product managers, support folks, etc. involved in hiring for their respective domains. Our interviews are humane, first and foremost, and a good number of candidates I've gotten to speak to have described the process as refreshing (well, relative to the general hell that is interviewing). The general process is: written questionnaire, two interviews (one technical/skill-focused, one non-technical), and a chat with execs.

It's completely understandable if this process doesn't work for all candidates; we've made great progress tightening up the process, shortening it without compromising on quality, and have invested a lot of time in tooling to help us out to speed things up. But it also works exceptionally well for us and the folks we're lucky to work with (~0.1–1% hire rate depending on position) — since I started a few years ago, the company has more than doubled in size (from a small to a medium company), and in that time, we've had a total of 2 individuals decide it wasn't a good fit for them. The company culture is like nothing else, and it's an amazing place to work.

And, of course, easier (for me) to set up and configure. Maybe no _huge_ incentive to switch over to it if your setup works, but might be worth trying out if you're curious.

Along with what Kliment said about not investing in building capacity, I don't think this specific statement is necessarily true. Many of the original factors that caused these setbacks in the first place are still ongoing: everyone is still trying to catch up, and demand is still outstripping supply almost everywhere, for many, many products; worker mobility is still extremely limited (across countries and regions) because of the ongoing pandemic, so it's not trivial to ramp up.

Short of investing in that capacity and expanding into new regions, I'm sure it hasn't been easy to actually ramp up production again, and changes in customer demand and patterns are still shaking out. (And even for those companies which have been investing into ramping production, two years can be the low end to start seeing returns on investments: plants take time to build, resources need to be allocated and transported, new employees may need to be trained, etc.)

It's important to understand that many manufacturing industries operate on a "JIT (just-in-time) manufacturing" model[0], where goods used in a manufacturing process are only ordered and received as needed, minimizing inventory and storage costs. (e.g., instead of having a warehouse full of screws sitting around waiting to go into products, you order X screws from another manufacturer every month to fulfill Y number of effective orders) This means that many industries (especially the automotive industry) operate on a constant stream of supplied products, in many interdependent chains.

There are two downsides to this approach:

1. The JIT model has to be at least partially predictive. You can't necessarily order components right as you receive orders, because it takes time to produce those components (remember, no one has warehouses full of those components ready to ship, because it's often JIT all the way down) and you don't want to keep customers waiting as components get shipped to you. Instead, you need to at least somewhat predict how many orders you expect to fulfill in order to balance between keeping customers waiting ("shortage") and having excess stock laying around which might never sell (waste)

2. The other main downside is that JIT production is highly interdependent on other industries and can be fragile. If you expect to be able to order X screws this month from your supplier, but some external event causes them to only be able to supply you with Y screws (Y << X), you're shit out of luck. You literally cannot produce your product because the underlying components simply do not exist, which leads to a shortage of your product

Both of these downsides come to a head in the presence of some global event that causes uncertainty and inefficiency. If a low-level JIT process depended upon by many industries suffers from an inefficiency (e.g. workers can't come in because they're sick), many higher-level processes start to slow down (e.g., no one has screws to build their products with). This effect is multiplicative across industries, since many manufacturers specialize in specific products and downtime can affect many "downstream" clients.

Along with this, such global events can dramatically change customer demands, and when you've only predicted needing to produce X products but you now have Y demand (Y >> X), customers are out of luck because the products literally do not exist to be sold (shortage).

Considering that computer chips are now present in almost all major consumer products these days, it doesn't take much uncertainty and inefficiency at the "base" for a domino effect to significantly slow down a lot of industries.

[0]: https://en.wikipedia.org/wiki/Lean_manufacturing

> hex string (which is entirely ASCII)

My point is that JSON doesn't need to be UTF-8 or a superset of ASCII to be valid. It can be any representation of Unicode, including UTF-16, UTF-32, GB 18030, etc.; so long as the text is is comprised of Unicode code points in some Unicode transformation format, the JSON is valid.

As I said in the parent comment: if you are working within UTF-8 exclusively, and can assume valid UTF-8, then great! But this isn't necessarily true, and in some cases, you will still need to care about the encoding.

(Either way, this starts straying slightly from the more general discussion at hand: regardless of the encoding of the string, you will still need an ergonomic way of interacting with the contents of the data in order to meaningfully parse the contents — even past the hurdle of decoding from arbitrary bytes, you still need to manipulate the data reasonably. In some cases, this means working with a buffer of bytes; in others, it makes sense to manipulate the data as a string... In which case, you may run into some of the string manipulation ergonomic considerations being discussed around these comments.)

If you have valid UTF-8 already, then yes, the task is a lot easier. But depending on the level at which you're parsing, this might not be the case — i.e., if you're writing a JSON parser from the ground up, you do need to know what UTF-8 and Unicode are, and will need to validate the input data.

> Converting the unicode character escape codes to utf-8 would require knowledge of utf-8 encoding

Agreed. Even if you're not working at the "array-of-bytes" level, you will need to be able to parse and translate "\u..."-style strings into the appropriate output character encoding.

> but this unescaping is not a feature that would be provided by the language regardless.

I'm not sure we're talking about this being handled at the language level. This translation is something that would likely be offered at the parser level (working with the features offered by the standard library), but the parser does need to know about it — and does need to be able to work with strings at a granular level to be able to parse it out. By definition, it cannot leave the input data as an undecoded bag of bytes.

Note, too, that the JSON spec does not specifically require UTF-8. UTF-16 is a completely valid encoding for JSON (though much less common than UTF-8), in which case none of these characters are an ASCII subset, and greater awareness is needed to be able to handle this.

1. "JSON syntax describes a sequence of Unicode code points. JSON also depends on Unicode in the hex numbers used in the \u escapement notation."

2. "A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar."

3. "A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. There are two-character escape sequence representations of some characters."

4. "Any code point may be represented as a hexadecimal escape sequence. The meaning of such a hexadecimal number is determined by ISO/IEC 10646. If the code point is in the Basic Multilingual Plane (U+0000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the code point."

5. "Note that the JSON grammar permits code points for which Unicode does not currently provide character assignments."

JSON does require Unicode awareness, both for general parsing, and for correctly interpreting strings. Backslashes are allowed for special escape characters, which means that you must be aware of the format (and the encoding of the text) in order to be able to decode.

Note that JSON also doesn't specify a required encoding, only Unicode correctness, so a parser may need to be able to handle multiple Unicode encodings and differentiate between them.

The spec doesn't specify what to do with code points which are not understood as Unicode (given especially the allowance for unassigned characters), but explicitly-invalid Unicode should be rejected.

[1] https://www.ecma-international.org/wp-content/uploads/ECMA-4...

Swift is pretty pedantically strict about Unicode correctness, and avoids some pitfalls which lead to incorrect handling (e.g., integer-based indexing). This means that the traditional way many developers might be used to interacting with strings is cumbersome and annoying — but once you get past the initial hurdle*, most operations are actually (1) really easy, especially when expressed in terms of generic Sequence/Collection operations, and (2) much more difficult to get wrong.

*I think the largest part of that hurdle is overcoming what you may have gotten used to from other languages, i.e., treating strings as an array of "characters", for some language/library definition of "character" (whether bytes, code points, etc.). It's relatively rare that you actually care about indexing into an arbitrary spot in a string: instead, combinations of slicing operations (including `prefix(_:)`, `dropFirst(_:)`, `take(while:)`, etc.) and generic Collection operations will get you what you want. Things like `.reversed()`, `.sorted(), and `.shuffled()` all work trivially correctly too (since you're not operating on a bag of bytes), and it's exceedingly rare that user input will confound the operations you might need to perform. (Exception: operations like case folding and collection, which are locale-specific, need special handling through a framework like Foundation.)

To be clear: not everything is sunshine and roses, but an amazing amount of functionality "falls out" of basic protocol conformances on String, and its exposure as a Collection of grapheme clusters.

Given a specific string manipulation task, I'd be happy to provide an example of what it might look like in Swift!

There's a fun subtlety in this case too: a single grapheme cluster need not draw as a single "visible character" (or glyph) on-screen. The visual representation of a grapheme cluster is entirely dependent on the text system which draws this, and the meaning that system applies to the cluster itself. This is especially true for multi-element emoji clusters, whose recommended meanings[1] change with evolving versions of Unicode.

To add to this, Unicode 12 simplified the definition of grapheme clusters by actually generalizing them so that they can be matched effectively by a regex. (See the "extended grapheme cluster" definition in TR29[2].) This reduced the overall number of special cases and hard-coded lists of combinations in the definitions of grapheme clusters (particularly around emoji), but it also means that there are now infinitely more valid grapheme clusters that don't necessarily map to a single glyph.

One really simple example of this is, e.g.

     ©

That is,

    U+1F434 <horse head> + U+200D <zero width joiner> + U+00A9 <copyright sign>

    extended grapheme cluster :=   crlf | Control | precore* _core_ postcore*
    core :=  hangul-syllable | ri-sequence | xpicto-sequence | [^Control CR LF]
    xpicto-sequence :=  \p{Extended_Pictographic} (Extend* ZWJ \p{Extended_Pictographic})*

    U+1F434: Extended_Pictographic
    U+200D: ZWJ
    U+00A9: Extended_Pictographic

Importantly, you can tell this is actually treated as a real grapheme cluster by the text system on macOS because if you copy that string into a Cocoa text view (e.g., TextEdit), you will only be able to place your cursor on either side of the cluster, but not split it in the middle. A nice interactive way to see this in action is inserting U+1F434 into the document, followed by U+00A9. Then, move your cursor in between those two glyphs and insert U+200D: your cursor should then bounce out from the middle of the newly-formed cluster to the beginning.

This was a pretty short example, but this is arbitrarily extensible: (Edit: Originally I had posted U+2705 <check mark symbol> + U+200D + U+1F434 <horse head> + U+200D + U+1F50B <battery> + U+200D + U+1F9F7 <safety pin> [sorry, no staple emoji] but HN stripped that out too. It does appear correctly in the text area while typing, but HN replaces the sequence with spaces after posting.)

As linked above, Unicode does offer a list of sequences like this that are considered to be "meaningful"[1], which you can largely expect vendors which offer emoji representations to respect (and some vendors may offer glyphs for sequences beyond what is suggested here). If you've ever run into this: additions to this list over time explains why transporting a Unicode sequence which appears as a single glyph on one OS can appear as multiple glyphs on an older one (each individual glyph may be supported, but their combination may or may not have a meaning).

In general, if this is interesting to you, you may enjoy trawling through the Unicode emoji data files [3]. You may discover something new!

[1] https://www.unicode.org/Public/emoji/14.0/emoji-zwj-sequence... [2] https://www.unicode.org/reports/tr29/tr29-35.html#Table_Comb... [3] https://www.unicode.org/reports/tr51/#emoji_data

> If you bought your reMarkable before 12.10.21, we want to give you full access to Connect. If you have a reMarkable account, go to my.reMarkable.com and approve our new terms and conditions to get Connect.

On the "Connect" section of my account:

> As one of our valued early customers, you have full free access to Connect. This is our way to thank you for believing in us from the start. Your free plan includes all launch features, such as Google Drive and Dropbox integration and Screen Share.

I don't use these features right now, but it'll be interesting to see how the plans expand in the future. As a recent-ish owner of the device, the update cadence has felt pretty good and the new features have been relatively impressive, but I hope we don't see more features eventually get locked behind monthly plans.

Not trying to change your usage or habits, just wanted to clarify.

[1]: https://www.youneedabudget.com/security/#direct-import

Not a Homebrew maintainer, just a satisfied user.

The Three-fifths Compromise was a compromise reached among state delegates during the 1787 United States Constitutional Convention. Delegates disputed whether and how slaves would be counted when determining a state's total population, as this number would determine a state's number of seats in the House of Representatives and how much it would pay in taxes. The compromise counted three out of every five slaves as people...

In the US Constitution, the Three-fifths Compromise is part of Article 1, Section 2, Clause 3:

    Representatives and direct Taxes shall be apportioned among the several States which may be included within this Union, according to their respective Numbers, which shall be determined by adding to the whole Number of free Persons, including those bound to Service for a Term of Years, and excluding Indians not taxed, three fifths of all other Persons [italics added].[2]

> About 2 weeks later I was approached by my boss. Someone told him that I had helped a friend with his computer. I told him that yes I had in fact helped a friend with a data transfer (something Apple does for free) and that I had helped him on my own time. He told me that I had just admitted to a major conflict on interest, and that an official investigation in to my actions would now start, two days later I was suspended.

This did not sound to me like mandatory reporting.

I did not, but if you did, I'd love to know more about what it says that I'm not aware of. If this was explicitly listed in your employment contract but not mine, that's a valuable piece of information to know for interpreting the context here.

> explained as mandatory reporting not active hunting

I did not get the sense that this was mandatory reporting, only that his manager had heard about it (potentially off-the-cuff or through unrelated channels), but will gladly re-read the article again when it comes back up.

Working there, there have been plenty of no-no's that we had to be careful about, and periodic training about conflicts of interest and similar, but helping out family, friends, and acquaintances was certainly not it.

Always a fun one to share. :)