Please don't ever make this assumption. I referred an acquaintance from school to my workplace (he was a great project partner, and I was the first of us to get hired after graduation, so why not?), and apparently when he passed through everyone was just... doing work. That was a telltale sign that everyone was grumpy to him.

I had to explain that we basically don't work at all on Friday afternoons because we're too busy drinking, we play pingpong religiously, frequent out of office events on the weekends, and in general it's just an enjoyable crowd. Random conversations happen all the time.

But nope, that one time he came through the office, everyone looked unhappy. Because they were working, I guess.

That sounds ... very strange. Weekends aren't generally speaking "office hours", and more importantly also not "working hours". Having an "out of office event" in my world is when you're doing work, i.e. it's during normal working hours, but you're not at work.

Having frequent work-related "events" on weekends sounds like a total bummer.

This also sounds like a major bummer -- aside from the fact that does smacks (way too heavily) of bro culture, it's incredibly off-putting to anyone who doesn't drink (or who does, but thinks drinking in the office -- or drinking heavily in the afternoon on any kind of a regular basis -- is basically pretty stupid).

But it's okay to tell them what to do?

Um, neither of those are true in any companies I worked at in the US except for a job in high school as a cash register attendee.

Did you suggest that you would feel more comfortable if they sat differently?

This doesn't make any difference for me personally but I understand why some people would prefer that the person not sit like that. However, if you did not express an objection with regards to how that made you feel, I don't think "insisted" is a fair choice of words there.

"He insisted on chewing with his mouth open, I mean, ew. Gross."

The offender is generally expected to read non-verbal, and often non-expressed, communication of the offended's opinion.

Wait, what? Slow down a sec and elaborate more about this please

Everyone knows this because Netflix released a big presentation about it a while ago. They keep "top performers" only as long as they are top performance from Netflix's perspective, and then dismiss them with a "generous severance".

It's definitely an interesting way to do employment.

http://consultingadultblog.blogspot.com/2010/10/unreasonable...

I just thought it was incredibly interesting how a person can be so polarizing. This person acts like she walks on water!

What's basically clear is that the candidates complaining here a) didn't do their basic f-ing homework, and b) are seriously misrepresenting Netflix views on letting people go.

Not I agree with that part of Netflix culture (and it would pretty much be illegal in most Western countries), but there is a clear logic behind it, and I seriously doubt they skipped that part in the interview.

You can assume the posters here are being malicious, or that they're honestly telling what they understood from the interview. If the latter, then I'd argue it's Netflix fault for failing to leave the right impression.

Potential employees don't need to know her name to make an informed decision about whether or not apply to Netflix.

I got an offer but turned them down because their recruiter was so crazy aggressive it made me feel that Netflix would be a very unhappy place to work.

From what I've heard from ex-employees (one a recruiter) the hiring/salary/firing process there is not well organized. People often make more than managers or more senior employees and large layoffs every year for the 'bottom 10%' make for some weird social dynamics.

As much as I respect and admire their technical processes there I'm not convinced it's really a good place to work.

I've been a happy Netflix employee for over 4 years and have never experienced a 'large layoff' event. All the layoffs I've witnessed were not a surprise for the people affected.

Senior engineers usually make more money than their direct managers, but I fail to see how that's an issue.

I'm guessing RayVR met with Patty who left Netflix 2 years ago. My interview with her was different but I guess it would depend on your background and what she was trying to determine. In my case it was mostly to see if I was going to be a good cultural fit since I was at the time working for Yahoo which had a completely different culture. To me that was an entirely reasonable thing to do. Actually the whole interview process was great, and it was one of the major reasons I chose Netflix over other companies.

The day after I took over the team, my director sat me down and said "I don't know if you've looked yet, but most of your engineers make more than you do. That's because they're incredibly valuable. Your number one job is to keep them happy."

In the last two years of managing this team, I've consistently gotten paid less than the top engineers on my team.

Totally OK with it.

Also remember that HR are not your friends, they don't work for you, they don't understand your job, or you as a person; they work for the company; their job is to:

- make sure the company doesn't overpay for "resources" (a "talent buyer" if you will)

- make sure said resources, once hired, stay in line and don't make waves of any kind, and terminate them as needed, as silently as possible.

We tend to think of HR as an adult version of the nice and benevolent elementary school teacher who first helped us understand the world; the reality is they are more like cops. Bad cops usually.

This part is so important. Our HR department doesn't actually know anyone in the office. It becomes particularly interesting when they organize a company outing and have completely missed that there is a large percent of the workforce that does not speak the native language where I live, but they still have event hosts that will only present things in this language. They've done this 3 years in a row now.

The "bad cop" analogy is spot-on. I've used that exact analogy—my boss (unwittingly) played "good cop", while the HR consultants played "bad cop".

I pretty much just go to work, chill out, and hope I can find a better gig sometime in the near future (I'm on basically an ever-renewing contract but the vendors in our system are horrible about rate increase).

About the offer you got, maybe they thought you were strong in areas that would be important to the DW team even though you didn't fit into their expectations for the position you interviewed for. I've interviewed people who were obviously talented engineers but not quite right for the position in question, and suggested them for other positions they were better-suited for. This has worked well in my experience, but who knows if that's what happened at Netflix.

The truth of the matter is you could probably get statistically similar results from a voodoo witch doctor reading chicken entrails.

Ok, maybe not, but I really get the feeling that most hiring systems are arbitrary and are less "tilted toward false negatives" and more just plain random. In the cases such as Google, they also tend to create a monoculture which probably feels right at the moment but I think really hurts the company in the long term.

There are thousands of pegs on the board, and your resume predicts the starting position of your disk.

But once you hit the pegs, it's essentially random. Some pegs bounce you towards the jackpot and other pegs bounce you towards 0.

It all depends on if you have a similar background, if the person likes you, if you've heard of the question before or solved something similar, if your chosen language fits the problem domain, etc.

At the end of the day, your ability to actually do things doesn't matter much in the interview process. I've worked at 2 huge well known companies and failed at several other interviews. Hundreds of millions of people use my code every day. After nearly a decade in tech, I've never gotten a bad performance review. But I still plinko'ed into the 0 spot many times.

As I get older, I find it's easiest just to enter orgs from friend's recommendations, preferably at smaller companies. Playing the plinko game with your livelihood is an exhausting waste of time, and often represents the politicking that goes on at these huge companies when review time comes around.

It's a great way to feel good about yourself and your interview process; it's also a great way to not find fault in your interview process as it becomes arbitrarily ... arbitrary.

I would agree with you about the monoculture aspect where they tend to hire new college grads from mostly the top colleges. I thought it's a little bit too inbred, but they also buy a lot of companies and get a much broader set of employees that way. Although, they might dump a lot of the acquired employees instead of keeping them on permanently once the acquisition goes through.

I mean seriously, this is the question as I found it:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

And here is an answer in bash that took me literally 30 seconds:

  for num in {1..100} ; do
    out=""
    (( $num % 3 == 0 )) && out="Fizz"
    (( $num % 5 == 0 )) && out="${out}Buzz"
    echo ${out:-$num}
  done

My main problem is that, as a candidate, I would interpret being asked this question to mean that the interviewers have already undervalued me (or worse, have no idea how to value me).

One weak question in hours of interviews isn't bad, but now I'm mentally preparing for more weak questions. Making a candidate disengage is a sure way to get a bad interview, or a good interview that results in a "no thanks" to your offer.

No, your main problem is just how many of your contemporaries with indistinguishable backgrounds and experience totally bombs this question.

Being offended by a simple fizz-buzz style question[1] is roughly as constructive as being offended by "Is this a good time to talk?" even when a good time to talk has been carefully scheduled.

1: I don't think many people use fizz-buzz exactly, it's too well known, but there are tons of other really quite simple questions that exercise two or three basic programming concepts, maybe throw in some basic problem solving for good measure.

But that's the problem that FizzBuzz highlights. A bunch of people just can't do it. This isn't about the (now retracted) Sheep and Goats stuff. Plenty of the people who fail fizzbuzz are computer science graduates or senior programmers.

I don't know of any research about why people who think they can program can't do FizzBuzz. I'd love to see it though.

During an interview, I'm interviewing the interviewers as well as being interviewed. Part of that process (for me) is to see if they have correctly identified my skill level (in my opinion), so that hopefully they have the right kind of position in mind for me.

The name of a position is often meaningless, unless you know the inner workings of that organization. "Senior" is meaningless window dressing. It's how the role fits within the team that determines if it's right for me and if I will be able to have the kind of impact I want.

Now, I am sure that you, skuhn are able to do those simple things, but the guy interviewing you doesn't know it. If he asks you a simple question that you can nail in 5 minutes, and answer "sorry dude, your question is so easy I find it offending", the interviewer will think you're an arrogant douche - that's how I would feel at least. Instead, just solve the problem he's asking you and move on.

If after that he keeps asking stupid questions, well, it's a different story and you probably wouldn't fit well in that company.

I think this question is suitable for phone screening. You should already know if someone can do the work equivalent of tying their shoes before bringing them on-site. If I was asked a question at this level during an on-site interview, I would be a little disappointed. If the entire interview continued in that vein, I wouldn't accept the position.

There is also the common problem where candidates google for answers or at least seem to google for answers during phone screens.

The problem with asking truly challenging coding questions during an interview is that they are often too challenging to finish in the time allotted. Frequently challenging coding questions require an ahah moment or domain knowledge. For example if an interviewer asks a candidate to invent an advanced algorithm on the spot what is being measured? If the candidate gets the answer right they might be really smart, they more likely have been previously exposed to the idea, or they got lucky. If they got the answer wrong the interviewer must judge them on their ability to communicate their thought process during their attempt - but from that the interviewer didn't learn if they can code.

You shouldn't be disappointed that interviewers don't know straight away that you aren't a charlatan. You should instead be disappointed by the fact that there is such a high number of successful charlatans in our industry.

When I asked that question, I was looking for fluency. A candidate shouldn't have to think about it. They should write c >= 'A', instead of floundering because they don't remember the ASCII value of 'A'. If asked, they should be able to iterate over the string without taking strlen first.

This is basic stuff, but you might be surprised how many people with years of software development experience on their resumes can't do it. Moreover, I found that a good performance on this easy question was highly predictive of good performance on harder questions. Not that this didn't stop me from asking hard questions. :)

Where it does get complicated is determining whether a codepoint or a digraph of multiple codepoints is a letter, and that's culture-dependent; e.g. IJ in Dutch.

That should have been a big clue right there that it wasn't going to go well. Based on their hiring criterion and culture, that they still do a technical interview like they were hiring junior developers is a bad sigh.

And so I did. And oh boy, there were a LOT of previous Fortune 500 Senior devs that could not write anything that even resembles a correct fizzbuzz solution in any language they like without time restriction (I had to kick a few people out after I left them alone for 30 minutes and they told me they need more time).

All their CV's looked fine though. If I interview you, I'll ask you to write code, on any level. Usually I asked interviewees for ~3 code samples on paper starting with fizzbuzz moving up in difficulty to still beeing a relatively easy ~5 minute task.

I've had one interviewee that started to laugh when I asked him for a fizzbuzz sample and he said, "well that's like asking a baker to bake a bun". he proceded to write a fizzbuzz solution down and is apparently one of the top developers at that company now.

I don't care how senior you are. If you're offended by quickly writing down a fizzbuzz solution you're not senior enough to realize how much some people suck at programming.

Obviously the actual only interview only started after they wrote fizzbuzz, fizzbuzz helped me stop wasting my time and I convinced HR to stop sending me CVs of people that played bullshit bingo in their CVs.

Sure you could blame HR on this for not filtering good enough but HR aren't developers. Although I'm not saying HR couldn't have given me better CVs...

The volume of "good" CVs that landed on my desk was consistently high, but when we spoke to the candidates on their first telephone interview it became immediately apparent that they were not nearly as skilled at security as they were at writing CVs.

In the end, we inserted a 10 minute quick-fire Q&A at the beginning of the telephone interview which was as basic as "Define: Confidentiality, Integrity, and Availability" and other such trivial security knowledge. It was terrifying the number of people applying for mid/senior level jobs, or contracts with high day-rates who couldn't get past this. What was most galling was when people were obviously googling the anwswers whilst we spoke - we countered this with simple "which is better, and why" type questions so that there was too many variables to google and you also needed to defend your answer.

There were only a very small number of candidates who, when confronted with the Q&A responded in a "are you serious?" kind of way and just rattled off the basic knowledge in a couple of minutes. With these we could get down to the detail of the real interview pretty quickly.

I did that when we were ~7 people, then the company grew, we got a HR department and I kinda lost interest in the company and was just doing my job. Efficient shouting-trough-the-room to get shit done was replaced by by slow corporate processes, office politics started to happen, somebody decided that our SMB shared folders must have a number in front so they are shown in the order admin though they needed to be shown... So when they decided to optimize folder structures for mouse-heavy non-technical users, taking my ability to quickly nagivate trough the directory structure, I decided it was time to leave :)

Edit: One funny thing I forgot, they built a file-name generator in excel we had to use :)

[1] http://blog.codinghorror.com/why-cant-programmers-program/

If you can not find anyone at all with example code/projects, perhaps then start employing fizzbuzz on folks, but... I can't imagine it's too hard to find developers with at least a minimal portfolio that demonstrates something at least as complex, if not moreso, than fizzbuzz.

I really like Fizzbuzz because for someone who is a good programmer, whether they've ever seen it or not, they can do it in about two minutes, and then at least I can believe that their code sample is theirs.

He had a nice code sample (pre-github era).

When I see "expert" on a CV I have learned to become cynical.

I asked him about his expertise and he spoke in platitudes about it - at a sort of BBC News kind of level. I'm certainly not an expert but I know sufficient to be able to ask useful questions about it.

He couldn't tell me anything at all about biometrics. I continued to probe.

Turns out that by "biometrics expert" he quite unashamedly meant he had, at the request of a manager, bought a USB fingerprint reader from PC World and installed it so that his manager didn't have to use a password any more.

One has to play this game on marketing documents to be considered. For some reason "pretty good, definitely still learning" doesn't click with many HR people. You can't really blame candidates for trying to get hired by presenting themselves in an authoritative context.

I don't consider anyone an actual expert in something unless they have hard, indisputable credentials, like a long history of commits to the core project (for expertise in specific software/languages/frameworks), etc.

But something about "expert" really grates on me. I think it's that it is a self-anointed title in nearly all cases. There are legitimately experts in lots of different areas - if you happened to invent IDS, for example, you go right ahead and call yourself an expert. If you happen to have run a bunch of Snort rules across a prod environment for a year or two, you might be "experienced", go on, stretch it to "highly experienced" for all I care, but if you stretch it to "expert" then paint me cynical.

Some of these stories about super experienced ("10+ years") developers not being able to answer the most basic of basic syntax or "algorithm" questions seem far-fetched to me.

Really I don't think those sort of on-the-spot tests/trivia questions are representative by themselves. They may be a useful part of a larger investigation.

Two things to stop code sample plagiarism: choose a unique code challenge and, if you're really worried about it, give the client a laptop and tell them to bang something simple out right there and come back in 30-60 minutes to check.

Honestly, though, I've rarely depended on either code samples or code trivia to determine if someone is a good hire. If you sit and talk about dev with a person, you can tell if they're on their game or not 90% of the time. The sample/on-the-spot tests can help weed out that extra 10%.

I'm not sure how this is possible either, but the world works in mysterious ways.

In the end they said "Okay, you pass." When I asked why, the answer was "While we don't agree with all the choices, it's basically well-written and does something interesting. We just wanted to know if you were the one who wrote it."

- did they likely write the code, for obvious reasons - are they aware of the various tradeoffs and choices they made, i.e. we might not agree but can they make a reasonable argument for them - this demonstrates breadth of knowledge - how are their communication skills?

I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives.

Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.

I would be delighted if an interviewer asked me such questions about my code.

Fizz buzz you can't skate around. Either you know how to implement something, or you don't.

I'd actually have to think for a minute on how to do fizz buzz right now, simply because it is so far remove from the actual engineering workflow.

Err, what? Fizzbuzz is NOT a riddle. It's intentionally meant to be a stupid simple test, and everyone has written stupid simple code at some point. Even as a "senior engineer" you'll have to write dumb business logic code, even if it's only occasional.

If you really struggle with fizzbuzz it would almost assuredly be a sign that you would really struggle to write quality software in a timely manner. It's also a sign that you really aren't familiar with even the basic control flow of your chosen language, which is similarly worrying.

The only part of fizzbuzz that's "removed from the actual engineering workflow" is MAYBE the modulus operation, which I'm willing to bet most interviewers probably won't give a shit if you goof on the syntax a little and write "%" when you should've written "%%".

And even then, a perfectly acceptable fizzbuzz can be written without using mod if you're not familiar with that basic arithmetic operation.

This type of attitude is highly suspicious.

If you're not the kind of person who thinks fizz buzz is trivial, then there are actual red flags.

The idea of "fizzbuzz" is to show basic understanding of language control structures and flow. Better, more universal tests that actually use language constructs that are encountered in daily operation could definitely be devised to demonstrate the same fundamental concepts.

90% of the code I've written, and all the clever stuff, is copyright of and property of corporations. There's no way I'd jeopardise my current job by showing someone else that code

I would love to exist in a world where everyone could fizz buzz flawlessly.

I'll stop asking fizzbuzz when people stop failing it.

And you know what? More than 1/2 the people that claim to be doing a job writing code right now can not do it. If you can't write a simple loop in your preferred language, I have to wonder how you are doing coding right now and being successful.

That said, for FizzBuzz proper, one should have dozens of solutions memorized for these situations, but for similarly easy questions the candidate might not have come across that might end up being a big deal.

I've definitely felt that pressure as an interviewee. It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.

The most fun technical questions I've had start with making a functional algorithm and then massaging it to meet whatever time/space complexity requirements are asked for. Sometimes it results in a complete rewrite and that's ok, the real world works like that too.

I almost always preface whiteboard coding sessions with "I'm going to write some dumb, slow code and then we can make it faster if you want. Sound OK?" I've never had anyone disagree with this, but if they tell you they want you to go straight to the clever solution, hey, now you know what they're looking for.

50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?

I don't quite buy the whole fizz-buzz story, though I don't have an adequate explanation for what could cause these kinds of failure rates. Something seems very off.

Not 50% of working programmers, but of the programmer applicant pool. The applicants who can find jobs quickly aren't in the pool very long, and so it's dominated by the fakers and those who otherwise shouldn't be there. ... Which should make the reported phenomenon a little more believable.

However, that's all it's good for, which means it should be a single pass/fail question. Asking the candidate increasingly specific iterations of fizzbuzz would be a waste of time.

No, it really isn't. You should have a set of hiring standards that you strive to make as objective and quantifiable as possible. The interviewer should also be doing everything he or she can do to minimize their own personal bias entering into the evaluation of you as a candidate.

Hiring people you get along with, i.e. people like you, is usually a quick path towards a homogeneous team of straight, white males from privileged backgrounds.

The primary reason is so that everyone is seeing the same thing, including these sorts of personality conflicts. If Bob thinks the candidate is horrible due to some weird hangup and they were interviewing solo, the team would have to believe Bob. But if everyone else saw the interaction, they'd know that Bob was just being a cantankerous coot.

The first company I worked at for 4 years made use of this, in addition to meeting in person, at the end of the day, to make a decision.

Benefits of the pair interview: Two different opinions on the candidate for the same "experience". If either interviewer had poor tendencies, they'll be curtailed a bit because they know someone else is there to witness them.

If both interviewers are in agreement, that's a pretty strong data point.

When it came time for "review" at the end of the day, we started with an around the room "thumbs up/down". No hiding behind an anonymous email to the recruiter/manager. If it was unanimously up...offer. Unanimously down? Obvious no hire. If it was mixed, we'd go around to all of the thumbs down, and ask, "Are you on the fence, or are you 100% vehemently opposed to this candidate?" If they said, "NO WAY JOSE", we'd ask them to give their reasoning. Then, we'd ask if anyone had a positive enough experience to argue in favor of the candidate. If not? No hire. If yes, we'd then go around the room and ask all of the interviewers to give a full description of the interview. You'll note that this part gives the full data, but takes the most time, but could be avoided (an optimization) if it was going to be ultimately fruitless.

This was by far the best hiring decision making process I've been a part of. No process, is perfect, but I feel this was pretty fair.

Oh - lastly, if a candidate was particularly hard to decide on, and we went around the room, and some people were for them, and some were against, and it ended up in deadlock - we ended the meeting and it was up to the ranking members of the team to decide (i.e. managers.) This meant that after one round of debate, we wouldn't keep wasting the company's dime trying to force consensus, and instead moved the decision to the people who the company had already decided it wanted to make decisions. So, if democracy worked...great, but this was a business, and we had get shit done, so lacking clear consensus, the burden was reduced.

After typing this out, I really, really whole heartedly respect this process - compared to much of what I've seen in the Valley.

Interviews are clearly stressful situations for a majority of candidates, even if their technical chops are without question. This ends up manifesting in ways that can come off as personality defects / lack of fit. I can think of a few times where the person I went in with came out with a specific point in spacetime that was wrinkled for them - a comment they thought was off, something about their behavior - and more than half of the time I've noticed comments the candidate made, or compensating factors, that reasonably explained these wrinkles. A lot of the time, I'm trying to balance the things I care about asking with paying attention to my co-interviewer so I can provide objectiveness down the line.

So far, it's worked out well. No lemons yet.

I happen to work on a three person team right now and I like my two colleagues. It does not conform at all to your forecast for (straight, white, privileged, men). Sorry. I think this is based on the assumption that people like others that are like themselves, which in fact is not very true. I prefer to be around people that are very different from me.

Unfortunately, it is uncontroversial that most people show preferences for people similar to themselves when choosing friends, romantic partners, and employees. Nobody, that I've heard, is saying that this applies to every single person, so there's no reason to say that it can't be true because you don't follow it.

http://www.sciencedaily.com/releases/2011/09/110922093313.ht... for a random paper

Precious.

And of course, an entirely different take could be made from your response -- precisely because you do have a solid grounding in CS, you've probably chosen to spend your time with languages with (for want of a better term) more "powerful", and arguably more standard constructions than what Python affords for this kind of a logical switch -- namely, a ternary operator -- which if Python had it, would probably look a lot like this:

    x = y ? 100 : 0

So if you were interviewing for a senior-level, Python-specific position I can see why they'd expect you to know the if-then-else trick. But if it's a secondary language for you, then the feedback that interviewer gave you definitely seems more than a bit off-base.

(DISCLAIMER: No, I don't think Python is a flawed language because it doesn't have a ternary op, or that it should have "stronger CS fundamentals" or any of that. It's just a side aspect or a different, larger point I was making).

    default_result if condition else alternate_result

I'd like to bring up that while it's a matter of opinion the older ugly ?: syntax is much less readable even when you memorize it. I never use ?: syntax ternary expressions in languages that have them because I always have to look it up. That's why a number of languages prefer python-like versions or forms which emphasize to an even larger degree the fact that its just an if-else as an expression to an even larger degree(so I'd question that it's standard, I'm not 100% it's older either as I think the LISP version is closer to the python version).

CoffeeScript

    s = if condition then "yup" else "nope"

    abs := x > 0 ifTrue: [ x ] ifFalse: [ x negated ]

Scala a = if (n == 12) "twelve" else "not twelve"

Rust

    let y = if x == 5 { 10 } else { 15 }; // y: i32

    fac x = if x==0 then
           1
           else x * fac (x - 1)

    boolean and true_branch or false_branch

This is parallel to the standard C one. I'm surprised no one has mentioned it, but I guess that makes sense because it's not very explicit about what it's doing, which goes agains the spirit of python. Probably not very common for python programmers to use.

  x = 11 if False else ( 12 if False else 13)
  print x
  => 13

  x = False or (True or False)

    if cond1:
        if cond2:
            x = 12
        else:
            x = 11
    else:
        x = 13

This also removes ambiguity in the case where you might want to assign to x some falsey thing like None or [] or zero:

    >>> y = None
    >>> x = False or ( y or False )
    >>> x
    False

    >>> print [bool(f) for f in [None, 0, 0.0, [], ()]]
    [False, False, False, False, False]

Maybe if you never program in python. Otherwise it makes absolutely no sense to do so because its obvious that every value is evaluated for its boolean value.