timv

And there lies the tradeoffs you need to consider as part of an interview question.

But if the best alternative is to sort the whole collection, then Quickselect doesn't introduce a new problem. You either accept that modifying the collection in place is an acceptable behaviour (and describe that in your API docs) or you make a copy of the collection and operate on that.

Given a choice between quickselect and quicksort, quickselect will get the answer with less overhead and no additional constraints (because it's essentially the same algorithm with unnecessary steps removed).

There are alternative approaches that don't require a full copy/sort, but they either require a partial copy + partial sort, or multiple passes through the collection.

You can use Quickselect (https://en.wikipedia.org/wiki/Quickselect) or Floyd-Rivest (https://en.wikipedia.org/wiki/Floyd%E2%80%93Rivest_algorithm)

Quickselect is fairly simple to understand if you already understand Quicksort. You use use a binary division but you avoid sorting sections where the order doesn't matter.

Let's start with a 7 element array

    [ 2, 4, 7, 5, 3, 6, 1 ]

    [ 2, 4, 3, 1, 5, 7, 6 ]

We pivot the first partition (first 4 elements) on 3 and get

   [ 2, 1, 3, 4, 5, 7, 6 ]

You mention early in the article that you intended to base this approach as a response to your own subpar user experience with support in other products.

This was the biggest (1) complaint for me - in light of what you discovered from your actual support experience, why was your expectation so off?

Was it that you expected support to be full of "how do I do this complicated thing?" questions that can be answered by an expert? That's an unrealistic expectation, but I guess now you know.

Or was it that you really thought that customers would be happy if you just took the time to explain your pricing model to them (also unrealistic).

It is kind of obvious from the types of emails you get, and the types of responses you give that it was not going to lead to strong customer relationships. If all you're doing is writing a 100 words to say "No, I'm not going to do what you want" that's not going to make things better.

(1) Actually 2nd biggest - the biggest was talking about "buying Castro" but having no explanation/links about who the author is, what Castro is, or how/when/why it was bought.

I wrote something like that about 15 years ago for a financial institution.

For what we needed, we intentionally wanted both people to be at the same terminal (it was going to be used to give shell access to a specific unix account that ran a critical system).

That mean that we could implement it as a setuid (root) binary that required both users to authenticate. It had a config file that worked like sudoers, and defined a list of commands that could be called, how many people were needed to authenticate, and which unix groups they had to belong to.

Imagine you were making purchasing decisions about which LLM-based coding tool to use.

If one of the possible vendors convinces you that that they have a next gen model that is so powerful it found 20+ year old bugs in a hardened operating system, that would undoubtedly have an influence on your decision even if you are only buying the current model.

The argument here is that they're confident that the bounds check isn't needed, and would prefer the compiler not insert one.

The choices therefore are:

1. No bound check

2. Bounds check inserted, but that branch isn't covered by tests

3. Bounds check inserted, and that branch is covered by tests

I'm skeptical of the claim that if (3) is infeasible then the next best option is (1)

Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. If it's not an impossible scenario then you have an untested case with option (1) - you've overrun the bounds of an array, which may not be a branch in the code but is definitely a different behaviour than the one you tested.

This is also an unconventional drinking fountain.

Why do you say that?

At least in Australia, drinking fountains ("bubblers"!) are fairly non standardised. I don't recall seeing many with that rubber top, but the rotating release mechanism is pretty common. I'd say press buttons are more common but both are typical.

In Australia the entry level "Dolphin essential" is A$30k which is between US$18.5k and US$21k, depending on the (fairly volatile) exchange rates.

Still not US$14k, but not quite the $25k it is in other markets.

Phones have a lot of that market covered, and the Switch Lite gets close enough for a lot of people who want something other than a phone.

I guess Nintendo don't see enough left over space to bother trying.

Even Linux users in 1999 (when you had to be pretty well informed to know that Linux even existed) were truly that uninformed.

http://www.slackware.com/faq/do_faq.php?faq=general#0

The market penetration of the switch makes it harder for Sony to expand into the family/casual gaming space. That forces Sony to stick to the AAA lane (which is where their focus is) limiting their growth opportunities.

If the switch had been a failure, then a lot of households that currently have a switch (only) would have bought a different console and that would likely have been a PS5 (even if they held on to their previous generation console, and waited a couple of years until the PS5 price dropped below $500)

I have a PS4 and a Switch at home. The kids play the switch and occasionally play on the PS4. I can't justify buying a PS5 because there's only so much gaming time available, and family gaming is covered by the switch and my personal gaming is good enough on my PC. Take the switch out of the equation and that changes.

PS5 is winning the AAA console lane, no doubt. But Sony could have been making more money if they could also own a significant portion of the family console lane.

It's been more than a decade since I was involved with emergency services, but ~15 years ago there was a requirement (in Australia and elsewhere) that phones must be able to call emergency services from any available network even if the preferred carrier did not have service in that area. I assume that is still the case.

That requirement forces phones to have some degree of special handling for emergency calls. It may have required (or been interpreted to require) that a phone make emergency calls over 3G if VoLTE was unavailable. I can imagine someone deciding that means "lets just use 3G for all emergency calls" because who ever expected a case where 4G was available and 3G was not.

Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.

"Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.

Any company that is tying to recoup the costs of building those features will charge the customers that use those features. The existence of a price differential between the 2 editions does not tell you whether they are overcharging.

It's not as widely available. My bank doesn't support registering my card with GarminPay. Pretty much every bank supports Apple and Google.

It would also be interesting to consider smaller groups for discussion. Break the jury into 2 groups of 6, or 3 groups of 4 people.

I wonder whether you could get the benefits of weighing the evidence collectively but reduce the influence that 1 or 2 dominant jurors might have.

If 2 or 3 independent groups reached the same conclusion, does that increase the chances of them being correct?

The main source code for DSA is here

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ss...

You can see that the team did a big refactor of key handling about 14 months ago that required multiple rounds changes to the DSA code.

That's the sort of cost that legacy code brings - it's not about make changing to the DSA feature, it's about the cost of maintaining the DSA code when you make changes across the codebase.

In the original mail, DJM mentions that they'd like to explore a post-quantum signature algorithm. Adding that to the codebase is likely to require some broad changes to key management, and that will be less work if there are fewer supported key types.

It doesn't even have to be a totally "random" (unrelated) motorcycle accident.

If he panicked after the Stuxnet attack, as his family is reported to have said, then it's likely he has behaving erratically and was fearful for his life.

That could easily translate to circumstances where he rides a motorcycle in a particularly dangerous manner - e.g. fleeing from someone he thought was Iranian/Dutch/US/Israeli intelligence (even if they weren't).

The issue doesn't appear to be "pay" but conditions.

From the decision (linked 2 up)

At all material times, Respondents Cognizant and Google have codetermined the essential terms and conditions of employment of employees employed at the E. Parmer Lane facility and have been joint employers.

(2nd to last paragraph of "Findings of Fact > Jurisdiction")

The original article (the register) quotes a union member

Google and Cognizant have proceeded to make unilateral changes to our working conditions such as a forced return to office, removal of sick pay during a global pandemic, and the implementation of a 'Clean Room' policy that bars us from having our phones, paper, or pens in our office, without bargaining with our union.

The line of reasoning seems to be something like:

- There are decisions that Google is making that, if the workers were employees, would need to be negotiated with the union.

- Google is making those decisions with application to the contractors as well as their direct employees

- Consequently, for the purposes of union negotiation, Google is a joint employer (alongside Cognizant) of the contractors because it is making decisions that affect the workers and ought to be negotiated with a union.

If that is the argument, it seems fair to me.

If Google wants to make decisions about the employment conditions of contractors then it needs to accept that it is an "employer" of those workers. Alternatively it can decide not to make decisions about their conditions and leave all of that to Cognizant - but in that case it cannot enforce those policies on the workers until after Cognizant has negotiated with the union and reached an agreement about the the workers conditions. Google would have to make sure that every workplace policy that they wished to have applied to the contractors was handled as a contractual arrangement between Google and Cognizant, not an employment arrangement.

The purpose of a system is what it does.

Do you have a reason to believe (c) is true in practice?

I strongly suspect many interviewers (myself included) would have a few "top issues" and significantly favour candidates who pointed them out. But as the candidate you don't really know which issues will seem important to the interviewer.

It's not an irrelevant exercise though - code reviews are a real part of many roles and making sensible choices about what to comment on is a necessary skill. But it is hard to avoid turning the interview into an exercise in "guess what's on the top of my list"

The ridiculousness isn't that Google has changed their hiring process to reflect their current state, it's that other companies are copying what Google does now with the hope that it will allow them to replicate the success that Google had 20 years ago.

If your premise is "We look a lot like Google circa 2015, and I really like what they've done since then, how did they do it?" then it might make sense to replicate their hiring.

But if you want to achieve what Google achieved between 1998 (founding) and 2004 (IPO) then asking what they do now (or have done over the last 10 years) isn't particularly relevant.

I don't think that's true. The underscore is valid in RFC4648, but the exclamation point is not.

And the RFC explicitly says:

    Implementations MUST reject the encoded data if it contains
   characters outside the base alphabet

In which case it wouldn't be "still light" it would be "already light"

a location east where its still light.

You've got your directions backwards.

7pm in NYC is 4pm in SF, so you wanted to use solar power to provide evening energy then you generate in the West (SF) to power the East (NY).

The GPLv3 has exactly the same clauses (both 5c and 11) yet Google explicitly allows its engineers to contribute to such projects.

Why? Because this isn't about IP risk, it's about trying to kill the AGPL.

There's definitely segmentation by role.

As an example, the product in the linked article is designed to be customer facing, and at the very least, linked to from within an app or site. The person who decides to take that direction is some sort of product owner.

If a person has the authority to decide to incorporate that sort of product (accept & expose feature requests) into their app but doesn't have the authority to sign off on a few hundred dollars a month, then something very unusual is going on.

On the flip side if you're selling something to an individual engineer then the price point is a lot lower. A developer might have autonomy to pick their tools, but they typically won't have the authority to sign off on a large expense.

(Disclosure, I work for Elastic)

It's definitely complicated, and can be quite confusing due to the number of subscription tiers, the ambiguity around terminology, and historical documentation.

We need need to find a way to bring more clarity to the documentation, and we try, but the subscriptions page, in particular, is very difficult. It's already very long, so we don't want to add detailed explanations to individual points but it's hard to find short sentences that are both accurate and well understood by a variety of audiences.

To be clear:

- There is no security in Open Source elasticsearch.

- There is security in the free "basic" license. It is, at the time of writing, disabled by default.

- Early versions of Elasticsearch had no security at all.

- The security product that we (Elastic) produced was exclusively a paid feature for many years

- The core security features (authentication, users management, role based access control) have been free in the basic license since May of last year. https://www.elastic.co/blog/security-for-elasticsearch-is-no...

- If you download the latest version of the Elastic-licensed distribution of Elasticsearch (which is the default download if you get it from our website or package repositories), you get a version on which you can enable security, free of charge, without needing to register, with no expiry.

The only documentation I found which says "there is no security", etc is from old blog articles (e.g. this one from 2013 https://www.elastic.co/de/blog/found-elasticsearch-security). We don't do a great job of indicating that the information on those articles is out of date.

I'm the lead engineer for Elasticsearch security.

I'm sorry - I have never seen that specific post on our forums before, but the poster was mistaken and by not correcting it at the time, we have allowed incorrect information to perpetuate.

In versions where security was a paid feature, if a trial license expired, security would remain enabled, but certain operations would be rejected for all users (per the warning text "Cluster health, cluster stats and indices stats operations are blocked")

We intentionally did not open the cluster to be world readable/writable. The administrator would be left with a cluster that was secure, but blocked access to some functions that are necessary for running a production cluster. It was up to them to explicitly upgrade to a paid license and re-enable those APIs, or downgrade to a "basic" license which required acknowledgement that security would be disabled.

An example (this is from 6.7.0 because it's the newest version I have installed at the moment, where security was not free. This was true at the time the original forum post was written - I just tested 5.2.0 as well, and the results are the same, with slightly different error messages):

License state:

   license [fc5bee69-f086-4989-a32a-5db329692363] mode [trial] - valid
  license [fc5bee69-f086-4989-a32a-5db329692363] - expired
  recovered [1] indices into cluster_state
  LICENSE [EXPIRED] ON [SATURDAY, SEPTEMBER 28, 2019].

  curl http://localhost:9200/
  {"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication token for REST request [/]","header":{"WWW-Authenticate":["ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}}],"type":"security_exception","reason":"missing authentication token for REST request [/]","header":{"WWW-Authenticate":["ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}},"status":401}%

  curl -u elastic http://localhost:9200/
  Enter host password for user 'elastic':
  {
    "name" : "node1",
    "cluster_name" : "es-670",
    ...

  curl -u elastic http://localhost:9200/_cluster/health
  Enter host password for user 'elastic':
  {"error":{"root_cause":[{"type":"security_exception","reason":"current license is non-compliant for [security]","license.expired.feature":"security"}],"type":"security_exception","reason":"current license is non-compliant for [security]","license.expired.feature":"security"},"status":403}

  blocking [indices:monitor/stats] operation due to expired license. ...

(Disclosure, as mentioned at the top, I work for Elastic)

As someone who has built and maintains the SAML implementation for an SP it's funny how many of your complaints about bad SPs match my issues with bad IdPs.

Most IdP-as-a-service vendors produce their own metadata, but can't consume SP metadata. They invent their own terminology, make it hard to pass attributes, and rarely offer options around which binding to use.

It's unfortunately all too common to get into a situation where The spec says X and Y are valid. The interoperability profile requires X. But this popular vendor only implements Y, and does it incorrectly.

In my experience that leads to the organisation hiring more people at the upper ranks of the management track, and the end result is that management becomes the easier path to promotion and most of your senior staff are managers, not ICs.

If you have a team of engineers rangining from L3-L7 (on Square's scale), and you want to hire a new engineer you'll interview, and then decide on a level based on the person's skills & experience. Probably you knew up front that you were targeting a 4/5 or a 6/7, but generally, you don't go looking for a L7 IC, you look for an experienced engineer and then put them at the level that is appropriate.

But if that same team needs a manager then your policy is that they need to be a L8 or above (otherwise you'll need to do a big reshuffle to move all the L7 ICs out). So now you interview looking for a L8+ EM, and you hire the best person you can find, and you make them a L8. Maybe they're at the lower end of the L8 scale, and you know this role will be a stretch for them, but that's OK because it's good to stretch people into new roles and you think they'll step up.

But, you would have made a different decision when deciding what level to give an IC. My experience has been that for ICs, companies (rightly) err on the side of caution and if they think that the new hire is on the lower end of the scale they'll bring them in at the lower level, and let them prove themselves.

So if you're asking Is this engineer a N or (N+1)? you'll be more likely to bring them in at N. But for a manager, there are incentives to bring them in at N+1 so that they can maange the members of the team who are N.

And now your standards for an (N+1) IC are higher than your standards for (N+1) EM. And when it comes to promotion time, the new hires form part of the benchmark. And your existing Level-N EMs are performing just as well as your new N+1 EMs, so they're good candidates for promotion. But your existing Level-N ICs are really only performing at the same level as your new Level-N ICs, so things seem to be balanced.

I don't think there are any easy solutions to this problem. If you have a policy of ICs reporting to higher-leveled EMs then you create a system that makes it easier to be promoted on the management track. But if you have ICs reporting to a same-(or lower)-leveled manager, then you have a perception (and possibly an reality) that being a manager gives you more organisational power than the same level IC.