My 2A term surprisingly felt less demanding compared to first year. Don’t get me wrong, there were still moments where I was under stress to finish assignments or understand alien-like concepts, but overall I felt more relaxed and focused. With this term behind me, it’s a good time to write about the courses I took.
This is probably the horror course you read about on UW Flow. While there could be improvements to how the course is taught, the material itself was still interesting. Some of the weekly assignments could be finished relatively quickly if you kept up with the material, and they were also great practise for the midterm and exam. Tip: if you find some of the course slides confusing, try going through Lubiw’s slides from a previous term. They’re more concise and easier to understand.
A big step up from CS 136. You now graduate from C to C++ and get to learn all the quirks that the language has. A lot of useful content is covered in this class, such as the programming design patterns. Each assignment is split up into two due dates, where the first is for the test cases and the second for submitting the actual code. Don’t underestimate the time required to do the test cases, some of them can be very tricky to find. The midterm was also difficult and long (I think the average was a 62%), but the final was fair. Also be sure to take good notes since they’ll be what you study from. I was lucky to have Nomair for this course. He’s the best.
The beginning is almost the same as what you learn in high school data, but the content ramps up quickly from there. There’s also no weekly assignments, but the 3 tests and 2 midterms make up for it. Be sure to keep up with the content or it will be difficult to catch up in time the end for the final (which is kind of what happened to me).
Surprisingly applicable to CS for a psych course. You get to learn about the different ways of representing the mind and intelligence, and how each of these approaches can relate to one another. Unlike most psych courses at this level, the tests are comprised of only short answer questions, with one short essay question at the end. I personally found the content more interesting near the end when we started discussing neural networks. This course is great for those who are interested in AI.
Some overlap with psych 256, but with much less attention on CS topics. There’s a greater focus on cognitive disorders, experiments, and case studies. For some reason, my prof glanced through most of the physiology content in the textbook, which just so happened to the topics I was most interested in. Despite that, the course was enjoyable all around and a great compliment to psych 256.
I must admit, I didn’t expect the job application process to start so soon. I mean, I knew exactly when it would start according to my co-op sequence, but it just felt like time passed much faster than it should have.
The application process began two weeks into my 1B term, so I luckily had time over the break to brush up my resume and short-list a few companies. There were only about a hundred jobs targeting the Computer Science and Software Engineering disciplines on Jobmine at this point, but that was enough to get an idea of the skills companies were looking for. I also planned to read McDowell’s Cracking the Coding Interview to prepare for any technical interviews that I could come across. I never got around to doing it though, which turned out to be a big mistake that I’ll talk about later.
Besides the things I did myself to prepare, CECA also provides a lot of services to help with the job search, such as resume critiques and mock interviews. I never got around to using these services though. What I did take attend regularly are Employer Info Sessions, which I encourage all students to take a look at, co-op or not. You get to learn a lot about companies and get an inside look on what it’s like to work there. They also often talk about the work of previous co-ops and sometimes even share interview tips. Of course, the free food is a plus. I was lucky to have the option to view these sessions in my first term when I wasn’t applying for jobs, since most of the sessions were scheduled after the job application deadline for the first round.
When the job postings opened, I used up almost all my applications to apply for more than 50 jobs (openings from IBM and Blackberry didn’t count towards the quota). This was much more than originally planned, but it turned out to be a good strategy since there weren’t many postings I was interested in in the second round. I also pushed my luck and applied for a few “higher up” companies, such as well-known startups and Silicon Valley companies, just for the slim chance that they might give me an interview.
As it turns out, that’s what happened. It also happened to be that the interviews of these companies were the most technical (no surprise, really). You can probably see why not reading Cracking the Coding Interview was such a big mistake now. I performed so badly on one of them that I wouldn’t be surprised if the company would straight up toss my resume out the next time I applied. Thankfully, my other interviews went much better, mostly because they didn’t nearly have as many tricky technical questions.
In retrospect, there were a lot of things I could have done to improve. The main ones were spending more time preparing answers to potential interview questions, and practicing solving and explaining solutions to coding problems. My time management could have been better too. I ended up skipping most of my classes the week I had three consecutive interviews. I thought it was worth it to spend the extra time preparing for the interviews and catch up on my missed classes the week after during reading week. This turned out to be a pretty good decision, although I probably could have avoided doing this altogether if I prepared more in the beginning of the term.
In the end, I received 6 interviews and 2 job offers, one from the first company I interviewed for and one from the last. I ended up taking the offer from the first company, TD! I am super excited to work in their innovation lab in the Communitech Hub next term.
My first job hunting experience was definitely a positive one. I was fortunate to find a co-op position early in the term, so I didn’t have to worry about employment or interviews during finals. It was also great to have the extra interviewing experience. It’s safe to say that I felt much more confident in my later interviews than in my first. Overall, CECA was right about treating co-op as an extra class. Finding a co-op job can be a lot of work, but there’s no denying the valuable experience you get from it.
This year, a thousand students from across the world gathered in Waterloo’s Engineering 5 building for Hack the North, Canada’s largest international hackathon.
As this was my first hackathon, I arrived with little knowledge of what to expect. I wasn’t familiar with the structure of the event or what I was supposed to do when I got there. I didn’t even have a project idea in mind. But somehow, the uncertainty didn’t bother me – it only made things more exciting.
Fortunately, soon after checking in, I was introduced to another fellow hackathoner by a friend I ran into. Since we were both looking for a team, we decided to work together on whatever we decide to make. Being with a partner made me feel more confident about the whole event. Although I wouldn’t have minded working alone, I felt that working with someone else would be much more worthwhile.
During the opening events, my partner and I joined with two other people, making us a team of four. We just so happened to all be first year Waterloo students at our first hackathon. With the building so full, we were also fortunate to have a table in a nice classroom that my original partner found beforehand to work in. Our workplace had a great view of the hallways and workplaces around and beneath us. I found it a bit intimidating at first, but I soon learned to enjoy it. Settled down at our table together for the first time, we were calm but motivated, and we were ready to make something.
My team spent the next half hour deliberating on what our project should be. Our ideas were all over the place: a web app that maps the prevalence of a given job across different geographical regions, a smart Android app that tells you when to sleep based on your schedule for the next day, a Google maps-like app that gives step by step directions to each room on campus, and much more. Despite all the crazy ideas we had, we settled on something smaller and within the scope of a 3 day hackathon.
Inspired by the popular WatIsRain app, WatIsFood aims to solve the hunger epidemic experienced by university students. The app helps them find food by mapping out all the open food serveries on campus. It also displays store details such as descriptions and operating hours.
Development for the app went smoothly at first, but as expected, we eventually ran into various problems. Being responsible for developing the map and marker display for each restaurant location, I faced the challenge of developing an efficient way to display this information.
I originally wanted to store and display the map as a vector file. This had the advantage of being able to zoom without losing image quality, which is essential when navigating a map. However, the lack of a native way to display vector files on Android and a suitable third party SVG library quickly led me back to the drawing board. With the option of having a vector map out, I decided to instead use a single high quality raster image. Of course, during testing, I was greeted with an abundance of out-of-memory errors due to the large size of the map. I tried to break down the map into smaller tiles, with separate tiles for each zoom level to improve image quality, but time restraints led me to back out from this approach. Eventually, I settled with just shrinking down the map image to an acceptable size. It definitely wasn’t the best solution, but it’ll work for now.
Drawing store markers consisted of two parts: positioning the markers on the map and overlaying them on top of the map. Having a fixed size image made positing the store markers a breeze. The markers were positioned based on the coordinates of the stores on the image, and their visibility was determined by whether or not the store was open. Drawing them, however, required much more experimenting. The most obvious way to draw the markers was to overlay them on top of the map in separate ImageView. Unfortunately, this approach led to a lot of lag when panning and zooming on the map. The next option was to draw the markers directly on the map and display it as a single image. I used Android’s built-in bitmap functions to merge the images, and after some more memory optimizations, the marker drawing was done.
Marker touch detection
This was the part of development that caused me the most headaches. The process seemed simple at first – just get the coordinates of the touch event on the ImageView and check if it’s within a certain radius of a marker. Despite being a seemingly straight forward task, I found a major issue during testing. Sometimes, the dialog that opened when tapping on a marker did not correspond with the store that the marker represented. This bug seemed to occur completely random at first, with some markers working one minute but not the next. After a few long hours of debugging, I found that the problem began occurring after the map has been zoomed. As the map image was originally set to fill the viewport, the top left-most corner of the map had the coordinates (0, 0) as desired. However, once the map had been zoomed out and is no longer filling the viewport, the coordinates of that particular point changed. The coordinates (0, 0) now represented the start of the ImageView and different coordinates represented the start of the map. In essence, the coordinates obtained were of the ImageView itself, not the image it was displaying. I tried to compensate for this behaviour by processing the numbers using the map zoom level and the screen dimensions but to no success. As time was running out, my team and I decided to disable map zooming altogether to prevent the bug from occurring. This was another Band-Aid fix that I was not proud of, but It was nice to finally move on to refine other parts of the app.
We finally finished our app an hour or so before the submission time. Although several compromises were made during development, we were still surprised that we even got this far. The last few hours of the event was spent on preparing a presentation of our app. It turns out that we were the last team to present to our panel of judges, so we had a lot of time to spare. Unfortunately, when it was our turn to present, the judges didn’t seem very interested. It might have been because we were the last of a hundred or so teams they saw that day, or our idea wasn’t that interesting in the first place. It was understandable either way; we were novice hackathoners, and we were tired too.
Despite the sheer amount effort devoted to developing WatIsFood, our achievements with our project wasn’t what made the event great. What made it great was being part of a community that was motivated for both their own achievements, and to help others reach theirs as well. We were fortunate meet developers from companies such as Instagram and Big Viking Games, who not only gave us insight about their job in the company and future employment opportunities, but also helped us with developing our app. I also enjoyed listening to the many seminars that were offered, including one where we got to do a small Q and A session with the president of Y Combinator, Sam Altman.
With so much to do, it’s easy to get lost in it all. Looking out the window of our workspace down at the atrium below, you can see everybody buzzing around like bumblebees. But despite the chaos, you’ll never have trouble finding someone that’s happy to stop and chat, and this is where the magic comes from at Hack the North.
The second week of my last summer break is coming to an end. The sun’s smiling, birds are chirping, and people everywhere are playing soccer. Amidst this temporary state of perfection, why not start a blog?
I’ll begin my first post with some information about myself. I’m a Canadian student entering the University of Waterloo this year in their Computer Science program. Throughout my high school years, I’ve been fortunate to have been taught by some phenomenal computer science teachers. They led their classes by their genuine interest in the subject, and I attribute them for where I am today.
Moving forward into university, I decided to start a blog as a way to collect my thoughts, discuss topics related to my field, and perhaps talk about student life as well. It may also be interesting to look back upon in the future as a journal of my years to come at Waterloo.
So here it is. I hope you’ll enjoy it as much as I will.