I want to write down my memories of this year because I might forget them otherwise. I debated whether to publish this because, for the world, 2017 has been an awful year, worse than any other in my short memory. Yet it was a year of huge personal growth and professional success for me, and I still want to celebrate that, in a way that acknowledges my own privilege. I’m not sure what else I should say on this note other than that I recognize that I am fortunate, and I am grateful for what I have.
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.
When Whistling Vivaldi was first recommended to me, my initial response was, “I already know what stereotype threat is. Why do I need to read about it?” In other words, I was your standard punk-ass college student. I had never really given concentrated thought to stereotype threat in the broader context of society, or how it affected people who weren’t me. But this book gave me a deeper understanding of how stereotype threat happens and how it can be combated. My only regret from finally reading it is that I didn’t read it before starting college. Now that I’ve finally dragged myself to the finish line for my bachelor’s degree (after 6 years!), it seems especially bittersweet that this book helped me recognize some of what was happening to me right at the end of my journey.
I haven’t felt so compelled to share a book with other people in years. Reading, for me, is usually for entertainment or personal development, and I go from book to book without wanting to sit down and reflect in a way that is useful for others. This book is different. I feel obligated to share Whistling Vivaldi because it made me burst into tears from recognition of my own past pain. I didn’t think I needed affirmation that my experiences in college were shared by others, but I did. This book gave me time to reflect on moments of self-doubt from the past and helped me re-interpret them in the context of stereotype threat instead.
This book is useful both as a tool for self-reflection (even if you don’t consider yourself as a minority!) and as a tool for supporting others. I want more people affected by stereotype threat to read this book so they can have the time to think back on their own experiences and how they were impacted. I want more people in general to read this book to gain empathy for what students, coworkers, and friends might be suffering from without realizing.
People are so mad at women. The way they dress, the way they speak, the way they dare to exist in modern society. People are never not going to be mad, but I’m going to try to break down the latest problem with women anyway.
Women sometimes do this thing where they talk and we’re supposed to listen, but they sound so annoying that it’s hard to focus on the content of their message. I mean, who cares what a woman has to say when she keeps doing that croaky vocal fry tone bullshit and every other word is um, like, sorry, just, actually — it’s so unprofessional! What if we made an app that stopped them from using those weak filler words? Maybe then we could take them seriously!
I know what you’re about to say. It’s not about women! When people of any gender talk unprofessionally, they lower their credibility. They sound incompetent and insecure. By eliminating phrases like “I think” and “sorry, I just…” from their language, women can get proper recognition for their ideas and become better communicators. We’re helping women get ahead in the professional world by showing them how they undermine themselves with their linguistic choices.
On the surface, this sounds fair, but it’s loaded with assumptions about the way the world works that aren’t true.
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?
When I was 17, I desperately wanted colleges to accept me based only on my academic achievements — my “merit” — without consideration for external factors. My family and school counselors insisted that I emphasize my immigrant family / low income status in order to gain sympathy from admissions officers. To me, that meant not getting into my dream school through my own talent. I spent my first year at Stanford doubting myself and fearing that people would realize I wasn’t talented enough to be there. This sounds like textbook impostor syndrome, but it was worsened by constant comments about my minority status. Students from other high schools said they wished they had my background so they could get into whatever schools they wanted. Everyone assumed it must have been easy for me to get accepted. Stanford likes poors like me. Of course I got in. I learned to not mention my upbringing because people would think less of my qualifications and belonging at Stanford if they knew.
At the end of my sophomore year, I was lucky to end up in a required writing course with a black professor who understood what I was going through (having spent over a decade working on social justice issues). She encouraged me to investigate affirmative action stigma for my term paper as a way of understanding my own feelings about being a “diversity pick.” My paper focused on research surrounding the psychological impact of being considered a diversity pick on minority students. That research is what I want to summarize now.
Back in December, I wrote an article for Model View Culture. You can find it here. I’m proud of it because it’s my first paid article ever and it deals with a topic that had bothered me about the tech industry and women’s advocacy efforts in general. Enjoy!
Update: Because MVC is no longer publishing, I have re-printed my article here for posterity. Continue reading
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.