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:
- 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, and maximum case.
- 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.
- 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.
- 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.
- 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.
- 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
Last month, I gave my first conference talk ever, titled “UX Design and Education for Effective Monitoring Tools,” at TechSummit Berlin. I felt terrible about it. All I could say about it was that it was over and I didn’t make any glaring mistakes, but something felt hollow about the whole thing. I realized that it was because I couldn’t say honestly to myself that I had expressed what I really wanted to say when I wrote the abstract. The good news is that I gave a talk at Monitorama with the same title and abstract, and I feel like I made a bit more progress towards saying what I needed to say. I wanted to write down some of my thoughts on what changed between the two talks.
Allies, put your career where your mouth is.
There is no fire under any tech company’s ass to change their ways. Over the past few years, we’ve seen every major tech company release a statement about their abysmal numbers, their token efforts to improve, and how much they value diversity and inclusion at their companies. It’s been a feel-good hug fest where everyone gets an A for effort.
Yet from the same companies, we see all this talk of not lowering the bar, tolerating of abusive behavior from their employees, and unwillingness to hire from the existing pipeline. How could this behavior be so pervasive when tech companies claim to be so concerned about diversity and inclusion?
I’m a Vietnamese American woman in technology. That is not synonymous with being an Asian American in technology. Here’s the shortest summary of my background I can give: My parents escaped Vietnam on a boat and moved to the United States in 1990 with barely any understanding of the English language. We grew up poor and I pulled myself through high school and university with little guidance from others. I worked after school until 10–11pm several nights a week throughout high school for my family. My high school nearly lost accreditation while I was there, which would have made my diploma useless. There’s so much more to my upbringing than that, but I’ll save it for another time.
In an ideal world, you would be perfectly prepared for technical interviews before having to go through them and you would know exactly what to say. For most people (myself included), however, that first interview is a complete mystery — you have no idea what to say or do or expect. I wanted to compile my personal list of preparation reminders so that I have a semi-permanent reference for people who ask me for advice!
The trivialization of women’s interests throughout history and what we can learn for the future
In the 1920s, flight attending was a predominately male profession. Passengers were fearful of this new mode of transportation; having an all white, male staff reassured them of the safety of commercial airlines. These men were perceived as capable, competent members of the crew, right alongside the pilot in importance. It was only after World War II, when women took over the job as men left for war, that flight attendants lost their respect, instead becoming sexualized and trivialized.
Let’s leave imagined gender differences, evolutionary psychology, and the idea that “women just aren’t as interested” out of the discussion.
Earlier this week, Dave Winer wrote a blog post about why he thinks there are so few women programmers. He suggests that it dates back to our roots as hunter-gatherers:
Programming is a very modal activity. To be any good at it you have to focus. And be very patient. I imagine it’s a lot like sitting in a blind waiting for a rabbit to show up so you can grab it and bring it home for dinner.
The Internet has been in an uproar about this and several people have written excellent responses to his post. I’ve included some links in the further reading section, which you should check out if you’re interested in the debate surrounding whether women are naturally inclined towards or against programming. I don’t have much to add to that conversation that hasn’t already been said.
I originally posted this on Medium. You should go there to get the full effect and sweet header photo. I’ve reproduced it here just for my own archiving purposes.
Think of a woman in the tech industry you admire. Describe her. If you’re thinking of someone particularly memorable, you might say, “She’s amazing! She’s an awesome software engineer, always has interesting things to say, and is really pretty.” I’ll be the first to admit that I’m fascinated with these women because they reject all the stereotypes to which I’ve grown accustomed. They’re perfect.
I like Vim.* Without further ado, here are some commands that I use regularly: