The 5.4e+03 Second Litmus Test

This is a blog post from my late friend and mentor Frank Madrid. Posted February 24, 2018.

To a computer science student with no industry experience, few things are as unnerving as a technical phone interview. An interviewer must determine if the interviewee is slightly more proficient than a monkey using vim and implicitly assign a value to 4+ years of theoretical education and technical experience in under 5400 seconds.

Two days ago, I underwent such a litmus test with two Google interviewers and barring the heavy accent of my interviewers and the poor cellular connection, the interview process was a positive experience.

The Google Technical Internship Interview

A quick Google search immediately reveals the mystery and confusion surrounding the technical interview process. Forums are riddled with variants on the question, “What questions are asked during the Google Technical Interview?”

I assume the daunting and all-encompassing list of candidate topics indicated by Google in their 8-page Google Slide presentation is what solicits such a response.

In summary, these topics include:

• Algorithms
• Data Strucutres
• Operating Systems
• Mathematics

Though a list of four topics may seem far from all-encompassing, any second-year computer science student with 10 fingers (yes, a binary joke) can count how many classes do not use some subset of these topics. The possibly sole class meeting this requirement includes Introduction to Programming where the concept of an algorithm is barely introduced amidst the hurried foray to understand proper C++ or Java language syntax.

Preparing for the Technical Interview

Two weeks were spent reviewing and practicing these concepts in preparation for the technical interview. I attempted to find sources which offered a breadth of knowledge but didn’t require tremendous effort to understand any particular topic, and a slew of problems to reinforce the concepts learned during the review.

Reference Material

The first, and highly recommended text is The Algorithm Design Manual. This text offers an introduction to the most important data structures and sorting algorithms without being weighed down by heavy symbolic notation. It also offers a catalog of algorithmic problems which is useful for solving challenging coding questions. It also offers amazing interview questions but lacks a corresponding solution manual. This text is is available from Amazon for about $40.

The second, and widely popular text, Cracking the Coding Interview, boasts good insights into the interview process and includes detailed solutions to many important (but publicly available) problems. This one is available from Amazon for about $30.

Practice Problems

Cracking the Coding Interview included many problems targeted at a specific topic but most of my beneficial practice was found on websites dedicated to hosting a plethora of programming questions such as LeetCode. These problems did not necessarily indicate the appropriate data structure or algorithm to solve the problem and were sufficiently vague enough to be thought provoking yet not misleading. Solutions to some of the more interesting problems may be featured in future posts but many, if not all, of my solutions can be found on Github in my public repository.

The Interview

After the usual introductions and pleasantries, I was excited to finally begin the technical interview and witness what exciting problems the Google software engineers would be challenging me with. The questions were of average difficulty, completable within 30 minutes, and didn’t require a brilliant or archaic solution. The three solutions required string manipulation, the use of basic repetition structures and binary arithmetic operators, recursion, dynamic programming, and Big-O analysis.

I was not explicitly asked to withhold any information regarding the interview, but the specific content of the interview was indicated to be confidential.

As is commonly stated in their publicly available presentations: the interviewer is more so interested in interviewee’s ability to analyze and solve a problem than their ability to code. A fundamental understanding of the chosen programming language is of course required, but my interviewers allowed the use of loose pseudocode to explain ideas which would have required multiple lines of instructions. After each implementation, the interviewers indicated particular instructions which would have resulted in errors and allowed me the opportunity to identify and correct the error before moving on.

Final Thoughts

Being my first internship technical interview, I allocated a large percentage of my free (and not so free) time to the review of concepts which had the potential to be discussed during the interview. In actuality, hardly any topics I specifically reviewed were discussed. All questions would have been answerable without the review but not with the level of detail I was able to provide. In hindsight, the amount of preparation, though appropriate for a full-time position, was overkill for an internship.

Within two weeks, I will hopefully hear about candidate projects which are viable with my skillset. If not, then I will have to consider other internship opportunities.

CST 438 - Week 8

5 important things I learned in the course

Software Engineering is not programming

One of the questions I had coming into this course was how software engineering is different from software development. I was already aware of the controversy over calling oneself an "engineer" as a software developer. While that issue may never be resolved, and the titles are often used interchangeably, I do see how there is a difference from a regular programmer and one who applies engineering principles to software development. Software developers write code just like software engineers, but "software engineering is programming integrated over time" (Software Engineering at Google). Software engineering focuses on project sustainability, scale, trade-offs, and costs (financial, resource, personnel, societal, etc.). This means that software engineers have a greater responsibility than just writing code and follow a different set of "best practices" than your average software developer.

Agile Software Development

As stated in my previous blog post, Agile focuses on continuous releases and frequent customer feedback, allowing dev teams to be flexible and able to adapt to changing requirements. Some of the key Agile concepts include user stories, daily meetings, small teams, incremental development (each version builds upon the previous version), and iterative development (redesigning previous work). The Agile lifecycle repeats itself throughout the product's life span. One of the tools I was exposed to is Pivotal Tracker. It allows dev teams to easily create and track user stories and also to gauge their "velocity," or speed of development per iteration. 

Full Stack Web Development

Another concept that I was eager to learn about is what exactly "full stack" development entailed. Now I know that it just refers to developing both the front and back ends of a web application. Some people may specialize in one or the other, but a full stack developer is knowledgeable in developing both ends. This course provided some really good practice in this area, from the Spring Boot back end (and its use of JPA/Hibernate to communicate with the database) to the React front end. I had heard a lot about React but never knew exactly what it is. Now I know it is just a JavaScript library created by Facebook that allows for easy front-end development. It was also interesting to learn about service-to-service communication using tools like RabbitMQ.

Code Testing

Testing is one of the most important parts of development. Although writing tests can be time consuming, shipping broken code is embarrassing and can result in people losing faith in your software. There are different kinds of tests ranging from small to large scale. I think learning about unit tests (with JUnit and mocks) was a really important concept because I see a lot of job listings that require experience with them. However, I actually had a lot more fun with the large scale, end-to-end tests (with Selenium). 

System Requirements Specification (SRS)

Although we were only assigned an abbreviated SRS, I think it was still good exposure to documenting technical requirements. An SRS focuses on "what the software needs to do and how it must perform." One of the parts we focused on was providing the framework for our use cases. This turned out to be useful to me because I recently had to read a technical document for my internship that spelled out use cases for the system under development. My exposure to SRS writing made me feel much more comfortable when reading through and understanding the document.

CST 438 - Week 7

Agile vs Waterfall

Agile and Waterfall are two approaches to software development. Agile focuses on continuous releases and frequent customer feedback. It allows dev teams to be flexible and able to adapt to changing requirements. This is in contrast to waterfall project management, an approach that uses a clearly defined path with limited deviation. Customer interaction with the product doesn't occur until the end of development. This rigid approach works well when the development process is predictable. However, if anything goes wrong or needs to change, the dev team may experience costly setbacks and delays. The pros and cons of each should be carefully considered before choosing an approach.

CST 438 - Week 6

Security Vulnerabilities

This week I learned more about web-based security vulnerabilities. Some I was already familiar with, like SQL injection and DoS attacks. Others I either had not heard about or did not understand the technical details, like CSRF, XSS, and CORS. 

• CSRF (Cross-site Request Forgery) attacks allow attackers to send data to a website that you are already logged into. If the legitimate site relies only on session cookies for validation of user requests, it is possible for a malicious site (that you happen to visit) to take advantage and make HTTP requests using those session cookies. This may result in passwords being changed or information being stolen. One way to mitigate this attack is for the legitimate website to include a CSRF token with all requests. Tokens should be unpredictable and tied to a user's session. If the token is invalid or missing, the request is rejected.
• XSS (Cross-site Scripting) attacks allow attackers to "trick" web servers into returning malicious JavaScript code to their users. This can happen if user input is not properly filtered. For instance, if a website stores user input in a database for later viewing by other users (such as a car sale listing website), a malicious user could include <script src="..."> in their listing which would then be delivered to other users who view the listing, resulting in their browser running the malicious script. Attackers can use this to steal session information and impersonate a legitimate user, potentially stealing sensitive data like credit card information. One way for websites to mitigate this is to prevent users from including angle brackets in their input by replacing them with &lt and &gt, respectively.
• CORS (Cross-origin Resource Sharing) is a policy that allows web servers to request resources from other web servers outside their domain. For example, website foo.com may need to request a resource from bar.com (like an image file). However, web browsers do not automatically allow cross-origin requests due to their same-origin policy. This means that web servers must explicitly allow requests from outside their domain. If a web server implements its COR policy improperly (e.g., using wildcards in whitelisted domains) or makes it too lax (allowing requests from any domain), attackers can take advantage. 

OAuth 2.0 Message Flow

I also learned about OAuth 2.0, an authentication protocol that allows clients to access resources from web servers on behalf of a user. An example message flow is as follows. A client sends a login request to a web server which redirects the user to an authorization server (e.g., Google). The user enters their credentials, and the authorization server authenticates the client. The authorization server returns an access token to the client which is redirected back to the web server. The web server uses the access token to obtain information about the user from the authorization server (e.g., Google profile information) and informs the client that login was successful.