Anchor Web Hosting Blog

How to smack people in the face with your resume

by

It’s hiring time again here at Anchor1 and that means we’ve been sifting resumes. Lots of them.

We’d like to offer some advice. There’s no shortage of advice on what to put in a resume, how to format it, and how to highlight the most salient terms. All that still applies, but our advice is not about that.

You don’t have much time to make an impression with your resume. Let’s make the seconds count by cutting the cruft from your resume and focusing on what matters.

Short is good, shorter is better. We think this also applies to resumes:
Keep your resume to 1 page. But, you might say, my career history is far too extensive to keep to a single page. That’s a nice problem to have, but all the interesting and relevant information fits on a single page.

“This person’s resume is too short”, said no hiring manager ever. We kid you not, we’ve received 20-page monsters from applicants before! Your resume is your foot in the door, it only needs to get you to an interview. Stick to 1 page, hiring managers everywhere will love you.

If you’re serious about your resume then you’ve put a good deal of effort into producing a good looking and easy-to-read document. Don’t shortchange yourself at this stage of the game: Send your resume as a PDF.

PDF files render the same regardless of who’s viewing it, so if it looks good on your screen then it’ll look good to your potential employer. Some job sites and recruiters insist on submissions in MS Word format. You should run a mile from them, there’s a good chance that your carefully arranged document will look terrible for the intended recipient.

So, a short resume in PDF format. Because you’re keeping it all to one page, you only can only afford to include the information that will help you get an interview, and hopefully land the job. Your resume should be a vehicle for your accomplishments.

Skills are useful, but achievements are better. Highlight your accomplishments for the roles listed on your resume. Many other candidates have the same skillset as you, but the accomplishments are yours and yours alone. Here’s what you want the hiring manager to think to themselves:

“Wow, I can see this person’s done good work in the past, I wonder if they can do good work for me, too? I’ve got to interview them!”

The best way to understand what we mean by accomplishments is through an example. Even for a relatively mundane role you can focus on your contributions and achievements.

Sep 2011 – present    Service Assistant, Woolworths Ltd

  Include a brief paragraph describing the job's responsibilities; cash
  handling, restocking, answering customer enquiries, etc.

  * Multiple bullet points, each of which identifies an accomplishment.

  * If you can make each of them one line, that's fantastic, but two
    full lines is OK too.

  * A bullet point that takes two lines but has only a word or two on
    the second line isn't cool - take out a word or pick a shorter one.

  * An ideal accomplishment is quantified and explained.  The form
    "[past tense verb] [noun] by [quantity] by [doing something]" is
    best, but not everything will suit this format. Examples:

  * Delivered checkout throughput 20% above average by focusing on fast
    and accurate scanning and cash handling.

  * Answered 95%+ of customer enquiries satisfactorily by focusing on
    ensuring the customer's real problem was solved.

  * Had zero lost-time-injuries, by always following manual-handling
    guidelines.

  * Produced a balanced till on 100% of shifts by always
    double-counting the tendered amount and returned change.

In case we haven’t made it clear, your accomplishments should constitute the bulk of your resume. This is what you’re smacking them in the face with.

If you’re writing your resume right now then you’ll have it a bit tough, but it’s a good habit to keep a little file of achievements. Maybe once a week, note down something you achieved that you’re proud of. Tom Limoncelli calls these “feathers in your cap”, and that’s really what they are. When you need resume material it’s all there ready for you to use.

Pick the best ones that are relevant to the role you’re applying for and use them. If it’s a customer service role, highlight your expertise in dealing with tough customers. Similarly if you’re going for something requiring a high degree of accuracy (like a bookkeeper or something involving cash handling), accomplishments that showed you were conscientious with attention-to-detail would be good.

If you’re disciplined and do this regularly what you’re actually doing in the longer term is building a Career Management Document, which we might talk about a bit more in future. It sounds fluffy, but it’s basically a resume that’s ready to go the moment you find something worth applying for. You distil it down to the roles that are worth mentioning and send it off with a suitable cover letter. That’s a lot of confidence right there, with very little effort required to maintain it.

Now hurry up and apply!

1. It’s always hiring time at Anchor, you should get in touch. :)
0
Comments

Second strike with Lightning!

by

We put Kyoto Cabinet under the gun recently as a means to improve Redis. The Anchor Propulsion/Internet Laboratory validated Kyoto Cabinet as “fresh”, but extended live testing has revealed sub-optimal behaviour in some situations.

To recap, we used Kyoto Cabinet to give Redis near-realtime disk persistence with a greatly reduced memory footprint; we called this “NDS” and published the code. Dirty keys are flushed from memory periodically into Kyoto Cabinet’s backing store.

This works fantastically most of the time, but we’ve discovered that some operations cause a massive blowout in the on-disk files. Kyoto Cabinet is a key-value store. When you update a value in Kyoto Cabinet it can be rewritten in-place, unless the new value is longer than the old one. In this case, Kyoto Cabinet makes a new copy of the value and leaves the old chunk of space unused. NDS is conservative about flushing to disk, but there’s no way to avoid Kyoto Cabinet allocating more and more space if your values keep growing in length.

So how does this apply to Redis? Setting a new value for string, like updating “foo” to “foobar”, will do it. It’s a similar story with numbers, which are also stored as strings: “1000″ is twice as big as “10″. In our particular situation, a Redis list is also a value. Repeatedly appending elements to a list is a perfect recipe for this problem.

Kyoto Cabinet’s own defragmentation methods weren’t doing it for us and it became apparent that we needed an alternative, so we went looking, and found the Lightning Memory-Mapped Database (LMDB).

LMDB is part of the OpenLDAP project so it’s got some decent pedigree behind it, and extensive testing in the lab showed that it doesn’t have the same issues as Kyoto Cabinet or any of the previously tested options.

On paper it’s very good: high performance, multi-version concurrency so clients don’t tread on each other, transactional and fully thread-safe. In practice it seems to hold up, too. We don’t actually need all the fancy features, and it keeps track of free pages for reuse, which addresses our qualm with Kyoto Cabinet.

Integrating LMDB into the NDS codebase isn’t quite a walk in the park, as the API is very baroque and requires a lot of jumping through hoops to get simple things done. That said, we’re pretty excited about it; we’ve rewritten NDS to use it without too much difficulty, and performance is definitely up to scratch. Once the very smart people down in the lab verify that it doesn’t cause problems under production loads we’ll be eagerly rolling it out into production.

0
Comments

Let us take your breath away with Wheezy!

by

A new version of the Debian GNU/Linux operating system, version 7.0 (codename “Wheezy”) has been released today.

wheezy_toystory

Thanks to the open and transparent development cycle of Debian, we have been able to work on improving our support for this release ahead of time, and are happy to announce that we now offer our market-leading Anchor Complete support on Debian Wheezy immediately.

Aside from the improvements and new software versions shipped with Debian Wheezy, we are also supporting some newer versions of software we like that didn’t make it into the release. When you choose Anchor Complete support with Debian Wheezy, you also get full support for the following:

If you’re an existing customer and want to upgrade, just get in touch and we’ll take care of the upgrade process. If you’re ordering a new server, you’ll get Wheezy straight away!

As always, if you’ve got any questions or just want to chew our ear, feel free to give us a call (1300 883 979 in Australia, +61 2 8296 5111 from overseas) or drop us a mail.

0
Comments

Hiring only the best

by

Regular readers of this blog will know that we’re hiring – we’re always hiring, in fact, and we’re going to be talking about it more in the near future. Hiring good people is really hard, so a smart company is always ready to scoop up a great candidate when they crop up.

Hiring is hard because there’s a lot of really good people out there, but not that many great people out there. The esteemed Joel Spolsky covered this at length over a decade ago in The Guerrilla Guide to Interviewing, but it comes down to this:

We only want the very best and can’t afford to do otherwise.

Here’s why…

As a webhosting company, Anchor operates in a pretty unique space. We provide a level of support that goes way beyond what most other companies would ever consider doing, and are often instrumental in designing infrastructure for our customers. There’s no one-size-fits-all for us, and that means that we run into all sorts of weird and interesting problems. We need really smart people to solve those problems.

We’ve written about these sorts of interesting problems before, but that’s not all we’re looking for. Just being smart doesn’t cut it, we need people that are pragmatic, know how to see things from different perspectives, and can communicate well.

We test all these things, and we test hard. A successful candidate goes through four or five different stages of testing and will typically make contact with at least half a dozen Anchorites as part of that. At the end of it we can be confident that we’ve found the right person, and they’ll know whether Anchor is the right place for them.

Now, you might say, that seems unfair on candidates that miss a beat when it comes to seeing the big picture, or perhaps struggle communicating with a group. Might we skip over a brilliant candidate and miss out on hiring them? Absolutely yes.

The thing is, hiring is as much about finding someone who “gets it” as it is finding someone who can do the job, and that’s especially important for Anchor. The effects of a bad hiring decision can go well beyond just lost time and money on one employee, so it’s far better to be discerning and miss a good hire than it is to make a bad call.

Speaking of fairness, keep in mind who this is fair to: our staff and customers. It’s only fair to other Anchor staff to know that everyone else here is superlative at what they do. It’s only fair to our customers that they can call up and expect the very best work.

Those that do make it through the gauntlet turn up to work and know they’re working with some of the brightest minds around, in an environment that is positive, welcoming and switched-on.

It’s what Anchor is built on, the very best.

0
Comments

Meet Michael, (another) Linux nut!

by

Screen Shot 2013-04-30 at 10.44.35 AMMichael Sampson has a reputation for being the office Linux nut. No small feat, when you consider that everyone at Anchor is a Linux nut. He works as a Systems Admin with Chris and Ryan.

How did you come to be working at Anchor?

“I was attending PyCon AU in Tasmania. I saw the Anchor banner next to the food table. When I got back, I checked out their company blog. I’d never worked on high-availability stacks or a lot of the other technologies mentioned and I thought that would be fairly interesting. So I applied for a job. I’ve been here since January.

What did you do before working at Anchor?

I spent the last 7 years working in an IT position in the education sector in Armidale. I’m from Tamworth originally, but I did both my Bachelors and my Masters in Computer Science at UNE in Armidale.

Tamworth hey? So you’re a country music fan?

Not really. The festival is good for the town obviously, but to me it always felt like two weeks of people wearing big hats and getting in the way.

Have you done much travel?

I’ve never really been big on travel, but I wouldn’t mind seeing a bit more of Australia. I once spent a couple of weeks up north around Cairns and Port Douglas. I’d like to go back to Tassie and check out Cradle Mountain and the west coast.

I’ve often thought that one trip I’d like to do would be to go from one side of the United States to the other. I’m not sure how – whether car or bus or train – and try and hit all of the highlights on the way through. So many things to see in the States.

When did you start getting interested in computers?

When I was a kid. My first computer was a VIC-20, back in the day. I was one of those kids that was always pulling stuff apart to see how it worked. Wasn’t always so great at putting it back together though…

What is something about Anchor you wish more people knew?

The level of technical ability here. Very smart people.  Every day I learn something new.

What’s your favourite technology?

Before I came here I hadn’t really been exposed to KVM virtualisation. I’d seen it, I’d played with it, hadn’t really seen it in production. In my previous job we used proprietary virtualisation solutions. KVM’s have come a long way and some of the add-ons like Virt-manager are pretty slick. It’s nice that it is built right into the Linux kernel.

Got any favourite movies, TV shows or books?

Usual Suspects, The Sting. Inception was a good movie. I really enjoyed that. Most of my movies tend to be a bit sci-fi.

I do enjoy reading. I like to read a lot of technical blogs. I have always enjoyed reading behind the scenes technical articles. GitHub and Slashdot have both posted fairly in depth information about the hardware/software powering their sites. Whenever I read posts like that I think, “that sounds interesting”.

I enjoy novels by John Sandford and Lee Child. Lee Child’s books all feature a guy called Jack Reacher who’s a fairly unique character. They just made a movie based on one of the books. In the books Jack Reacher is always described the same way,  he’s a 6’5″ guy, 220 pounds – he’s huge. In the movie they got Tom Cruise to play him…

Lastly, the most important question. Star Wars or Star Trek?

I like both to be honest. If I had to pick one, probably Star Wars. With the exception of the newer ones…

0
Comments

The btrfs backup experiment

by

Today we’re talking about our experience with btrfs, the next-gen Linux filesystem. btrfs has been maturing rapidly over the last few years and offers many compelling features for modern systems, so we’ve been putting it through its paces on some of our backup servers.

How does it stack up? Read on!

We chose to test btrfs on backup servers because they can make good use of the features on offer, and the threat-level of data loss is low. For our backups, the biggest benefit comes from copy-on-write and atomic snapshots.

At Anchor we use a modified version of Dirvish with support for btrfs: instead of hardlinking directories to provide historical snapshots we just use btrfs’ snapshot facility, which is very quick. Expiring old snapshots is similarly quick – it’s a btrfs operation instead of traversing a filesystem tree.

In general btrfs has been a very positive experience. We’re looking forward to btrfs getting dedupe support in future, something that ZFS already does, which could pay off massively in our environment.

However, in recent weeks it looks like we’ve reached a sort of “critical” mass and a few near-showstoppers have cropped up.

Each backup server hosts around 100-150 backup clients. Every night at midnight they swing into action, creating dozens of snapshots at once and hammering the network for all it’s worth. It’s not perfectly reliable, but we’ve observed hung tasks coincident to snapshotting with a fair degree of regularity. When this happens it blocks I/O to the filesystem, which makes for decidedly ineffective backups.

Quota groups (qgroups) are a relatively new feature, added about six months ago in version 3.6 of the kernel. As well as enabling policy-based usage restrictions, quota groups allow for detailed usage reporting, which is very useful for the usage-based billing that we do. We believe we’ve stumbled upon a bug in the qgroups code that causes CPU soft lockups.

CPU soft lockups are basically unrecoverable, so we’re forced to reboot the system. This has a knock-on effect that, as best we can tell, corrupts btrfs’ free space cache, requiring a time-intensive rebuild after the reboot (over an hour on our 16TB filesystems). Failure to do so results in an error some hours later, with the problem being detected and forcing the filesystem into read-only mode for safety. We haven’t nailed the problem to the qgroups code with absolute certainty, but our investigations are pointing in that direction.

The final lesson for today relates to full filesystems: you never, ever want to fill up a btrfs filesystem. Normal filesystems (eg. ext3) behave fairly predictably when they fill up or get close to capacity. Your system might behave erratically, but by and large it’s easy enough to fix.

In the one instance that we filled up a btrfs filesystem due to some misplaced rsync options, it slowed everything down to the point of being unusable. It wasn’t practical to diagnose the exact reason for the slowdown, but it suffices to say that if you can’t even navigate the filesystem to fix the error then it’s a big problem. Avoiding a recurrence was actually a key motivator for enabling qgroups when they appeared, but it didn’t quite go to plan.

Summary: it’s not all doom and gloom

This probably all sounds very critical, but we think the reality is actually quite positive:

  • Staff have been using btrfs on workstations and personal servers, and it works great
  • We’ve used btrfs in conjunction with Ceph and had no problems
  • Zero incidents of data loss or corruption in our testing so far
  • btrfs has actually detected single-bit corruption in an underlying hardware RAID volume – that’s a win for data integrity!
  • btrfs has fairly gracefully managed thousands of snapshots on each of our backup servers

In the short-term we’ll be pushing most of our systems back to ext4 with hardlinking, while keeping an eye on btrfs and zfs for backups.

Development is very active, with new features and bugfixes appearing in every kernel release. Many see btrfs as the future for Linux beyond ext4, and we think it’s worth trying if you haven’t already – it probably won’t be too long until it’s the default recommended filesystem for a distro like Fedora or Ubuntu.

0
Comments

Peering into the private lives of our network admins

by

In a departure from our usual technical posts, we thought we’d share with you a little of what it’s like to be a network admin here at Anchor.

A properly functioning network is critical for a internet services company, and our net-ops team does a fantastic job of ensuring that things keep running smoothly. When they’re not dealing with problems (which are rare) they’re hard at work improving and upgrading our network.

Just last week they extended our VoIP PABX to the US and enabled QoS support from end to end. A bit of late-night work was needed to avoid disrupting the support team, but it came off without a hitch.

Photo of our senior network admin crashed out on a couch, covered with a green blanket and holding a plush horse
Our senior network admin getting some much needed rest after last week’s upgrades

Hang on a moment.

What is that, is that… a pony? Zoom in and enhance it.

Close-up of the hindquarters of the plush horse seen in the previous photo
A-ha! I’d recognise that branding anywhere, that’s a fabled NodePony!

When asked about the origins of the pony, the senior network admin refuses to say more than “no you can’t have a pony”, and clutches the equine plushie closer lest one of us attempt to spirit it away.

Well, you can’t have everything, but it turns out that sometimes you can have a pony. We’d like to give a shout out to our friends at Internode, they’re almost certainly our most hassle-free upstream network provider.

Better yet, NodePony has proven to be a very reliable member of the support team. He’s a gun when it comes to resolving tickets, and he only needs a very small barn to live in.

NodePony wearing a monocle
NodePony remains superlatively classy even while performing support duties.

Unfortunately you can’t call up and speak to NodePony, he’s only doing email support at the moment due to having a sore throat. He’s a little hoarse.

Are you in possession of a NodePony? We want you to work for us!
0
Comments

eCommerce Melbourne – WIN an iPad mini!

by

eCommerce-melbourne

Anchor’s Keiran Holloway, Jessica Field and Phillip Pace are heading down to Melbourne to attend the eCommerce Show. The event is being held at the Melbourne Convention and Exhibition Center on Wednesday and Thursday.

Our booth is no 6006. If you’re in the area, come down to say hi – and enter the draw to win an iPad mini! We hope to see you there.

0
Comments

Nagios checks for iSCSI targets with a blind initiator

by

We’ve recently found ourselves in the situation where we’re managing a highly-available storage service for a customer without actually having direct access to the data on the server. HA storage is commonplace for us now, but not having access to the data is unusual, particularly as a full-stack hosting provider.

The reason for this is that the server is presenting iSCSI targets, effectively networked block devices for the clients (“initiators” in iSCSI parlance). We don’t have access to the clients so we can’t find out what they’re doing. In short, there’s no easy access to the data, and it would probably be dangerous for us to try – we’d have to join their OCFS2 cluster to avoid corruption.

That doesn’t mean that we can’t monitor them though. As long as we give the monitoring node access to the iSCSI targets, we can access the LUNs. That’s enough to test reachability without escalating up the stack for deeper access; that’s the “blind” aspect of the check.

We’ve posted the code in a github repo in the hope that it might be useful to others. It’s pretty basic stuff, but it might be just the thing if you’re in a similar situation or aren’t getting enough love from more heavyweight checks that tend to use SNMP.

It’s important to note that this isn’t a standalone check, it’s part of a comprehensive monitoring and trending suite that we deploy. The servers providing the high-availability iSCSI targets are closely watched to ensure that we’re aware of any low-level issues, while this check provides assurance of correct behaviour at a higher level, as far as the handoff point to the clients.

0
Comments