I originally wrote this article more than a year ago, before getting my first job offer as a developer.

I'm sharing this with you now because I recently went through another interview process. And I found that the same concepts and thoughts that helped me get my first job offer allowed me to pass all the interviews successfully again. 🙂

My Background

I took up coding more or less a year ago. I started learning out of pure curiosity, and as I learned more about it and was able to build personal projects, I just fell in love with it.

I got so obsessed and passionate about it that I dedicated all the free time I had to coding, reading about code, watching videos about code, and just learning as much as I possible could, because for me it was fun and interesting!

Time passed and at a point I started imagining myself working as a developer. First it was like a blurry thought, and then I started thinking about it seriously and learning about what I needed to do to get to that point.

My learning journey and the approach I took towards becoming a dev will probably be the subject of another article, but my point is that I made it! I recently got an offer for my first job as a full time developer and I couldn’t be happier about it.

And there were many things and learning experiences I had to go through to get to this point, but I’d say the toughest one – and the one I was less prepared for – was technical interviews.

What are Technical Interviews Like?

I come from a social sciences background, and most of the time, within that field, there’s nothing too “technical” to talk about during interviews. Employers normally hire you based on your experience and behavior during interviews.

But in the coding field it’s really different. Experience is valuable, of course, but employers also value projects you can show to them, theoretical knowledge about different programming topics, and, most of all, the problem solving skills you can show off during technical interviews.

In almost all selection processes I went through, there was a technical interview in which an interviewer tossed me a problem and I had to solve it live with them looking at me the whole time.

This is a standard practice for coding jobs, but I wasn’t prepared at all. I failed miserably more than once, and these experiences were some of the most embarrassing and frustrating moments in my professional life so far.

At times I felt stupid for even thinking I’d be capable of switching careers at almost 30. I thought I just wasn’t smart enough. But luckily I kept going, researched about technical interviews, learned, practiced, and kept failing until I didn’t fail anymore.

Technical interviews are tough and can be really stressful if you’re not prepared correctly. Also, even though I successfully passed a selection process, I know I still have a lot to learn about this and that I’ll need to perfect this skill to further grow my career in the future. So here are my main tips for nailing your technical interviews.

1. Prepare for the Interview

This is important for all kind of interviews, but for technical interviews I think it’s crucial. Your chances of passing these evaluations are way lower if you don’t prepare correctly for them.

Here are some ideas that allowed me to better prepare for these interviews.

Do Your Research

Find out about technical interviews in general, how are they normally organized, what interviewers ask and what do they intend to measure, what kind of problems do companies toss at you, and what are the best approaches towards interviews.

The internet is an infinite resource of knowledge, so don’t waste it! Google about everything you can and take advantage of the experience of the thousands of people who have gone through similar situations and share their experiences.

Practice Solving Problems

Problem solving is a skill just like any other. There is specific knowledge you’ll need to get good at it, but most of it is practice and getting your brain to be comfortable in that situation.

There are tons of websites that contain the types of problems you’ll see during interviews. freeCodeCamp has an amazing course designed for this. Some other cool resources are hackerrank.com, leetcode.com, codewars.com, exercism.io, app.codesignal.com, and algoexpert.io.

Solve as many problems as you can from any of these sites and you’ll start getting good at them.

And when you practice, at first it’s okay to just worry about solving the problem. But once you get comfortable enough, a great idea is to try to make your practice as similar as possible to an actual interview. And by this I mean setting a timer, explaining your solution out loud, analyzing your final algorithm and refactoring…just basically following all the steps you’d normally follow in an actual interview.

If your practice is similar to the actual situation, once you get to that situation you’ll feel more confident because in some way you’ve already been there.

Build a Theoretical Foundation

Besides actually practicing, learning theoretical concepts about algorithms and data structures is a great idea to get better at solving these problems.

Think about it as adding tools to your toolbox. The more tools and concepts you have in your mind, the more problems will sound familiar or ring a bell in your brain, and from that you'll be more able to arrive at a solution.

There are many resources on the internet, some free and some paid. A course about data structures and algorithms is pretty much a must for any programmer, so I encourage you to find a good one. Here are a couple you can start with:

• Data Structures Explained

• Learn Data Structures from a Google Engineer

• Learn Algorithms and Data Structures in Python

• Learn about Algorithms and Data Structures

Of course also theoretical knowledge about your programming language of choice and any other tools in your stack (frameworks, libraries, databases, and so on) is also very important.

Imitate Others

It’s ok to run into problems you don’t know how to solve or to come up with solutions that are not the best suited ones.

In these type of situations, or always actually, it’s a good idea to take a look at how other people solved that same problem and learn from them. What approach did they take? What ideas did they have? Did they get stuck? How did they move towards the solution?

Analyze their solution and their behavior, identify what works for them, think if that could work for you and if the answer is yes, copy them! It’s crucial that you deeply understand why their solution works and how their logic works. You want to internalize the logical approach, not the code, as that’s just an after effect.

Looking at problem solutions and videos of mock interviews is a good idea to get this kind of data.

Understand What Kind of Interview You'll Have

I mentioned the most classic type of technical interview is the one based on algorithms and data structures, in which the interviewer will give you a problem to solve through an algorithm.

But I found that there're also interviews that are mostly theoretical, in the sense that the interviewer will ask questions to measure your knowledge about a given programming language, framework, library, design and architecture patterns, and so on.

Another kind of interview is where the interviewer shows you an actual project or asks you to build one. During the interview you discuss the decisions you made to build it or implement new features/modifications on it.

Each kind of interview is different and might require different preparation, so it's always a good idea to ask the company what will the interview be based on, and prepare accordingly.

2. Breathe and Think Things Through

Once you've seen and gone through a ton of examples and start feeling somewhat confident around coding problems, it’s time to get to the deeper stuff.

Here are some tips that helped me go through the interviews successfully.

Don’t code

This sounds crazy right? The best approach to solving most coding problems is actually not coding, or at least not right away.

No matter how anxious or secure you are about the idea you have in mind, I find it better to always take a step back and make sure you understand things deeply before going to the details and breaking out the code.

So how do you do that?

Understand the Problem

The first step to solving a problem is actually understanding it. And to understand it, the best idea is to “make it yours”, and internalize it.

A good idea is to read the exercise twice, repeat it again in your own words, and go through multiple examples (simple ones, complex ones, examples with null or invalid inputs…).

No matter how silly, complex or simple the problem may seem, this helps you make sure you understand it properly and gives your brain data and time to come up with solution ideas.

Make Sure You Understood It

Repetitive? Yeah, but effective. Check and make sure you understood what you need to do and how your function will work.

Ask yourself, what are the inputs going to be? What will be the output? Check for edge cases. Will you always receive the same input or could you expect different formats? Do you have to be prepared for strange cases or does the exercise restrict the kind of situation you’ll encounter?

It’s better to clear out all this things before even starting to think about a solution.

Explore Your Toolbox

I said that learning theoretical concepts and practicing is like adding tools to your problem solving toolbox. When you see a new problem, it’s a good idea to explore that toolbox and see if any of the concepts or solutions you’ve used in the past could work here.

Could it help to use some sort of counter? What about implementing some sort of data structure to help you out? Could you use pointers or a sliding window? Would it be a good idea to take a divide and conquer approach? What about recursion? Could sorting the input help for anything?

You don’t necessarily have to know the exact path to take, but comparing the problem to previous patterns you’ve seen can help spark ideas in your mind.

Of course the more you practice solving problems and learning about possible solutions, the more patterns you’ll have to remember and compare.

Break Down the Problem

Once you’ve analyzed the problem deeply, hopefully you’ll have at least an idea of how to tackle it, or where to start.

A great idea here is to try to think about the different steps you need to take to get to your solution and write down those steps to analyze them, check if your logic is correct, and later use them as little memory helpers and “instructions” for you to translate into code.

Simplifying your solution through steps and specially writing them down will often help you identify flaws in your logic or cases you didn’t think about before.

This is great because you’re at a stage when it’s really easy to modify your approach or lean towards a different idea. You didn’t waste time coding or getting yourself into a maze of logic that doesn’t actually work.

Simplify the Problem

Specially when facing complex and difficult problems, a good idea is to first ignore the main difficulty of the problem and try to solve a similar, simpler version of it.

When you nail that solution, bring the main difficulty back and see if you can translate your solution to it.

Visualize the Problem

Complex problems are sometimes difficult to get your head around. Having a whiteboard, either a physical or a digital one, is always a great idea.

Visually stimulating your brain by drawing up the problem or an idea can be a good approach to buy yourself some time and see if that perspective shows you some data you didn’t notice.

Start to Write Your Code

So once you have a clear idea of the steps you’ll need to cover to get to the solution, it’s time for translating that into code. This should be the simple part if you’re comfortable enough with the language.

A thought to keep in mind here is that if you can’t remember something very specific, don’t let that hold you down – pseudo code it and carry on with the rest of the solution.

Talk to your interviewer and see if they can help you with that part, or ask if they'll let you Google it. In most cases this will be ok and the important thing will be to show that you nailed the correct logic to solve the problem.

Test Your Code

Test your solution at every step and at the end. There’s nothing more annoying than writing a ton of code and later seeing it fail without knowing the exact cause.

Test your code and your logic at every step of the solution, as this will allow you to catch bugs earlier and will save you from wasting time and effort.

Of course testing at the end is important to check if your solution actually works! So throw your function different inputs and edge cases to see if it behaves as expected.

Analyze the Solution

Once you've gotten to the solution, you’re not done yet. It’s a great idea to show your interviewer you can analyze what you did too.

Ask yourself and tell them, what’s the big O complexity of your solution? Can you think of a way to improve the performance or the memory usage of your algorithm? Is there a way to make your function easier to read and understand?

Even if you can’t think about how to code it exactly, it’s great to show them that you’re the kind of developer who is always going to look for improvements and not settle for something that just works.

Improve Your Solution

Of course, if you can find ways to optimize your solution and know how to code it, do it!

And about this, in a coding interview situation you’ll rarely come up with the perfect solution for a problem. You’re under pressure and on the clock, so it’s perfectly ok to come up with a so-so solution and then refactor it until it reaches an acceptable level.

It’s often better to show you can solve the problem even if not in the perfect way than spend all your time just thinking about the perfect solution.

Talk to Your Interviewer

Talk with your interviewer during the whole process. What your interviewer is trying to measure is your problem solving ability and your level of comfort with your programming language of choice.

That is a hard thing to measure if you don’t open your mouth and just code away.

It’s crucial that you talk to your interviewer and let them know what you’re thinking, what is your thought process, what ideas are you having, how are you understanding the problem, what logic are you going to follow with your solution and why are you making decisions.

Talk to them, ask questions, explain yourself, and if you get stuck or don’t know how to go on, explain to them exactly the thing that is giving you trouble. In most cases you’ll get some help and more importantly you’ll show them you’re actually trying to work towards a solution.

Listen to Your Interviewer

When you’re being given the problem to solve – and specially if you get tips or feedback from your interviewers – pay attention! No matter if you think you already have the best idea or if there’s something that’s driving you crazy and need to solve right now, just drop it and listen to what you’re being told.

If you don’t listen to feedback, you’re giving a very negative signal to your possible future employers. Think about it: would you like to work with someone that doesn’t listen to feedback? Besides, feedback will certainly help you solve your problem, so listen!

3. Control Your Emotions

This for me was the toughest part of the interviewing process, and it's something I didn’t really find a lot of information about when researching technical interviews.

Dealing with the anxiety and frustration these situations can provoke is hard, but also a crucial step to improve your performance.

So here are some things that have helped me in this regard.

Prepare Your Body and Mind

Interviews are stressful situations in which you have to deal with expectations and perform to reach those expectations while being judged by other people.

I’ve always felt uncomfortable in these type of situations so I’m quite familiar with the type of anxiety you might feel.

Something that helps me is try to think about it like the moment of a game for a sports player or when actors get out on stage. You normally see these people trying to warm up and focus before they start to perform, right? There’s a reason for that – and it’s that this preparation actually enhances performance and gets you ready to give your best.

It may sound stupid at first, but stretching, warming up your voice, meditating, imagining the moment in your mind and picturing yourself being successful in the moment are all things that will push you towards doing nicely in this important moment.

Be Confident

Easier said than done, right? Absolutely. Confidence for most people isn’t something you can just turn off and on, but something you build along the way and comes with lots of practice, studying, and preparation behind it.

You'll build confidence with the work you do prior to the interview, but once you’re in the moment it’s important to remember that you want to show the interviewers you have confidence in yourself as a coder and that you trust yourself to solve any problem you face.

This doesn’t mean you have to know absolutely everything and be able to solve any complex problem absolutely by yourself. Rather, it means that you won’t panic when you face something you don’t know how to solve at first, and that you have the ability to slowly analyze the problem, break it down, and work towards a solution.

Slow Down

Stress, anxiety, and the wish to show that you can solve the problem can make you rush more than you need to. And rushing can lead to missing key information, flaws in your logic, bugs in your code, and errors in general.

So take your time, actually, take more time than you actually need. Analyze the heck out of the problem, talk slowly, code slowly, think slowly, and remember to breath. Things are easier to deal with when you take your time and slow-mo the process.

Don’t Take it Personally – or Do...

You’ll mess up at some point, that’s a certainty. Especially in your first interviews, you’ll probably fail and feel miserable about it. It’s just the way it is, and it's a step that is needed for you to understand where you need to improve.

A key issue here is how you deal with that frustration. I could tell you to think about it as a process, to not get mad when you fail, to be patient… But if you’re an anxious and self demanding person as I am, you’ll be very frustrated when you fail, and there’s nothing you can do to avoid it.

But how do you deal with that? Do you get depressed and quit coding forever? Do you get scared of interviews and never apply for a job ever again?

Personally, I get very mad at myself when I fail at something or find out I don’t know something I "was supposed" to know. I get mad at myself for not preparing correctly or for missing things, and even though that anger feels bad at first, later on is something that pushes me forward.

I feel so bad about it that I make absolutely sure I won't fail at that again, and I practice as hard as I can to avoid being in that situation again.

Different approaches work for different people, but the thing is to handle your emotions in a way that pushes you forward and not backwards.

Learn from Your Mistakes

As it’s a certainty you’ll mess up, the smart thing to do is to learn from the errors you made and try to not make them again.

Always try to take note of the problems you were presented and your solutions, analyze your mistakes, analyze other possible approaches you could have taken, what optimizations you didn’t see, and what key concepts you didn’t remember at that moment.

Also always ask your interviewers for feedback about what you could have done better. This information is gold if you get the best of it.

Have Fun

If you love coding, you probably have lots of fun doing it. Never forget that, no matter the context.

In interviews, try to approach each problem with curiosity rather than fear of failing. Try to show your interviewers you’re enthusiastic about problems, because you’re probably going to work with similar stuff on a daily basis.

Plus if you’re having fun and thinking in a positive way, you’ll be more relaxed and your mind will be clearer, which of course helps your problem solving skills.

Keep Going

If you pass or if you fail, at the end it doesn’t matter, in the sense that your approach and behavior should stay the same.

Just as code can always be improved, so can you as a programmer. You should always keep learning, keep getting better, keep practicing, keep facing stuff you didn’t know anything about and eventually overcoming it.

So don’t get too high if you pass or too low if you miss – just keep coding and keep learning.

Roundup

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on LinkedIn or Twitter.

See you later!

Recently I attended a meeting with multiple stakeholders from the business side. When asked to explain a feature, I started explaining them the details of the feature and its implementation. After the meeting one of my colleagues told me even though I explained it in detail, they will be requesting a follow-up meeting to discuss the same thing and it was true — the next day we had a meeting invite for the same thing as a follow-up. He explained to me that the reason was I had provided them more details than necessary which probably confused them. This incident led me to the principle of Occam’s Razor.

Quoted from Wikipedia

Occam’s razor or the law of parsimony is the problem-solving principle that essentially states that “simpler solutions are more likely to be correct than complex ones.” When presented with competing hypotheses to solve a problem, one should select the solution with the fewest assumptions. The idea is attributed to English Franciscan friar William of Ockham (c. 1287–1347), a scholastic philosopher and theologian.

We have all heard the famous quote by Sherlock Holmes

Once you eliminate the impossible, whatever remains, no matter however improbable, must be the truth.

This follows directly from Occam’s Razor. This principle states that given two explanations of a situation, the one in which there is the least number of variables(simpler) however improbable is the most likely explanation. This principle is very helpful and it can be used in a wide variety of situations but it is especially powerful in the hands of software professional.

There are many areas of Software development which can benefit from this principle. A few of them are:

Coding

The first and foremost area is coding. As developers, we make hundreds of decisions every day which directly affects the health of the codebase and in turn the business. Few of the mistakes we make include adding unwanted abstractions, designing for the future, making it “extensible”(whatever that means). These code with unwanted additional complexity slowly rots over time and becomes “that” part of the codebase that no one understands and nobody is willing to touch. These are the things we do either knowingly or unknowingly which can put a dent on our codebase health in the long-run.

To overcome this it would be prudent for us to think in terms of Occam’s Razor. Always do the simplest thing possible at any point in time. Principles like YAGNI and KISS are examples of Occam’s Razor in coding. If you want to combine 3 design patterns to accommodate a feature request you expect in the future, restrain your primal instincts and stick with a single class for now. Using Occam’s razor during the development process would keep the codebase simple and readable and your future peers will really thank you.

A word of caution here is, this principle should not be used as an excuse to write bad code or take shortcuts. If there is a real need to add complexity, by all means, you should do that. Consider this a framework for you to step back and think for a moment and weigh the cost of your decision in the long run.

Debugging

Another interesting application of this principle is while debugging. The hard part about debugging is nobody knows the answer especially when you work in a legacy code base with business critical functionalities. Bigger the codebase, more complex the debugging process and thus the Occam’s Razor comes in really handy. All the good software developers I know trace the root cause of a bug by using this principle without even realising it.

Let's say there you write a program to display a few stats in the dashboard. You observe that each time the dashboard is updated you get 2x instead of x for a particular stat. What would be your first instinct? Is it a double counting issue or some thread level race condition? I am guessing most of you with go with the former. This is Occam’s Razor in action. You picked the choice which provides the simplest explanation for the issue intuitively.

This is not to say that always the simplest explanation is the right one. Instead, you start from the simplest one and eliminate one by one either by theory or experimentation until you arrive at the actual root cause for the problem. This provides a framework for you to tackle problems methodically.

Communication

One of the most under-rated functions of a software developer is communication. Be it with peers/ managers/ stakeholders, communication is as important as coding for any developer. As developers, we are the closest to any given problem and it is natural for people to rely on us for understanding the whole picture of a product/feature. This makes what you communicate and how you communicate extremely crucial from a business standpoint.

As we are closest to a problem, we will have a lot of technical and domain knowledge around it. But it is extremely important to communicate the right things to the right people. Assume you are in a mail thread with Sr. engineer, PM, Manager, and a Business development executive, you need to provide just the right amount of detail so that the Engineer can get the technical challenges and the others can also understand the complexity technically as well as the business justification. You need to achieve the right amount of balance in the technical/business mixture for the audience to understand and not lose interest. This is where Occam’s razor comes in. You need to provide the least level of detail in the mail and schedule a follow up for the people who need to understand more.

Take this as an example “we did a POC on x and we were able to achieve y. Even though we discussed A in the previous mail, we could not achieve A due to the complexities in a library that we were using. There were a lot of assumptions in the threading model in the library and thus it prevented us from achieving A”.

Now, what do you think the different stakeholders will understand?

1. Engineer — Yes I get the issue.
2. PM- So basically we cant achieve A. And what is a threading model?
3. Manager — Did he try enough to achieve A?

Instead, if we write “we did a POC on x and were able to achieve y. A was targetted but not achieved. I’ll schedule a meeting to demo the POC and go into details on the blocker for A.” After that, you have all the time in the world to explain in detail the blockers for the right audience and achieve a consensus.

Now, what is the thought process after the demo?

1. Engineer — Makes sense.
2. PM — The POC is good for now. I guess we can drop A for now and proceed without it.
3. Manager — He has done an in-depth analysis and knows what he is doing.

Conclusion

Occam’s Razor can be employed in a wide variety of scenarios and these are just a few examples. Developers use this principle intuitively without knowing it. But knowing it and using it deliberately in various situations will greatly improve you as a software developer. If you can think of any other area of Software where this principle is being used feel free to leave your thoughts in comments.

If you liked this article, feel free to reach out to me at https://kaizencoder.com/contact.

When we are inspired to set goals, what inspires us are the outcomes not the process. We are never eager to do 50 crunches at the gym — we are eager to walk around with flat abs.

Our wonderful human imagination makes us fall in love with the destination and overlook the path.

This is a good thing. Without this, none of us would start. But the flip side is that because of this most of us quit, or lose momentum. When the reality of the path to our dream is experienced, day in and day out, it’s very easy to slow down and eventually stop. Maybe we don’t want the dream after all. Or, more specifically, we want the result, not the work.

Right?

Sadly, this natural human habit is what stands in the way of many us learning new skills, especially complex skills like coding. Setting outcome goals is what drives people to action, but without process goals, the outcome is seriously at risk.

This is how I set my coding goals the first time I tried to learn to code: I am going to learn HTML this month. Then next month I’m going to do JavaScript.

Sound familiar? Exciting outcome, no process.

That is actually a risky, ineffective way to set your coding goals. Here’s why.

In your head that target date seems reasonable, achievable, and importantly, encouraging. It’s motivating to think you will have results that soon. The problem is that a deadline-based goal like that is arbitrary. Learning a new skill takes a certain amount of time. Some are faster than others, but everyone has to put a minimum amount of time that they need to acquire that skill. The skill doesn’t care which month you want to finish by. It only demands that you put in enough time to learn it.

Therefore, setting a deadline-based outcome goal is incomplete — it ignores some vital math about learning.

For example, if you want to learn HTML and CSS in 30 days (outcome), it is absolutely achievable. But**,** what does that actually mean? How many hours, on average, does a person need to learn HTML and CSS? And then, how many hours a day or week (process) do you need to achieve that goal? If it takes 8 hours a day, 5 days a week, are you in a position to do that? Which metric really decides success: the outcome or the process? (hint: it’s not outcome).

Simply put: knowing how much time it takes to achieve a goal and how much time you can commit to regularly will decide when you you can expect to achieve that goal by.

It’s like a time and distance navigation problem — if you need to travel 100 kilometres, you cannot know when you will get to your destination unless you know how fast you’re traveling. No matter how sincere you are, you cannot do 100 kilometres in 1 hour if you’re walking. Setting that sort of goal is absurd and will result in frustration if you fooled yourself into thinking it’s possible.

So when you set your coding goals, work out the distance between where you are and the skill level you want, how much time will it take in total, and most importantly how much time you can guarantee you will devote to it every week. Divide total time by weekly time and you get the number of weeks it’s going to take you. That is your deadline.

Most learning resources online make this easy. freeCodeCamp.org makes it super easy — the curriculum tells you clearly how much time a certification takes! Sites like Udacity and Coursera also tell you this, but it’s buried under other course data. Typically they tell you you can complete a course in X weeks if you spend a minimum of Y hours a week.

Even on Udemy this can be calculated. For example, my course is about 3 hours long. You can finish it in a day, if you spend 4 hours (including thinking and assignments). If you spend an hour a day you cannot finish it in less than 3 days. For more technical courses, where you learn by coding along, I would multiply the hours of video by at least 3 to get an estimate of time required to complete the course.

Put this way, it’s pretty clear that deadline-based outcome goals for learning are arbitrary if you don’t focus on the process goals of daily or weekly commitment. “When by” is useless without knowing “how much every day”.

And this one shift in approach will greatly improve your odds of success. This way you will know if something is going to take you 6 or 12 or 18 months. No nasty surprises — and you can build a solid plan around that, and prepare yourself for the journey.

Ultimately, every place is walking distance if you have the time. It’s no different for learning new skills. It takes the time it takes. You just got to be ready to show up and do the work until the math gets you to your destination.

If you would like to learn more about my journey into code, check out episode 53 of the freeCodeCamp podcast, where Quincy (founder of freeCodeCamp) and I share our experiences as career changers that may help you on your journey. You can also access the podcast on iTunes, Stitcher, and Spotify.

I will also hold a few AMAs and webinars in the coming months. If this is of interest to you please let me know by going here. And of course, you can also Tweet me at @ZubinPratap.

If you get distracted during work, you may also end up with this 5 to 15 minutes left. What do you do with it?

If you find yourself in a distracting situation, like having to take care of a baby who cries every now and then. You probably have 5 to 15 minutes pockets of time very often. How do you use this time?

I think you can use it in four possible ways:

1. Use it do errands
2. Use it to learn
3. Start the next thing
4. Use it to chill

Use it to do errands

The most obvious thing to do is knock something off your todo-list. Ideally, you want something that’s urgent or important. And it doesn’t take up a lot of time.

Here’s a possible list of things I cooked up with:

1. Reply to emails
2. Make a phone call
3. Chat with someone
4. Eat something
5. Do grocery shopping online
6. Do 1 push up

If you do this, make sure you keep a running list of small errands. Trying to search for an errand to do, deciding to do it, and doing it often takes more than 5 to 15 minutes.

Use it to learn

I used to hate learning in distracting environments. I can’t even finish a page in a book or watch a 2-minute video before someone interrupts me!

When I get interrupted, rage builds up inside ?.

I realized this rage builds up because I wanted things to be perfect. I want to be in my room. I want to have an undisturbed block of time. I want to make sure my back isn’t hurting, etc.

But we don’t need situations to be perfect to learn. We can tell ourselves this:

1. If we read 1 sentence, that’s enough
2. If we watch 5 seconds of video, that’s enough

If we get distracted, we’ll just resume from where we left off.

Start the next thing

If you have 5 to 15 minutes of undisturbed time left over, the best thing you can do is start the doing the next important thing.

Stop when your 5 to 15 minutes is up. Yes, even if you’re only halfway into the next thing.

When there’s unfinished business, we want to finish things up. And our brains work overtime without us knowing.

The best way is always to stop when you are going good and when you know what will happen next. If you do that every day… you will never be stuck.

Always stop while you are going good and don’t think about it or worry about it until you start to write the next day.

That way your subconscious will work on it all the time. But if you think about it consciously or worry about it you will kill it and your brain will be tired before you start. — Ernest Hemingway

Use it to chill

It feels like taboo to waste time and do nothing. After all, we have too much to do, why are we wasting time here?

But it might just be the thing we need.

1. We need boredom to be creative.
2. We need to relax to perform.

And sometimes, 5 minutes of rest can get you enough clarity to do the most important work for the rest of the day.

Wrapping up

Remember, you’re free to use this 5 to 15 minutes any way you want. It’s not a stupid block of time where you can do nothing with it. It’s a gift. Do what you want with it.

One simple reframe can change how you spend your time. It can change how your day turns out. Compounded over time, it changes your life.

What will you do with the next 5 to 15 minutes?

Let me know in the comments below :)

Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!

This article was originally posted at my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.