Introduction

The general format of the interview process at software companies for software engineers consists of three parts: recruiter screen, technical screen, and on-site interview. A phone screen is usually the only part of the technical screen and the immediate barrier to being brought on-site for the final stage. The technical phone screen is where you complete a set of coding challenges given through some shared collaboration editor while speaking to another person who is evaluating your performance.

Continue reading “How to pass your technical phone screens”

Introduction

Dynamic programming (DP) is just recursive programming with caching. The cache comes in for saving the results of smaller subproblems.

Because we ultimately have to solve smaller subproblems, we have to traverse our solution space. You can think of the solution space as a directed acyclic graph where each node represents a subproblem. Each outward edge from a node represents immediate dependence on a smaller subproblem. The solution space DAG (directed acyclic graph) will have leaf nodes which have no outward edges. These leaf nodes are base cases.

There are two general ways we might go about solving a dynamic programming problem and they are labeled top-down or bottom-up. Solving a DP problem top-down is like traversing the solution space in post-order depth first search (DFS) starting at the root node. Solving a DP problem bottom-up is like processing the nodes in breath first search traversal starting at the leaf node. That last statement is not quite true from a technical standpoint, but the general idea of computing sub-problems in order of “closeness” to the base case is accurate. In the bottom-up approach, we only compute a sub-problem when all smaller sub-problems have been computed. One implication of this is that the bottom-up approach doesn’t involve recursion.

Continue reading “Interesting case study in dynamic programming”

A hint of an undercurrent

Undercurrent: an underlying feeling or influence, especially one that is contrary to the prevailing atmosphere and is not expressed openly.

When I see job listings in software engineering, there are three frequently listed areas of study: computer science, electrical engineering, and mathematics.

That computer science and electrical engineering are on the shortlist is not surprising. The core curriculums involve a substantial programming component and promote an understanding of computer architecture.

The odd one out is mathematics. It is strange because the core curriculum is not particularly relevant for writing software. It’s easy to graduate with a degree in mathematics without ever having written a computer program. If fluency in mathematics is a qualification for software engineering, it has to be something other than exposure to software engineering concepts.

Continue reading “What technical recruiters and managers don’t know about physics students”

Pre-requisites: A conceptual understanding of what recursion is, as well as other basic concepts in algorithms like: asymptotic notation, time complexity, and graph traversal.

Dynamic programming is an optimization of recursive solutions by using a cache. If you have a recursive solution (e.g. Fibonacci sequence), then we call it dynamic programming if we make use of a cache to optimize performance. Dynamic programming is a trade-off where we use extra memory to reduce the time complexity by more than a constant factor. For traditional dynamic programming problems, we are forced into this choice by an exponential recursive solution with unacceptable performance. DP is probably fascinating because with a relatively small optimization, exponential recursive solutions are transformed into linear solutions.

Continue reading “Top down and bottom up dynamic programming simplified”

When I transitioned from physics to software engineering, it felt as if I was playing life on hard mode. Learning about academic computer science, coding, and taking coursework wasn’t the difficult part, though. What was challenging, and this often surprises people, was that I was often discounted because of my background. It was a bizarre situation where it was easier to pass interviews than it was to get them. The details of this are for another post, but this weird situation made it prudent to understand some core aspects of what profile recruiters are looking for. That is, among an ocean of resumes that pass the minimum requirements of a job listing, who gets picked to interview and why, when the choice is completely at the discretion of the recruiter? From my conversations with recruiters, some AB testing, and other surreptitious methods, I found that there were four factors that really stood out as good predictors that recruiters would want to network with you. These factors are part SEO and part unconscious biases.

Continue reading “Big four elements of branding for a software engineer in the early stages of your career”

This is my favorite case study among bugs I encountered while working on a search engine at FactSet.

Some context is necessary: The front-end for this search engine is html-based, and it has a feature where charts are shown for some queries. For example, type in “price ibm” and a little chart might show the stock price over the last 5 years. It’s an attractive visual component and also a core part to this kind of feature (showing data in response to a query in addition to links). We have maybe 10 – 15 direct javascript dependencies, each of these having their own dependencies, etc. This chart is rendered by an internal charting library at FactSet. There’s a CDN for which we use a CDN resolver. This CDN resolver takes those script element source files and changes them to direct CDN links if possible. This CDN resolver is buggy so some dependencies are hard-coded to use the CDN directly. Managing these dependencies as they update versions is challenging. We promote devel to QA on Tuesdays. We have internal tools to quickly test the product, which is very close to a clone, but technically a similar imitation.

Continue reading “Post-mortem of a strange bug: dependencies that aren’t what they appear to be”

To run

g++ --std=c++11 -g -pthread [source-code-file]

Summary:
We spawn one thread for each character we wish to print and force all spawned threads to sleep with a condition variable. With the go() function all threads are woken up. Each thread has two parameters: the character it is meant to print and a value which forces synchronization among the threads so that the threads execute in a specific order. The synchronization value is the test condition for a while loop whose body forces the thread to go back to sleep, and the test evaluates to false when this synchronization value is equal to a global counter. Once a thread exits this while block, it prints its character, increments the global counter, and wakes up all other threads waiting on the condition variable.

Continue reading “Programming oddities: Multi-threaded Hello World program”

Dear reader,

If you have just realized the magnitude of your misfortune by stumbling into this strange place I am sure you doubtlessly have many questions. Like:

• How did I get here?
• Who are you?
• What are your intentions?
• Are you going to let me go?
• How do I get home?

The first question has a simple but unsavory answer: You were simply unlucky. You probably were driven to the edge of sanity with yet another opaque and awesomely inscrutable compiler error and had an epiphany. That epiphany, at least for me, was that compilers couldn’t exist in a fair and just world. If compilers exist, so must the devil. In your desperate search for meaning in an unjust world, you probably slipped on a hyperlink and fell far into the deepest pit of the clearnet, where we made our chance acquaintance upon your awakening.

Continue reading “Genesis post”