Jeffrey Wang's Blog

Important notice about this site

I graduated from the University of Texas at Austin in December 2020. This blog is archived and no updates will be made to it.

Welcome to my blog!

Here, I post on topics relevant to my time here at the university, general topics on computer science and business administration, and anything interesting that I learn as a student and lifelong learner.

Wish to reach out to me about my blog posts? I'm open to questions, comments, and suggestions. Feel free to contact me.

Archives

The formula to writing a great resume

August 18, 2020

For years, I struggled to come up with a way to write good resumes. They were long, unstructured, and not very descriptive of the work I did, nor its impact. As a result, they were essentially a waste of paper.

It wasn't until I started applying for internships when I realized that there's a few tricks of the trade to writing resumes. Once you get the hang of it, writing great resumes can become second nature. To make things easy, here's a few steps you can take to making your resume great.

(These tips are specifically written for college students.)

  1. Use a good template. I personally like using the template provided by the McCombs School of Business. You can download it by clicking here. You can use another one for sure, but make sure it is readable. Another common format is the Deedy resume format (LaTeX), which is also very readable and organizes information quite well. These two formats are about as good as you're going to get. Please don't ignore my advice and go off and find some odd resume template because it "looks cool", and also be wary of making your resume too fancy and colorful. Often, finding a good-looking template means you might be overdoing it. By placing emphasis on appearance, layout of information is sacrificed and ultimately this will lead to an ineffective resume. An argument to be made against colorful resumes: think about how that would look if your resume was printed out on a grayscale printer by a company. My resume is based off of the McCombs format, and while it looks "boring", it has nonetheless been able to get me great job offers. I'll explain readability in a bit—it's more important than beauty. TL;DR: don't get too fancy. Just use either the McCombs format or the Deedy format (if you know LaTeX).
  2. Remove anything that is high school specific. NHS president? Congratulations. Unfortunately, that doesn't make Goldman Sachs want to hire you any more than if you weren't NHS president. Take out what high school you went to, your rank, your GPA, etc. — these are all relevant to high school and college applications, but not to your future career. From here on out, it's what you do in college that matters.
  3. Keep your resume under one page with a reasonable font size. Right at one page is perfect. A resume should take up at least 3/4 of a page—any less and it looks very awkward. A resume that's more than one page is not okay unless you have worked in industry for more than 5 years and/or you have a PhD and have published a crap ton of papers. Some recruiters will simply not read past your one page if you have more than a page. Don't make your font size under 9, as that will make your resume too small and unreadable. Keep it between 10-12 ideally, but 9 is permissible if you have too many accomplishments that need to be all listed out.
  4. For each work experience, keep it between 3-5 bullet points, and each bullet point should be one line only. Some say 5 bullet points on a single work experience is too many, but I think it is fine if you achieved a lot. Each bullet point should describe a different aspect of your work experience. No bullet point should exceed a line. You can definitely cut out something and refactor it into a new line if your font size is 10 or 9.
  5. For each bullet point, not only talk about what you did, but also how you did it and the impact it caused. Google calls this the XYZ format: "Accomplished X as measured by Y by doing Z". As the next bullet point alludes to, don't copy paste this verbatim. Instead, make sure each bullet point contains the X, Y, and Z; in other words, make sure it says what you did, how you did it, and what metrics you can put behind it to establish its impressiveness. Here are two samples from my resume, before and after improvement:

Before:

Put in metrics tracking to my custom task

After:

Added metrics tracking by creating custom REST client to send data to Azure Application Insights API, speeding up task execution by 600%

Not only do you know what I did (added metrics tracking to send data to Azure App Insights), you also know how I did it (by creating a custom REST client) and what impact it had (sped up task execution by 600% — and by the way, that is not a lie).

  1. Use a plethora of exciting verbs rather than boring ones like "used", "did", "made". Words like "established", "introduced", and "implemented" provide variety and infuses energy into your resume.

Instead of:

Used Python to make a script that refreshes the dashboard

Try saying:

Wrote a Python script to refresh team productivity dashboard

  1. Be sure you're collecting metrics to put on your resume. Whenever you work on something, make sure you have tangible numbers to use that are impressive. Saying something like "my task will be used by hundreds of teams within Microsoft" sounds really impressive, and I guessed that by asking my team and my manager what the purpose of my project was, as well as what the scope of it would be. Then I made a reasonable estimation based on the scope. Other times, your team might be collecting metrics on their Kibana dashboard or whatever, and from there, you might be able to see how much time you've shaved off of something or how much more efficient you've made something work. As long as you use relevant numbers, you'll go far.
  2. Don't share any secrets. Your resume should be as specific as possible, but keep your resume vague enough so that you don't violate your NDA by accident.
  3. Make your resume as readable as possible. The layout should be good, as previously discussed. Each bullet point should be readable. While the XYZ format needs to be followed for each bullet point, that doesn't mean make the bullet point too difficult to read. A personal tip I have for technical resumes: I like to bold and underline each programming language so that it stands out, is easy to read, and is easily picked up subconsciously by readers of your resume. Bolding, italicizing, and underlining (within reason) is your friend when it comes to making your text stand out on your resume. Don't all caps anything to emphasize something, because yelling is scary, even on paper. Remember that a recruiter only takes between 5-15 seconds to scan your resume with their eyes.
  4. Order matters. First impressions count, so put most impressive things first while preserving the order prescribed by the resume templates. Education first, then work experience, then personal projects, then honors and awards, and finally additional information.
  5. Indicate your work eligibility. Employers need to see whether you are able to work in the United States with or without sponsorship. If you are a U.S. citizen or lawful permanent resident (i.e. Green Card holder) then you can put "eligible to work in the U.S. with no restrictions" so the recruiter won't have to worry about sponsoring you to work. Otherwise, indicate your visa status (i.e. F-1, J-1, H-1B, L-1, etc.) and explain what kind of sponsorship you need (i.e. CPT or OPT for F-1 visa holders, H-1B sponsorship for full time jobs after OPT runs out).
  6. Put some relatable hobbies. Play sports? Knit? Fly a drone? Love history? Put down a select few hobbies that define who you are, yet are relatable and are professional. Netflix bingeing is tragically not a hobby (at least, not professional enough to be put on a resume). This will allow you to potentially strike up a conversation with whomever you're interviewed by.
  7. Last, not really a content tip, but make sure you know what you put on your resume and don't lie. You'll be asked about your resume. Be sure to remember what you put on there, and I don't mean just the content, but rather do you actually know what you claimed you did? For instance, if you put down Docker or Kubernetes, these are two technologies that people often claim to know but really don't. You don't want to sound like you are talking out of your ass. If you put down Kubernetes on your resume, then when someone asks you "what does Kubernetes do?", you need to be able to say that it is an orchestration platform that coordinates deployments of server images and containers. Oh, and lying will obviously backfire if you aren't able to justify or back up your claims. Be sure to know your resume by heart. Don't forget what you worked on.

These tips should be enough to get you started on writing a great, impressionable resume. Reach out to me if you have any questions.

Example resumes:

  • Technical resume, 2020 - this sort of resume is ideal for technical jobs like software engineering and product management
  • McCombs BBA resume, 2020 - this sort of resume is ideal for general business jobs like analysts and consultants, and is McCombs School of Business approved (BA 101)

Getting kot up with Kotlin

July 12, 2020

That was a terrible pun, but it was the best I could come up with.

I've heard people say how great of a language Kotlin was. I didn't quite exactly understand why until I learned Swift and TypeScript. Now, I can understand how these two languages greatly improved their predecessors (Objective-C and JavaScript, respectively).

Kotlin is aimed to be an improvement over Java. Some of the key problems in Java, such as its verbosity (Java takes forever to write) and its lack of null safety, are addressed quite well by Kotlin's features. There aren't any groundbreaking innovations that come to mind, but it significantly improves the quality of life for a Java developer. And as someone who has wasted countless hours of productivity debugging a null pointer exception lurking deep within enterprise-scale code, I know very well how important it is to have proper null safety. Java optionals in Java 8 simply don't make the cut with its clanky syntax, in my opinion, compared to the vastly superior null safety mechanisms you see in Swift, TypeScript, and Kotlin.

If you haven't made the switch from Java to Kotlin yet, I recommend you do so as soon as you can. Kotlin interoperates with Java code because both compile down to JVM bytecode. There's a very low switching cost; it's possible to simply create new files in Kotlin and use the existing Java code, with no need of writing wrappers or anything silly like that.

If you already know Java and a language similar to Kotlin like Swift or TypeScript, I recommend reading this 5 minute quickstart. It'll not only give you a good overview of Kotlin, you'll feel like you'll know Kotlin by the end of the guide. Learn the Kotlin programming language

If you know Python and want to learn Kotlin, there's a 15 minute guide located on the official Kotlin language website: Migrating from Python

If you want to learn Android development with Kotlin rather than Java, which has been recommended as of Google I/O 2019, check out this guide: Android Basics in Kotlin

A swift introduction to Swift

July 11, 2020

There's more dad jokes where that came from.

Swift is used primarily for iOS app development, although in a few years this will be true for macOS development as well, with macOS's move from Intel to ARM.

I learned Swift from CS 371L and if you're an undergrad in UTCS, I highly recommend the course as taught by Dr. William Bulko. Any accidental borrowing of phraseology is attributed to that course -- please don't sue me.

Swift is a language described by some as C++ changed to be more like Python. I completely agree with that characterization. It'll be familiar to people who know Java and Python. And if you know both, that's even better; it'll make learning Swift relatively easy for you.

So rather than focusing too much on the fine-grained details, I'll present a block of Java and an equivalent block of Swift for comparison, to highlight some basic differences.

Java:

public class Circle {
    private static final double PI_APPROX = 3.14;
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    public double getRadius() {
        return this.radius;
    }

    public double getDiameter() {
        return this.radius * 2;
    }

    public void setRadius(double radius) {
        this.radius = radius;
    }

    public void setDiameter(double diameter) {
        this.radius = diameter / 2;
    }

    public double getCircumference() {
        return this.radius * 2 * PI_APPROX;
    }

    public boolean sampleOne(String one, String two) {
        System.out.println(one + " and " + two);
        return one == two;
    }

    public static void main(String[] args) {
        Circle circ = new Circle(3);
        System.out.println("Circumference is " + circ.getCircumference());
        System.out.println(sampleOne("yeah", "nah"));
    }
}

Swift:

class Circle {
    let piApprox = 3.14
    var radius: Double?
    var diameter: Double? {
        radius * 2
    }
    var circumference: Double? {
        radius * 2 * piApprox
    }

    init(intendedRadius radius: Double) {
        self.radius = radius
    }

    func sampleOne(outerLabel innerLabel: String, _ noLabel: String) -> Bool {
        print("\(innerLabel) and \(noLabel)")
        return innerLabel == noLabel
    }
}

var circ = Circle(3)
print("Circumference is \(circ.circumference!)")
print(circ.sampleOne(outerLabel: "yeah", "nah"))

Other than differences in syntax, such as the absence of semicolons at the end of lines, some differences stand out, such as the lack of a main method (just type everything in there and it works!), as well as the tendency to manipulate variables directly rather than requiring accessors and mutators (that's the proper term for the slang "getters and setters"). Also, parameters are required to be labeled and they have a caller label and an internal function label too, unless you use the underscore. Variable values can even be derived from other variables; these are called computed properties.

Then, there are the concepts unique to Swift that Java, Python, and C++ all lack. One thing that's a good addition is something called optionals. They're used when a value might not exist yet. In other words, if a variable can be null (Swift calls it nil) then you have to take extra care to deal with it. If a type has a question mark (?) or an exclamation point (!) after it, that means it's an optional and might be nil. A question mark means it's most likely starting off as nil, while an exclamation point means it's likely starting off declared but it could be nil. When using optionals, adding an exclamation point after it means you're force unwrapping it. This is like using a variable in Java knowing that it's possible it's null but you're very sure there's a value in it, and if there happens to not be, you'll receive a null pointer exception. In Swift, there's ways to check to see if it is nil or not, and add failsafes to make sure that you're not going to encounter a pesky null pointer exception. Optionals make this possible.

Optionals in Swift are most like from C#, TypeScript, or Swift's predecessor, Objective-C.

Chronicles of being a TA, part 2

July 11, 2020

Perhaps my biggest goal was to be someone who wasn't apathetic and someone who didn't ruin students' lives. I wanted to be the exact opposite -- someone who cared and who empowered students to love the subject they were learning.

I had the great pleasure of being a TA for CS 312 in the spring of 2020. My plan was to be a good TA so that students could learn a lot from the class and get a good foundation in CS, as well as make sure that students had an empathetic authority figure who wasn't out to get them, but rather genuinely assist them.

Who knew that a pandemic would interrupt the middle of the semester? The university gave all of us an extra week of spring break to allow the transition online. Moving online shed my spring break from two weeks into almost none. As in these emergent situations, the person who spearheads change is the one who does it. As a TA, my job was to make sure I could figure out a way for my team (my professor and the other TAs) to adapt well and continue delivering the class experience that was expected out of us.

Figuring out how to use Zoom and how to reconfigure our class didn't come down to the university. It came down to other faculty members and teaching assistants. I had to come up with the playbook myself because I knew the university wasn't the ones who knew this class inside and out.

And it worked. A lot of effort later, we managed to figure everything out. The wrinkles took about a week to iron out, and then voilà, we had pretty smooth sailing from there on out (except, of course, for the fact that it was still very difficult for people to learn at the beginning of a traumatic pandemic that had altered our lives permanently and irreversibly).

Even before the pandemic, I tried to be available for students and empathetic in as many ways as I possibly could. Giving them the tools to succeed was important to me and thankfully to the rest of the TA team. I can see why UTCS appoints undergrads to be the TAs for CS 312 and 314 -- because the ones who do become TAs genuinely care. TAs are underpaid, so it's not like they do it for the money. They do it because they want to make a difference.

I don't like to draw conclusions when evaluating myself (I let others do that), but I do like to be tough on myself. I think I could have done a better job personally. At the same time, I tired myself out being so available and passionate about my students. The job typically took over 10 hours a week and even impacted my own classes' academic performance. But that's alright. I still thoroughly enjoyed the experience nonetheless.

The stress of being a good TA, in my opinion, made the experience as a whole worthwhile. It also solidifies my future of being a TA -- probably won't happen again, since I have to graduate soon anyway.

Did I achieve the goal I had set out for myself? Well, I will let others make that decision for me.

I'll conclude by sharing the anonymous feedback solicited by students on myself. I think they are well written statements that reflect my attitude towards being a TA, and these notes alone, I think because they are such good evaluations, I do believe they serve as honest attestations to how I did my job and my firm beliefs in being a student's ally, and I'm very happy for that. I want to note that I would have picked constructive criticism feedback to share if I had any, but unfortunately I did not receive any, so I will have to do some deep reflection on how I could improve as an educator on my own.

Jeffrey was extremely helpful and understanding during office hours. He clearly knows the material in and out and often pointed out helpful tricks and shortcuts to condense code. I believe Jeffrey not only helped me significantly with the material in this course but has also made me a better programmer. And he gives really good advice!

-

Great TA for the class! He helped a lot and answered all questions with nice answers. He is enthusiastic about his class and students.

-

Hands down an AMAZING TA! Jeffrey cared a lot about the success of his students and always tried to help us understand useful concepts for our assignments during discussion sections. I initially thought this class was intimidating because of how important it is for the transfer process, but knowing that I had a supportive TA that really wanted us to succeed made the class seem a lot less scary. Plus, he always replied really fast on Piazza to answer any questions, which was nice! Another thing that I appreciated was how quickly Jeffrey would grade assignments even though he's probably really busy! I'm grateful that I had the opportunity to take this class and learn the things that I did during this semester. I literally wouldn't trade this experience for anything.

-

You helped on something and I really didn't really expect you to help at the time, but the fact that you did really surprised me. I know it's kinda of what is expected from a TA, but at that moment I didn't really expect you to do that and I won't be forgetting that day because of it. I just want you to know that you're a great person. I really appreciate everything you did not just for me but for the class. You are no ordinary TA. You made me feel comfortable in reaching out to you if I ever had any questions and went above and beyond from what I expected from a TA based on previous TA's.

Undergrads of UTCS: you probably don't need a master's in CS

April 9, 2020

Originally, I was going to pursue a BS CS (Turing) + BBA Business Honors, and then go on to graduate school or a PhD program. After a hard look at the reality of things, I've realized this is all the wrong decision for me, and thankfully it's not pinned down in stone. Instead, I'm now going to pursue a BSA in CS and I'm not sure about the BBA anymore, with the uncertainty of the COVID-19 pandemic.

This choice is because 1) BS vs BSA has no difference if you're going into industry and 2) you can get really good jobs from UTCS undergrad.

I usually see CS masters programs as great fits for people who 1) need the credentials (like international students who are trying to get H-1Bs), 2) people who didn't get their undergrads in CS and are trying to enter the SWE field, or 3) people who went to not as good schools for CS undergrads and need a credential booster to get a better than normal CS job.

Archive

Back to top