Protect Your Users

Aug 19 2020
As software developers, we have more power than we realize. Our programs directly affect people and influence their behaviour. It's a good idea to take a break from coding from time to time, and ask yourself this question.

Would I use this product myself?

Or, its corollaries:
  • Do I want my personal and sensitive info shared? 
  • Do I want my data be given to big tech companies, sold to the highest bidders? 
  • Would I be happy to be driven by this autonomous vehicle? 
  • Am I comfortable doing this? 
If the answer is no, take action. Make change in the software to protect your users.

At CityView, I am building an application that allows city inspectors to conduct virtual video inspections with the contractors, without having to drive all the way to the location. The inspector, from his home or office can talk face-to-face with the contractor, just using the browser, without having to install Skype, Zoom, or WhatsApp. It's a really useful application, and I am really having so much fun programming it, using WebRTC and Twilio Programmable Video.

The latest feature I implemented allows the inspector to record the entire virtual meeting just by clicking a button. The easier way to implement this recording feature would have been just to use a third-party library, or use a video framework from a big Silicon Valley company, record the video, and store the video on the cloud, which is just someone else's computer. I would have finished in a couple of hours and life would have been great.

Except, when it came time to testing the feature, I was hesitant. I faced the phone camera away from me, outside the window to not record myself or my personal space. I didn't even turn on the webcam on my desktop. I didn't want my video to get uploaded to cloud, no matter how safe and password protected it was. 

Which bring us back to the question in the beginning. If I am not willing to use this feature, how can I expect the poor inspectors and contractors to use it, record their homes and offices, and trust that the app is not selling the recording to the highest advertisers online, or storing it in an insecure way, vulnerable to hacking, or exposing their private lives to the world?

Once that realization set in, and I got over the shame caused by the question, I redesigned the complete recordings architecture, and re-implemented the entire workflow. Now, the entire recording is captured and stored on the inspector's computer, safe in the city's servers. Their IT staff knows which physical machine it's on, and delete it permanently if not needed. It's not getting uploaded to a cloud server farm in somewhere far away, or sitting on a cheap laptop waiting to get hacked; but it's on their machine, in their hands, and they take the responsibility for it. The contractors can ask the city to delete the recording, if it contains any sensitive information, knowing that it will be done according to the data privacy act.

Implementing the second design was much harder than the first one. I had to think hard about it, use the native apis provided by the browsers, worry about synchronizing the audio and video streams of multiple users at the same time and storing them on the inspector's machine. The design became more complex, and the code size increased by a factor of five. However, the assurance I had when testing the video was priceless. I didn't hesitate while recording, knowing that the video is going to be stored safely on my computer, and I can delete it whenever I want.

As software developers, we are literally building the future. Each line of code we write can have massive impact, both for good and bad. Given that responsibility, we should think about the long term effects of the code we are writing and take responsibility and ownership for it.

Here is Joel Spolsky, founder of Fog Creek, creator of Stack Overflow and Trello, and a very influential programmer that I admire and respect so much talking on this topic.

Support Calls

Aug 14 2020
One of the quirks of being an enterprise software developer is that when your users find a problem with the product, they actually call your company support. Most of the time, the support resolves the issues on their own, but sometimes, especially for complicated ones, developers have to get on the call and see what's going on.

Most of the CityView R&D team is on vacation for last couple of weeks, and I've been swamped with the requests from the support, implementation specialists and the project managers. This week alone, I have been on call with the clients three times.

I have to say, getting on call with clients and to watch them use the software that you wrote can be a humbling and very enlightening experience. You get to watch your users struggle with the software you helped create. It is very painful to see them click a button, and see "Object reference not set to an instance of an object" error slapped onto their face, just because I didn't check if a variable was null before I called a method on it.

Programmers who are two or three levels removed from the actual users of their code are unlikely to be aware of the context in which their work is used. They will not be able to make informed decisions.

Raymond Chen puts very elegantly in his 17-year old post, A day in the trenches,

Product support calls let you participate in the other end of the pipeline. The software is written, it’s out there, and now you have to pay for all your mistakes and bad designs when people call in with their problems. It’s software karma.
I think all developers should be made part of support calls, occasionally. It helps build empathy, when you are writing software. Not just for your customers, but for yourself, few months from now, facing a strange error, just because the current me didn't write a clear message indicating what and where something went wrong. 

The Google Resume

Jan 25 2018
While preparing for the Microsoft and CityView interviews, I did a lot of meta reading on interviews and resume building. I came across a few really good resources such as The Google Resume from Gayle Laakmann McDowell. I also read a bunch of blog posts which I have grouped in this same post. 
This doesn't cover everything, but I think it covers the most important foundational elements. Also, this is not a summary and/or my thoughts on the interviews, but a collection of my notes and highlights from the books and blogs that resonated with me, so if the tone of the text sounds different, that's probably why. Here we go..

Setting expectations

If this is your first time looking for a job, or you haven't had to interview in a number of years, expect to invest some effort in preparing for the interview. It's usually the industry professionals that completely ignore this step, but some college students do as well. 

You're essentially studying for a test, don't slack off - it's going to be work. All of those things that you've been telling yourself don't matter (maybe you're a bit fuzzy on how exactly the internet works - do you really know what happens after you hit enter on the URL bar?) that you don't know - now it's time to address those gaps head on. 

For the sake of space, I'm going to focus on what a fresh grad needs to do to prepare and that's more consistent across companies (and it's a shorter list).

Data Structures

  • Array
  • Linked List
  • Stack/Queue
  • Trees (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc. Learn as many as you can)
  • Heap
  • Hash Table (this is really important - understand all of the different collision mitigation mechanisms, understand what amortized constant-time means)
  • Directed/Undirected/Weighted Graphs
  • Trie (pronounced "tree")
  • Linked Hash Map (this is very specific, but comes up a LOT in interviews)
You should know the Big-O for insert, delete, lookup, etc. for each of these. Know how the mechanics work. It isn't a good interview questions, but you should be able to code every single one of these. Then, prepare real-world examples of when you'd want to use each of these and explain why it's the best choice. Data Structures come up in technical interviews in two way. The first is in coding questions where you're expected to use the right one at the right time. The second is on a comparison question - not connected to code - "why would you use X over Y in situation Z."


Again, make sure you actually code these for real when practicing. Simply reading code someone else wrote will not cut it. Open up your favorite IDE and start typing. This is critical because often times you actually have a gap in your knowledge, but your brain convinces you it's ok (this happens without you even realizing it). The only way to find these gaps is by writing code. Know all of the Big-O for this and how it's derived.

You don't have to go crazy here, but review a couple of:
  • Sorting algorithms (both comparison sorting and non-comparison sorting)
  • Tree traversals (just memorize all of these inorder, preorder, postorder, level order)
  • Traversals - Dijkstra's, A*, BFS, DFS (know the difference between DFS and BFS when would you use one over the other and why - hint, is usually matters when you don't have to search the whole space. Also make sure that you can code recursively and using your own stack/queue)
  • All the prefix-tree searches
Great, you're about 60% done now. Now you need to practice applying this knowledge. Find a source of interview questions (random websites, glassdoor.com, cracking the coding interview, etc.) Code answers to those questions. 

I strongly recommend forcing yourself to pretend you're in an interview setting. Most of these questions should be solvable in ~10-15 minutes, some will be more like 20-25. Time yourself. Before you write a single line of code, organize your thoughts and figure out the entire solution, then start coding. 

The coding part should be boring and straightforward. In the actual interview, do the same thing. Before you write a single line of code, make sure that you validate with the interviewer that your approach is a good one. Practice practice practice this stuff.

Fill Gaps

This is where you get to be honest with yourself. That long list of things you don't know that you keep telling yourself is ok because the stuff you don't know isn't actually important....well, it is. Even if it isn't, your interviewer might think it is and it's better to have a job than be right. Here's a list off the top of my head that I hear people say isn't important (but you really should know).
  • Writing code - (I put this here half as a joke. I can't tell you how many people with 15+ years of experience lose their mind when I ask them tow write some code with me. These "architects" do not end up getting jobs. Same goes for managers and other support positions. I know that you're not going to write production code, that's fine - you should be able to write some code, though.)
  • Bits and Bytes - Yes, you should understand how all that bitshifting stuff works in whatever language you're going to interview with. You should know what big and little endian are. Do a couple practice questions, even simple one. Try something like..."write a method to determine if the bit-wise representation of an integer is a palindrome."
  • How the internet works. This applies more to companies....yeah....it applies to everything these days. You should know how sockets work, you should know what TCP/IP is. You should know what HTTP actually is. Learn your networking layers and what's responsible for what. You don't need to know all of the details of the protocols, but you should know some of them and that they exist. This sounds daunting, it should only take a couple of hours.
  • Databases. Learn some basic SQL and data modeling if the job you're applying for uses databases.
  • Learn a bit about testing. Write some code and test it. What's TDD
  • If you've only ever used Windows....consider using linux for a bit.
  • Whatever else you can think of. A good mental exercise is to imagine yourself in an interview..."man, I hope they don't ask me about X." Figure out what X is and read about it.
The good news is, the things on this list usually are far easier to learn than you think they will be. These are usually scars from undergrad or gaps from a non-traditional route to CS that sound hard. They're all easier to tackle than you think.


Alright, almost done. Tech interviews aren't all about tech (they mostly are these days, but not completely). You need to come across as someone people want to work with. Smile, be energetic, be excited about the company, know what they do, have ideas about what they could be doing. You're almost certainly going to encounter some behavioral interview questions. You can prepare for these. 

I suggest coming up with 3 situations where you were working on a tech project and things went well, and 3 stories for when things didn't go well. Then practice telling the stories, make sure to include some setup information, what was the setting, what was the project, who was working with you, what was your role...then tell the story....then for the positive stories talk about the impact of your work, did you win, save the company money, what? For the negative stories, finish up by talking about what you learned and how you'd approach the problem differently in the future.

Parting Words

Get a good nights sleep and do the best you can. Expect to fail at some of these interviews, that's ok, treat it as a learning experience and recognize that there are both good and bad interviewers. It's possible for a terrific candidate to get thrown to a bunch of shitty interviewers and not end up with a job (happens more than people like to talk about). That isn't to say that you should use this as an excuse to not learn from the experience, but interviewing is a game. Don't try and fight the rules or think it's stupid. It is what it is and that's what's standing between you and the job you want. Learn to play the game and win by practicing :-)

Best of luck, sorry for the typos. For the people just getting started, you aren't a fraud, we all know how little fresh college grads know, we factor that in to the ramp-up process. Be prepared to work hard.

Don't Sell Past the Close 

To all you extroverts out there, I can't tell you how many times someone's been just a bit too honest. When I'm interviewing you, I'm your best friend. My goal is to get you as relaxed as possible for a couple of reasons. First (and really the main motivating factor in choosing to be nice), your performance is best reflected when you're relaxed. Freaking people out is expensive because some awesome engineers just freeze up when overly stressed in interviews (I've also found little correlation between interviewing-stress-paralysis and real-world-fire-drill-paralysis). 

I'm nice because I don't want to exclude certain types of introverts from the hiring pool. The other reason I'm nice is because extroverted people think we're friends. We aren't friends, I'm interviewing you. I don't care how much you think you're clicking with your interviewer. He's invited you on his boat already, etc. You aren't friends, so don't run your mouth.

It's human nature to want to form bonds with people and one way we make friends with people is by doing this elaborate dance of sharing secrets with people. Early on there's a tendency to share some extra truths, usually fairly mild, but in an interview setting - bad idea. Things I've heard:
"Yeah, I know it sounds impressive. But hey, between you and me, I only really had to work 5-6 hours a day to get it done."
"I know I'm not supposed to say this in an interview, but the real problem was my co-worker. He was such a stickler for the littler details we could never get any code pushed out." (Actually anything that would start with "I know I'm not supposed to say/talk about this in an interview - just avoid that).

Don't over-share. If you think something is going to make you look bad, it probably will.

Exceptions to this rule: There are a few things that people think are bad which are perfectly fine: 
  • Admitting you don't know something (better than making stuff up) 
  • Asking questions to make sure you understand the problem 
  • Saying that you're a bit nervous and want to take a couple seconds to compose yourself (totally fine, don't be overly dramatic about it, though)
You can be friends with the interviewers you like after you get hired. Don't give people reasons not to hire you for free.