Winnie-the-Pooh brought joy to readers, but misery to the Milnes - <AUTHOR> https://www.economist.com/blogs/prospero/2017/09/beary-sad <comment><USER2> > Winnie-the-Pooh brought joy to readers, but misery to the Milnes [...]

[...] and, functionally, a constitutional amendment to the United States. Disney's Winnie-the-Pooh annual merchandising revenue are said to be north of 5 billion dollars a year. As much as the mouse, preventing the escape of the bear has paid for two copyright extension acts, defeat of various constitutional challenges and copyright reform attempts, support for US adoption of the Berne convention, and for TPP's Investor State Dispute Settlement provisions (aka regulatory capture insurance - "if we pay your legislature to get us a windfall, and you someday change it's mind, you'll have to reimburse us for our lost windfall - it's only fair"), and for a multi-decade press PR campaign.

While the bear remains in bondage, so long will copyright law remain unable "[t]o promote the progress of science and useful arts". Free the bear! ;)

<comment><USER3> Worth noting that almost all the rights for Winnie-the-Pooh rest with Stephen Slesinger, Inc and Walt Disney, and not with the Milne family.

In '98, Clare, Christopher's daughter, attempted to prevent Slesinger from expanding their copyrights, but the US courts didn't agree.

</comment></comment><comment><USER3> Always interesting to see people's take on my family's history, but I can't agree that the original Winnie-the-pooh books were rosy and cheerful.

The philosophy of A.A. Milne bleeds through into them, in ways that few children of today could be expected to grasp, and life and death aren't dealt with as something as taboo as you find today. Poverty, hunger and war all appear in their own small ways, if just by their impacts.

Being said, I do think most people of today think of Disney's rendition when they think of the bear and his boy, which is far more light-hearted and rosy. It may be a shock to see the dysfunction between father and son, who birthed such a famous story.

<comment><USER4> I enjoy reading Winnie-the-pooh to my daughter. Every character is dysfuntional in their own way, but at the end of the day they all stick together. I find it a great tool to plant the seeds of diversity: the world is not made up of "all the people who share my interests and live like me", it's colorful, messy, sad, spontaneous, full of surprises and generally a much better place when sticking together.

</comment></comment><comment><USER5> The biography of the kid obviously shows he disliked the way he was exploited but this review sounds like it was something completely horrible.

<comment><USER6> I mean, if he didn't speak to his mother for the last 15 years of his life it was probably pretty horrible.

<comment><USER7> I've spoken with my father just once in the last 15 years or so, and that 9 years ago. It happens, not all people are good parents, not all relationships can or should be healed. I doubt I'll speak to him again before he dies, that could be tomorrow, it could be in 20+ years. I've made my peace.

Does that mean my childhood was "pretty horrible"? Parts of it weere, and I'm not sure that there is a calculus of human experience that would allow me to calculate a net horribleness quotient. But even with my father I remember happy and sweet moments.

<comment><USER8> As someone who has lost people that I wish I could have done more with, I think you should still talk to him now and then, if only because you and him and your relationship with each other is never going to occur again in the infinity of this Universe..

<comment><USER9> As someone who lost some people who I should have done more with (or see more) AND people I am so happy to see dead that I almost celebrate their funeral every year by a big party - I think one should not offer such philosophical ideas to a random stranger without knowing the whole story.

<comment><USER8> I still think it's a terrible thing to live with resentment for anyone, especially long after they are gone, and I'm free to voice my thoughts, but of course I'm not telling anyone what they should do.

I've had people I despised too, where the best course of action for all involved was to completely cut contact, but letting them influence my feelings after they're out of my life just means allowing them victory over me.</comment></comment></comment></comment></comment></comment>


Productivity Is Soaring at Top Firms and Sluggish Everywhere Else - <AUTHOR> https://hbr.org/2015/08/productivity-is-soaring-at-top-firms-and-sluggish-everywhere-else <comment><USER2> The author implies that the gap is due to lack of diffusion and that this is a problem that should be addressed and corrected. I think that the real issue is much simpler:

Technology has made manufacturing, services, mass communication, and markets much more efficient. When they are efficient, competition creates fewer winners and the winners win big.

If you want to understand inequality understand that. This is fundamental economics. We can dream of a world where there are 1500 different brands of phone each having close to equal market share but when one gains advantage, the advantages multiply and you end up with one or two major phone manufacturers. Propping up the other ones is nice, and may do some local good, but it's Sisyphean - it won't change the dynamics.

<comment><USER3> The end goal of capitalism is one corporation selling you air.

I'm pro-capitalist (not least because it works) but also pro-market regulation, capitalism should be harnessed for the good of everyone not just a few.

<comment><USER4> I think you might be interested in this article on the end of capitalism: [http://www.theguardian.com/books/2015/jul/17/postcapitalism-...](http://www.theguardian.com/books/2015/jul/17/postcapitalism- end-of-capitalism-begun)

"Postcapitalism is possible because of three major changes information technology has brought about in the past 25 years. First, it has reduced the need for work, blurred the edges between work and free time and loosened the relationship between work and wages. The coming wave of automation, currently stalled because our social infrastructure cannot bear the consequences, will hugely diminish the amount of work needed – not just to subsist but to provide a decent life for all.

Second, information is corroding the market's ability to form prices correctly. That is because markets are based on scarcity while information is abundant. The system's defence mechanism is to form monopolies – the giant tech companies – on a scale not seen in the past 200 years, yet they cannot last. By building business models and share valuations based on the capture and privatisation of all socially produced information, such firms are constructing a fragile corporate edifice at odds with the most basic need of humanity, which is to use ideas freely.

Third, we're seeing the spontaneous rise of collaborative production: goods, services and organisations are appearing that no longer respond to the dictates of the market and the managerial hierarchy. The biggest information product in the world – Wikipedia – is made by volunteers for free, abolishing the encyclopedia business and depriving the advertising industry of an estimated $3bn a year in revenue."

<comment><USER5> I'm not sure whether I agree or not but thank you for sharing that article. Very interesting.

<comment><USER4> I appreciate your polite reply.

</comment></comment></comment></comment></comment><comment><USER6> Can many people really say that IT is being used effectively in most organisations ?

Almost every one I have worked in use haphazard methods, unnecessary manual input and duplication of input, outdated forecasting, bad choice of software tools (e.g. spreadsheet heavy) ... the list goes on of small day to day things that add up.

There was a recent story about 90% of people not even knowing about Ctrl-F to search documents.

Think about all the times you've had images sent in Word documents or crappy artwork you've had to re-create by hand because the only copy of the logo was a 400px jpg.

Multiply the time wasted on those things by a few hundred million.

Now tell me there's no productivity to find, and we haven't even got on to your actual business processes.

</comment><comment><USER7> How much of this is productivity and how much is merely increased revenue? If you assume that costs are not linear with large economies of scale (which is not such a wild assumption), then some of this "productivity" increase can be attributed to rent taking; especially so when taking into account the power law distribution at the thick end of markets and reduction of competitiveness at the big end.

<comment><USER8> They use a measure called Multifactor Productivity. From the linked report :

 _Multi-factor productivity (MFP) growth measures the growth of GDP over the combined contributions of total hours, workforce skills, machinery and structures and ICT capital._

From wikipedia [0] :

 _Multifactor productivity measures reflect output per unit of some combined set of inputs. A change in multifactor productivity reflects the change in output that cannot be accounted for by the change in combined inputs. As a result, multifactor productivity measures reflect the joint effects of many factors including new technologies, economies of scale, managerial skill, and changes in the organization of production._

[0] [https://en.wikipedia.org/wiki/Multifactor_productivity](https://en.wikipedia.org/wiki/Multifactor_productivity)

</comment></comment><comment><USER9> The most productive teams were mostly bought and consolidated by rich firms, that is until a new generation of disruptive small startups that take the chance of not wanting to be bought out by the big firms, will take things to a different level again. This pattern has always been there and always will be, business as usual.

</comment><comment><USER10> It's strange to read this story immediately after this other one [https://news.ycombinator.com/item?id=10367253](https://news.ycombinator.com/item?id=10367253)

I'd be afraid to see the correlation between who uses those kinds of methods and who is at the frontier of productivity. I hope that other article isn't the future :(

</comment><comment><USER11> There's something of a snowball effect here, especially in the manufacturing sector (and coincidentally, the most productive mfg companies have been diversifying into services (logistics, warranty mgmt, co-engineering, etc) because it's so much more profitable -- often in the 15-20% gross margin rather than 4-6%), but additionally, just having the working capital and financial leverage that large corporations have helps ensure their continued growth and success. The big have gotten so big that even the small guys wouldn't succeed without somehow also giving money to the big guys. For example, if I'm in Shenzhen and I start a widget factory, it would be hard for me to avoid the influence of Foxconn, for better or for worse. ... Just like further up the food chain, Apple's iPod/iPhone/iPad successes padded the coffers of Foxconn, Jabil, Samsung, TSMC, and others. The "no one was ever fired for choosing IBM" maxim holds true manufacturing, too. :-/

</comment><comment><USER12> Article doesn't mention _what_ firms tho'.

<comment><USER13> It also doesn't appear that the firms are constant year over year. It just takes the top 5% and labels those the frontier firms.

So with just the info in the article i don't think it supports any particular conclusion without more information.</comment></comment>


Function Purity and Immutability in D - <AUTHOR> http://www.drdobbs.com/architecture-and-design/function-purity-and-immutable-data-struc/240169087 <comment><USER2> >A pure function does not read or write any mutable data that is not accessible via the function's arguments [but it can read/write mutable data pointed to by its arguments]

That's not a particularly strong or interesting definition of purity. It just means you can't have mutable globals. That is not really powerful or helpful in any way that I can see.

I feel like this is a bit of a disingenuous (or perhaps just misunderstanding) attempt to latch onto a buzzword from the functional programming realm that means something almost completely different. Purity has a much stronger definition than "don't mutate global variables". See [http://en.wikipedia.org/wiki/Pure_function](http://en.wikipedia.org/wiki/Pure_function)

<comment><USER3> A function simply annotated with pure is sometimes called "weakly pure". If its arguments are declared immutable, it is "strongly pure" which essentially matches your definition.

All languages I know (e.g. Haskell) make concessions to pragmatism. For example, even pure function can somehow create debug output. Every memory allocation does mutate global state.

The weakly pure class of functions is useful. It limits the potential side- effects to stuff reachable from mutable arguments. For example, a image filter function can be weakly pure while it mutates the image provided as an argument. It removes the need allocate a return image or wrap computations in monads and thunks.

To get really strong guarantees in D, you declare your functions pure, nothrow, and @safe. The nothrow means no exceptions are thrown and @safe means all the low-level tricks (casts,assembly,etc) to break type safety are disabled.

<comment><USER2> >All languages I know (e.g. Haskell) make concessions to pragmatism. For example, even pure function can somehow create debug output.

From the Debug.Trace docs: "should _not_ be used in production code."

>Every memory allocation does mutate global state.

Yes, Haskell is approximately pure just like computers are approximately Turing machines. Computers are technically FSMs, but they're practically so close to Turing machines that we usually don't care. Haskell is so close to pure that we don't care. It's also guaranteed to be semantically pure, until you start to run into those edge cases where computers don't act like Turing machines (i.e. when you run out of RAM).

>It removes the need allocate a return image or wrap computations in monads and thunks.

No one is arguing that impurity/mutability is (frequently) useful. I'm just arguing that it's disingenuous to call what you've described "pure", or that this extra "purity" is very useful.

</comment></comment></comment><comment><USER4> Walter Bright is indeed a really bright mind. Having worked with D recently, I really enjoyed the richness and empowerment the D language offers.

I believe the recent rising interest in functional languages is in part due to the elegant blend of expressiveness and performance. Performance is always a delicate topic nevertheless there are some aspects of functional languages which tend to make them more performant.

</comment><comment><USER5> There is also a good article about purity in D by David Nadlinger, who is one of the core developers of LDC (LLVM D Compiler):

\- [http://klickverbot.at/blog/2012/05/purity- in-d/](http://klickverbot.at/blog/2012/05/purity-in-d/)

<comment><USER6> (For whatever reason HN is nonstandard and includes the trailing >; working link: [http://klickverbot.at/blog/2012/05/purity- in-d/](http://klickverbot.at/blog/2012/05/purity-in-d/) )

</comment></comment><comment><USER7> > This is why a cast to immutable is not allowed in D code marked as @safe.

It's an interesting design decision that D code is (presumably) @unsafe by default.

<comment><USER8> Yes, although one can explicitly mark code as @system. (I've never liked the "unsafe" attribute, as it implies the code is actually broken.)

Safety is something that becomes more desirable the larger and more complex a program is. I wanted D to also be convenient to use for quick, simple programs without burdening the user with having to add annotations.

</comment></comment><comment><USER9> It is unfortunate that the length of the `immutable` seems to ergonomically discourage its use. I know it's really hard to go back on language design decisions, but have there been any thoughts about providing a shorter alternative?

<comment><USER8> It used to be called "invariant". We found ourselves constantly explaining to people that "invariant" types were immutable.

Bowing to the obvious, we changed it to "immutable". This has been highly successful in that people immediately understand it.

Nobody ever found a shorter, equally clear term.

<comment><USER9> Yeah - naming things is hard. I agree that `immutable` is clearer than `invariant`. I would suggest `imm`, but that is damn ugly and more opaque. :(

</comment></comment></comment><comment><USER10> Why not get rid of mutable data in the first place? That would make this language (and my others) much cleaner.</comment>


Rebuilding a broken Gameboy with a Raspberry Pi - <AUTHOR> https://superpiboy.wordpress.com

<comment><USER3> This is a really nice example of a project post/build log.

Related, I think it would be a lot of fun to interface the Pi with the original (not very good) LCD. Then you could make some kind of 'alternate history' nextgen gameboy where the processor was massively upgraded but the screen was not - enabling low res 3D, temporal dithering to expand beyond the 2bit palette, etc.

(I guess you could also simulate this on a regular computer or even the mod discussed here, but that's somehow slightly less charming)

<comment><USER4> I don't know if the latency on the original LCD would allow for temporal dithering, but it would be pretty cool.

</comment></comment><comment><USER5> If this was a commercial product I'd be interested in buying one. The formfactor (yes, yes, no internal batteries) is impressive for what essentially amounts to a full PC.

Although myself, much like the OP, would almost certainly run RetroPi off of it.

There are a few emulation stations kicking around (you can find them on Amazon) but nothing near this compact or with this good of controls.

<comment><USER6> >There are a few emulation stations kicking around (you can find them on Amazon) but nothing near this compact or with this good of controls.

I've found a DS flash cart and a DSiXL to do this job well enough for what the system is capable of emulating (up to GBA, Genesis, SNES). Not sure what the state of 3DS flash carts is. For ~N64/PS1 a modded PSP is a great choice from what I've heard.

<comment><USER7> Classic modded PSPs definitely work well. They're also pretty good for Gameboys of all generations. DS wouldn't work though, at least as far as I know.

<comment><USER8> If I am not mistaken, what jimmaswell is describing is the same mod that made my Gameboy Advance my most favorite of systems... Just google 'ds homebrew' and you will discover a wealth of information... For gbas and ds(es???), you could/can purchase a flash cart. There is a surprising amount of homebrew and software hacks available out there that this flashable cart brings to the table - not the least of which is the ability to load up emulators for everything 'equal to or less than' the gba/ds(in general regards to cpu/ram requirements) to play 'backups' of the games (which were also flashed onto the cart along side of the emulators). My former GBA (paired with 2 flash carts) was likely the third most used gaming system of my life to date(2600, NES, GBA). All the games you could want (or fit on 512MB (A LOT when the games are a few hundred k (nes) to a few mb (gba)) - 2600, NES, GBA, GEN and SNES - <USER2> few/no issues.

All of this said, the PSP (1001?) was/is an awesome emulator... Capable of playing everything up to PSP backups, you could play all of the above, with PS1, NeoGeo/Capcom, and PSP support... Definitely a very nice gaming system with a lot of power and capability... In the end, it was the GBAs battery life, wonderfully thought out screen and compact size that always made me come back to the gba. The PSP got a lot of play, but being able to stomp turtles and collect rubies while sitting on a beach without shade just made the gba the general purpose go-to for this casual gamer (as the PSP could serve as little more than a mirror and hand warmer in this setting).

While generally frowned on by gaming manufacturers for obvious and founded piracy concerns, there are some awesome hybrid systems that can be made out of existing on-market systems. While I am sure that there are many whose ultimate goal is piracy, there are a lot of people who enjoy modded systems for their flexibility and enhanced capabilities.

<comment><USER7> Yeah my PSP 1001 was a great all-around device, especially when I used homebrew apps and games - that's what got me interested in programming.

But as far as my original comment, this is actually what I meant: [https://news.ycombinator.com/item?id=8082102](https://news.ycombinator.com/item?id=8082102)

</comment></comment></comment></comment></comment><comment><USER9> Fantastic work. I think the pride one would feel in making this work is well worth the $90 or so required for parts!

</comment><comment><USER10> Put this up on Kickstarter! :)

</comment><comment><USER6> shame how the midi music doesn't work in so many doom ports</comment>


The Double Whammy of Bankruptcies for Entrepreneurs - <AUTHOR> http://online.wsj.com/article/SB10001424052970204731804574386844132423118.html?mod=WSJ_hps_sections_smallbusiness

<comment><USER2> There's a third one a little while down the road, having been involved in a bankruptcy you will find - especially states-side - that your credit rating is now in the basement which will make it almost impossible to do anything other than to get a job. (and even some employers use credit scores to decide who to hire).

<comment><USER3> _... which will make it almost impossible to do anything other than to get a job_

I'm not sure what you mean here. Are you saying that after declaring bankruptcy it's difficult to convince someone to loan you money to start a business?

Getting a job is the normal state of affairs for most adults, so I don't see what's particularly exceptional about it.

<comment><USER2> In some places it can be difficult to even get banking.

Borrowing money is not the issue.

Employers are not above doing credit checks and banks might simply refuse to deal with you.

That can make the road to recovery a very difficult one.

Sure, most of the people out there have jobs, but since there is no better way to learn than to fail if you're going to try again some day it might help that you're able to get a half decent job so you can save some $.

Assuming the bankruptcy is a real one and not one of those where banks and credit card companies get to garnish your wages for the rest of your life.

<comment><USER3> _banks might simply refuse to deal with you._

How odd -- I've never heard of that happening in Canada. Sure, banks will run credit checks before allowing an overdraft; but the only problems I've ever heard about with people being entirely unable to get bank accounts have been homeless people without any ID.

<comment><USER2> Coincidentally my experience is also in Canada (not my own experience, but a close friend there, an older person).

This was about 6 years ago. I was quite shocked to learn that you could be refused banking at all, for any other reason than for instance being a criminal or something like that.

</comment></comment></comment></comment></comment><comment><USER3> I don't get it. People are signing personal guarantees on business loans, and then say that they didn't realize that their personal assets are at risk? What did they think "personal guarantee" meant -- or did they just sign blindly without even trying to understand what they were signing?

<comment><USER4> I agree with you, but I've seen it repeatedly. People firstly don't understand the real differences between personal assets and business assets, thinking that because they own the business they can move things around freely.

Then people don't really, really read the fine print _and understand the details._

Sometimes the fine print, or even not so fine print, is designed carefully to appear clear, and yet still not get the message across. In the UK people have started to tune out the "Your home is at risk if you do not keep up payments on loans secured against it." becuase they are hearing it so often.

It's easy to gloss over things you don't want to hear, know or acknowlege, and sometimes I wonder if entrepreneurs aren't especially prone to that.

If you listened to all the naysayers you'd never get started - there is a tendency to ignore the negative, focus on the positive, and push on regardless.</comment></comment>


Threaded vs Evented Servers - <AUTHOR> http://mmcgrana.github.com/2010/07/threaded-vs-evented-servers.html <comment><USER3> I would find it much easier to follow the article if the author used traditional mathematical notation instead of Clojure. Which do you prefer?

        (* t (/ 1000 w))

or (perhaps typeset properly)

        t * 1000 / w

<comment><USER4> Clojure notation for me. In my view, it's a lot more appropriate for today's programmer world than the traditional math notation, because computer parsing is an issue. So I prefer the moldable Lisp version.

Many programmers dislike math notation; they have bad experiences of school, and gloss over anything which reminds them of dull homework and tests. On the other hand, programming notation symbolizes a feeling of freedom.

It helps that I'm more used to Clojure's notation than traditional math notation. Also it's easily executable for me. No need to execute precise arithmetic mentally; the computer can do it.

</comment></comment><comment><USER5> "Finally, we'll assume single-core servers"... isn't that rather like working out mathematically that the best gait for horses is hopping, provided you assume a one legged horse?

<comment><USER6> No, while this is a wonderful analogy, I don't think this is actually a problem. It's more like assuming horses weigh 1000 kg --- wrong for all but the biggest draft horses, but a nice round number to work with.

For the level of analysis in the article, there's really no difference between a 4 core machine and a processor with a 4x clock speed. His point is that the threaded model makes the most sense when each request is CPU intensive, and the event model works best when the work is light but the delays are long. All that would change for a multi-core processor is the definition of when the works starts to be CPU 'intensive'.

<comment><USER7> Moore's law is no longer in effect, it is cheaper to add more cores these days then add more speed.

Edit: My point is that, since we live in a real tangible world, where CPU power is being expanded by parallelism rather then increasing single pipeline throughput, we have to deal with that reality. To dismiss it to prove your point, seems a tad bit naive.

<comment><USER3> Moore's law is about transistor count, not about speed. The increasing number of cores on a single die is predicted by Moore's law.

</comment></comment></comment></comment><comment><USER8> Event driven servers should not block on disk i/o, dns queries, or db calls [by using/writing async libs]. At least the well written ones. Else the Server Is likely to be dos-ed. The author is wrong in using a db call as an example. Secondly, the author totally ignored the time it takes to launch a thread vs not launching one at all in an event driven model and that affects the # of new connections/sec. Finally, switching between threads is not a very cheap operation since it causes a context switch, which directly affect the response time of the server.

</comment><comment><USER9> Paul Tyma discusses some other myths regarding evented vs threaded servers: <http://www.mailinator.com/tymaPaulMultithreaded.pdf>

<comment><USER10> That looks interesting enough to post separately too: <http://news.ycombinator.com/item?id=1546711>

</comment></comment><comment><USER11> This article seems to focus on fairly heavy weight threads, but what about green threads? It seems like green threads with proper nonblocking libraries could behave performance-wise just like evented servers.

<comment><USER3> Check out GHC's new IO manager. GHC, by default, uses non-blocking IO exclusively and calls "poll" or some equivalent syscall to figure out which green thread to wake up.

</comment></comment><comment><USER12> The examples given seem to indicate that evented servers are as fast or faster than threaded servers. If that's the case, why doesn't everyone just use evented servers?

<comment><USER13> First, the analysis relies on every step from request to response being evented, which in turn relies on the existence of event-based libraries for everything you want to do.

Also, most languages don't have a good way of dealing with callbacks. They tend to make the code verbose and difficult to reason about. This is especially true for non-trivial applications, where there are more than two or three callbacks chained together.

However, you can counter-argue that the additional complexity isn't endemic to the programming model, only certain languages. Also, in languages which support multiple threads (read: not Javascript), a hybrid approach that uses events where possible, and threads where necessary, may retain many of the benefits of the event-based approach.

<comment><USER14> _First, the analysis relies on every step from request to response being evented, which in turn relies on the existence of event-based libraries for everything you want to do._

This is one of the main reasons I like node.js, EVERYTHING is evented, if it isn't it's probably a bug, or at least carefully explained why it can't be (and usually there's an async alternative).

<comment><USER15> IIRC it does not support things like the mysql lib because it is normally not event driven. So yes everything in node.js is event driven, but not everything you may need is included. Last I checked work was being done on it. The solution was to create a thread pool and treat communicating with it as an event driven protocol.

</comment></comment></comment></comment><comment><USER16> Not specific to this article:

I find it unrealistic that threaded vs evented (or blocking vs non-blocking I/O) comparisons always use a slow database server as the prototypical thing to wait for.

I get that this is not the point but to a newcomer it must seem like "oh.. database servers are super slow, I must first and foremost worry about optimizing access to them".

If your queries regularly take more then 10ms to complete, something is wrong with the database (do caching, put database closer to querying server - <USER2> even on the same machine).

<comment><USER17> Whatever. >10ms is perfectly reasonable db access. Of course if your data is small enough to fit in memory you will have much faster access time, but if it's and you don't have a SSD, every disk seek will be at least 10ms and you may need several to do all the queries needed to render a page.

</comment></comment><comment><USER18> <http://www.kegel.com/c10k.html></comment>


Stanford CS9: Problem-Solving for the CS Technical Interview - <AUTHOR> https://web.stanford.edu/class/cs9/ <comment><USER3> This is what I was afraid of. I always thought interviews were something where you present your abilities, experience and knowledge. It should not be something you "prepare" for because then you're not showing off your skills, instead you're just regurgitating what you are trained to do.

I do somewhat blame the whiteboard culture, but I guess that's the one that has given the best results so far. I've no doubt that it will change soon.

<comment><USER4> FWIW, preparing for interviews is standard practice irrespective of the industry.

<comment><USER5> > FWIW, preparing for interviews is standard practice irrespective of the > industry.

This is simply wrong. I suppose if you've spent your whole life as a developer, it may _seem_ like it would be done likewise other industries, but it's not the case.

Typically, how you _might_ "prepare" for interviews in other industries is...learning about your potential employer. And maybe reviewing your accomplishments. That's it. And most people don't even do those things. None of this hours and hours reviewing textbooks from your college classes, since you've been in the same job for 5 or 7 years and have forgotten algorithms that you never use in your job. It's simply perverse.

Software development is the only industry I'm aware in which technical preparation for job interviews is not only advisable, but increasingly necessary for interviews at _all_ levels of the career hierarchy.

Even in other engineering disciplines, this kind of bullshit is unheard of for any interviews except _maybe_ your first interview out of college. And in industries like law, medicine, etc., if a potential employer asked you to perform some random task from a highly technical and complex subject from med school or law school, it would be very unusual.

<comment><USER6> _Typically, how you might "prepare" for interviews in other industries is...learning about your potential employer._

It has always shocked me that people don't instinctively think that doing this is an absolute necessity for every single job interview. I have very often been met with a totally blank look when I've asked candidates what they think it is the company I'm interviewing them for does, even when phrased as nicely as, "Tell me a little about what we do and why you'd like to work for us" \- surely not a hard question, you would think!

<comment><USER7> > surely not a hard question, you would think!

Not so much hard, more that it sounds like a complete waste of time and could be signaling to people that this is one more non-technical/HR interview they have to get through before getting to talk to people they'd be working with and who can fill them in on details specific to their prospective job or team. Whatever you're trying to figure out with that question, there's gotta be a better way to probe that, that doesn't make it look like you're wasting the available time.

<comment><USER8> I wouldn't want some one on my team who had know idea of what the company did.

I normally for public companies read the annual report and accounts.

<comment><USER9> This only works depending on the scale of the company. If the company is huge and involved in many things there is less engagement from each employee with the overall mission of the company. This is even more pronounced when employees can't even see the fruit of their work in society. Like when the developer workforce of a company is spread across many countries but the clients are focused only in one company. I think expecting candidates to have a basic idea what the company does is fine. But unless the company is a small startup, expecting them to be engaged with the mission is unreasonable.

There are many reasons for candidates to be excited to work for a company:

\- friends

\- great team fit

\- technological challenges or preferences

\- work-life balance

\- location

These and others contribute to an employee doing his job with passion. (note: money is not one of them. there is a study that showed that above a certain level for a person, no amount of extra remuneration will result in an increase in productivity)

And I imagine this is the case even for pinnacles of vision like SpaceX. I imagine employees at SpeceX do not care about the future of SpaceX , they care about putting man on mars, making space available cheaply, pushing the boundaries of human exploration and of technological capabilities, Musks vision and enthusiasm. But not SpaceX as a company.

People should really stop expecting companies to have emotions. Companies do not care about people so people should not care about companies either. People care about other people and society at large.

<comment><USER8> I was talking about for the purposes of the job interview, I though that was obvious. Also you want to look a bit at the companies financials to get a feel for any equity based comp and also if the company looks like its in trouble - eg Carillion in the UK

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I think this is terrible. I feel there are many good engineers that can't possibly compete for decent jobs in tech companies because they haven't spent 6-12 months reading cracking the code interview, doing this Stanford course, practicing mock interviews in crowdsourced websites, getting their leetcode rank up, attending bootcamps where they pad their githubs and practicing any single interview question they can scrub off glassdoor. All things that are marginally useful in the job at hand. And this is getting worse all the time.

<comment><USER11> It's really not that hard. I suppose there might be a few companies with insane expectations, but most interviews don't require that level of preparation.

<comment><USER10> I don't know. If all the candidates are _that_ well prepared, then if you are not you are at a disadvantage, even if it didn't used to require it. And at companies where people want to work for, like Google/amazon/FB/Netflix, etc. and startups many people come prepared.

<comment><USER12> No matter what system you use to interview people, if the position is desirable enough, and the number of positions is smaller than the applicant pool, isn't gaming the system the expected outcome?

If people at Google were interviewed by juggling raquetballs, there would be books, courses, etc. on how to juggle better. People are willing to pay for this prep because they want to work at Google. Eventually most everyone interviewing at Google would be very well prepared to juggle.

<comment><USER10> Sure but if that were the case wouldn't you think it's silly that you need to train months to be able to juggle to land a SWE position? wouldn't it be stupid? the current interview culture in those companies is not as silly as juggling but is also not a fair representation of candidates, with too much weight being in algorithmic puzzles and behavioral checkboxes you can train for.

Obviously if the process was a 100% fair assessment of knowledge and potential and people do better than you then good for them.

<comment><USER12> Yes, it is silly that you have to train for an interview for months to land a SWE position at a top company. However, until someone comes up with a less gameable system or a magic wand that stack ranks applicants, then I don't see a viable alternative :\

As someone who gives a lot of interviews, I'd love a better way to assess a candidates ability that is less gameable, but we haven't found one yet.

<comment><USER13> > until someone comes up with a less gameable system or a magic wand that > stack ranks applicants, then I don't see a viable alternative

This is exactly the concept of an IQ test, right down to the stack ranking.

They're pretty well understood by now, and they take less than a day, which compares pretty favorably to "months".

<comment><USER14> Isn't it illegal to hire people based on IQ in the US?

<comment><USER13> It is presumptively discriminatory unless you do a formal study documenting that high-IQ employees perform better than low-IQ employees. PG&E and the NFL use IQ tests in hiring.

<comment><USER13> Low-effort correction: I may or may not have been thinking of GE when I said PG&E.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Could there be a clearer sign that the quality of higher education in our time is in steep decline?

If, one hundred years ago, Oxbridge had floated the idea of sanctioning a student to embark on a program of study designed to anticipate questions that might arise in a job interview, it would have been as preposterous as suggesting that the Queen should take her meals in a pub.

And yet today, we have one of the preeminent universities not just of the United States but of the world offering a course that appears to amount to Kaplan for a tech job.

<comment><USER12> I doubt this is a sign of a decline in quality of higher ed, and more a sign of the popularity of CS as a major and software engineering as a career.

These kinds of courses and prep has existed in similarly popular fields for many yeas: law, medicine, finance, etc.

<comment><USER15> 1) Those are professional schools 2) Even so, no respectable law school offers a bar prep class. Nor does any med school offer "How to ace the USMLE".

<comment><USER16> But do most law school grads take bar prep classes?

<comment><USER17> Yes, but good law schools aren't squandering the value of their most cherished currency on them - the reputation of their course credits in the world of academia.

</comment></comment></comment></comment></comment><comment><USER18> This makes me very, very sad.

I will never subject one of my potential hires to this nonsense. These concepts are valuable and academically interesting, for sure, but for the practical kind of engineering that's done at most companies it's simply not needed. Either that or it's already implemented in a library.

What a waste of time.

<comment><USER12> It's very tempting to say this. However, trying to find an alternative that is not equally or more gameable is very challenging.

Take home assignments are easy to cheat on and take a lot of time.

Asking questions about someone's experience is a great way to find someone who is a great conversationalist that can't code.

Asking someone to program at a computer in a limited amount of time falls victim to the same issues that the competitive programming, whiteboard interviews currently do.

<comment><USER19> Take home assignments are easy to cheat on? What does that mean (in the context of a take-home problem as an interview method)? Are candidates expected to derive solutions to coding or engineering problems themselves from first principles as their day to day? The answer is "no" almost without exception, even in serious research or hard core low level systems programming jobs.

<comment><USER20> "Are candidates expected to derive solutions to coding or engineering problems themselves from first principles as their day to day?"

Does performance on these tasks correlate with performance on the job? Is it easy to measure this performance in interviews reliably? Then it's going to be used by companies.

<comment><USER19> The answer to both your questions is "no", and companies use them _in spite of that._

<comment><USER20> Any studies that support the answer "no" for both questions?

Technical interview performance has ~0 correlation with performance on the job? I find it hard to believe. Is the mean performance on the job of a software engineer that fails to pass Google interviews as good as one that does? Why do most companies want to hire Google software engineers if that is the case?

As for my second question, it should have been "is it easi-er to measure this performance reliably than other skills that may be relevant"? It sounds like this would be hard to answer. But this kind of interview seems to be best suited for repeatable evaluation (although, of course, you do have the problem that people will prepare and bias the results, but I don't see how you can avoid that if you want a repeatable way to measure performance).

Finally, "and companies use them in spite of that". Any guesses why?

<comment><USER19> > Any studies that support the answer "no" for both questions?

Google had a study that has been linked to death around here which showed the scores hires received on their interviews didn't correlate to job performance ratings. There are of course biases and flaws in that study, but it underscores another separate point: studies should show they do correlate, not the other way around (prove a negative).

> Finally, "and companies use them in spite of that". Any guesses why?

Bandwagon effect, cargo cults, ego boosting/confirmation bias from applying a hazing ritual, laziness all come to mind.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> The on-the-spot technical interview is the biggest waste of time in the history of humanity. _Everyone_ underperforms in technical interviews. I've conducted a number of them and I've never learned a single thing other than the fact that people make surprising mistakes when under pressure in contrived situations. Here's something that I think works much better: come up with a novel challenge that requires a couple hours of honest effort and have candidates present their solution to you when they come in.

<comment><USER12> How do you prevent cheating? Someone can very easily have a friend complete the challenge and walk them through it in a lot of detail. They could prep well enough that you hire someone who is massively under-qualified.

Then if your company is large enough, your novel challenge gets leaked and everyone knows it ahead of time. Solutions start being sold or distributed. Then your interview is meaningless.

I'm all for a viable alternative to the whiteboard interview, but I haven't encountered one yet.

<comment><USER21> If your challenge is novel, as I said, then it should be difficult for them to cheat. All the same, people are welcome to cheat. It should become clear that they've done so when you're interviewing them if you ask the right questions when they're explaining what they did. And if they somehow make it through anyway, you should be evaluating the quality of their work until they get established in your company. If they're underperforming over the first month, you should be showing them the door.

<comment><USER12> Any challenge that doesn't change across applicants at a company that has a large enough applicant pool, will eventually be solved and prepared for so well, that almost any question you can ask will be prepped for.

Beyond that, if you do use a single question, you're now playing a game of whack-a-mole: I used to ask this question about the challenge, now I can't because it is leaked and people prepped for it. How do you scale that across an engineering organization? Do you have weekly meeting with every interviewer informing them of the questions about the challenge that are now blacklisted? It's going to be infeasible for any reasonable sized organization.

The challenge with this idea as well is that the risk of false positives is much higher than the whiteboard interview. The current interview process is designed around minimizing false negatives.

False positives are really costly to an engineering organization. It's not good for morale when engineers are being hired and fired in the same month on a regular basis. It's takes time to onboard, and slows the team down. It's also not good for the company reputation - would you apply to a company who had a reputation of firing a good chunk of its new software engineers within the first month?

<comment><USER22> And any challenge that is no longer novel no longer requires "top performing engineers" to work on.

A big part of the interview problem is that everyone wants to think that they are solving really important problems and are changing the world, etc.

Companies need to be honest about what they are doing and who they need to do it. Sometimes you have a hard problem and need a specialist or a brilliant problem solver to conquer it. Most companies need middle-of-the-road people who are reliable and consistent but not necessarily geniuses to maintain the things that have already been built. The idea that everyone needs to be a rockstar or a 10x-er needs to die. This overly inflated notion of what even some of the top tech companies are doing is the reason for all of this craziness.

Extremely few genuinely hard problems are solved by profitable companies. Some exceptions happen. But they happen(ed) in the R&D sections of those companies. Bell Labs, Google, Apple, Intel, Facebook-ish. But those are not the money- making day-to-day jobs that power the profit engines of those companies.

Those think tanks do excellent work, but they are not significantly different from research PhD programs. They just pay better. It's always been the .0001% of top people who solve problems theoretically, and then lesser people find ways to implement those solutions.

For any genuinely novel or hard problem there are ways to suss out how much a person has been coached, and how well the problem is truly understood. You don't have to change from week to week. It's not that hard.

In my own field, I can give a take-home challenge: here's a relational dataset. I want to work with this as a data warehouse. Give a rough outline of what changes need to take place, and how you would design the warehouse. Ask questions as needed as you go through the exercise, and be prepared to defend your design choices at the tech interview.

In less architecty roles, perhaps I'll ask a person to do some pretty basic data transformation as a kind of a fizzbuzz. But the tech interview is just to ask a series of questions that are pretty open-ended but have a list of points I think are relevant and assign points based on how many checkboxes they hit. And yes, that list can and will be leaked at a sufficiently large and desirable company, but it doesn't matter. Because the checkboxes are there to remind _you_ from interview to interview what you were looking for. They are not a replacement for your assessment of the person. And you, personally, can change your mind as you go.

The point of an interview shouldn't be to find out if a candidate knows exactly what you know. If that's the design of your process and the only thing you care about, then you are going to have problems. The point of an interview is to let the candidate tell you what they know and for you to have some baseline for comparing that to what they need to know for the role.

In some cases, all the candidate needs is basic programming skills and the ability to memorize stuff. And in that case, you don't need to worry about if the candidate cheated, you need to worry about how honest your team is about what it's doing and what you need as a manager or coworker.

It's like security through obscurity. It never works. You need a better process.

</comment></comment></comment></comment></comment><comment><USER23> How is this conceptually different than a course that focuses on standardized tests like the SAT? Having worked for only almost 2 years after college graduation, I can still see that there are many more technical and non- technical skills that affect one's and his/her colleagues' performance on the job. Being nice and helpful is one. Constantly learning from mistakes and rapidly iterating while adding value to the team/company is another. More examples: Picking up technical books, writing toy projects to learn new languages/frameworks/libraries and being able to come up with good engineering decisions. The list goes on.

Not to be too salty about this, but I remember friends from college who are terrible teammates (no significant contributions to group projects, barely understanding the project material, but knowingly do so cause others will finish it for them etc.) but go on to get job offers from the Big Four. Having these technical whiteboard interviews will not filter for such soft skills that are needed to succeed in the workplace.

<comment><USER24> People measure what's easy to measure, not what's valuable.

</comment></comment><comment><USER25> To everyone bemoaning the introduction of a class such as this, it's a 1 credit class, which at Stanford roughly translates to about 3hrs/week of work given that you're expected to take 15 credits per quarter. It is comparable to a class on financial responsibility or golf. Its focus isn't so much on how to crack a technical interview than it is on how to prepare for a job interview in general.

Mock interviews, resume writing and critiques, life at startups, how to answer team/behavioral questions, and panels of employers and employees are all covered with sample whiteboard/coding problems only being given one week of attention. This is simply preparation for how to professionally navigate the job landscape.

</comment><comment><USER26> I know this has been said a billion times but the CS interview is bullshit. It's like asking a pianist to describe how they would play a composition on the white board.

I always thought that this is a good question to ask [https://github.com/alex/what-happens-when](https://github.com/alex/what- happens-when) but then again probably not for all roles. It's good because even if the interviewee has seen the question, you can really gauge how much they know.

<comment><USER27> Still very gameable, and only test domain knowledge, rather than problem- solving skills.

</comment></comment><comment><USER28> I kinda like the idea of having an intense data structures and algorithms class for hands-on problem solving.

If a candidate has shown an ability to solve several hundred medium+ DS & Algo questions on the spot, that gives him an edge up in day to day to programming. Not everybody can do that.

You can supplement that with other areas (concurrency; distributed systems; execution latency, memory management etc; quirks of and design ideas behind your favorite programming language).

I think this class can be a good prep for day to day programming.

<comment><USER29> I hate the interviews as much as anybody... but really I wish that kind of instruction had been a bigger part of my college curriculum. Yea, we had data structures classes, algorithm classes - but none of them really made me _good_ at any of them. Not like how math classes makes you good at the math, by forcing you to solve problems over and over, until it becomes nearly instinctual.

I've actually become a better programmer by practicing interview problems, because they ultimately are a bit like the arithmetic involved in solving more large scale problems.

<comment><USER30> Yeah, I agree on the last part. Practice helps. Memorizing solution doesn't. It takes effort to crack those Leetcode problems.

</comment></comment></comment><comment><USER31> Maybe it's just me, but this seems to either miss the point of a CS interview, or makes a point about CS interviews containing pointless parts making them trivial. If an interview contains a known set of possible questions and you simply remember the answers, than in the end the whole exercise is somewhat pointless, isn't it?

<comment><USER32> Yes you are right. This is why I take some standard problems but change things a little bit so they have to think a bit. And I ask additional questions like how would you test this function, how to change improve performance, etc.

</comment></comment><comment><USER33> As crazy as these interviews are they have to be working right? Some people must be passing these things otherwise there would be a lot of unfilled positions.

So much for there being a staffing shortage in our field. These types of interviews imply there is a much higher bar that exists to weed out all the chaff due to oversupply or companies won't settle for anything less than the most academically best people.

<comment><USER34> > Some people must be passing these things otherwise there would be a lot of > unfilled positions.

The point is - there _are_ a lot of unfilled positions. Companies notoriously complain for not being able to find "good" software specialists, because... people with minimal clue on how to judge relevant skills introduce increasingly more cut-throat filters and processalize everything.

</comment></comment><comment><USER35> My school does co-op's and has a 1 credit co-op prep course. We do have practice interviewing there. We also do resume workshops, general best practices for the industry you're in, etc.

You can do both the content and the prep, as I am sure is the case with Stanford CS.

While it's unique to have a course specifically named for this and am sad to see it as well, I don't think this is as big as people are making it out to be, nor is it a canary in the coal mine for higher education. To me, this only signifies the growing shift in education, as it becomes more available to all, being about preparing for your career as much as learning itself. The simple fact is that most attending college today are not doing so just out of the desire to learn alone, but also want to, well, have a nice career in their respective industry. To be able to make a living.

While I would also agree with cautioning about education for career alone, I think it's important that modern education focuses on both. It's the reality of an increasingly college educated world.

<comment><USER36> Hey it could be worse, people could be getting a degree because they need it for signaling purposes and/or to satisfy an arbitrary immigration bureaucracy and don't actually need any of the things they're being taught. Oh, wait :)

</comment></comment><comment><USER37> Just wait until you start interviewing at even crazier companies than FB/Google that would like you to tell them 20 ML algorithms, 20 computer vision algorithms, compare expected results of non-linear optimizations applied to some weird Deep Learning problem and analytically justify it (why is it worse/better than SGD on this loss function?), then off to some deep domain knowledge, conjure graph algorithms on the spot on problems you've never seen before, all in 1.5h, expecting Stanford/MIT PhD-level answers.

<comment><USER38> Sharing a data point: I've interviewed with Google multiple times and at no point during the interview was I asked a question that required an ML/CV/DL algorithm.

I suspect those would be more appropriate for a 'data scientist' / 'researcher' position - for a generalist, the interviews were very standard and not crazy at all.

In hindsight, if I had taken the time to review basic CS algorithms ahead of the interview, I would have done much better.

That said, I'm not sure I'd be a better employee at Google if the only difference between my being hired or not hired is the fact that I reviewed some basic data structures and algorithms.

</comment></comment><comment><USER39> If a stanford CS degree doesn't otherwise prepare students properly for a tech interview, I'm going to wager it is the interview process that has a problem, not the stanford CS degree..

<comment><USER26> You are right but like just having to use the fucking white board is different enough to throw people off.

</comment></comment><comment><USER40> If there is whole course on "interviewing", in or of top schools no less, then the interviews really became divorced from any meaning. That should be seen as major red flag that industry is doing something wrong.

Maybe there should not be cookie cutter interview at all, but more of harder look at which skills and personality traits are really needed for this or that position.

And I tend to do good on whiteboard interviews.

</comment><comment><USER41> Don't programming bootcamp classes do this kind of thing too? I feel like this just increases the probability for a student to do well on the interview. If you read their intro slide, it clearly states "Level the playing field between applicants who may learn these things through informal mentoring in their friend network, and those who would otherwise not know this stuff"

It's kind of sad that there's a trick that needs to be learned to solve technical interviews without testing the candidates' inherent knowledge, but at the moment, this could seem like the most logical way to get a good job for a Stanford CS student with no knowledge on technical interviews.

</comment><comment><USER42> What the hell?

Shouldn't we focus on creating great engineers instead of training them to make a good impression on an interview?

I think is completely immoral. Becoming good at something is a matter of consistent practice that brings experience and expertise over time. There is not other way around it.

People might pass the interview but their hat will fall in a matter of weeks. This is PUA for interviews by a University, this is really depressing.

The only thing that gives me hope is that great engineers will always solve problems no matter what. Tech hiring is going to become much harder.

<comment><USER43> This is a _single_ pass/no pass unit out of 180 required to graduate. Stanford absolutely focuses on creating great engineers (or computer scientists, for those more interested in the math or theory sides), but it still helps to have a small course pointing out tips and things to look for in the interviewing process.

</comment></comment><comment><USER44> Question from European side.

We hear there's a shortage of good people in SV / USA. What if you plainly ignored all companies that whiteboard? There should be plenty well paying jobs left.

disclaimer. a major tech company whiteboarded me twice (codility + live coding via google docs). They were really selective, none of my friends passed. In the end the job was lousy so ultimately the test selected more for willingness to jump through irrational hoops than productivity.

</comment><comment><USER45> A whole class for technical interviews seems like overkill. It also gives me an uneasy feeling of being in a tech bubble.

<comment><USER12> This kind of prep has been common place in other desirable fields for many years. Law, medicine, finance. They all have books, classes, etc. that you can take to prepare for interviewing, taking the bar, mcat, etc. Compared to college admissions, the CS interview process looks downright sane.

<comment><USER46> They all have prep for everything but interviewing. An interview to get a residency or a junior assistant position will be much more about your credentials and a history of your performance.

<comment><USER12> Finance at least has prep for interviewing for investment banking, trading, and consulting. When I was in undergrad it was common to have mock interviews and prep for commonly asked interview questions. Most people prepped on being able to walk you through basic financial statements, valuation, brain teasers, case interviews, and stuff like that.

I'll take your word for the other fields as I can't speak directly to interview vs exams there.

</comment></comment></comment></comment><comment><USER47> The last two places I've interviewed and was turned away would have loved a "software engineer" who had taken this class. I am a typical developer, I can get shit done but there are rough edges I have because I'm human. I think, interviewing in general is tough for me and when there's a set way of showing your abilities comes up, I'm not great at presenting that.

My github is active, I work on things that a potential employer as well as fellow developers would be interested in and I also am trying to grow by showing bad, good, and some code that I'm very proud of on my github. But, the thing I noticed at the two aforementioned interviews was that they hadn't even taken a look at my github.

</comment><comment><USER48> I'm glad they are teaching students about resume writing, and hopefully the professors are versed in hiring outside academia. I write hundreds of resumes a year for my clients, and a high percentage of young clients are using really poor resumes when they engage my services.

It seems many new grads are being drawn to highly-visualized resumes with fancy templates, often featuring a bar graph for skills ranking (some ranking themselves as "8 out of 10 in JavaScript", which comes across as laughable and out of touch).

My feelings on memorizing data structures aside, the resume lessons may at least help some grads get interviews that they wouldn't have otherwise, and that's a good thing.

</comment><comment><USER49> I always thought the the technical white board interview never really matched what was expected.

A binary tree search has little to do with figuring out the pros and cons of which api to code against.

How about a scenario where you get to try to find a bug with legacy code?

</comment><comment><USER50> I understand this encourages an imperfect system, but I would have really appreciated this as an undergraduate who didn't understand how interviews worked.

While the system is admittedly problematic, does it really come as a surprise that for extremely competitive jobs at the entry level, such artificial hurdles need to be used to filter the plethora of black-box applicants? I can't speak to more senior roles, but for entry-level, this only seems like a natural (and practical) response. It happens everywhere, not just CS:

For any competitive school admissions, SAT/LSAT/MCAT what-have-you are all poor indicators of student performance, and boil down to trainable tests.

In finance (both quant finance/and positions like sell side banking, private equity), people constantly practice math/financial modeling/accounting, for interviews. Many of the more selective quant shops (for undergrad hiring, I should mention) have much more difficult problems than MS/GOOG/AMZN technical interviews, and I would argue the type of competition level math/probability are just as unrelated to their jobs.

In management consulting, people spend hundreds of hours practicing for case study interviews. Just search consulting interview prep, and you'll find an egregious number of prep companies.

Some people brought up law and medicine. First, I don't think the grueling nature of the medicine certification is even close to what it takes to be an entry level developer. In law, while "technical" interviews are rare, often times employers filter you by much cruder means: pedigree (both the school you attend, and at top echelon law firms, clerkship status, and top-top grades within those schools). Is that any better?

The common denominator here is the high demand for all of these schools/jobs, and the problem always seems to come down to, how to optimally recruit -given- resource constraints. Maybe I'm cynical but almost any reasonable entry-level interview can be "gamed" or trained for, and most firms are either small and lack resources to extensively evaluate their applicants holistically, especially if they're only in undergrad, or they are large and get way too many applicants, so some proxy is necessary.

</comment><comment><USER51> So, Stanford grads can't pass interviews without training for it. Looks like a degree is really worthless. Al that matters is memorizing these problems.

</comment><comment><USER52> As other commenters alluded, interviewing and coding are indeed two different skills. However, contrary to some of the comments, I don't think there is anything wrong with preparing for an interview or even taking an entire course for that matter. If it helps you shine and showcase your real skills to an employer then why not? I've seen many brilliant software engineers get rejected for positions cut out for them only because they were so nervous at interviews that they had trouble even understanding simple questions until right after the interview ended. I know that because I'm a co-founder at Pramp.com, a free p2p mock interviewing platform for software engineers. It's incredible to see the improvement in one's confidence even after a single practice interview.

</comment><comment><USER53> I've been through the ringer quite a few times now (though less than the average Stanford student) and I think about these interviews more than I probably should just for my sanity.

This is a decent primer (and people need primers!) and a good resource overall but I'm very skeptical that this is terribly helpful for most interviews. I liked some of the problems but most are about a notch lower in difficulty than required for the offers Stanford students get.

With that said, it's clear that the students that take this class are going to do well in their internship and job search. I'm honestly just becoming more convinced that ability to perform in these interviews is an inherent quality of top students (no matter the original field!) at this point.

</comment><comment><USER54> Institutionalzing a broken process. :-/

</comment><comment><USER55> I trained for google and failed. Still it didn't feelt like stupid or a waste of time.

It was interessting to do so, i think it made me better and i will try it again.

And yes there are people who don't care enough to work for companies like google and there are.

Also while i did more interviews as the person who is interviewing: I feel that i like to have more better prepared people to interview.

</comment><comment><USER56> FWIW the second example of finding halfway points in [https://web.stanford.edu/class/cs9/sample_probs/ListShufflin...](https://web.stanford.edu/class/cs9/sample_probs/ListShuffling.pdf) is buggy. Crashes if the list have odd number of elements.

<comment><USER57> "Your job is to write a function that accepts as input a pointer to a linked list _with an even number of elements_ "

<comment><USER58> Would writing it to handle odd numbers of elements as well cause the employer to move forward with a different candidate?

<comment><USER59> This may not have been a serious question but I'll give a serious answer: depending on the interviewer, you could get bonus points for going "above and beyond" or, yes, you could be penalized for "not reading the spec."

I've found that the best way to handle it in a conventional whiteboard interview is to mention it when appropriate and offer to add the functionality later.

"Now, here's the part of the code where I'd deal with odd N. Since we're guaranteed even N in the problem statement I'll skip this for now, but we can come back to harden this function later if you like."

</comment></comment></comment></comment><comment><USER60> Not all jobs require this preparation-style. If you don't like it - <USER2> around and find companies with different styles that match your preference. Interviews are equally important to the interviewee as the interviewer.

</comment><comment><USER61> Do people actually put "objective" on a resume? It seems laughably hackneyed. My experience is that something near 40% of people have it, and it usually is the most trite sentence possible.

</comment><comment><USER62> "Most metrics are good until you start optimizing for any of them"

</comment><comment><USER63> What a joke, but I'm completely unsurprised. Prep for the SAT, prep for jobs, prep on the job - minus the whizkids, Stanford grads make great corporate drones.

<comment><USER53> Corporate drones that are paid $50-$100k more than me total comp their first year, yes.

</comment></comment><comment><USER64> This is a natural response to the incentive structure that has evolved. But fear not, the fact that this metric is being overemphasized to this large a degree surely must mean that the adversarial species (the industry) will respond by changing their strategy. The more universities focus on vanity metrics (helping students build their peacock tail), the more likely it is that the industry realizes the kink in their armour and shifts to some wiser signaling measure.

</comment><comment><USER65> I know universities are sometimes accused of "teaching for the test" anyway, but, well, wowsers

</comment><comment><USER66> Say what you will about the state of the software dev interview, it sounds like it could be a fun class.

</comment><comment><USER67> maybe a bit meta but i've been wondering why course links are posted to HN. is this a tradition or something?

</comment><comment><USER68> This just feels wrong.

</comment><comment><USER69> Two more of my favorite interview questions rendered useless :C

</comment><comment><USER70> Off-topic probably:

This timing!

I'm going to interview on Tuesday with a startup in SF. I've spent better part of last 3 weekends studying and solving DS&A.

Any advice from HN on what could I do in ~14 hours of prep time?

<comment><USER37> Do Codelab at Facebook, sleep, avoid jetlag.</comment></comment>


Ask HN: Did adding a payment system subject you to blackhat hacking attempts? - <AUTHOR> I run a small web app that makes a little bit of money through ads.
People commonly give the advice that you should ask your users for payments if you want to keep your web app alive.
I do not know if people will pay for this app, but recently, I decided that I would add some for-pay features to my app.
I mentioned my decision to a friend. He said "Aren't you concerned that accepting payments may open your site up to attackers or abuse?" I pressed him, but he couldn't come up with a reason for asking. This idea had not occurred to me.
So, I'm asking you, people of HN: is my friend just paranoid? Have you heard about something bad happening to a website or app after payments were added? Do you have experience with this problem, or was it never a problem for you? <comment><USER2> It happens. Candy Japan gets a bit of discussion here on HN, and has a few posts about credit card fraud on the blog (eg [https://www.candyjapan.com/behind-the-scenes/how-i-got- credi...](https://www.candyjapan.com/behind-the-scenes/how-i-got-credit-card- fraud-somewhat-under-control)). The basic premise is that credit card fraudsters use small online transactions to check if a card is valid before they use it for the big high value stuff, and the cost of those transactions to a small business can make it expensive to run.

That said, if you're just enabling features on a site the actual cost to you is effectively zero, so maybe it's not something to worry about.

<comment><AUTHOR> Oh yeah, I did see that Candy Japan post. I had forgotten. Thanks!</comment></comment>


GCC optimization flag makes your 64-bit binary fatter and slower - <AUTHOR> http://timetobleed.com/gcc-optimization-flag-makes-your-64bit-binary-fatter-and-slower/

<comment><USER2> To put this in context, this particular bug makes your binary fatter and slower in the same way that eating a tic tac makes you fatter and slower. A single load/restore from memory through a slightly (and only slightly) slower path is really going to be blown away by every other operation in all but the most trivial program (imagine LOTS of recursion with _very_ simple functions (no looping)). Do a single IO operation and you're really talking about nothing.

<comment><USER3> Except that this is intended to make things faster, but actually makes things slower.

If it had some other purpose, and a slight slowness was a side effect, then OK. But when the entire purpose is reversed that's a problem.

<comment><USER2> I agree that it's a bug and should be fixed. I just don't agree with the implication of the title that it's a super huge deal. I mean, all we're doing is swapping out mov for push and leave. The functionality is completely unaffected, and the slowdown is so minor that no one would ever notice without running a ridiculous microbenchmark.

Fix the bug, but don't make a mountain out of a mole hill.

<comment><USER3> Where does it say anything about functionality? It just says fatter and slower, and that's exactly correct.

I don't see any mountain either. Are you reading some emotional context I'm missing?

</comment></comment></comment></comment><comment><USER4> It's nice to see someone tell you that their benchmark is flawed and why. Most try to pass off their benchmark as the end-all-be-all measurement of whatever they are testing

<comment><USER5> Graphs were also flawed - scale grossly exaggerated to make the point. Why not zero-based vertical scale? See "How to Lie with Statistics".

<comment><USER6> If the scales were flawed, it's in defense of -fomit-frame-pointer: according to his bench, it reduces the cycle count by ~0.3% in 32b, but blows it up by nearly 30% (29.7) in 64b.

I have put both graphs on the same image and scaled them correctly, then extended the canvas to the whole scale and finally shrunk the graph back to the original 600px high, this is the result: <http://imgur.com/yG3R9>

64b on the left, 32 on the right, blue is without -fomit and red is with it. On the 32b graph, you can barely discriminate between with and without, whereas on the 64b graph you can very clearly see it.

If he lied, his fault is to have dismissed his own findings as less important than they are.

<comment><USER7> thanks man. i've also updated the graphs on my blog.

<comment><USER6> Still a small issue: the graphs aren't the same scale (64b goes 0-5; 32b goes 0-4)

</comment></comment></comment></comment></comment><comment><USER8> A couple of points:

\- It's hard to reproduce the benchmarking results, as source code for the benchmarks is not provided.

\- The original bug report was for 32-bit code, not 64-bit code, as the post assumed throughout.

\- If you compile the code given in the original bug report as 64-bit code with and without -fomit-frame-pointer, there's no difference in the generated code.

\- It's not clear to me that the "potential pieces of code" in the article are actually generatable with real-world C code. Again, not having actual source code available hurts.

\- You shouldn't be using -fomit-frame-pointer on 64-bit code anyway, as you don't need the frame pointer for debugging/unwinding purposes on x86-64 like you do on x86. If the poster had read the x86-64 ABI, this would have been apparent.

<comment><USER7> Chill, son.

1.) I can provide the codez. I'll add a link to the article.

2.) Yeah. If you read the article, it reproduces on 64bit code, too.

3.) Not true. Try gcc (Debian 4.3.2-1.1) 4.3.2. The version I mentioned that I used in my post.

4.) etc

5.) Read the article.

I'll add some more shit and reply to you again when its online. I need to eat breakfast and head to the office but I'll make you happy soon.

<comment><USER6> Maybe you should provide both graphs on a full scale (from 0 to 4.8) to show just how little, in your benchmark, -fomit-frame-pointer brings to the table in 32b (under half a percent using your mean cycles count) versus how much is lost due to it in 64b (nearly +30% cycles)

<comment><USER7> done, refresh page and you should see em.

</comment></comment></comment></comment><comment><USER9> Anyone doing timings in Linux at the cycle level might be interested in the PAPI library: <http://icl.cs.utk.edu/papi/>

</comment><comment><USER10> It sometimes pays to run your tests at different levels of optimization. There are optimizer and code generation bugs in compilers. Running your tests at different levels of optimization can detect some of these.

<comment><USER11> _There are optimizer and code generation bugs in compilers._

In my experience these are much, much rarer than the bugs in _my_ code that are optimisation level dependent...

<comment><USER10> Then there's a whole lot more reasons to test with different optimization levels.

<comment><USER11> Definitely. Even better, have them run inside valgrind or a similar tool, as this type of bug is often laughably easy to locate that way, and sometimes devilishly difficult to find with more crude methods.

<comment><USER10> When I was doing C/C++ we didn't have valgrind, or at least it wasn't widespread enough for me to hear about it.

</comment></comment></comment></comment></comment><comment><USER12> uhh, what is that disgusting thing on the picture near the top?

<comment><USER13> I believe it's a ferocious water bug:

[http://www.google.com/images?um=1&hl=en&tbs=isch:1&#...</a>

<comment><USER3> It's a Giant water bug. The ferocious thing is a joke.

</comment></comment></comment><comment><USER14> The analysis is flawed because it merely takes into the account the fact that ebp is callee saved verses using a different register that is caller saved. But ultimately, the register still needs to be spilled somewhere so you're not changing the overall amount of work done.

Furthermore, it doesn't take into account the fact that by using ebp as a GP register, you've got an additional register to work with which eliminates additional spilling.

Basically, there's nothing to see here.

<comment><USER7> Spilling has nothing to do with this. GCC has the chance to pick another GPR that is caller saved but instead picks a callee saved register.

This decision increases the size of libc by 1% when compiled with -fomit- frame-pointer[1].

[1] [http://sources.redhat.com/ml/libc- alpha/2010-07/msg00022.htm...](http://sources.redhat.com/ml/libc- alpha/2010-07/msg00022.html)</comment></comment>