JG logo

Joshua Gilless

I recently received a question from someone (paraphrased and anonymized):

I’ve got 6 months to brush up on job skills and knowledge to get ready for the job market. I was hoping you could tell me the stack and skills that Clique uses? I want to focus on those tools and be best prepared for any openings at Clique in the future.

It’s a fun question, a lot of the advice out there is to “Just study algorithms and data structures”. But the truth is there’s a lot more to being a programmer than programming. The technology stack often doesn’t matter that much, but skills matter a lot.

So what does Clique use?

Well, a lot of everything. There’s the stuff that everybody uses: Javascript, HTML, CSS, and a CDN. These technologies aren’t going anywhere, the only thing that changes is how you use them. It turns out once you use them for a few years, you get used to the happy path. Doing things with them doesn’t take nearly as much time as it did in the beginning. It’ll take some time to get there, but continuously building things compounds learning.

There’s also the stuff that fewer people use: Golang, Appengine, Google Datastore. These are great technologies, but Appengine doesn’t take long to get used to. Datastore is a lot like every other non-relational database. Go feels a lot like if you took Javascript, and mashed it with C. Once you’ve learned one language, others are easier to pick up.

In my time here, I’ve written programs in PHP, Go, one random Ruby script, and every flavor of Javascript under the sun. Right now, we’re a Javascript and Go stack. Our current favorite JS library is React, but we have an old SPA written in JQuery that we still maintain. And to be honest, most of our JQuery could be replaced by vanilla Javascript these days.

So what’s actually important to working here? I think I can give 5 things that I think are important to working at Clique. These skills don’t go away from job to job, you’ll use them everywhere you go.

  1. Have “Soft Skills”
  2. Be Able to Learn New Things Quickly
  3. Know Your Tools
  4. Have Business Skills
  5. Know Data Structures and Algorithms

Have “Soft Skills”

I put this at the top because it’s the most important. The programming industry is small, you will meet a lot of people and you’ll run into them again and again. First impressions matter, but consistent good relationships last a lot longer than jobs. “Soft skills” is buzzword that doesn’t do justice to the importance of these skills. Empathy is not “soft”, it’s how you build relationships. Self-management is not “soft”, it’s how you get things done.

We all have heard stories about the brilliant jerk, who writes great code, but everyone dreads interacting with. Don’t be that person. Instead, be the person who can talk empathetically to everyone, from the senior managers to the people fresh out of school, in any department.

Communicating technical things to non-technical people is an incredibly important part of being a programmer. Don’t use jargon and do be patient. You didn’t learn everything you know in a few seconds of explanation, so don’t expect that of others. You’re a person first and a programmer second.

It’s almost a guarantee that you’ll screw up some times. Appreciate when people forgive you and give you room to grow, and remember to do the same for them. I haven’t mastered this at the moment at all times, but I am always trying to do better. It’s a good thing to learn from your mistakes and do your best to correct them in the future. Try to always treat others the way you want to be treated. This isn’t something that you one day become the master of, you can always do better.

Be Able to Learn New Things Quickly

Programmers are people and people don’t know everything. I write a ton of code and I can get really really far without looking anything up. The longer I’ve been doing it the less often I have to look things up. That can change quickly, I just started learning the Go programming language. Every core programming topic I know from Javascript transfers easily, but I end up googling the standard library a lot and using the docs to figure out which method does which thing. I’m slower writing Go than I was Javascript, but I’m picking it up quickly because I have a good foundation.

Part of your job will be getting new tasks of the form “Integrate with this…”. They’re usually quick, easy and simple. You still have to learn how to do them. Whether it’s integrating your ads in with some header bidder or speeding up your server logging, you’ll have to learn how to do it and then do it.

Know Your Tools

You’ll spend a lot of time in places you don’t expect and a lot of time in places you do expect. You can predict a few tools that you need to know your way around:

  • Your text editor of choice. VS Code, Atom, Sublime, Eclipse, Jetbrains, Visual Studio, whichever. Learn it and learn it well. Get to know the shortcuts and the editor.
  • Vim or Emacs. You’ll end up using them more than you think. Learn to navigate, learn to write, learn to save.
  • The Command-Line. Linux/Mac, learn to navigate, learn to command things to do what you want. Understand the Unix Philosophy. I can’t offer much advice on Windows, but I’d spend a lot of time learning the command line there too. Harness it, customize it, it will make you powerful.
  • Developer Tools of your environment of choice. Browser, compiler, whatever, learn to step through code, learn to read the errors and messages.
  • Scripting. I write tons of little scripts for things that I’ll use over and over again. You get some practice in and then you write little things in a few seconds and just start using them. They can easily be discarded when you’re done, but they’ll save you lots of time. Scripting can be done in any language you want, some are easier than others. Check out Bash for a good one to start with.
  • Typing. I joke with people that I type for a living, most of my time is in front of a keyboard, and a lot of yours will be too. Practice good ergonomics, work your speed up and learn to love your keyboard.
  • Source control. I use Git, there are other options and every one of them is better than none.
  • Testing. It’s worth learning a good testing philosophy. Test frameworks come and go, but learning to test the right things transcends frameworks. Testing is a tool you can use in any project to move quickly and release with confidence.
  • Continuous Integration (CI). Worth knowing, but may not be required. You can set it up to do tests, run builds, deploy your code with zero downtime. It’s great, know it at a high level and be able to learn how to set it up if you need to.

There’s plenty more, I’m sure, if you find yourself using a tool often, learn it well. The dividends of knowing your tools add up quickly.

Business Skills

You’re a business asset! Hopefully, you’re an asset. If you’re not an asset, you’re probably a liability. Don’t be a liability.

Selling ideas, and sometimes yourself isn’t really a skill that most programmers expect to need in their careers. You will have a lot of ideas that you’ll have to sell people on. You’ll have to negotiate timelines and priorities. To sell things, you need to be able to communicate ideas clearly and thoughtfully.

Business skills aren’t really taught in engineering school, but understanding the business you work for will help make you more valuable to the company you work for. Much of your value will be in writing code, but you’ll find out how to write the right code by having good business skills. Find out the requirements before you start, discuss things and then build the right things together with the business.

Data Structures and Algorithms

For a long time, I was sorta scared of all things Computer Science, I had a few classes in college, but there was a lot out there that just sounded intimidating. What’s a red-black tree? What’s a trie? When should I depth-first search, when should I breadth-first search? What’s a Dijkstra?

What I’ve found recently though is that I can understand these algorithms a lot better than I could even a few years ago. You come across a lot of random knowledge while programming. All of that knowledge builds and compounds and you end up knowing data structures and algorithms better than you expect. DOM traversal is tree traversal. document.querySelector is just DFS. After you’ve been programming for a few years, you’ll pick up more on this than you expect.

Lots of people say it in the reverse order: “Algorithms and Data Structures”, which is nice and alphabetical. In my opinion, algorithms often tend to show themselves based on the underlying data structures. You’ll write better algorithms by understanding the data structures available, what they do and when to use them. You might not need a course on it, but it helps to at least understand the basics.

I hesitated to include this section due to how broken tech-hiring is. Interviewing in the HackerRank style doesn’t promote diversity, it self selects people who already have access. To pass an interview like this requires studying. Interviews that require 5 hours of commitment on-site select for people that can afford to take that off of work and sometimes afford a babysitter. Hiring like that makes access one of the strongest signals.

With tech hiring as bad as it is, we still are operating within the system. Plenty of companies model their hiring practices off of Google or Facebook. You can choose to not work for companies that hire with these practices, but I’m not sure that I’m one for protest votes.

Why do Stanford students pass Google interviews at a higher rate than Howard students? Here’s an excellent thread on Twitter by Mekka Okereke that shows this better than I can. Basically, Stanford students have a class on how to pass the interview, CS9. You can probably guess what happened when Howard students were given the same access. For now, we do have access to a course on Coursera, Mastering the Software Engineering Interview. Which is probably a good refresher, I haven’t taken it, but I would if I was interviewing in 6 months.

There’s also sites like LeetCode or HackerRank that you can use for practice. These problems are nothing like what you’ll likely end up solving at work, but if you approach them as a game, like Sudoku or Set, you can get a lot of programming practice from these. You can even solve them with a pencil and paper for bonus whiteboarding practice.


If I knew I was going to be looking for a job in 6 months, I would build a few things. Put a few random little projects online. Make up your own projects. Remember that everyone builds a todo list, but just ‘cause everyone does it doesn’t mean you can’t too! Clone a popular site, Reddit and Hacker News get cloned all the time. Clone flappy bird or some other simple game.

I would spend time reading. Read up on anything software related. Learn cool things, like graph traversal, linear algebra, geometry. Learn random things that you’ll probably never use like how to turn on your webcam with OCaml or how to animate a bouncing ball in CSS. Every piece of knowledge you gain compounds and you’ll eventually end up knowing more than you even knew was possible when you first started.

I would spend some time writing my resume. I’d pick what I think needs to be on my resume, learn it, build a project with it and then put it on my resume. It might even be good to keep your LinkedIn up to date.

I would study data structures and algorithms. I would join a site like LeetCode or HackerRank and pick a language. If the jobs I wanted to go for were backend, I’d pick something like Go or Python, if the jobs were for frontend, I’d pick Javascript/Node. Then I’d do lots of problems in that language.

When the time came, I’d apply, I’d go in with some confidence that I have the basics and can learn what I need to.