About 5 years ago, I moved to another city across the country to work for a small startup. The city was small, candidates were few locally, and maybe fewer still wanting to move there (Lubbock, but my inlaws are nearby, and I liked the idea of my kids getting to see their grandparents).

It was the funnest job I ever had, moreso than I could describe. I was hired on as a web developer, but about 3 weeks in they started asking me to help work on firmware written in C for pic microcontrollers. Soon after that, they asked me if I thought I could produce comparable products with commodity hardware, and I found myself trying to write linux drivers for a packet radio (the usb development kit that the chip maker sells... but only provides Windows drivers for).

A few weeks in, I had that working. With a dozen other projects on the backburner too, all of them interesting and challenging. They were buying whatever hardware I said I needed, and if I ordered something that turned out to not be so useful, no one ever complained.

It was easy to be excited doing all of this. So of course the day after I managed to get a working prototype of the biggest challenge yet, I was shitcanned. Startups run out of money.

Now I write stupid web apps for a university. They pay me better ($20,000 more a year, not including benefits, probably more like $35,000 more with those). But it's boring as hell. And it's not the university's fault. The world needs alot of boring stuff to keep running.

My point is, if you've found alot of enthusiastic people, it's not your HR department's competence that gets the credit. It's not really those people's credit either. You just have a rare job that's actually fun.

That's an interesting story. Did you have experience writing firmwares and drivers in C before joining that startup? Did they ask you about it or it came on the spot? I am quite curious.

I had never written C before that, not on the job. Not much hobby-wise, just maybe tweaking shitty open source code to fix syntax errors or whatever. Never submitted a patch.

First time I had to write a makefile too. Ouch.

It had memory leaks, but nothing I couldn't have fixed given more time. It was userland, libusb, hadn't had time to get it anywhere near ready for a kernel driver.

I don't even know that I've ever properly learned any programming language... I get syntax Alzheimer's quite a bit. Other than novelty languages, how can you not look at code and not have some idea of what's going on though?

My Wordpress blog used to go down because of HN. I fixed that as follows.

1. Use the Wordpress supercache plugin.

2. Put Apache behind Nginx, and limit the number of Apache processes to ~6. This way you're effectively using Apache as a "PHP app server", simulating an architecture similar to Passenger/Unicorn. Nginx acts only as a buffering reverse proxy, shielding Apache from slow clients.

Why this instead of running Wordpress/PHP through Nginx using php-fpm? It's because Apache is just easier: mod_rewrite rules work automatically, etc.

I'm not even sure step 2 is necessary, my WP blog has hit HN a few times and the supercache plugin alone has been more than sufficient to handle it.

Really the big problem at this point is that stock WordPress falling over under even moderate traffic is such a common experience that having caching broken out into an optional plugin doesn't make a whole lot of sense. WP should probably ship with at least a basic caching solution built in.

This is first time I've seen the words "Apache is just easier" in that arrangement. I think php-fpm is significantly easier to set up than Apache and expect it to be more performant with less resources.

This probably depends more on experience, and which OS/platform you're using; although I don't do it a lot, I've configured Apache servers several dozen times, whereas I've only done nginx a couple of times, so it is 'easier' for me.

Also, on ubuntu (and centos, but haven't used it in a while), it is something like 'apt-get install apache-mod-php' and everything is there :)

Yup. I've been running nginx + php-fpm for pretty much as long as it's been possible, and it's pretty great with far less hassle than most other configs.

It's easier for things that are written in broken ways that work best with Apache because that's the only platform they targeted.

Caching HTML to disk via W3 Total Cache or WP Super Cache is really all you need on most hosting. I never got around to putting Apache behind nginx, but have still survived some relatively large traffic spikes for a personal blog (e.g. 100k+ page views in a few hours) without any trouble at all.

Not to say that your setup isn't better (it obviously is), but I want to make sure no one's intimidated by the task of hardening their WP install because they think they'll need to do both 1 and 2 for it to be worthwhile.

Never configured Apache that way, that sounds really interesting. I was running the site on a fairly well tuned LEMP stack and was using a cache plugin (forgot the name) but it would still choke fairly often.

Since the content of my site only changes a couple times a month I started migrating away from towards a static solution. I'm not trying to say WP is bad but I think if your content is relatively static and you aren't doing a ton of updating, just make it static HTML instead of doing hacky cache stuff. It's simple, secure and runs on any type of server.

The only thing that's lacking right now is a really solid static site generator. Octopress/Jekyll are good solutions but can be a bit frustrating and not very portable.

Using nginx/varnish as a caching reverse proxy in front of apache/php is rather common. You get all the ease of use of Apache (mod_rewrite instant .htaccess rule changes, mod_php, etc.) , ability to use whatever cpu intensive plugins/code you want in your application, and once the page is cached it loads instantly for as long as you cache it. Nginx can be configured to serve static assets directly or your app can use CDN links.

I've never really understood the recent fascination with static site generators. I get that it's neat you can upload just everything to S3 and host it there with no servers, but then if you want to change something site wide you have to reload everything. Dynamic app + with caching reverse proxy + optional CDN is a tried and true method. I've been on projects that use this method with small VMs to power sites with tons of traffic.

I've had strong recommendations for nanoc and middleman. Additional static site generators can be found all over; one good resource is this list: http://blog.iwantmyname.com/2014/05/the-updated-big-list-of-...

In my case, I did two things:

1. Add memcached 2. Serve static files via nginx

It allowed me to handle 2.9 million requests

I documented it here: http://idiallo.com/blog/handling-1-million-web-request

Nice! I tweeted this, you might see some additional traffic, definitely something my group of friends would be interested in.

Thanks, and I'm glad you found it interesting.

Nginx + PHP-FPM isn't necessarily hard to setup, just different. It will be much faster than nginx in front of apache.

You can do the rewrite with a single nginx command:

    try_files $uri $uri/ /index.php?$args;

> Even now with a programmer shortage companies are still unicorn hunting and making people jump through stupid hoops for jobs.

What's worse is the companies who try to defend their unicorn hunts when called on it.

And arguably in some respects this was a unicorn hunt amounting to making people jump through even stupider than usual hoops (responding with a 500 page manual!) to prove their aptitude for learning. I'm surprised that, to the extent I can make it out from rather small pictures, the applicants don't appear to be in the sort of age bracket generally associated with unpaid internships...

Difference is, it balanced an unusually onerous assessment with the unusual reward of a de facto guarantee that anyone persistent and smart enough to get through it all would get a job at the end. I hope it paid as well as they presumably thought it would.

There are a few companies out there with a desire to build an ecosystem on obscure or unproven technology that could and probably should experiment with elements of this as a hiring strategy. Getting the class to vote on who gets the [first] jobs is particularly neat; it both selects the most effective team member(s) and leaves the rest with the impression they weren't ruled out of contention by the hiring manager and therefore shouldn't be deterred from reapplying in future

I actually applied to work with Brooke a couple years ago, and I probably still have the Craigslist post saved.

The original ad was posted with the title "If you enjoy mathematics, no prior work experience needed" and a really intriguing body that alluded to interesting work that they'd train you on. He asked if we had any questions for him, if we could get to his office (i.e. were in commuting range), what was interesting about us, and finally asked for a brief summary of our work/schooling. He specifically didn't ask for resumes, although a lot of people sent them to him (and then dressed for the open house in a suit, lol) because of how ingrained the standard motions of hiring are among candidates.

He followed up to every email with a personal response where he sounded like a human being, and then told candidates that there'd be an open house and then we could decide if we wanted to keep on in the process.

I imagine some people shied away because of the time commitment of learning what we could about a new, weird language over a week, and there were some things that didn't work very well because of how different his hiring process was from the norm, but it was enriching and fun in the end.

The big thing that might have worked in Brooke's favor was that this all took place in 2011, when the job market was even worse than it is now.

Fyi, the author is a man.

Fixed, thanks