I published my first blog post on here in March 2013 (6 years and I’m still at it!!) and I talked about how I get intimidated when thinking about doing things that I’ve never done before, such as installing WordPress. At that time, I wrote:
When I learn new things, I’ll try to document what I learned to delineate exactly why I reached the conclusion that it was simple. Installing WordPress, for example, is only simple after you do it.
Today, I finally sat down and moved from amynguyen.net to this new domain, amy.dev. You know when you log onto Turbo Tax and they ask you “How are you feeling about doing your taxes?” before you get started? I would definitely choose the frowny face option for how I felt about getting through this today. And six years ago, I would have chosen the “don’t ask” extra frowny option.
I’ve been having the same conversation with myself over the past few months. Whenever I end up in a cycle like this, I like to write everything down. I think writing gives my brain permission to stop ruminating because it feels assured that I won’t forget. So this time, I’m going to share a little about what I’ve been thinking regarding starting a business!
I was originally planning to tweet this by itself:
STARTUPS HATE HER: DATA STRUCTURES TO NAME-DROP WHEN YOU WANT TO SOUND SMART IN AN INTERVIEW
- bloom filter
- prefix trie
- ring buffer
But I realized I actually wanted to say some earnest, not-shitposty things about each of these data structures, so I figured I should take it to my neglected blog instead. If you just wanted the clickbait version, you can stop reading now.
I moved to Singapore a few weeks ago! I’m not going to go into great detail about all the why (awesome job! awesome country!) but I promised some people I’d write down all the stuff I had to do in preparation for the move.
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.
Originally posted on Medium.
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.