This is a sequel to Part 1 of my thoughts on Software Engineering interviews, you can read it [https://leratoletsepe.com/blog/thoughts-on-software-engineering-interviews-part-1-of-2-experiences](here).  I highly recommend it because I don't want people calling me crazy, like who the hell makes a part 2 without a part 1? It could also be very useful and contain some valuable insights, so do check it out.

In part 1, I mentioned that this one will be for the geeks 🤓 and so,* (inserts nerdy greeting)* I have come back to deliver.

When I look at some of the people that inspire me in tech, personal, online, or some colleagues even, I sometimes wonder; what was the beginning like for them? How did the first tech interview go? Did they have a whiteboards interviews as I did? Did they have to write code on a piece of paper like I had to? Were they dressed in formal wear like I was? And did they ever get nervous?

All these questions can be pretty daunting if you haven't had your first interview. But worry less, because in this article I will dissect some of these questions and share my thoughts on technical interviews. I'll try to do this in a way that creates beauty around all this madness.

Here's a quick snapshot of what I'll cover:

*  Critical things to know: don't play yourself.
*  Talk is cheap, show me the code.
*  Simplicity, dissect and demonstrate.

Let's go!

Critical things to know..
============

— don't play yourself.

In the world of computer sciences, coding and developing software in general. There are a few "must-know" concepts, theories, and principles. Just like in any profession, there are those things deemed necessary by the powers above. For example, for a professional psychologist, communication and patience are must-have skills. Likewise, there are key principles you should know before your first dev interview. Let's look at some of those things:

1\. SOLID Principles.
2\. DRY.
3\. KISS.
4\. SDLC. 
5\. Abstraction.
6\. Design principles/patterns.
7\. Source & Version control. 
8\. Software and Systems Architecture concepts
9\. Basic networking concepts.
10\. Theories of Computations, Algorithms, and Heuristics.

Listen, not everyone will expect you to know this kinda stuff because its mainly mainstream; and if you are a developer by reading docs all of this stuff is gas to you. So to the companies and interviewers out there and try to break these rules, I just wanna say I respect y'all; you guys are the real ones man.

"Talk is cheap, show me the code."
============

— if I live by anything, it has to be this quote by Linus Torvalds.

Often, there will be at a stage in interviewing process where you will have write code, either on a whiteboard, or on some online tool during an online meeting, or even writing a technical assessment. This can be scary for some people, more so when you struggle with the imposter syndrome; at times, it may seem like throwing yourself in a dragon's den. But it is moments like these that force us to reflect on our flaws and build on them.

Yes, talk is cheap, but there is so much power in it - especially when it comes to a tech interview. Here's is an example of how you can use this to your advantage. Picture a scenario in an interview where you're asked to write a function that takes a number and returns the sum of all the numbers before that given number as a way to demonstrate your understanding of recursion.


First take a moment to internalize the problem, understand what the problem is and what solution you are thinking of. Ask an important question that may be unclear, like "Is the function supposed to include the number given in the calculation?"

Listen to the response and internalize it, vocalize your thought process (talking) as you go. For example. "I will call this function, 'calculateSum'. If I give it the number 5 then it should return 15, because 1+2+3+4+5=15. There is a lot of ways to solve this, as with many problems. I will use the following solution because it ….. then proceed to explain why you are choosing to solve the problem with the solution you have in mind"

As you write out your solution, explain what you are doing. Take this snippet as your final solution, in C#.

    // This function returns the sum of all the numbers before and including the given number.
    public int CalculateSum(int number)
    { 
          if (new List<int> {
              0,
              1
           }.Contains(num)) {
                    return num;
              } 
              else 
              {
                 return num + CalculateSum(num - 1);
           }
    }

Focus on the first part of the solution, and explain it.

    public int CalculateSum(int number)

"This is the signature of the function. It is public because it should be accessible outside of this class. It returns an int data type, which will be the calculated sum. It takes in a parameter called 'number' with the data type of int."

    if (new List<int> {
        0,
        1
        }.Contains(num)) 
    {
        num;
    }

"The first part of the function creates a List on integers with 0 and 1 as the values, it then checks if the given number is contained in the list. If it is contained this means that we can return it, if not it means we have to do some sort of computation."

    else 
    {
        num + CalculateSum(num - 
    }

"This is the most important part, and this is where the recursion happens. If the number isn't a 0 or 1, we call the function again, from the function itself.

It's also important that you know why you used the solution that you chose for whatever question - so you that you reason, yeah?

You get the idea.

Research, simplify, dissect and demonstrate.
============

— make it easy, because less is more.

**Simplicity**: It's nice writing complex algorithms and functions, it makes you feel good, but it is this vanity that that can work against you, especially to an untrained eye like a 'not so technical' recruiter. So be nice to them, you want them to be your friends. Leave comments where necessary, and explain concepts to them as though you are communication with a 10 year old, adhere to every trick in the book to make your code easily understandable. This could help you understand it again in the future if you need to reference it.

**Dissect and demonstrate**: When it comes to interviews, technical talks, presentations, and completing tasks - separate your topic into smaller chunks that can easily be understood. This will make your audience better understand in detail what you are doing of trying to achieve, and also helps you to organize your thoughts chronologically. For example, you have to build a feature for liking a post on your blog. Start by understanding what you are doing, look at the design, structure your model, proceed to write out the feature's backend functionality, write the different tests, build the interface (referencing your design), integrate your backend, write your integration test, try to break your feature, and iterate.

In conclusion for this two part series, I want to leave you with these words by Sahil Jah. 
>  " A job interview is a two-way communication to probe for cultural and team fit. No matter which side of the table you sit, you should be asking questions that are important to you without fear."

Thanks for reading.
============

medium_the-sequel.jfif

small_the-sequel.jfif

thumbnail_the-sequel.jfif

the-sequel.jfif

This is a sequel to Part 1 of my thoughts on Software Engineering interviews, check it out in the blogs section.

Thoughts on Software Engineering Interviews. (Part 2 of 2: Behind the madness. - The Sequel.)

[](https://miro.medium.com/max/10850/0*v-kNicMI5zC1Z4IB)Photo by [Kaleidico](https://unsplash.com/@kaleidico?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)

I'll be completely honest, I have re-written this post about 3 times before publishing, and the reason for that is because I didn't know how I wanted to structure the content, how to approach it, and what to share to ensure that it will actually be valuable to my readers. So, after some thought and a bit of procrastinating... I have decided to take a non-technical approach and share some personal experiences. In part 2, we'll talk about some technical stuff for the geeks.

Here's what to expect:

*   The Journey.
*   The interviews.

Without wasting any more time, let's get into it.

The Journey.
============

Getting a software engineering interview and nailing it is never an easy task, especially if it is your first one. And for an array of reasons, a lot of people confuse the journey with failure; you see, on your road to success it isn't about how many times you fall it's more about getting back up and going for what you want. Always remember that delay is not denial (say it with me) delay is not denial. We have to go through certain experiences to be prepared for our upcoming opportunities and you only truly fail an interview if you learn nothing from it.

My first tech interview was with a company I had always idolized. However, it quickly turned into a mess. I'd gotten past the technical assessment, which was followed by a remote interview and that's pretty much where the fantasy ended. It all happened so fast that there was hardly any time to assimilate it, kind of like love you know. But that kind of love that you know you will never get back, and even if you did ' it wouldn't be the same.

To be fair, I really had no idea what I was doing. I liked the company and I knew nothing much about the industry at that time, so my natural reaction was to impress the people interviewing me and take it from there. It was only after the interview that I had gotten a snapshot of what to expect from the industry. In hearing the interviewers present the opportunity and measuring their levels of expectations and what the role entailed, only then was I able to comprehend and decide what I wanted for myself and which company to apply for next.

The Interviews.

1\. **The worst thing you could do in an interview is to lie or claim you know technologies that you will have a hard time dissecting.**

You see, for me, nailing a job interview had always been about perfectly selling myself to the interviewer. Literally, sing music to their ears and convince them that they're lucky because in me they've found exactly who they are looking for. You want someone and I make you believe I am exactly that person, and in time I grow in that role to be what you wanted; fair game, makes sense right?

However, this mindset quickly changed after my first interview. I spoke about things that I didn't know the intricacies of and this set me up to be asked numerous follow-up questions, most of which I couldn't answer.

(Ne ke tlangwe keng? ' means "what was the reason/why did I do that?").

I spent a lot of time thinking about my responses and very early it was clear I had no idea what I was talking about. The problem with interviewers is that they've probably interviewed a lot of people before, and they know what they're doing; so they'll be able to see right through you.

Some people lie better than others, and maybe you're really good at convincing people but I wouldn't bet on it when it comes to interviews. Rather; spend time researching your opportunities, find the company that you love, only speak on things that you know, and if you're in a position to speak on something you're not completely familiar with it's always better to say "This is not a concept that I am familiar with, but if I could answer this, I believe ABC is a solution used to solve problems XYZ... you can correct me if I am wrong."

This shows that you are an honest person and although you don't understand the concept, you have no problem trying it and you are open to learning and taking criticism.

This makes for a perfect sequel to my second point.

2\. **You only truly fail an interview if you learn nothing from it.**

Your ability to carry the knowledge acquired from one interview into the next is essential to improving your chances for success and being a good candidate overall.

It can be heartbreaking receiving a "we regret to inform you..." email, but what you do after reading it almost always defines the path you'll follow next. In the "dev world", criticism and constant improvement make a huge part of how people succeed. Taking a moment to analyze what set you off, and asking for feedback to carry into the next problem (in this case your next interview) is something that is of the essence.

Identify the areas you can improve on, send some more applications and as you wait for the next interview, jump back to the drawing board.

3\. **Post interview.**

A simple thank you note or email can go a long way after an interview, especially if you are being closely considered with another candidate. This gives you a chance to assert your professionalism, which you should have done in the interview anyway. Furthermore, it can represent your eagerness and dedication in getting the role.

If you spoke about an awesome project you worked on, this could be an excellent time to share that with the hiring manager, or whoever the interview was with, preferably the links to your work(i.e. the GitHub link) and the demonstration thereof. (i.e. the live site)

Lastly, be comfortable and wait for a response. In the meantime, interact with the company's content online if you are that kind of person, connect with the interviewer on Linkedin and engage with them on shared interests, be mindful about this. Again, you want to do all this in a professional manner and leave an impact that influences your chances of success in a positive manner.

Thanks for reading.
===================

If you made it this far, you're a gorgeous unicorn. 🦄

Shameless plug, if you enjoy reading my shits, connect with me on [Twitter](http://www.twitter.com/lerato1ofone) and [Linkedin](https://www.linkedin.com/in/lerato-letsepe-1312b5156/).

See you in part 2. 😎

large_thoughts-on-software-engineering-interviews.jpg

medium_thoughts-on-software-engineering-interviews.jpg

small_thoughts-on-software-engineering-interviews.jpg

thumbnail_thoughts-on-software-engineering-interviews.jpg

thoughts-on-software-engineering-interviews.jpg

Here are my thoughts on Software Engineering interviews - My Experiences. (Part 1 of 2)

Thoughts on Software Engineering Interviews. (Part 1 of 2: Experiences.)

[](https://miro.medium.com/max/12032/1*2yekvip0YxnrkVrr3b0eGQ.jpeg)

Have you ever wondered why it is so hard to get a software development job yet so many people and sources claim that there is huge demand? Well, this dichotomy is of no surprise to me, why? damn because the world is so weird man. So if this is one of those things that make you wonder a bit, or maybe you're studying for a computer science degree and you're wondering what your chances are. Well, worry no more. Indulge me a bit as I unpack some of the metrics that influence what opportunities you will have.

This is a sequel to my "Views of a 21-year old Software Developer" post that [you can find here](https://medium.com/retrorabbit/views-of-a-21-year-old-software-developer-e7e057001d34). It'll give you some context. If you haven't checked it out please do, also I'm just plugging it here because you might find some value in it; value that would make me seem like less of an idiot for writing about this. Cool.

In [that post](https://medium.com/retrorabbit/views-of-a-21-year-old-software-developer-e7e057001d34), I spoke about how I feel like uni doesn't really get you a developer job. So I want to dive a little bit more into that here. I think in the future a degree won't be necessary to get a dev job; it's already happening in other countries, and I personally know of at least one situation where it has happened. So that served as a nice confirmation to me. But more of this would have to do with the industry gatekeepers not mentioning a qualification as a job requirement, so looking at things from that perspective you can argue that we're far off from reaching that level.

In this post, I'm going to speak about some mental shifts, and the general mindset I had after qualifying for my degree, how and why I think having a CS degree is beneficial but doesn't guarantee your success in the industry. Then following this I'm going to share my interview experiences and what they taught me. Thereafter; plug some tech resources for noobs, and things I could've done before getting into the industry, and then we'll take it from there. **Alright, let's go!**

I believe there are things I did that made me end up where I am today, and I'd like to share some of those things with you. I have sort of reflected on how and why this happened, but overall I think it was luck — I've been extremely lucky to end up where I am today. But before you think that's a crazy thing to say, here is my cool definition for luck.

> " luck is when opportunity meets preparation." — Roman philosopher Seneca.

Take that and add a fair amount of hard work, some more preparation, and a well-presented opportunity.

Here are 3 things I mention.

*   Stop feeling entitled.
*   Be better.
*   Study your L's.

Stop feeling entitled.
======================

— your tech degree isn't a measure of your ability.

As graduates, we tend to have this strong sense of entitlement. When we look at how far we came, the many hours we spent, how getting that qualification was so hard, and reflecting on the sacrifices we had to make to be where we are; struggling to get a job after the trying times in university can almost feel like a huge slap in your face. I believe that a big source of frustration amongst grads is having this sense of entitlement being met halfway by life's own ways of presenting us with below-par expectations.

While I was not able to find a study that could back up my understanding of this, it certainly makes sense as to why graduates may feel this entitlement, especially tech graduates. Tuition is way too expensive for us to get rejected for jobs, get offers from internships that only want to pay R4000. It is so mentally expensive to complete a degree and then be presented with mediocre offers.

So what's the real story here. Well, simple. Tech "rules the world" and every day it's getting harder to deny it's potential to completely disrupt our world and how we do things, it has become so integral to our everyday lives that checking your messages when you wake up has become somewhat second nature. By virtue of this, it keeps presenting more and more solutions to businesses and individuals. So why must it be hard to get a job if employers and innovators are looking for people like me?

The simple answer to this question is competition. But it gets much more complicated than that. Some of the things that will set you apart are your desire for learning, the projects you've built, if you are part of the community or not (some companies don't care about this though), experience contributing to open source projects, and yeah you guessed it, years of experience (the most dreaded of them all to grads) . The list is endless, and honestly, trying to understand all of them is as clear as mud. My advice is to choose at least two or three of them, and that will surely amplify your chances and gear you towards success. Let me give you some context: If a hiring manager was to give one job and the two candidate profiles are: a) someone who has worked on projects, is enthusiastic and has contributed to an open-source project but has average marks and maybe one or two A's, and b) someone with straight A's for every single module on their degree and nothing else. Who do you think will get the job?

Be better.
==========

— adapt or die. improve or you shall perish.

Yes, it's not a joke. I really mean it.

"Be better" is actually a thing at my company, lol. #BeBetter is the official way to write it. Now, this is something I did not know before starting, but it is more fitting to explain the mental shift I had to go through. Being better means being open-minded, being teachable, willing to learn, and wanting to improve. It also means investing in yourself to be better.

Tech and development, in general, is an exciting ever-evolving industry. The kids out at Silicon Valley roll out new frameworks as often as you check your phone. The hype in the industry then builds up, maybe because it is indeed a super great framework or tool. Regardless, then boom ' you walk into your office one morning and they want to start using this new baby. So if you are intransigent and somehow still believe PHP is still the future _(lol, love you PHP developers_ 😚😘_)_ then people who pick up the new skill/framework will surely be better than you. Better in terms of how efficient they solve problems and how diverse their skill set is.

There are so many misconceptions I had about the tech industry, things I didn't know and stuff I didn't think were real. The mental shift of being better makes you recognize that you can achieve a lot more if you become teachable, because learning only opens you up to greater opportunities.

Study your L's.
===============

— learn from your mistakes.

Before I got my job I had failed two interviews. Now, I don't know if failing interviews is a thing, or I'm just dumb. I've never spoken to any of my colleagues and work friends about it so I really don't have an idea what the average number of interviews people generally fail before landing a job is. But I would like to believe failing interviews is a common thing and it is absolutely normal; especially among people who have just qualified for their degree. _(also just firing make-believe so I don't think I'm dumb.)_ I've heard stories of people failing 3 interviews at google and only making it on the fourth one. Lol, 4 years just get into a job is a stupidly long time I know. But I think there is a very good lesson to take from that, which is what I apply every day.

The trick is to be clinical and really get into the details of what made you flop, so next time you get into a similar situation and get presented with the same opportunity you know how to do it better. I also believe that you can apply this concept to any other spheres of your lives really, I do. Taking this approach and combining it with some deepened research and then ultimately taking your failure as a lesson; instead of being embarrassed and walking away like you just took a major L, you could instead walk away with a smile because you know what not to do next time.

These are the mental shifts I had to apply, and even though some were very general I had to hear them somewhere before taking them seriously. So find them useful, touch wood. In the future I will be writing about more technical stuff _(maybe on lerato1ofone dot com, we'll see),_ I trust you to stick around long enough.

Thanks for reading.
===================

I hope you didn't fall asleep trying to read all this. If you've made it this far, I really appreciate it. You are a gorgeous unicorn 🦄. If this was a cool read or you found it useful in any way, please leave those 👏👏 down below, it makes me smile.

Time for some shameless plugging _(lol you thought i wouldn't do it, didn't you?)_: follow me on my social media too, please… [@lerato1ofone](https://twitter.com/lerato1ofone/) on twitter and [_Instagram_](https://instagram.com/lerato1ofone/). Connect with me on [LinkedIn](https://www.linkedin.com/in/lerato-letsepe-1312b5156/) too.

large_chances-of-being-a-dev.jpeg

medium_chances-of-being-a-dev.jpeg

small_chances-of-being-a-dev.jpeg

thumbnail_chances-of-being-a-dev.jpeg

chances-of-being-a-dev.jpeg

Have you ever wondered why it is so hard to get a software development job yet so many people and sources claim that there is huge demand?

What are your chances of getting a software development job?

 ![Trust the vibes image by @TheRastaViking on twitter](https://miro.medium.com/max/700/1*2HZ9TRP8HRJNTab6zJypzg.jpeg)

I first want to start by disclaiming that this is in no way a motivational or inspirational “Should I become a software developer” story. It’s also not one of those “I code at 3 AM because I am a superhuman who turns caffeine into code and lives in an incredibly effective loop of writing complex code.” I’m also going to mention some things that might be a little hard to swallow, and because this comes from a certain perspective anyway, take some of what I say with a pinch of salt.

So, since I've failed drastically at introducing myself on the first line of this story, now is probably a good time.

Well, I am not popular for anything besides my obsession with music amongst my friends. I thought I would become a rapper/musician earlier on in my life actually but I guess I'll write about that another day, lol. So besides my cool job, I'm not known for anything else besides my horrible overspending on food and my twitter ([@lerato1ofone](https://twitter.com/lerato1ofone)) where I talk a little smack once in a while. In a nutshell, I am a creative and I love seeing ideas come to life. Did you get that? I am _'a creative'_, kids these days smh.

**So, here's what I'll talk about. '**

*   University is so...
*   The truth about being a dev that no one tells you.
*   Being a dev is more than just coding.
*   Itsy-bitsy wholesome content. (just my 2cents worth of advice.)

**University is so...meh, idk.**

First of all, let's get one thing out of the way. Our precious and expensive universities are far behind what the industry standards are like and they don't equip us enough; that's the sad reality you have to face as a developer in South Africa. So in my sophomore year, I already knew that I didn't want to get into honors. I couldn't wait to get my foot in the industry and play with the big fish, and I don't regret this decision one bit. You'll notice how many companies offer a graduate program before they can fully employ you right. I hope you don't think they do this because they just got some extra bucks they want to throw at you while teaching you some things. They do this because there is an actual gap they are trying to bridge. I was lucky enough to have one of the big software development companies in the country (_which is my current company's now rival btw, yeah evil I know_) come to our campus twice every year to show us some cool things, and it was in these times that I saw how my life was different from theirs.

I've learned from my job in four months what I couldn't learn in university in 3 years ' yeah read that again. And this has nothing to do with my institution's teaching standards in any way. I found that the biggest lessons I've come out of varsity with are the concepts of programming and how to learn stuff, so I essentially spent loads of money for okes to teach me how to learn, yikes! This is not to say it was a waste of money though ' because the concepts of learning and programming will remain the same for a long time. Moreover, the people I met at the time in varsity were brilliant and some I'll keep in my network of colleagues, clients, and friends for life, needless to mention those parties at rag farm and gulping beer like a goat every weekend; that's why we get into uni in the first place right?

While your university may not teach you the latest JavaScript frameworks, or no JavaScript at all (_thanks UFS_), no version control, Azure or AWS or no tools that you will end up using in your day-to-day job, I can see how studying computer science formally helps to give me an upper hand to many ΓÇ£self-taughtΓÇ¥ developers _(because of the principles_). But, and this is a big but. I'm sorry to burst your bubble but the truth is you need to learn what they teach you and a bit more because if you don't you will graduate and then struggle to get an interview or struggle to make it past one, simply because you don't know the real stuff your lecturers didn't teach you and you haven't built anything. Please don't call me a villain, but I find this very beautiful. Why? Because it represents exactly how the industry is. Your qualification is just a piece of paper, okay, what the industry wants is demonstrated ability.

**The truth about being a dev that no one tells you.**

I'll be blunt and shoot straight for the head here because this is something that genuinely pisses me off. I think the hype around software development has gotten a little out of hand honestly, well at least in my opinion. People think we spend our days drinking the best free coffee, free beer, and free soft drinks. Eating free food, going on free adventures, and free dope exhibitions and attending free talks. (_speaking to you directors of movies like The Internship, lol_) While this is true to some extent, it deeply saddens me that some people get into the industry just for these free free free benefits and end up being unhappy or even depressed because people don't talk much about the other side of the job. I am very big on mental health and that's why I want you guys to know that it's not as it seems in the movies.

We spend 80% of our work lives frustrated and screaming at our machines. 80% bro, this is a bit scary and unhealthy if you think about it. The job is very stressful. We solve problems every day and it can get pretty frustrating being stuck on something for half a week when you thought it would just take you half an hour. Now I'm not saying I have the hardest job on earth and my brain cells hurt because I solve the matrix every day on my life, but trust me, you will solve a lot of complex problems.

If you hate learning and you're just a lazy dude you might wanna run off to somewhere else, honestly. This shit is like medicine and there's a new virus every day, but for code. I like to use this comparison because of how I was terrified of the idea that doctors have to keep learning for the rest of their lives (_because I hated school, still do_). Continuous learning is something that will be at the very heart of your career because technologies change, things are advancing every single day and people are finding new ways to solve problems so you need to up-skill yourself to remain competent. This is why companies fall and rise, and a language that was popular 15 years ago is not that popular today. One of the BIG reasons I love my job at this company and chose it against its competitors who pay slightly more is — I am built to know no stack. That means I am a full-stack developer and I can take anything being thrown at me because I engineer solutions and not “mobile apps”, “web apps”, “IoT” or “games”. My company might decide to stop using C# and jump to Python on the same project tomorrow, and I should be fine with that; you can see how that requires me to continuously learn, right? So I think it’s important to understand what you value as a developer.

**Being a dev is more than just coding.**

You're going to spend a lot of your time communicating. Whether you'll be discussing features or updates, speaking with your designers about something you don't understand, speaking with another developer — either helping them on a task or trying to understand something. Or even worse, when you're still starting you will be in a lot of meetings to ensure that you understand your work and the processes of building software. But you will surely be stuck in some meetings where you'll be thinking "damn, I could be coding and getting some work done right now." Bet.

So, it is very important that you know how to communicate professionally and you can express yourself comfortably. Lol, that's what I'm trying to do here anyway. _(It comes in handy when you want to suggest what you think is a better implementation of something.)_

Now, this one is more of a preference and some people don't see the importance of it, but I'll explain why I would advise it. Become part of a community. Whether it's stuff like attending developer conferences, meetups, or simply getting together with some friends and chatting about some tech and solutions over a beer on a Saturday. It goes a long way. I understand that we may not value the same things, but the tech industry in South Africa is still growing, kinda small actually, so that means it's the perfect time to build relationships and networks that will not only benefit you and your career but they will also help share and gain some knowledge. The big shot guys leading teams in your company talk to other big shot guys in other companies okay, understand this. So if you come across as a negligent and incompetent person they will speak about you, they speak about these kinds of things because the game is only so big. So keep yourself in check and don't cuss your whole office before you quit.

**Itsy-bitsy** **wholesome content:**

So, it is very important that you know how to communicate professionally and you can express yourself comfortably. Lol, that's what I'm trying to do here anyway. _(I comes in handy when you want to suggest what you think is a better implementation of something.)_

 ![eat(); sleep(); code(); repeat(); but don't do it](https://miro.medium.com/max/700/1*wmVViQPTJhlUsTfF53O7Xw.jpeg)

**Take care of yourself.** Do you see the picture above? yeah, don't do that, please. This picture is meant to be motivational to engineers so they can get some work done, not that you should do it. You will spend most of your days sitting down, in front of a computer screen. I don't know what you think about that but I think it's very unhealthy. That's why you must take walks/jog to balance it out. Drink water, try to eat less junk and, get some nutrients. Also, look into getting a pair of computer glasses to protect your eyes for those long hours in front of your screen, they reduce the amount of blue light that hits your eyes.

>  "the better your body, the better your mind, the better your code!" — [Lydia Hallie](https://medium.com/u/b7975c9264f4?source=post_page-----e7e057001d34--------------------------------)

**Don't get yourself in tutorial hell, or if you are in it already, GTFOT.** Tutorial hell is when you spend a lot of time and money (but some tutorials are free) doing online courses or tutorials without getting your hands dirty. While they can help in getting started, it's very important to re-build what your lecturer showed you without their help. This is where the real learning happens. Then take what you learned from that and apply it to your project. Practice, practice, practice — that's the best way to learn, IMO.

**Be humble and observe.** The industry has a couple of jerks and assholes. I mean, people even pick on each other because of programming languages and the games that they play, wtf. So with that in mind, you will work with an asshole or egotistic developer at some point in your career, and if you don't, you are probably one _(just kidding)_. When you come across this kind of person, don't lose your temper. Be cool, calm, and collected, and, don't be emotional about it. As a developer, you must have a shield because you will feel vulnerable a lot. Also, when you are still starting you will have a lot of comments in your code reviews. It's very important to understand that people are coming for your code and not you: take this as a learning opportunity instead. If you're not clear on something, always ask why they suggested it over what you had because some intermediates will rain on your parade just to look cool to the seniors, I hate it so much.

Thanks for reading.
===================

With that said, please leave me some 👏👏 down below or leave a response if you enjoyed this read or found it helpful in any way.

I am looking forward to writing about more topics so do follow my [account](https://medium.com/@letsepe100). Connect with me on social media: [Twitter](https://twitter.com/lerato1ofone), [Instagram](https://www.instagram.com/lerato1ofone/), [LinkedIn](https://www.linkedin.com/in/lerato-letsepe-1312b5156/). See you on my next post, or on my sm. Kthnxbai.

large_views-featured-img.jpg

medium_views-featured-img.jpg

small_views-featured-img.jpg

thumbnail_views-featured-img.jpg

views-featured-img.jpg

In this post, I share my views and perspectives on the software development industry in South Africa, at first glance. I start by sharing my past experiences prior to working as an engineer in the industry and further discussing some painful truths I had to learn on my own; before closing off with some reflective analysis and wholesome advice.
<br></br>
This is really where my story began.

In this post I share my views and perspectives on the software development industry in South Africa, at first glance.

Views Of A 21-Year-Old Software Developer.

Connect with me →

Welcome to my dev space