There's a few computer science principles that can be surprisingly applied to general life. As an example, the notion of greedy algorithms. One can liken the idea of optimal choice at every iteration to trying your best daily so that it works out over the long term -- seems reasonable.
Another one is the idea of instructions, that is, single operations for the processor. Code in aggregate is difficult to comprehend, but when taken line by line, make for a narrative of sorts. The key is that the big concepts are broken down as much as possible, to the point where the processor can accomplish a single task.
This works outside of computer science too. The notion of building a great career over 40 years can be intimidating, but can also be broken down: are you improving technically? Are you taking on harder tasks? Do you demonstrate enthusiasm?
Let's say you do want to improve technically. What area do you want to improve? Maybe your database systems knowledge needs some work. Perhaps you haven't worked much in the browser, but want to learn more.
Once you've determined the area, the actual step may be to read an article or watch a video on the topic. At this point, you have an actionable task that you can do and check off, knowing full well that you've made progress toward your goal. You can't decide that this afternoon you want to "build a great career" or "master database systems", but you can go through a few Lynda videos on the topic or scaffold an app.
If you've been meaning to start something and have been feeling resistance, try breaking things down until you can do something, and see if that helps.
I'm trying something new: AlgoDaily was created to help developers land their dream jobs, but a huge part of why we want them is to build wealth for ourselves and loved ones. I'm going to start profiling software engineers from humble means who've built generational wealth, both on Twitter and this newsletter.
As of this writing, there's a lot of political unrest in the United States-- but imagine growing up in an environment far worse and having to flee. Jan Koum grew up by Kyiv, Ukraine before moving to California, and his family had to rely on a social support program to get by.
Growing up, he often got into trouble, and barely graduated high school. What kept him going was a deep interest in computing and networking, which he tended to by buying and returning books as soon as he read them.
Eventually, he became skilled enough to land a job at the former powerhouse Yahoo!, and quit college to work there full time. But like many smart engineers, he eventually got bored and looked for opportunities outside of Yahoo! One of them was Facebook, but he was quickly rejected.
Not one to despair, Jan kept on looking for new ideas and eventually bought an iPhone. Realizing that this was going to change the way people interacted forever, he started working with a friend to build a communication app for it. He chose the name WhatsApp because it sounded like “what’s up”.
At first, WhatsApp was largely unpopular— but then Apple added “push notifications”, making it much more useful. By the time a fellow named Mark Zuckerberg asked Jan to dinner to discuss a deal, the app had 400 million users. Today it has over 2 billion.
The big takeaways from Jan’s story? First, rejection can lead to an even better path in life. And secondly, technological shifts reveal some of the best business opportunities and pivots.
If you learned something from this thread, consider following me on Twitter at @jzraps. Also be sure to check out the most accessible technical interview course available-- sale extended through this weekend.
Getting hired for a tech job is not the easiest thing to do. Although there's undoubtedly a significant shortage of tech specialists in America, it doesn't make the playing field less competitive. That's why you need to play your cards right and go for those skills that will be highly in-demand in the next couple of years. Here we've compiled a list of the most sought-after skills in the industry based on multiple online reports including Indeed Hiring Lab.
Machine learning, which falls under the artificial intelligence umbrella, is a powerful skill that is expected to change several industries including drug development and the stock market. This technology involves programming a computer to learn by itself without human intervention. Through different programming practices, a machine learning engineer can make a machine identify objects, patterns, and anomalies in datasets.
Since there's no designated bachelor's degree for machine learning, people who want to become machine learning engineers need to opt for a computer science degree, bootcamps, or self-learning. However, don’t worry, because there are some great machine learning bootcamps out there, such as the ones offered by Galvanize. At the school, you'll learn the fundamentals of mathematics and statistics, as well as programming languages like Python, among others.
Data science is the ability to study data to get meaningful insights to solve problems, identify phenomenons or errors. Data scientists are some of the leading tech professionals today, and this trend will only continue to grow. Companies that don't have the help of a data scientist are at risk of falling behind in their marketing strategies and business decisions. So this could give you an idea of how essential this skill is for every company.
Now, if you'd like to become a data scientist, you'll need to have some mathematical knowledge, as well as statistical and analytical thinking. There are some outstanding schools out there that can help you become a certified data scientist. Springboard's data science program, for instance, will introduce you to the most crucial aspects of machine learning, such as data filtering, data analysis, and even data visualization, among other relevant subjects.
Software engineering is another fundamental tool for companies to optimize their operations. When there are repetitive and redundant tasks, a software engineer could create a solution that helps smoothen and quicken the process. On top of that, they are responsible for creating, maintaining, and updating software. That's why a software engineer is usually a long-term position.
With the evolution of big data, the need for cloud engineers has also grown. Companies no longer rely on large rooms to hide and save their databases; they're using cloud systems that are more secure and accessible. Cloud engineers are the ones responsible for building and maintaining these systems to ensure they remain efficient and safe from potential threats.
To become a cloud engineer, you need to understand platforms such as Microsoft Azure or Amazon Web Services (AWS). In order to pursue this career, you need to get a certification that validates your proficiency in any of these platforms. Some of the best AWS bootcamps** **out there are the ones from Coding Dojo or Code Fellows. Both schools provide students with flexible payment methods and schedules.
This is the era of data; almost everything relies on it. Therefore, digital products and platforms must be created in a way that they're able to have efficient data systems. SQL is the coding language that is used to create and maintain database programs. This skill is especially important for data scientists or other professionals who work with databases and data-driven systems. If you want to get some examples of real-life situations when you use SQL-driven platforms, just think about technology or devices that depend entirely on their data systems like news platforms and Amazon’s virtual assistant, Alexa.
SQL is a programming language, so there are some basic courses where you can learn this skill. such as General Assembly's beginners SQL bootcamp. In this course, you'll learn everything you need to know to master this skill in a short period of time.
As mentioned, data is everything these days, so it's no surprise to hear that companies want to keep it as safe as possible. If fallen into wrong hands, datasets that contain a lot of sensitive information could jeopardize the actual safety of the masses and put businesses in a bad financial state. Therefore, it has become imperative for most organizations to hire cybersecurity engineers to keep their data safe. After all, a criminal cyberattack could become a company's worst nightmare. A cybersecurity engineer is a professional who creates policies and systems to protect data.
Flatiron School's cybersecurity bootcamp could help you understand all the processes involved in the creation of cybersecurity policies and systems. In this course, you'll be trained by cybersecurity veterans and you'll have one of the best labs in America for your practices.
Python is a very in-demand tech skill these days and will continue to be so in the next couple of years. It is a programming language used by data scientists and machine learning engineers, among others. If you're new to tech terminology and know nothing about coding, Python can be the best first language you learn because it is easy and straightforward to use. The syntax is simple and some even say it's similar to writing in English.
If you want to dive into this skill, you can take a look at some of the best Python bootcamps out there, such as the ones from Coding Dojo or Code Fellows.
The past few months, my side hustle and technical interview course AlgoDaily hit $3k USD MRR. It's a small amount compared to my software engineering position at a large tech company, but it covers rent and gave me something to work on during COVID. While running this project, I learned a ton of stuff that's been really useful for both the business, as well as for at work. Here's a small sampling.
This statement is of course being facetious, but not to a tremendous extent. Many outsiders will think that in a software project, engineering should roughly consume 50% of your time, and marketing/sales/biz dev the other half.
This is great in theory, but it turns out that marketing/sales brings in 100% of the money-- shocking, right? The old adage rings true: you can literally have the best product in the world, but if no one knows about it, it won't really matter. Likewise, when people are on your site or app, they just care that the button works when it's clicked. Only fellow developers will find it cool that you're using turbolinks or react-dom-router.
For the first year and a half of running AlgoDaily, I spent nearly all the time improving the product, and refining it technically. I built a daily coding newsletter and wrote hundreds of long-form, quality solutions. Then added an editor and runtime to the site so folks could execute solutions. Then I hired a team to add solutions in other languages. Then I worked with a team to create hundreds of beautiful visualizations and diagrams. None of these things improved sales dramatically.
You know what did work? Telling people about it! Sharing my work with communities (shout out Hacker News and dev.to), asking email subscribers to check out the premium course, getting and sharing testimonials, and spreading the word via social media/youtube/meetups-- getting people's attention was by far the most crucial thing for the sustainability of a small business.
One huge mistake I made in the very beginning was mistaking content plays with platform plays. It's too easy for a software product to just be labeled "software", and for its founder/maker to start listening to generalized advice that may not apply.
For example-- "it needs to be 10x better". Not if you're a content business! An online course, newsletter, or Youtube channel only needs to be marginally better to have users make the switch. Think about it-- if I have the option to watch Selling Sunset or Million Dollar Beachhouse, I'm picking Selling Sunset every time even though it's just a minor improvement in quality.
Another one-- "build an MVP first and iterate". If you're trying to offer articles, tutorials, videos, or podcasts-- an MVP is just episode one. You won't learn much until episode 100 or so!
AlgoDaily really started to take off when I got burned out after the first year for several months. I then started hiring people to help with nearly everything, and only then did it start seeing traction. If you're a solo maker, don't hesitate to hire!
The term "indie hacker" is kind of bull, largely because there's no such thing as a pure one-person business. Yes, one person may oversee or run things, but the second you need vendors (hosting, forms, newsletter, graphics, design), you've started to build a team. It may be a low-touch team, but if any part of your business depends on a third-party solution, you're no longer on your own.
I think the majority of entrepeneurial advice/content is largely useless in the moment that it's being consumed. I now strongly believe in favoring just in time advice versus just in case advice.
What's the difference? Just-in-case advice is when you peruse indiehackers.com or pick up a business book for entertainment. You'll read a case study to get motivated, or to get inspired, but it's probably not useful to you at that moment. There's nothing wrong with this-- in fact, I'm having a great time reading Reed Hasting's new book on Netflix-- but I know that it's infotainment.
Just-in-time advice, on the other hand, is when you don't know how to do something and look up a tutorial. It's when you feel chronic fatigue and see a doctor, or have a specific legal question and seek out a lawyer. I've found business advice to be much more useful here, because it's specific to the problem at hand.
It's cool to read up on how an ivy league grad launched a multi-billion dollar startup when she was 21, but almost none of what they did or said will ever apply to someone creating a small online course while trying to start a family. Learning about morning routines and what founders read is dope, but what will actually help your hustle is to try everything and learn from failures.
99.9% of AlgoDaily users are lovely. I've corresponded with hundreds, if not thousands of you at this point, and for the most part you're all great! I've made several mistakes along the way, and the AD community has been extremely forgiving and encouraging even during big mishaps.
However-- there really is a correlation between willingness to pay and customer quality. The nastiest emails I've ever gotten have been from folks who've bought a subscription during a sale, paid for a month (the absolute minimum), and then demanded a refund while deriding myself and the product. On the other hand, the folks who pay for the most expensive packages upfront, or stay subscribed for many years, never complain and are usually the first to give testimonials and praise in public.
I'm not sure what to make of this. I price AlgoDaily at a ridiculously low price. You get a daily coding email, hundreds of illustrations, and video solutions for what amounts to $5-6/month if you pay annually. I do this to try to help folks and give back to the dev community, obviously while also learning some things about running a business-- but why people will be rude and mean while getting so much value (and often completely free content) will never make sense to me. What a fascinating phenomenon.
As every thought leader now says, hope this brought you some value. If you're preparing for technical interviews, consider the best and most accessible course available.
There is perhaps no aspect of the field of software engineering that is more disliked than algorithmic whiteboard interviews. You know what I'm talking about-- sometimes they're called "algorithms and data structures", other times "leetcode-style" questions.
People dislike, and I mean, really dislike these interviews. Here's a sampling of quotes I randomly pulled from Hacker News. First, there's concerns about their effectiveness on a per-interview basis.
Most interviewers don't ask enough technical questions to have any idea what a candidate knows or doesn't know. If their one or two questions happen to be something the candidate knows well, they'll call them a genius. If they happen to not know, they'll label them an idiot.
We've already covered why companies use such interview questions. The problem is that they may be hit-or-miss for each person, but they're incredibly useful when hiring at scale. Other comments lament the interviewers themselves:
I find most interviewers unprepared to evaluate the person for the role, and instead exercise their own biases, stroke their egos, etc. It's largely a voodoo practice that we'll look back and laugh at as a civilization at some point.
This next one is what we'll be discussing. I've heard over and over again that studying algorithms and data structures isn't really applicable in day to day life.
There are companies that will pay near FANG levels (maybe 10-15% haircut) without subjecting yourself to onerous completion of hundreds of LeetCode problems. There are other options, and we should be aware of them. You'll still need to prove you can code, but the questions we ask have practical application to our codebases: we use recursion and trees, for example, so we ask questions about those.
The above commentor seems to be arguing that the top companies focus more on algorithms and data structures that don't appear frequently in real-life. He talks about recursion and trees are examples of "more applicable" concepts in day-to-day software engineering. This is true to an extent.
No, I have never had to implement a linked list at work. (For some reason, people always point to this as the classic example.)
No, I've never encountered a red-black tree in my career thus far, and I hope I never will.
Yes, I've tended to lean on some pre-built abstraction (database, library, framework, or other) to get my work done, without implementing fundamental algorithms.
However, has studying for them, and knowing these problem-solving patterns, made me a better engineer? I would wager an astounding yes. Here are some ways:
With these kinds of interviews, you're often nervous and coding in front of a stranger. When this happens, it's really easy to lose track of where you are in a problem.
The thing that helped the most with keeping the problem's "state" in my head, whether on game day or practicing these problems at home, is improved variable and function naming. There are two important constraints in this unique situation:
The reason for #2 is because you'll often have multiple pointers, nodes, or counters to keep track of.
pointer2 don't really work when they do completely different things, or are conceptually moving in different directions. You eventually realize
endingPtr help you remember their purpose, and eventually graduate to
The pragmatic David Heinemeier Hansson once gave a keynote about Conceptual Compression. It's basically the idea of embracing abstractions-- where increasingly, a developer doesn't need to know the often messy or complex details of some particular technology to be effective with it. Studying algorithms and data structures for interviews actually taught me to see the light on this.
New developers tend to think that solving algorithmic challenges is all about holding all the details in your head. In the beginning, when you haven't learned any patterns, that's the whole point. You haven't yet learned the tools of the trade.
These patterns and "tricks" are abstractions that, once understood, let you concentrate on solving the problem. When you know how
backtracking works, you suddenly have a filter through the various solutions. You're a level up, that is-- your focus can now be on how to use
BFS in this problem, rather than figuring out the exact steps to get to the shortest path.
It is true that, without knowledge of these patterns, it becomes more difficult to solve these kinds of challenges. However, the majority of companies that employ this style of interview are upfront about the expectation that you do study them. People derail this notion, because outside interviews, we never use these abstractions though, right?
Nope, these patterns actually come up all the time! Don't believe me? Here's a few examples.
I was working with a massive dataset of payments for a company spanning decades. My team had written an
ETL process that would pull records in chunks of 100,000 rows and transform them based on attributes of the payment. When the
ETL was shipped to production, I noticed the process was taking days instead of the hours we had expected.
Upon inspection, one of the methods in the
ETL was doing some de-duping. The way it was de-duping was by performing this routine:
Besides the issues with mutating the original array, the lookup time was just killing our efficiency. The great thing about tech is that most engineering cultures are blameless, so we as a team quickly changed it to this:
There was a literal 10x speed increase from this change.
Some readers might laugh and say that code like that would never make its way to production. Those people have never been under pressure to ship a feature, while having to work with a team of varying experience levels and managing PRs that regularly span hundreds or thousands of lines.
Knowing to use
sets is certainly something that could be picked up just by reading code and gaining more experience. But a concerted effort to learn more of these "tricks" can save you when there's a pickle in production.
I've certainly used
hash maps professionally quite a bit, even on this site. On AlgoDaily, we have the concept of
Challenges. Each time users finish a problem, we add a
Completion record with that
Challenge's ID referenced. Now, also note that
Challenges are also tagged on multiple
Categorys through a join table
When I was building out the dashboard, I wanted to display how many
Completions each user had completed per
Category. This was surprisingly difficult to make efficient with the built-in ORM. Even with eager loading,
ActiveRecord would make several
n+1 calls to properly group each
The fastest solution ended up outside of any framework. I simply made a solo database call to get all
Completionss for a given user by joining them to
Challenges. Then, server side, I used a good old
hash map to group the
Category and used it to look up counts when rendering the UI.
In this case, knowing that multiple network calls would be significantly slower than performing in-memory operations reduced the load time of the dashboard by over 70%.
People always say that 90% of software engineering nowadays is just data-in, data-out-- in other words,
CRUD apps. That may be the start, but what happens when you want to do things and analyze the data? Or debug it?
Modeling things is one aspect, but operating on what you've modeled is usually the next step. As an example, a friend of mine was recently working on a directory of company employees. Nothing fancy, most companies have something like this.
The difference with this one was that it would just display an employee profile, and let you click to see their manager's page. Then when you went to the manager's profile, you could navigate to his manager-- an on, and on, up the chain. Nearly every company has an org chart/directory like that.
Of course, for those who've studied data structures, this is clearly a
graph, in the making. And it was implemented as such. Each employee record in the database had a
manager_id column that pointed to another employee.
This "shape" was incredibly helpful when doing renderings/visualizations of org charts, and when shaping the payload to populate the HTML (which itself is a tree!). Knowledge of these data structures was especially handy when the team needed to audit the departments, their headcounts, and the reporting structure.
You may read these examples and assume that all of these are things that come with experience. Yet that is precisely my point. Those who've heavily studied Big O notation, Data Structures, Algorithms, and Systems Design will always have efficiency in the back of their minds.
These will always be fundamentals that have been painstakingly uncovered over decades, and are incredibly useful even in day to day work!
A friendly reminder that we’re running our 50% off summer sale. If you like the AlgoDaily emails and tutorials, you'll love lifetime access to a growing course for half off. We plan to add about several new challenges, lessons, and video tutorials each week for the next few months, so don't miss out!
We'll send you over 100 of the most common coding interview questions, once a day with visual explanations. Join over 16,323 users who are doubling their salaries in 30 minutes a day. All subscribers get a free 86-page preview PDF with a week of study material.
Welcome to the most accessible guide to technical interviews. AlgoDaily was created to be a gentle, visual introduction to patterns around solving data structures and algorithms challenges.
We believe that technical interviews are a matter of practicing well. We've referenced hundreds of resources on habit change, education design, and algorithms to design the best and most streamlined learning experience.