Does your job challenge and motivate you? Does it utilize your skills? Or, are you ready to go job hunting? Do you want an awesome job that is a resume booster? Companies should be supportive of their employees finding a job that matches their skills and interests. Also, when hiring, companies should offer thoughtful processes for interviews.
Today, I’m talking to Sarah Withee, a polyglot software engineer, mentor, teacher, and robot tinkerer. Sarah went job hunting, and after several job interviews, she finally found a job that made her super happy at Arcadia Healthcare Solutions. Sarah compares the interview processes she experienced at big name tech companies that offer Cloud services.
Some of the highlights of the show include:
Companies sometimes lose sight that even interview interactions need to be a two-way sale
Interviews often involve talking to many people; and if several are bad, that forms a negative impression of the company
Companies need to provide interview training and follow the same standards
Don’t farm out challenging or unfamiliar issues when interviewing candidates
Sarah is very competent, but she is new to Cloud platforms; she is like a sponge, who enjoys learning and having a bare knowledge of new technology
How HIPAA regulations impact Sarah’s learning and software engineering work; she has to be more aware of security and safety of healthcare data
Being a teacher and mentor affects how Sarah learns new things; everybody learns slightly differently
In the Cloud space, know which direction you want to go and start with simpler things to learn the basics; focus on what is relevant to what you are working on
Full Episode Transcript:
Corey: Hello and welcome to Screaming in the Cloud. I'm Corey Quinn. Joining me this episode is Sarah Withee, who is a polyglot software engineer. She's a mentor, teacher and a robot tinkerer, sometimes all at the same time. You may have seen her on Twitter, having started the #speakerconfessions hashtag which was just a wonderful thing for those of us who get up on stage and, unfortunately, embarrass ourselves routinely. Welcome to the show, Sarah.
Somewhat recently, you posted a blog post that was wonderful, and I'll throw a link to it in the show-notes, but you talked about winding up at your current employer, Arcadia Healthcare Solutions, and you talked about the interview process and the interview process at other companies that either didn’t extend an offer or you chose not to pursue. What was it that inspired you to write that post?
Sarah: I was kind of at a place where I found I wasn't sort of mentally fulfilled, if you will, like the work wasn't challenging me, I didn't feel like I was using my skills and so I just started this job hunt. I started about July 2017 and I was kind of doing it behind the scenes while I was working and just told myself, "You know what? This time, I don't want yet another developer job. I want something awesome. I want a cool resume booster, a big-name tech company or something. I don't know."
But I also thought I have a network big enough now or I know enough people in random cities all over the place that maybe I could just go buy referrals from friends or something, or just general people I know. I started down that path and ended up at some really amazing places, like the more you think about it, I'm pretty proud of the fact that I've landed at on-site interviews at Google, Amazon and Square and different places like that.
But, I really, in the end, ended up telling my managers that I was job hunting, eventually, and it ended up one of these things where you're just like, "I have a job and they know I'm looking so there's no reason they're going to keep me." In fact, the opposite happened for me in that they said, "You know what? We want to support you because we want you to land somewhere where you fit better."
Corey: That's an incredible mode of support from an existing employer.
Sarah: It really was absolutely weird and absolutely awesome at the same time because the director of HR knew, and even he said, "We just want to be supportive of you," and I'm like, "That is really weird," but definitely really great. I started going public and mentioning on Twitter like I was going somewhere for a job interview, I was going here and there. But I decided that it wasn't smart to mention the companies.
One of the things, as I was going through these interviews, was like, "Wouldn't it be so cool if I just wrote this post," like, "Look at all cool places I've gone," but I never had any ending destination. I was just still interviewing and everything was going left and right into the trash can. It finally was when I had some really good interviews in a few places, and I'm like, "I really should talk about why Square had some really good interviews whereas I didn't feel like Amazon really did." Not just that, but in the end when I finally got to Arcadia, I'm just like, "This was a really good interview. I really enjoyed it."
You think of job interviews and you don't think, "Gee, golly, this is fun. I want to do some more." You really think, "They're stressful and they're daunting," and you're just like, "Do I have to do another one? Well, I don't have a job yet. I guess I do," and I really kind of wanted to talk about there are places that have more thoughtful processes and you don't feel like a giant, miserable pile of rejection at the end.
I kind of wanted to talk about that but also kind of brag like, "Hey, you know what? I finally found the job. I'm super happy." That's sort of how the blog post came together. It was sort of this, "I kind of want to brag about these places but I don't want to just brag; I really want to say there's some good that can come out it, that you or your company can maybe take some of these ideas and take them to heart as you go into looking for candidates and talking with them."
Corey: One of the things that dropped that blog post onto my radar was that there was a giant list of companies you spoke with, but four of them are very relevant to what I do. You interviewed with Amazon, Google, Microsoft and IBM, all of whom are very large public cloud providers in one form or another. I was wondering if you could compare and contrast how those four companies went about the interview process and how it felt, respectively, between those different companies.
Sarah: I call them, in capital letters, "Big Name Tech Companies" and the trademarks signed after them. It was kind of interesting because they all have, in some ways, really similar processes but, in some ways, very different. A recruiter came after me for Google and I just kind of decided, "Let's try it. I don't have the foggiest idea how far I'll get into it." I kind of did a little research and they hire for the type of position. I wanted to be a software engineer so they hired, generically, for a software engineer position but I knew ultimately if I made it that far, they would put me on the site reliability engineering team. From there, they just asked questions generally for software engineers and if I didn't make it through then, then I wouldn't get any software engineer position anywhere.
Amazon was kind of different in that I had an initial recruiter interview and once I got past them and they thought I would be a good fit for Amazon in general, then teams started to come after me and I would interview with the specific team and then you either get a yay or nay. Then, if I got a nay, then I would still be possibly considered for other teams, which is kind of interesting because I ended up talking to about four different teams with them before I finally got far enough that I just didn't end up taking it or didn't end up getting the job.
IBM–I don't know if this is typically how they do similar stuff, but I interviewed specifically with a team so the people I talked to were on that team and kind of that way from the beginning. There wasn't any sort of doors I had to go through in the beginning before I got in there, like I just talked with the recruiter on the team and then a manager on a team and so on. Microsoft was kind of similar to Amazon in the sense that you had to get your foot in the door first and then, after that, you're interviewed among different teams.
In Microsoft, the recruiter I talked to specifically said, "Once you're in the door, we want to find the perfect team for you." It was kind of an interesting twist, sometimes. Microsoft was the one I had my foot in the door the longest in that they were one of the first companies I talked to. I talked to three or four different teams, I think, with them and, still, I had a little bit of contact with the recruiter. I probably need to email her and tell her I finally got a job.
Corey: She might have read about that on the Internet already.
Sarah: Possibly. She did mention that she did some research on me and knew I'd written some good blog posts. In some ways, they were all kind of the same and it felt like 12,000 interviews but, in some ways, it was also kind of interesting that, depending on the company and the process, I could still flop an interview and still be in the running, if you will.
Corey: As a follow-up to that, did you find that your discussions with these companies change your likelihood, in one direction or the other, of picking any of them for a project in the future? For example, one of them is such a good experience that you would definitely stand behind and give it a shout-out or a try to anything that they put out, and were other places so off-putting that you'd have a hard time even bringing yourself to look at their logo again?
Sarah: I think, for me, a lot of people probably want to hear me say, "This interview is terrible. I'm not ever going to work for or use a product of that company," and I don't think that's true.
Corey: That's unfortunate. Mud-slinging always brings eyeballs and ear balls.
Sarah: I'll do that on the next episode. I think, in general, I can look at it as in a lot of people are involved in a product and one team doesn't necessarily trash an entire product, like one team can be terrible but they don't dictate an entire company. Especially with the big-name tech companies, it's so dependent on each team. They're almost their own independent unit. Their culture is different and their work is different. They're not the same as every other team.
In terms of Google and Amazon or IBM, I probably wouldn't choose or not choose their cloud products or any product they do based on my interviews. I probably wouldn't. Microsoft, on the other hand, their interview that I had was actually pretty good with one of the teams. It was probably one of my top three interviews, which is kind of interesting. I probably would almost say I would want to go back and maybe they use their products more because of that.
Corey: It seems to me that companies often lose sight of the idea that every interaction someone has with them and, especially as an interview candidate, it needs to be a two-way sale. They want even people they don't extend the offers to, to leave the conversation, thinking, "Wow, that was such a good experience that I'll try it again later, go for a different role or recommend them to my friends," and other companies just seem to miss that context entirely.
Some companies tend to miss that point entirely and approach it from a perspective of, "We are a brand named Tech Company. You are a nobody," and that just leaves such a bitter taste in people's mouths that it becomes almost an aversion to anything that company touches in the future. I think that large companies are getting away from that and coming to a realization that it's always a PR exercise. I mean, you wrote a blog post about this. If you had been profoundly mistreated by a company, I imagine that is a story you would have told, no?
Sarah: Yes, there were definitely some interviews I went in and I was absolutely exhausted at the end, and then there were some I went in and, like, "Well, it's been an all-day interview but you know what? That wasn't terrible. It was kind of fine." I think the other thing they don't think about is when you get to the big-name tech companies, you have so many rounds of interviews. You talk to so many people.
I probably talked in Google to six people in one day, at Amazon, probably 10. I think Square had another seven or eight I talked to. It's not just one person; you're talking to so many people. If one of those is bad, you can maybe shrug it off but if several of those are bad, that's definitely kind of an impression you can make on the company itself. I've also found there were some interviews–I won't name companies for this one–but I would go into one interview and they would be like, "Wow, Sarah, you're really great. You know what you're doing. You're smart. You tackled that problem great. We definitely need to have you. Let's move beyond the next round."
The same company talked to somebody else and like, "You clearly don't have the foggiest idea of what you're doing. Have you ever touched code in your life?" I can't imagine that they're not training or interviewing people correctly. They're not holding the same standards for each level of interview, things like that, because I don't think somebody with an amount of experience like I do, for instance, shouldn't have, "Absolutely amazing, 10 out of 10 stars, we need to hire you as soon as possible," and, "1 out of 10 stars. You're terrible. Why did you even try and get here?" There's no balance there. I feel like it's just thrown up in the air, popcorn-style and just like, "You know what? We'll grade you however we feel like grading you."
Corey: "You've been a software engineer for 15 years at companies everyone's heard of. Let's double-check that you know how to write a four-loop on a whiteboard," has never struck me as a high-signal means of interviewing. There are people who would vehemently dispute that. I think that you're right; companies need to focus on having a process for this that can remain consistent over time.
Sarah: There's been some like, "Hey, let's go overwrite this thing that detects if you have two letters in the string that are matched together." That's a fairly simplistic problem but then also have something like, "Let's build some really deep program that solves some really super quirky challenge that would really run into the six-power time, but you can't run it like that. The way we would do it at big-name tech company is simpler." Those are drastically different levels of challenges.
Corey: The one I've always been partial to is you have such a highly-specific problem in an interview that you want to ask, "If I step outside and over to your engineering area, am I going to see them trying to solve this exact problem right now?" almost farming out your work to interview candidates.
Sarah: Yes, and Google is an interesting thing. I got to have lunch with somebody and I got to free-for-all ask and whatever I wanted and didn't have it counted against me. One of the things I asked him was like, "How long does your onboarding take, like if you hired me tomorrow, how long would it take until I was familiar enough that I was running on my own?" He was like, "Months, and months, and months." It's like the questions they ask don't even click in any way with the work they do.
I feel like, in some ways, "Your interview should be a good test of your skills, where you're at, at this moment, and whiteboard interviews don't do that. Word interviews are a lot like cram as much material as you can in your head and be able to regurgitate it on a whiteboard," and I'm like, "I don't ever code like that, ever. Why am I not in front of a computer with an IDE, working with in my natural environment because I think you would see I'm pretty good when you put me in my natural environment? When you take me into a weird space where I'm not doing anything like I normally do, there's no way I could possibly do as good as I normally could."
Corey: I can't speak for your workflow, anyway, but my preferred IDE is generally a whiteboard in front of a room full of very condescending people.
Sarah: How about a Google document?
Corey: But I repeat myself, exactly. Something that you posted on your online resume jumped out at me as fascinating, specifically that you're currently focusing on learning both AWS and Azure. The reason that that's interesting to me is that most people I sit down with and chat about technology for this podcast tend to be fairly steeped in cloud technology. You're an outlier in that you have an established set of technical credentials. You're obviously very competent but you're new to these platforms. What's it like coming from a software development background into a world where there's so much foundational knowledge that went into these things and history dating back 15 years that explains why these things are the way that they are. What's it like drinking from that fire hose?
Sarah: I think you just described tech in general. I don't think we can ever be up-to-date on everything all the time, like we can only pick and choose a certain amount of things to be really, really, really experts in but that constantly changes. I grew up learning to program on a Commodore 64 and you know things have changed over time, and I've kept up with computers that have evolved and nobody uses Commodore 64 Basic anymore.
I found, in my normal jobs, I wasn't getting all of the cool and trendy buzzwords anymore, and as somebody who's just loved programming in general, I just always thought it was cool and fun. For me, I just love being a sponge. I kind of love learning new things and even if I don't end up ever using it for good, I just like that basic knowledge of, "You know what? I've at least played with this for a week," or something.
AWS and Azure came out of different reasons I wanted to start learning them, and then the reasons went away for a while and you didn't actually use them anymore, but they're still an interesting way. I used to have set up a physical server and install Linux and install all these software things on it, and then it changed where we can just have a virtual server, still kind of the same process. I still didn't install software on it but I didn't need the machine anymore, and now we're kind of in this place like, "Well, you know, you can just run off a little virtual instance of just the tiny little thing that you need, so I suggest a web server instead of a whole system."
I just changed and evolved, and I think it helps me as a developer know I may not use these cloud services in my day-to-day life at the moment but, one, I might likely do that in the near future, which as it turns out, I'm going to need some of this for my new job I got but, two, it just helps me know the direction things are going and I can at least be aware enough of them that I can adapt how I do things, how I program and how I learn other things.
AWS came along because I got it free. I think you could use it for a year and I was just curious about it, but I was working with the Code for America Project, and they're just like, "This needs to deploy on AWS. It's just the way it was written," so I started playing with it with that but then found out, "Well, you know, I could use some of this for maybe like an inside project or something," so I started leaning into, "How does this all work and what in the heck is an EC-2? I don’t' know."
I learned from that and it was after one of my Microsoft interviews, and it was for a cloud developer advocate position, and they're just like, "We think you would be great for this position, but you just don't quite have the cloud knowledge that we need," and they sort of dropped hints like, "If you could pick this up, we would definitely reconsider you." I had this thought, "Yes, I will learn all the things Azure," and I think that lasted three weeks.
Corey: Not going anywhere for awhile? Grab a Snickers.
Sarah: Yes. It turns out it's kind of exhausting when you're working and trying to find a new job and trying to learn an entire huge ecosystem of cloud things at the same time. That's kind of exhausting so I didn't end up getting super terribly far on that but enough on both that I've spun up several instances and several different products. I've thrown up sample projects. I've tinkered with them.
I've done things like that. If I wasn't careful, they would probably start billing me because I've used enough of the trial things, things like that. I would not call myself an expert on any of these things but I definitely feel like just having the bar knowledge has helped me out a lot in terms of talking to other people and seeing other projects and how they work and being a better developer in general. We're a technical company in the healthcare space.
Corey: But you're still subject to HIPAA regulation, correct? How does that change how you view your work both in the learning the new platform space as well as how you approach your software engineering work? Often, from the infrastructure side, "We're HIPAA-regulated which means the things we use are normal cloud services but more depressing."
Sarah: I like the dry wit you have.
Corey: Well, thank you.
Sarah: I worked at a bank once so there was definitely some concern about customer information or whatever, but I didn't end up on a team where that data was really passed by me. I usually ended up on these other little side-things that I never really dealt with customer data. This would be the first time where my product I worked on will actually literally take this data and funnel it into other places, like I'm not really messing with the data but it definitely does cross my path, if you will, or my team's path.
It's definitely an interesting thing that I now have to be a lot more conscious of the security and the safety of the data, and there is something about the cloud as sort of this magical world where something happens behind the scenes and I don't totally know what it is. I know I have to learn a little bit how that works and just be more conscious of the healthcare data that we have. I don't know if this is totally answering the question or not.
Corey: No, it certainly is. It's nice in some ways and challenging in others to work for a company where the data that you work with, the problems that you're solving, have actual import for people. It's quite different to work for some trendy startup where the entire business problem you solve is making it faster to get milk bones to your dog when the dog paws at a lever somewhere. Just by saying that, I'm sure that someone somewhere just raised an $8 million-seed round for that exact thing.
Sarah: Hashtag, #businessidea.
Corey: Exactly. It's quite different when there's a real business and there are consequences tied to that. Let's ask something slightly different: Do you find that having a background of yourself, as a teacher and a mentor to other people who are learning new things, changes how you go about learning new technologies?
Sarah: Yes. When I was in my university, I ended up teaching some C++ labs and then eventually ended up teaching one of the lecture classes because one of the adjuncts dropped out at the last minute and they were just like, "Sarah, you can do this. Why don't you come teach this class?" so I sort of got thrown into it.
Corey: "Here, catch! You've been voluntold."
Sarah: Exactly. It was good. It was kind of awesome to say I was the only undergrad that taught an undergrad class. Through that, one of the things I learned is that you kind of expect you can just throw a book at people like, "I'm here to learn. Go." Everybody learns slightly differently. I partly found that of some of the learning styles, there's definitely a visual one where seeing pictures, seeing examples, seeing things like that resonate with people or if there's the auditory way so hearing people explain things. Visual may not work for you but just hearing people talk about it and hearing people explain things in words is a lot more helpful.
Then, there's the kinesthetic which is where you can see all the examples and stuff but it really doesn't soak in; you actually just have to sit down and play with it. People can also have little combinations of both. I think I'm more visual and kinesthetic. If I just listen to audio alone, it just doesn't go anywhere. As I've tried to teach people things in workshops and classes and stuff that I've done, I've tried to make sure there's at least a little bit of each of those partly, one, to keep the interesting going but probably, two, so that they actually do learn something when they're done with whatever I'm showing them.
I think for learning these new things, there's all sorts of resources out in the world now. There's videos, there's books, there's little short tutorial things. Sometimes, the products themselves have little tutorials in them, too. I think it's better when we do have all of those because I think that, sometimes, cloud things aren't easy to pick up. I found this out because I've tried both with AWS and Azure to just go in and be like, "I'm smart. I'll figure this out," and just leave going, "I don't have a clue what these things are."
Corey: Yeah. When I first started with AWS myself, I pulled up the console and, "Oh, my stars! What are all of these surfaces? I'm never going to learn all these," and there were 12. Now, there's 120 of them. "Let's the read the fine print. Oh my god, that's not fine print," and I can't imagine coming to it as someone new to this today. Do you have any pearls of wisdom around how someone who's new to this space and getting overwhelmed by what they see could think about, how to approach learning, even where to learn, where to start? That's a difficult challenge for people who are trying to find their way through a very confusing forest.
Sarah: It kind of helps if you have a direction you want to go. For me, I knew, eventually, like, one, I would have this website thing I wanted to do. For another, I had this idea for an IoT kind of thing I wanted to build. I knew for those like, eventually, I would probably need to use like UFESCO and Azure—I'd need to use the IoT hub. It turns out that you need to do service queues so I'd have to learn that, and then if I took it up to Raspberry Pi, there's a Raspberry Pi edition at Windows that I have to install, and that has to connect to Azure.
I know there's these pieces but, obviously, those would be really difficult to probably start on. If I could start off with something simple like, "How do I take a super Barebones website and just throw it up on AWS, Azure, Google cloud?" things like that. If I could start with the simpler things and learn the basics of those, just how do I spin up an instance, how do I upload things onto it, do I use GID, do I use FTP, do I use whatever, those kind of help the whole thing make more sense because they're not, like we just said, are not easy to use right off the bat. AWS, I think, was just overwhelmed at terminology and all the abbreviations. "What in the heck is an EC-2 or an S3 or a bubble?"
Corey: If you ever want to destroy Amazon as a company, all you have to do is give them a puppy and tell them it's their responsibility to name it. That will paralyze them for six months.
Sarah: I love that. As I jumped into Azure, "All this stuff makes sense," but as I started to configure things, like, "I don't have the idea what a resource group this, and is this important or is this just a name?" and some of these things had to be unique to me and some of them had to be unique to the world, like, "How do I come up with a name that nobody else in the entire planet has used before? That's fun, or something."
Once I found the basic tutorials of Barebones website, launch it, get some code on it, get pleasure or whatever, the whole thing made a lot more sense because a lot of the conversation's fairly standard throughout the entire product but just overwhelming at first. If you can get over the first big hurdle, everything else makes heck of a lot of sense. I think all the IoT stuff I was trying to learn with Azure, I could dive in and almost not need tutorials anymore once I knew the basics of how do I spin up a database, how do I spin up a web service, all these things. I mean, I still did need the tutorial but I was skimming a lot more than reading where, in the beginning, I was just like, "I don't know what I'm doing. Where's my teddy bear?"
Corey: Yeah, there's always been a fun trick that I've been able to play on people, which is I will make up an AWS service and some fictitious thing that it does, and people would not question me on it. The tipping point came when I'm now able to do that to AWS employees. It's too broad and vast. One of the tips that I like to give people is, "Just focus on the things that are directly relevant to what you're working on and don't worry about the rest. You'll get there when the time comes." Some services go incredibly deep, and are vast, and will take weeks. Others, you can pick up in a couple of hours because it doesn't matter all that much.
Sarah: I mean, the idea of the cloud is that it's worldwide; it's kind of this magical, infinite size of power, and space, and all these things. You almost can't make that simple. You just can't do it. Configuration is complex and the numbers of different service points you have is complex. Definitely like you said, you have to kind of start super simple and once you can get over that bare minimum, then the rest will make a lot more sense and you can slowly pick those up better. But I definitely don't recommend doing what I did and sort of diving into multiple clouds at the same time. The benefit is I learned they're all just as complex as the other one, but then everything starts to blend together so I would recommend learning one at a time.
Corey: No, I think you're right. There's no silver bullet when it comes to these things, and even with the providers competing with each other and learning from the stumbles of others, I don't think that there's a clear-track, silver-bullet answer. There's no, "Just learn DCP, or Azure, or Oracle Cloud and all these problems go away." There's complexity all the way down in all of these things. One of the more important things I like to touch on from time to time is that if you're feeling overwhelmed by the cloud, it's not your fault. This is something that all of us feel constantly.
Sarah: Definitely, and the other thing is to say one is better than the other, I think, at this point is moot because, like, "AWS is better." Well, you remember last year when their service went down and then nobody knew because their status service is also ran on AWS? Then, like, "Well, Google's better." Well, anytime anything Google goes down, people are just like, "Oh my god, I don't know what to do with my life. I can't work," and it's like they all have their problems and they're all going to go down at some point; there's no perfect reliability ever.
Corey: Everything is terrible.
Sarah: Everything is terrible.
Corey: Thank you so much for taking time to chat with me a bit about your experience. Where can people find you?
Sarah: I pretty much live on the Internet. Almost everywhere is GeekyGirlSarah, so Twitter, Facebook, LinkedIn, Digster, et cetera. www.geekygirlsarah.com is my blog, and you can check that out. I don't feel like I ever write anything of super use but, apparently, every so often I have something that comes along that's kind of awesome like I got a new job post that I just wrote that apparently is helpful. I love connecting with people. I am not just one of those people that tweets a whole bunch of things; I like asking questions and engaging with people so definitely come find me, send me a tweet and I'll definitely get back to you.
Corey: And I'll throw the links to all those things in the show notes. Thank you all for listening and thank you for coming, Sarah.
Sarah: Thank you very much.
Corey: My name is Corey Quinn. This is Screaming in the Cloud.