I am a technical recruiter in Zurich. We have a tiny Rackspace dev team here and from what I've heard from the guys here Rackspace has a very reasonable recruiting strategy.
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.
I used to be jealous about Americans and such for being able to not to have to worry about US visas and get paid a lot. Then it occurred to me that I can just go to Switzerland or any other European country as I have a Euro passport. Then the jealousy went away! ;) Currently in the US on a student visa. Idea was to go the H1B route, but that way seems annoying.
- 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.
ETH has cranked out all kinds of good, practical research. They were also the birthplace, via Wirth et al, of safe and efficient languages for systems programming.
When they decided to make Zurich the Google tech-hub in Europe I can assure you that taxes were not the main driver.
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.
I wrote this article in 2014, but left Rackspace a year ago.
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?
I used STAR for interviewing at the US State Department. It's a very clear way to communicate and it prevents aimless rambling. It's a great way to get interviewees focused.
I suppose, but when required or expected, I tend to view it as an 80's relic (like the "behavioral" interview) that devolves into something resembling a beauty contest where you're graded on your "poise and confidence"--the style of your responses, in other words, instead of the substance.
Yes. And I tend to use it outside of interviews too.
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.
Yes this is pretty common in my area (finance in London). Especially in the HR interview which is sometimes called a competency interview. You will get questions of the format "tell me about a time when you persuaded your manager to do something", or "tell me about a time when you had a conflict with another team member."
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.
So interviewees are supposed to read "how to interview" books to know that they should generate a STAR format answer? What does this have to do with being able to do a job?
Don't worry, it's not unusual for recruiters to just forget about you, or trying to get travel expenses reimbursed for a couple months after the unsuccessful interview process. Given that interviews are free form and you didn't enter a contractual agreement beforehand, I'd just start looking elsewhere, while pinging them regularly as long as you're still looking. Heck, there are firms that return to you 12 months later, especially on Wall Street, so it's not that unusual.
The Rackers that I have contact with are generally terrible. Once in a while I get someone who really knows their stuff, but most of the time it takes me 3-4 'tries' to get an answer to my questions.
>> 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.
Ex-Racker here. There are different levels of support available. AFAIK, there exists a level of support where you talk to devops engineers directly, but I believe its kinda pricy.
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 Rackspace, you will probably get an entry-level person. That makes sense, since answering calls all day is an entry-level task. If necessary, the call will be escalated as high as it needs to go, to meet the need.
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.
My experience has been the exact opposite. We host many of our clients' systems on Rackspace, and Rackspace support is not only on top of things (we usually get a response to support tickets in ~30 minutes), but they're also extremely proactive and let us know of potential problems before they occur. I personally have never spoken to a technical person there who didn't know their stuff inside out (speaking as a technical person myself).
They have good systems, less-awesome people, at least some of the time.
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.
I interviewed there 5 years ago. It was a pleasant process and I was impressed with everyone that I met. My experience was consistent with the article, it was a 'no bullshit' interview, no Google-style zingers.
When I interviewed at Rackspace 3 years ago I had 8 interviews. Things have changed since then but I remember the process really being comprehensive for both culture fit, technical, and overall just who you are. I used to do interviews when I was in Support and this article is indeed accurate.
I interviewed for a non-customer-facing ops position at Rackspace UK in 2006 and one stage was them handing me a pack of coloured pencils and blank paper and telling me to draw what my idea of "fanatical support" looked like.
If you want a job at Rackspace, a huge proportion of your result, assuming you are ok competent, would be to completely embody FANATICAL SUPPORT, for whatever role you are doing, I don't care if it is technical or product or marketing or sales or legal or operations.
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).
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.
Not so sure how FANATICAL SUPPORT applies to "satisfy the needs of WHOEVER happens to be your customer". I have a client with a $2k a month hosting bill with Rackspace. Which is small for big companies or startup tech companies, but a lot for a small non-tech business.
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.
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.
The Infrastructure plans seriously limits support techs from helping. They wont be able to see running configs or logfiles. They can't login to your box at all you are feel around in the dark and playing ticket ping pong until you get the info you need to even make an educated guess as to the issue even then you cant test the fix.
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.
"We currently use a white board for most of the coding exercises. I am not satisfied with this because it penalizes different ways of thinking and communicating."
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.
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.
Then I'd posit that they're probably wasting their time unless they're VERY specific in the requirements they publish in their job ads. CS is too big for anybody to be an expert in everything. If you want a graph specialist, or a machine learning specialist, or a filesystem specialist, then sure, go really deep. But my feeling is that most of the time, these companies aren't hiring for highly specialized roles and there's no point probing "is this candidate at an advanced level on graph algorithms" when the answer might be "no, but she's an expert on optimization algorithms and numerical computing" instead.
Computer Science is a three year degree at least - you can't spend an hour talking about it?
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.
Computer Science is a three year degree at least - you can't spend an hour talking about it?
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.
I'd be OK with using BFS or DFS, but with this caveat:
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.
If you complain about CS requirements for software engineering jobs your complaints are going to fall on a lot of deaf ears because people desire competency. Dunning-Kruger is having its impact felt in these threads. If you think computer science fundamentals aren't a requisite for software engineering it's probably because you don't have the experience and skill necessary to understand what engineering competence looks like.
Mindcrime isn't saying CS isn't required, they're saying it doesn't require a full hour to judge whether they're competent or not
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.
I find it very difficult to imagine how an engineering position wont benefit from having strong CS fundamentals. If you write code you need to understand how the code you are writing works. How the libraries you depend on do what they do. If you run into problems you'll be need to able to think of solutions. This idea that you'll look up how to do some computer science algorithm when you need to is ignorant, because you may not know when you need it.
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.
You were replying to me, but I agree 100% with all of that, and it doesn't contradict anything I said, so I'm not sure what else to say. I guess I could just be more clear in saying that, for me personally, I'm not "complaining about hard computer science problems", I'm just thinking about how to optimize use of time. Personally, whether I'm the interviewer or the interviewee, I'm not partial to interview processes that take all day. That and I'm not partial to asking people to implement difficult algorithms on the whiteboard. My take is this:
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.
Dunning-Kruger is about competence, as in competence at the job you will be doing. Competence in CS does not translate into competence in software engineering. People who are employed to write REST APIs or most other software should not regularly write novel implementations of basic data structures like hash tables, it's an incredible code smell.
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.
Your comment would make sense if CS is all they talked about during the interview, but it's actually only a small portion of the total process--an hour or less.
A couple of questions - how many years out of college are you, and how many red-black trees have you actually had to implement from scratch in that time? Me, 20 and 0, respectively.
if you can take multiple people and pull them off their work for an entire day, while having meetings about the meetings you'll be having, there's not enough real work being done.
The interview consists of 4-5 panels of 2 interviewers. Each panel is generally 1 hour long.
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.
I interviewed at Rackspace a few years back on the ops engineering side. It was part of a bigger recruiting push they were doing across the metroplex area I live in.
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.
I had the same experience, and also a lowball offer about 4 years ago. I find these all day interviews to be very infantile and pointless. It's even more insulting imo when you're interviewing to work at what is basically a giant call center, which is what rackspace is at the end of the day.
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.
Not rackspace but I had something similar with Google. I interviewed with them for a software engineer position but failed. On the next day a recruiter contacted me for a google apps support position without coding involved based on something in their system.
A whole hour for "10:00 to 11:00: Background and context"? That sounds very inefficient. Interviewers need to be able to explain the context and background in about 5 minutes.
Rackspace seems to like to hire lovable losers. They claim they are exceedingly selective, but they never go into details about what traits they value. They seem to value people who are not as driven as others. Those that'll hang around for average wages. People who won't be bored and want something better. They frame this as being 'more selective than Princeton' but that can mean a lot of things. My friends coworkers were a bit lol. Everyone was likeable but they all seemed flawed personality-wise.
I like that you have a framework for conducting interviews. This all seems civil, sane and well thought out. This is refreshing. More companies should codify their process like this. Most of the time it just feels like companies are just winging it.
Can I ask what the focus of the San Francisco office of Rackspace is? I know its a large company.
Did they ever drop the "Strengths Finder" testing? It was the oddest part of my interview there - they found I'd not taken it before flying out and put the entire process on pause to have me take it, only to find the results were incompatible with the desired results for the position they were filling.
76 comments
[ 1.7 ms ] story [ 130 ms ] threadThe 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.
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?
>> 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.
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.
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.
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.
https://www.google.com/finance?q=rax
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.
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.
Can I ask what the focus of the San Francisco office of Rackspace is? I know its a large company.