lambda

I would also like to point out, for the benefit of anyone else here (just replying to you to clarify your point), that the Logical Rules referred to are commonly referred to as the Tromp-Taylor Rules, after John Tromp (the submitter and parent commenter) and Bill Taylor, who wrote them up as a simplified version of the New Zealand rules; and that these, in turn, are in the branch of Chinese-style, or area-scoring rules (counting the sum of stones on the board and territory surrounded for score), to contrast with Japanese and Korean style, or territory-scoring rules (counting the sum of territory surrounded minus captured stones for the score).

The reason that rulesets in the Chinese style branch are more amenable to mathematical analysis are that you can play the game until you have an unambiguous result about the life or death of a group, and thus these rulesets usually involve simply resuming the game and playing it out if there is any dispute about whether a group is alive or dead (or, for the logical rules, don't involve resumption at all, you just play it out and score it as is after two passes, with all empty points that reach two colors being counted for no one; since in area scoring games, ending the game before that point is mainly a convention for human players who don't feel the need to play all the way to the point of killing obviously dead groups).

Under Japanese style rules, playing within your territory to kill a disputed group may reduce your own score, so rather than just playing it out to the end, there are an elaborate set of conventions for determining the life or death of particular shapes. This elaborate set of conventions is much more difficult to represent mathematically.

The American Go Association rules of Go have an interesting hack to allow you to use Japanese-style territory scoring, but wind up with the same result as Chinese-style area scoring would give you, by having you actually give your opponent a stone as a capture when you pass, plus making the game-ending passes be two or three passes such that each player has the same number of turns. This preserves the benefit of area scoring, that any dispute on life or death can be resolved by resuming the game and playing it out until the situation is completely unambiguous, while still allowing the somewhat easier method of counting that territory scoring provides (filling in liberties with captured stones, and then just counting the remaining territory, and thus having to actually count to a lower number).

The Tromp-Taylor rules do make some adjustments for the sake of making it even more amenable to analysis that most other rulesets do not, such as allowing suicide. This doesn't actually affect the strategy in very many games, as it's very rare to encounter a situation in which a suicidal move would be the best choice, but it tends to make analysis a bit simpler as there is one fewer constraint to worry about. I feel like allowing suicide is more elegant, but it is only allowed in a few rulesets.

It is unfortunate that for such a simple game, there is no one agreed upon worldwide rule set. There are a couple of different parameters that you can tweak in a ruleset that give you a game that is very similar, but different enough in a few corner cases to make them different games; territory vs. area scoring (and with territory, the large number of conventions on life and death you need to make it work), simple ko vs. situational superko vs. positional superko, suicide vs. no suicide, counting points in seki, and komi (number of extra points for the second player to make up for the first-move advantage).

Nope, it was a typo; I edited my phrasing a couple of times, and the last edit left two copies of the word. Fixed, thanks.

I apologize. I had skimmed the paper, but not read it in depth, and it was clear that you had considered symmetries (such as Figure 4 in the paper); I assumed, then, that your algorithm would prune symmetries and simply account for them by multiplying the results in each class by the number of symmetries. I hadn't yet finished reading the paper, however.

Actually, it's interesting in the sense of combinatorial game theory (https://en.wikipedia.org/wiki/Combinatorial_game_theory) not the branch of decision theory for interactive rational agents known as game theory (https://en.wikipedia.org/wiki/Game_theory). Two only very distantly related subjects which unfortunately have confusingly similar names.

When I say "TCP questions", I mean that I ask the standard "what happens when you type google.com into your browser and press return," and expect to get them to mention TCP at some point. If they don't, I specifically prompt them, asking what protocols HTTP is built on top of, and how it finds the address of the server to contact.

I am not looking for detailed knowledge of receive windows, sequence numbers, or anything of the sort. I consider knowledge that TCP exists, and DNS exists, to be sufficient. And as mentioned repeatedly, even if they know nothing of this question, this is one of many. I want to see if they are the type to dig into the stack and learn more than just their particular domain, but the basic programming exercise and portfolio are the most important things that I look at.

Of course they are taking symmetries into account. They are including symmetries in their definition of what the different states are, and thus accounting for them in the count, but they absolutely are pruning symmetries in their implementation. Read the draft of the paper (https://tromp.github.io/go/gostate.ps) if you're interested in the techniques.

No, nowhere remotely close. This is just a matter of trying to precisely characterize the state space; there are upper and lower bounds that have been established, but it's an interesting computational problem to precisely characterize exactly how many legal positions there are.

I think that there's not much utility in this work beyond "it's an interesting challenge," but, well, there's not much utility in any game beyond "it's an interesting challenge."

Exactly. I've had several candidates that I have passed who on the TCP question have said "I don't know, networking is not my strong point." That's great! Knowing when you don't know something and should just move in is a real strength.

As long as someone does fine on most of the rest of the questions, having one or two gaps in knowledge is not a problem, I can tell from the other questions that they'll be able to pick it up if they need it, or ask for help when they need it.

  Mainly because a lot of the things you just listed are 
  incredibly stupid requirements.

Do you know the job I'm hiring for? Perhaps I'm hiring for something a little more complicated than a front-end developer over a CRUD app.

  If I spent my life doing ruby sites that save basic data 
  into a mysqldb, why does it matter whether I use 
  sometching that takes 100,000 operations or 10,000 ones, 
  when the web page still opens in 0.5 vs 0.51 seconds?

Because sometimes, those 100,000 operations actually wind up pushing it from 0.5 to 5 seconds. Or even worse, something that works with 1,000 records in .5 seconds, once you go up to 100,000 records takes over an hour, because you're doing something that takes O(n^2) time, so a hundredfold increase in number of records leads to it taking ten thousand times longer. If you don't even know what big-O notation is, or how to think about an algorithm like that, you may not even realize why everything has suddenly gotten so slow; or even worse, you may have designed and implemented a large system with that O(n^2) baked in to the very fundamental design, so it would require a huge rewrite to eliminate it.

  Who gives a fuck about TCP when the browser abstracted 
  that all away?

It is not always abstracted away as cleanly as you would like. For example, here is a bug that occurred when Firefox sent an HTTP request in several smaller packets rather than one larger one, and that caused it to break when talking to IIS:

https://bugzilla.mozilla.org/show_bug.cgi?id=137155

How would someone impacted by that be able to even figure out what's going on, if they don't know anything about what HTTP is built upon?

  Imagine asking a front end developer to make a console 
  app in their interview

Hey, it's a good thing this isn't my front-end developer interview; in that, I give people a basic REST API to program against, and have them write a simple frond-end for it, using any toolkit they like. No console apps at all in my front-end interview.

This is my back end, systems interview, for people working on a network attached storage system, where we frequently need to debug complex problems in a distributed environment, solve compatibility problems with third party proprietary software in which the options for debugging it are slogging through syscall traces or stepping through it in IDA, where we've had performance problems where tweaking the kernel's TCP retransmit timeout for systems that we knew were on the local network has made a huge improvement.

  You do a particular type of programming. You seem to want 
  to judge everyone else by your niche without 
  understanding that a lot of the skills you list as 
  essential are actually almost completely irrelevant to 
  huge swathes of programmers.

Or maybe my interview is tailored for the job that I'm hiring for? As I said, this is my back-end, systems interview, and I have a different one for front-end developers.

And as I said, I don't expect every developer to pass every question. I do still ask the TCP and algorithmic complexity questions to front-end developers, but if they do poorly on those while being able to write up a front-end to spec based on the API I give them, and being able to describe intelligently how they would design a more complex interface with richer interactivity, then I know that they can do the job assigned and we have sufficient other people who can do review to ensure that they don't write themselves into a corner complexity-wise or help them debug weird problems due to something in the networking stack. Or if they do well at the TCP and algorithmic complexity, but are relatively new to front-end development, I know that they have a good base of background knowledge and analytic mind, which means they should be able to pick up the rest of the skills they need without too much difficulty.

But if someone does poorly on everything, or more than a couple of the questions, it means that we would basically be flying blind hiring them; we would need to train them up on everything they need to do, and in the end, there's no guarantee that they'd actually be able to perform.

No, we gave him plenty of interesting work. And as we discovered, the above described interview was actually a fairly low bar; when faced with problems slightly more challenging, he would fall apart and give up in frustration. And he was very touchy, so wouldn't accept help when he hit those kinds of situations; he would just spend all of his time reading Reddit and HN instead of getting the help he needed. He was essentially impossible to work with.

We had overlooked his personality quirks when hiring him, as we didn't want filter out someone who was technically sharp but was simply personally quite weird, but it turns out that in practice we just could not work with him.