eranki

I used to do it this way until I read this article a while back -- the hot start method gives me much easier-to-peel eggs than the cold start used to. I start with my eggs from the fridge and usually toward the end of their lifecycle though.

Here's an interesting paper on the prevalence of these misconceptions in both students and teachers (at least in Germany).

http://myweb.brooklyn.liu.edu/cortiz/PDF%20Files/Misinterpre...

TLDR: 80% of methodology instructors have a misconception about significance. Scientific psychologists and students perform even worse.

Interviews are hard because programming is an incredibly complex task with few qualified candidates.

Any programming challenge other than the most basic questions is going to have a long-tail distribution in the time it takes a person to answer them. It's easy to get hung up on something stupid, especially in a high-pressure situation like an interview. We've all had moments where we missed something "obvious" for weeks on the job.

In college they solved the time-pressure problem in tough classes by making the homework really hard and the tests really easy (like the take-home project OP suggested), but that relies on an honor code and the fact that getting a good grade on your homework is not nearly as important as landing a job. Also a lot of great programmers don't want to deal with your bullshit project because they're getting recruited by a million other companies.

If some new metrics end up in widespread use, most of the people that pass the test are going to be ones that gamed the system (e.g., added a bunch of GitHub projects), just like the majority of people that get really hard coding puzzles have seen the trick to solving them before.

No matter what you'll end up with low true positive/negative rates for any test you do. I think the right way to deal with this is to come up with a bunch of orthogonal tests and then choose candidates that pass a bunch of them. Have them debug a program, have them do web programming, have them talk about a project they did, give them a project to do if you can, etc.

The main thing I learned after doing hundreds of interviews is that I have a limited view on how to judge a programmer, and that view translates only so well to the question of "how much value will this person add to our company right now."

So yeah, TLDR, I don't think the status quo is great but I don't think any of the solutions proposed over the years are better.

Trying to become a successful academic seems about as insane as trying to become a rock star.

Here's Peter Higgs on the subject of how academics today compares to the past: http://www.theguardian.com/science/2013/dec/06/peter-higgs-b...

Most people I know who went down the academic route have left the world or are seriously thinking about leaving. I know a couple people with positions at top universities, and around the age of 30 their careers are just starting, with tenure being potentially a coin flip.

And it always traps the most brilliant people. That's the worst part.

Nobody knows how to identify "talent" other than in retrospect. We say people are talented when they produce results, and then we select little anecdotes about their story to allude that it was destiny.

We can't settle this debate because we just don't know enough about how the mind works and how genetics play a role.

My question is, what's the actionable piece of advice? If you try programming and don't get it, you'll never be a good programmer? At what point do you give up and say that you just aren't talented enough?

It seems to me that the only people asking the nature vs. nurture questions are the ones that want an excuse to give up.

The best food in the world isn't freely available to everyone. The amount you pay for software may not correlate with quality (expensive government contracts vs. a few smart guys making a website) whereas top-priced meals are consistently good. The only cost in software is labor whereas food involves perishable inventory, fluctuations in demand, etc. that works into the cost.

I'm just sayin they're totally different. But yeah they are both hard.

agreed. i think this convenience is confusing. also would make it hard to explain that a two-dimensional complex vector contains two complex numbers, not one.

Why do we always feel the need to upvote posts like these as if we don't discuss them every 2 weeks?

Next up in the topic cycle: Discrimination in tech. Why working more than 40 hours a week is killing your productivity.

You missed the point, which is that people are likely to pull out their phones at totally inappropriate times these days. Go to any restaurant or bar and see how many dates/couples/groups are just staring blankly into their phones. That doesn't really happen with books.

I think the benefit would be that people will ask more in-depth subject questions rather than "getting-to-know-you" type questions (to which we would get answers too short to satisfy).

I think HN has become increasingly focused on people rather than ideas and this would exacerbate the problem. IMO this should be news FOR hackers, not news ABOUT hackers.

AMAs would also largely be posted by people with a self-promotional interest (for the benefit of either themselves or their company) and upvoted by their voterings. Reddit AMAs seem like much more of a favor to the audience in comparison.

The problem is corporate culture and chasing secondary indicators of productivity (hours spent in the office, lines of code written, emails sent). The actual output of knowledge workers is hard to determine and bursty (you can spin your wheels on a problem for days but have a break-through in minutes) so people come to rely on these proxies.

I don't even think the problem is employers [in Silicon Valley]. Employees themselves, unaware of how best to show their worth, choose to optimize for these proxies because it's perceived as a safer bet.

That said, I think when I've worked 80 hour weeks before I've gotten twice as much done as 40 hour weeks, but only because I felt driven to produce a certain output, not because I cared about the hours.

I used to like Quora a lot but always hoped it would grow out of its Silicon Valley cliqueyness... I think a lot of these recent changes ensure that it's going to continue only serving that niche.

I think the alternative being proposed though (no brand name but lots of drive) assumes lots of coding experience outside of the classroom.

I really enjoyed my MIT education, and maybe it made me smarter, but I can't say it made me a much better programmer. We had exactly one class (6.170) that was a practical programming course and the content should have been familiar to anyone with previous programming experience.

The foundational "computer science" skills held in such esteem by companies like Google amount almost entirely to an understanding of algorithms and data structures (you will almost never see an interview question based on, say, programming language theory), which was covered by exactly one semester-long course in our curriculum.

I think we learned a lot of cool stuff, but not stuff a working programmer really needs to know.

Two points:

1) "Physics is like sex: sure, it may give some practical results, but that's not why we do it." - Feynman

Most smart scientists and engineers I know (not just web programmers) work on their problems due to some combination of: they enjoy the problem, they're scratching their own itch, they get prestige from doing the problem, and they make good money doing it. Even the ones that are working on "important" problems.

2) Sometimes it's hard to see the downstream effects of what we do. By improving ad targeting, maybe Google has enough cash to reinvest in something like self-driving cars, which ends up saving untold numbers of real lives in the future.

By spending time on planetary motion (seems pretty useless) in addition to alchemy (eternal youth and unbounded riches? clear winner), Newton has helped solve more "important problems" than anyone could dream to.

Summary: The incentives of people that work in science and engineering are generally far from altruistic. We don't really know enough about the impact of the stuff we do to be able to say what's important.

Only read a few pages, but I would eliminate a lot of the introductory formalism. Most people don't need to be confused by the different sets of numbers, or common uses of variable names, or how to alter the shape of functions.

I like doing this and changing all the variable names as well so I'm forced to keep track of what's doing what

lol, nobody gets paid to see the positive things. Everyone else at the company is also being paid to be critical and fix problems (lawyers, finance, HR, CEO, etc.).

I agree, it's a straw man. Also, who ever implements their own data structures anymore? These days people use native-language maps freely, which may be implemented as trees or hash tables.

Also life expectancy changes as you age: http://www.ssa.gov/oact/STATS/table4c6.html

By the time you hit 60, you've gone from ~75 to ~80.

But simplification is the hard part... Being able to understand a solution and being able to come up with a solution are two very different things.

Asymptotically, the question with more coconuts is more interesting. I haven't verified this for sure (there are some assumptions), but:

With the "naive" asymptotically correct solution (go up a constant number k of floors, then linearly search the remainder), two coconuts gives us a worst case cost of:

n/k + k

minimize for k, we get a cost of

2n^(1/2)

With 3 coconuts, we have

n/k + 2k^(1/2)

minimize for k, we get

3n^(1/3)

What happens when we get log(n) coconuts?

log(n)n^(1/log(n))

= O(log(n))

Sweet! So at least we can see that it converges to binary search as we add coconuts.

lol why are you so mad -- perhaps you couldn't make this out through your tears of rage:

"Why not just plan ahead? Because most of the time, it was a very abrupt failure that we couldn’t detect with monitoring."

It's actually more like dumping fuel for an emergency landing instead of dumping passengers, if we really insist on using completely irrelevant analogies.

I thought about it, but honestly, I think it's important to try to fight against all the sanctimony and handwringing that surrounds security. People should feel comfortable talking about security as a tradeoff without diluting the argument with gratuitous qualifications and apologies.

^ For those that wonder why there is even a separate clean log.

Thanks! Good point. We actually repurposed our offsite database recovery to clone slaves off a master (after LVM was no longer performing), so that's a great way to get more testing in.

NULL-terminated strings are understood to be the only acceptable way to pass around strings in C.

safercopy() will not be writing or reading garbage from memory, but the strings produced as output are not going to be well-formed unless the caller is being just as careful. e.g., safercopy gives me a string that I probably can't pass into printf, or to ANY C library for that matter.

I don't know about way better. We had the experience of being both in managed hosting and the cloud from 1 server each to hundreds, and the cloud was better the entire way, with comparable costs. Especially if you're going to include engineering cost and you're talking about not many servers, any few hundred dollar/mo premium on AWS pays for itself. AWS reliability has also improved considerably in the past few years while managed hosting has not.

Besides, this article is about scaling. If your needs are static, who cares what you use. It's about where you go from there, and I'd rather be on the cloud before I have to.

Management tools have different needs from 2 servers to 10 to 50.

This article is patently false and annoyingly severe. I used to run the backend of Dropbox and I can say without uncertainty that the cloud (AWS in our case) is incredibly useful. I would go so far as to say that the cloud IS for you, and probably for everyone until it really makes sense to move off. You may have had a bad experience with an off-the-shelf scaling solution, but that does not implicate "the cloud."

- Sometimes you just don't know whether your traffic is going to spike 10% or 100%. And I'm not talking about one or two computers, I'm talking about adding hundreds. Are you sure your supplier has everything in stock for a rushed overnight order? Your exact hard drive model? Your aging CPU? You're seriously going to experiment with a new batch of shit and tell your team to spend all night wiring all of those racks? Do you even have the space left in your cage? Enough space on your routers? Enough power? Even if you're in managed hosting like SoftLayer, these are now their issues and Not Their Problem if they can't turn around for you in the time you need.

- In the time we were on the cloud we were better able to understand our hardware needs so that we could actually spec out machines optimally. Even better, technology improved considerably to bring us low-cost SSDs which wouldn't have been possible at the start.

- There was no way we could manage these servers and a datacenter without a dedicated network engineer and an SRE. And even that was pushing it. If you've ever tried to hire these positions, it's even harder to find good ones than software engineering. We got really lucky. Also, you've spent a lot of time on your engineering interview process and you have it down -- now do the same for two more positions that you know much less about.

- There is a huge engineering cost to moving off and building your own tools. Two servers? OK. Two thousand? Different ball game.

- I would argue that even a company like Google uses essentially a cloud solution that they've built internally and made available to their teams. AWS helps make a piece of that accessible for the rest of us.

TLDR: I thought I was hot shit too when I ran a Newegg server off my parents' internet connection, but come back when you're pulling down a megawatt and tell me the cloud sucks.