Rackspace Interview Process
journal.paul.querna.org
journal.paul.querna.org
It involved a similar schedule of interviews across multiple teams in one day. Only 11 people apparently passed the tech pre-screening to get to that point out of the whole area. Interview process went great. It included a number of different fields at varying depths, yet didn't feel over the top at all. It was a very fair and positive experience. There seemed to be real interest from several of the interview teams.
Then the offer came. They wanted me to relocate for a swing shift chat support position at half my current pay even after shift bonuses. I don't know how you go from discussing Openstack production implementations (back in the Essex/Folsom days when you couldn't find anyone that knew that stuff) to basic Linux chat support.
After going through several screens, I was asked to take an entry-level ops position, in a completely different metro at a lower pay, while I was applying for a senior applications role.
My primary reason for applying was the location and type of role, so I declined. But I've never felt so disrespected by a companies hiring practices like that.
>> Culture, not just code
Rackspace appears to employ a lot of non-technical people that have been placed in technical roles. They don't understand the why's. Maybe their goals are to be able to train anyone and they don't want people being creative etc. I know a handful of people that work there that I would have never suspected they would work at Rackspace doing web or server support.
>> Flexible for multiple roles
This bugs me. Mediocre employees shuffling around from position to position. I would suspect the amount of people that can perform 'very good' at a number of jobs inside Rackspace is pretty low. Or any other company, for that matter.
>> Trained
Most of the Rackers at the first and second support tiers are not much more than script-readers it seems.
The word you wanted there is "reeks."
In general, I think you get what you paid for: most customers don't want to pay a lot for support.
Its true that Rackspace does employ a lot of non-technical people and train them. I actually really like how they do this: I've worked with many people who moved from support to developers, and they are not only top-notch, but understand the pain points of customer-service and help make the offerings very user and support friendly.
When you call AWS, Digital Ocean, or Linode... just kidding, you can't call them, at least not without paying at least as much as Rackspace.
They suffered the same issues a lot of companies that grew quickly had: their sales outstripped their ability to hire and retain the same level of talent that made them great to begin with.
The take-home assignment is a set of tasks that the candidate can choose from, which I believe is a smarter way to gauge tech-talent than giving an arbitrary algorithmic coding task and forcing the candidate to solve it on the spot like Google / Facebook does.
- The biggest Google software engineering office outside California (around 2000 employees).
- Logitec, Microsoft, IBM, Cisco
- ETH university
- Many ETH-spinoff/startups: Doodle, Bitspin (bought by Google), Teralytics, Archilogic, Fashwell, Getyourguide, Numbrs and I surely forgot many others.
It is a great place to live and is the only place where net-salaries are on par with New York / SF. Salaries are in the range of 7000 - 10.000 CHF / month after taxes. However apartments can be way cheaper than in San Francisco. You find more on Zurich from me here: https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-t...
Also, if you have a EU-passport, you can find my email address in my HN-handle.
Makes sense, Switzerland is a major tax haven.
One of the big guys at Google at that time studied at ETH and therefore knew the place is full of talent. Also, the Zurich is more or less in the geographic center of Europe. So is Munich, Germany, but would a French or Italian programming prodigy move to Germany? Maybe, but maybe not. The probability of different people to move to (neutral) Switzerland is higher so it is a natural place to attract talent from all over Europe.
11:00 to 12:00: Computer Science and Algorithms
Do you really need a full hour to tell if somebody has a good basic grasp of CS and algorithms? I can't see it. At least not in the best case. The way I'd suggest doing it is this: Ask a question that can result in a "1 question yes". That is, pick a sufficiently advanced / interesting algorithm, and ask questions about it, and/or ask the candidate to implement it. If they pass on that, move on from CS/algorithms to something else. If not, move to the 2nd choice algorithm, and repeat. Do that for a few iterations. This way you only fill a full hour if the candidate forces you to dig really deep into your list of topics.
The same methodology could be applied to the other domains as well.
> has a good basic grasp of CS and algorithms?
Maybe they want to see if someone has more than a "good basic grasp".
Even implementing something simple and well known (like a breadth first search for example) on the white board can take an hour, if you are discussing it as you go along, and the algorithm has to be tailored and optimized to fit the interviewer's question.
Sure, you could spend all day or all week talking about it. But the question is, do you need to, and is it a useful thing to do in a job interview setting. But I'm biased here, because I'm generally not a fan of day long job interviews. I don't think they're necessary or practical, at least for most roles.
If it's a whiteboard thing, then don't expect a detailed, working implementation in code. Ask for a sketch / high level overview / pseudo-code that shows the candidate understand it well enough that you can infer that they could implement it with a compiler / google / book / etc.
OR
If you want an implementation, give them a machine, let them use their language of choice, use google, etc., and let them actually code it up, making and fixing errors as they go, etc. I actually like this because it lets you see how someone approaches debugging, etc.
In either case, you could supplement the exercise with some discussion questions "why /when would you use BFS?" etc.
Yes, exactly.
That said, I should add the disclaimer that I'm referring to fairly general roles. If you're genuinely hiring for a highly specialized role that requires more specific knowledge, then that might change the equation a bit. I should have been more explicit about that earlier.
A lot of the CS fundamentals in interview questions demonstrate an ability for problem solving and abstract thinking. It demonstrates your ability to handle coding problems under stress. Resorting to complaining about hard computer science problems is the exact opposite response you should have. It should motivate you to improve and learn more, not feel bitter and angry. Likely this attitude indicates a poor culture fit as well. So in effect asking computer science question is doubly useful, because it helps filter out candidates who opt for alternatives to self-improvement and overcoming challenges.
1. If you're doing whiteboard stuff, keep it high level, see if the conceptual understanding is there, and move on.
OR
2. Give the candidate a computer, editor / IDE, compiler, google, etc., and let them work they way they work, implementing $WHATEVER.
Thinking that CS makes you competent as a software engineer and that you will regularly be implementing red-black trees is a typical fresh-out-of-college mistake.
Does anyone have any real world experience using these kind of techniques?
Context: hired 15 people in the last year.
Would you take his word when he said he felt that his approach had been quite effective?
Hiring 15 people doesn't mean that your hiring process is effective.
The STAR answering format is the single clearest thing I'll take with me as a good interview practice.
It keeps both the interviewer and interviewee honest and on track. I find it helps figure out what a person actually did: Yes, a whole team shipped X, but what was your role in it? Tech Lead? What did that mean there? Responsibilities and how did that turn out?
It feels like a good way to communicate the context of something and my intent. Those things open up more avenues of discussion. But it could be annoying if you're trying to reach a conclusion on something instead.
When I'm interviewing, I expect candidates to answer in a STAR-style. If I ask something like "Do you use TDD?" I absolutely expect more than "Yes". I want to know how you used it, what worked well/badly. How did it affect your code? Give me an example. How did it affect your company? Less bugs? Faster or slower development? More fun? More arguments?
More broadly it feels a bit like you're demonstrating the PDCA/PDSA/OODA cycle.
The interviewer generally expects a STAR format answer to these questions. Typically the candidate would come with two or three good stories in mind, and be able to tailor them to the particular question - many good workplace "war stories" would fit one or more of these sorts of questions if you emphasize different aspects.
I would ask each part of STAR, directly to the candidate.
The goal is to actually understand what the candidate did, less what "we" did.
- Tell me about a time there was a production outage?
- What was your role in the team? Were you on call?
- [ questions about what happened ]
- How was it fixed? What was your part in this?
- What did your team change afterwards?
- How do you think about production outages now based on this one?
Basically, what it means is that you will do WHATEVER IT TAKES to satisfy the needs of WHOEVER happens to be your customer. Most times "your customer" is a real customer, but you also have internal "customers" (for example, the legal team's customers are mostly internal).
Look at this page and internalize it.
https://www.rackspace.com/talent/culture/
A lot of the "culture" component tends to also be kind of cheesy, but I think that it is a sub-thread of Rackspace that is not necessarily part of the culture but perpetuated by HR. I have been told that during their "onboarding week" (yeah, it can take 3 days for the onboarding), people are encouraged to be silly and wear silly hats. Not everybody is up for that, but many are.
So for you, being in an ops position, be able to know what that is. They are not asking you to draw a Picasso. They are gauging whether you know what FANATICAL SUPPORT means for your role and whether you have even thought about it.
There have been occasions where we've received FANATICAL SUPPORT from individual techs, but mostly we're stonewalled by being on an infrastructure plan that doesn't allow for their FANATICAL SUPPORT it appears.
https://support.rackspace.com/how-to/cloud-servers-with-mana...
Speaking as an ex-Racker, yeah, if your infrastructure isn't listed on that page and you have something like Tomcat running or Cassandra, or Headless VirtualBox an dedicated box, it was best effort. If you want externalized customized support for that client outside the standard tech stack supported by Rackspace, you need to bring in an external MSP, consultancy, or FTE willing to take on your tech stack and provide an SLA, and pay for it.
Take it to the next level: do people come to you to get their Kool-Aid, or do you take it to them? If you take it to them, then that is more fanatical.
No, thanks.
Can I ask what the focus of the San Francisco office of Rackspace is? I know its a large company.
i guess they are top tier enough to be worth the effort
I'm already out. The kafkaesque bureaucracy must be epic. I suspected it the moment I read "Mailgun team (level II or III)." This stratification metric means the owners lost control of the organization. When you no longer have the capability to assess and judge your individual employees (nor trust your management to judge) at any level, let's at least give them some increasingly narrow vector title so we know who is more competent than someone else in a pinch. Because our concern is not looking foolish, so we rely more on the people who get paid more in a vicious cycle of incompetence.
So ask the interviewee to bring in a laptop (since he'll already have everything set up the way he's used to). Or buy one for this specific purpose. The answer is so simple. Instead they choose to complain about it. Any other solution is wrong. And while you're at it, shut the fuck up while your interviewer is working on your stupid problems. That will go a really long way.
Then again, a place that hires someone who can't see this obvious solution is not a place I want to work at.