My Recent Technical Interview Experience

I switched software engineering jobs earlier this year, mostly because I felt I wasn't growing enough at my previous company. It was very stressful, but I'm happy with how it turned out. Here are some assorted observations on the process of interviewing at different companies, written in haste right afterward and edited briefly some months later.

Recruiting Companies

I mostly went through two different recruiting companies for my search, TripleByte and Refdash.

TripleByte

Triplebyte was a great experience overall, in that they were respectful and kind, and got me onsite at a ton of companies very rapidly. And I do think they correctly optimized for interview/offer ratio in my case: I got offers from every company I had an onsite with through TripleByte.

The main downside was that I also wanted to filter for companies that paid a bunch more money, and they didn't do a very good job of filtering for that on top of the interview type. I would have preferred to do more interview prep on whiteboarding and algorithms and then interview at those companies, rather than only ending up with offers from companies not in the pay range I was looking for.

My Triplebyte recruiter lowballed me on salary - they suggested, if I were to mention a salary range, it should be $135k-150k. I didn't mention a range, and the company offered me $165k base. This was still lower than I was hoping, but substantially higher than the range the recruiter suggested. Also, I worked at a BigCo, and any of the TripleByte offers would have been a 50% pay cut or more for me. Obviously this wasn't malicious on their part, but I feel it reflects a lack of an accurate sense of the market for engineers at larger companies. Or maybe they simply don't have or didn't think I was qualified for higher-paying jobs. Regardless, I did not end up taking any offers from the companies I interviewed with through TripleByte.

Scheduling interviews and phone calls with TripleByte was a breeze. Their web app is extremely slick. No back-and-forth emails about "Well, Wednesday doesn't work for me, how about Thursday?" It removed a lot of stress from the process for me.

Refdash

Overall, Refdash was... okay. I did end up taking an offer through them.

They're still starting out, and it seems that many companies don't yet trust them with their phone interviews (unlike TripleByte, which is more established). So I ended up having to do several phone interviews in addition to Refdash. That was a huge pain. Doing phone interviews while still employed is particularly hellish; do I line several up and take the day off? Do I work from home and do one and then work extra time later in the day? Either way sucks, and I had limited ability to do either.

I failed the phone interview at Lyft, through Refdash. I feel that it was a rather silly puzzle/algorithm problem, and I didn't get the "aha" moment I was supposed to in a short enough time.

I did two phone interviews with another company via Refdash. I think I did well on both technically, but they rejected me after the second one. In the second one I asked them a question that, while more tactfully phrased, basically boiled down to "are you personally comfortable with the fact that your business model is evil?" and I suspect the rejection was due to, uhh, 'culture fit'.

I got the sense that my Refdash interviewer didn't respect me, so it was hard for me to work with him. Refdash kept suggesting that I do more interviews to "practice," and I couldn't help but think they didn't think I was a competent engineer. It's true I didn't do well on my second phone interview with them. It seemed like the interviewer was predisposed to think I wasn't doing well, in a way that made me feel anxious and do worse. He came off as very condescending both on the end of that call and on our later call. I don't want to speculate too much as to why, but it does make me a little suspicious that my husband didn't have this problem with them at all (he went through a job search with Refdash shortly before I did).

Scheduling phone interviews and recruiter calls with Refdash was a huge pain compared to TripleByte. This experience has taught me just how much I hate scheduling stuff over email: TREMENDOUSLY. I also really hate phone calls, especially with recruiters and other people I can't communicate with well. In a high-pressure situation, it's much easier for me to talk to other engineers, people who I know speak my language. TripleByte minimized the amount I had to do this, which I loved.

I feel bad that I didn't follow up with some of the companies Refdash connected me with. This job search caused me a tremendous amount of stress (I was hardly eating the whole week I was doing interviews), and I think it was reasonable for me to cut that off after a certain point. The Refdash companies seemed to be better-paying, though, so I wish I'd been able to endure the unpleasantness of interacting with the Refdash interviewers and doing extra phone interviews and calls.

On the plus side, Refdash did not lowball me on salary and gave me incredibly useful assistance with negotiation that resulted in my final job offer increasing by over 20%. Which I accepted. So I can't complain too much.

The Interview Experience

I took a whole week off to do five onsite interviews in a row. TripleByte made this pretty easy; 3/5 were through them, and the rest I managed to schedule quickly. This was a great decision. I had rehearsed various spiels and had all the relevant information in my head, and so there was a lot less context switching than there would have been if I'd been working in between.

I was surprised at how many companies asked me to write code on a laptop, "pair programming" style, or just do design interviews, with no standard algorithms-type whiteboarding. I suspect this is because Triplebyte slotted me into companies that do that type of interview.

Pair programming interviews were generally quite easy for me. Being able to actually run code and debug in an interview is amazing, and I wish more places allowed me to do it. Of course, "pair programming" in an interview generally means "they watch you write code and talk to you about it," rather than an actual collaboration, but it's still better than whiteboarding.

I did the Cracking the Coding Interview project grid to prepare: various behavioral question prompts for each project on your resume. As before, this was extremely helpful when I had to answer questions about my resume and previous projects.

My last onsite involved a lot of whiteboarding. I was surprised, since the recruiter told me to bring a laptop. By this time, though, I was so used to writing code under pressure that I think I did quite well. (I'll find out what my interviewers thought tomorrow. I got and accepted an offer from this company!)

I have a lot of trouble forcing myself to actually prepare for interviews, and still haven't figured out exactly why this is. Perhaps because I haven't done it in the past and so my System 1 thinks it's unnecessary. "Actually prepare" here means: 1) do problems on Leetcode or similar, 2) study basic Computer Science. I'm a fast learner, and I've picked up enough of (2) by now to do okay on that portion of interviews. But I don't enjoy the sort of "aha" "puzzle" problems that are still common at many companies, and so I don't like doing them to practice either.

What I learned about software companies

I do feel that this job search has given me a better sense of the market and what to look for, as well as good practice talking about what I've been doing at my current employer and so on. Even if I don't end up moving right now, I think I will in the future, and this is good practice. (I did end up switching employers.)

It shouldn't be surprising, but I was still surprised by how little the companies I interviewed with seem to adhere to good engineering practices. It seems there is a lot of low hanging fruit there. In particular it seems like no one knows how the hell to do SRE, which is hilarious coming from someone with as little experience as me. Most places seem to do universal-ish code reviews these days, which is nice. (Not all though!)

Everyone who is hiring will always say "yes, we have ton of code to write! I wish we had the problem of being over-resourced!" That's what my last employer said when I joined. They were wrong. Well - they weren't right for long, at least. Figuring out what to do next seems to always be a bottleneck on development, far more than the actual writing of the code and making of the thing to go. So it's a valuable skill, one that I'm still working on developing.

Asking good questions is tough, but I got better at it over time.

• "How has this place changed since you joined?" didn't seem to go very well. People would usually tell me some generic stuff about how they've gotten bigger, expanded into new markets, etc., which isn't very helpful for getting a sense of the culture. I occasionally had time to follow up with "How has your day-to-day changed?" which was more illuminating; it's possible you could frame this question to get those answers upfront.
• "What are your hours?" is nice to ask a couple people, just to get a sense.
• "How much time do you spend in meetings?" is a bit of a leading question, and will usually end with the person concluding "... not too many." It helped to ask "what are your regularly scheduled meetings?" - this ties in nicely to questions about project planning and so on.
• "What is something you find difficult about working here?" is nice - a different phrasing of the "tell me something negative / what would you change" question. I like this one because it doesn't restrict them to thinking about things that could be changed - it also illuminates issues that aren't really fixable or shouldn't be fixed, e.g. "our product handles sensitive data and the security requirements are a bit painful."
• "How does this compare to other places you've worked?" - Good because it gets at specifics, and also handy to get a sense of where your interviewers were before they were here. Asking where they worked before also puts their answers in perspectives. E.g. "we have a really scrappy culture!" means less from someone who worked at Google than someone who worked at Facebook.
• "How do you collaborate with your team?" - e.g. do you talk to them on Slack, turn around to the person behind you, send emails ... ? More specifically: "What do you do if you're stuck on a technical issue?" This is a great barometer of the team dynamics.

Conclusion

Looking back, I realize that I'd almost blocked out of my memory how incredibly stressful the interview experience was. I think next time I switch jobs, I will seriously consider quitting first and interviewing later.

Changing jobs has also helped me realize how valuable the skills that I had at my previous job are. I hadn't expected so much of it to be transferable, but it turns out having a sense of good practices and "how things are done" in a variety of respects can give you a really good framework for development, which I now realize not all software developers have.

Was the job change worth it? Probably. Some months in, I'm writing a lot more code and using my brain a lot more than I was at my previous job. So I'm happy now. I won't be interviewing again for some time.