Today, I told someone that when it comes to interviews, I am a robot with a checklist. I thought it would be useful to write it down for others! Here’s what I do:

1. Listen to the problem. Ask questions and give example inputs/outputs to make sure I understand the rules. Try to think of edge cases if possible – consider the empty input case, single (1) case, maximum case, and nonsensical input case.
2. Think of a solution. If nothing comes to mind, I ask myself if any of these tools are relevant to this problem: hashing and hash maps, sorting, classic data structures, classic algorithms / techniques, and bit logic. Classic data structures include: arrays, hashes, sets, trees, linked lists, stacks, and queues. Classic algorithms include brute forcing, breadth- and depth-first search (remember to explain when you would use one over the other), memoization / dynamic programming, recursive backtracking, and exhaustive recursion. Bit logic rarely comes up, but it’s worth mentioning in case your interviewer is an asshole.
3. Explain my plan. Once I have thought of a solution, I explain it to the interviewer verbally or with pseudocode. I usually clarify that my intent is to make sure we’re on the same page and that I’m making sure my solution works. After I explain it, I ask if the interviewer would like me to code it up or if there’s anything I should clarify or fix. This is a cheat code because sometimes an interviewer will say that I explained it in enough detail that we can move on without coding it! Or they might ask, how would you make this solution faster?, in which case I didn’t spend too much time coding something and can go straight to the optimizations.
4. Code. Once I’m coding, I refer back to my pseudocode pretty often because I lose track of my thoughts easily. I like having a plan to read from so that my nerves don’t stop me. I try to write the pseudocode in a way that there’s enough detail that the code isn’t a challenge. As an interviewer, I appreciate seeing the candidate’s plan because it makes it easier for me to follow what they’re doing if they’re silent.
5. Test and debug. If I’m on a laptop, I run the code with some test cases. If I’m on a whiteboard, I ask the interviewer if they mind if I step through my code with an example or two. I mark up the board with what I expect each variable’s value to be as I go through and make sure things work as I imagine.
6. Runtime and optimizations. Once I’m satisfied with my solution, I talk about Big-O runtime and potential optimizations, assuming the interviewer cares. Optimizations usually include some algorithm bullshit with sorting or hashing or some gotcha, or maybe adding threading.

Each of these steps take a lot of practice to become good at. Not only do you have to be good at coding, you have to be good at communicating, collaborating with your interviewer, paying attention to details, and talking about improvements. With this list, you can practice each step and get comfortable with it. Eventually, you’ll be able to systematically answer interview questions without hesitation!

How to use Chrome Developer Tools to get tickets to Taylor Swift’s next concert

For her upcoming concert, Taylor Swift partnered with Ticketmaster to ensure that only legitimate fans can buy tickets. I’d like to say that I’m a true fan who will do the honest work to get a ticket… but I am also a woman with a computer and I like a challenge.

I ended up having a lot of fun exploring Chrome Developer Tools and I wanted to share what I learned. Here’s what we’ll cover in this post:

• How to send code through the Console tab
• How to use the Network tab to find relevant activity
• XHR breakpoints
• Putting this all together to create fake user activity

Continue reading →