Developer’s Guide to Becoming a Manager

This article summaries my learning as I got comfortable into a manager’s position from being a developer. About 5 years ago, I switched from one company to my current job, just because they promoted me and made me a manager. I refused, and my then manager gave me a long talk on how I’ll get stagnant and go out of relevance if I continue to stay inside my comfort zone. I listened to him patiently, and then I quit. Now, after 5 years, I realise that I really can’t escape that fact. Except for very few careers, you do have to become a ‘manager’ (at least of sorts). Not because it’s compulsory, but because it makes more sense. After gaining enough experience, it’s simply better economic sense to lead (or train or mentor or manage) other people than contribute as a loner.

Even the senior people who claimed they’ve persisted to a ‘technical role’, are just under an illusion in my opinion. They are managing others one way or another. They just aren’t calling it management. Even hard core solo researchers have ‘research assistants’ – which does make it a management job in one way.

Photo by Hunters Race on Unsplash

So I did commit to learning to become a manager. Don’t mistake me – I really don’t think it’s necessary for everyone to climb the corporate ladder to become CEO one day. I just think us developers need to step out of the comfort zone and learn to lead a few people because it has tremendous value to be able to do that, and opens doors which we might not even have considered before. This article records some of the things I’ve learnt from experience so far.

Lead the Project

You’re no longer an ‘executor’ who has to complete the tasks assigned to them. Management doesn’t work that way. It’s not another job where you get a to-do list. You need to lead. You need to know your project’s roadmap – even if there is a separate Product Manager or Architect who’s responsible for it. If you don’t know this, approach whoever is responsible and get to know it. Make sure you’re in the know when decisions are taken in the project. That’s what you need to be thinking about – Where is the project going next? Will it get there on time? Does it need to switch tracks? Are the initial assumptions still valid?

Delegate First

When you see a task, don’t think ‘I can just do this myself – it’s just a little thing’. That’s probably the worst and most common mistake new managers make. It’s tempting to believe that in the time it takes to explain to another person, review their work and accept it, we can just do it ourselves. That maybe true, only you have a different job now. Your job is not to finish that task – not anymore. Your job is to get a specific person/team to finish that task. So that’s what you should be focusing on. Get out of your comfort zone and start thinking about how you can get the other person to do it for you.

Start Managing

You might have thought so long that managing is just maintaining the to-do list. But you’re in to find out how demanding it is to maintain a to-do list. As a new manager you probably have only one project/team to manage so you’ll be expected to know the status of every single item in your project. You need to know how many bugs are there. How many of them are critical? What roadmap items are coming up in the near future? How occupied are members in the team? How spirited are they? Is any task running the risk of getting delayed? Can that delay be avoided? If not, who should be notified of the risk?

Consolidate

A developer who know how to write programs, can’t really earn his own living by sitting alone and writing programs. A large company can’t get their requirements met by a single programmer. Now that’s where you come in – the new manager. You take the output of several programmers, and consolidate them into a unit which is useful to the company. Most of the job of a manager is just this – to consolidate individual efforts and pass it on to your customer (or your superior). Other activities of a manager – such as appraising team members, reporting project status etc., are supplementary to that main goal. Although it doesn’t come out that much, it’s the fact – you are there to tie pieces together towards an ulterior goal.

Get Feedback

This is something that we usually learn very late. This communication is important, and might be considered one of the most effective communication that can happen between a manager and their team. You should always be on the lookout for receiving feedback about how well you’re doing as a manager. You can succeed as a manager only if your team is committed to your leadership. But you might not be able to ask for this directly. It will put your team members in an awkward situation if you ask them to rate your performance. What your team thinks of you is as important as what your superiors/customers think of you.

Give Feedback

You should be expressive in appreciating your team member when they do a good job. And you should not hesitate to (politely and discreetly) suggest that they need to improve on something. While for many managers it’s easy to appreciate, they try to avoid criticising. They don’t want to hurt another person’s ego. It is indeed a good motive, but not enough to completely avoid giving negative feedback. Learn to do it in a way that doesn’t hurt their ego. Think how to put it such that they take it in a constructive way. Do not shy away from conflicts – deal with them in a friendly and respectful way. Use your influence, not your authority.

Learn Emotional Intelligence

Even before becoming a manager, you should have put effort in increasing your emotional quotient. I remember it was a buzzword and all the craze at one point in the past, but has been forgotten a bit now – unfairly so. Emotional quotient is considered more important than intelligence quotient. It’s common for technical people to start putting up spreadsheet, project management software and all those kind of things – and they start relying on those things. They assume that if they maintain everything up-to-date in their project management software, things will be running smoothly. This is far from the truth. After so many years in software development, I haven’t come across even one strong example where a ‘management tool’ helped success of a project. It’s about how well you connect with people. How well you can influence them. How well you can understand them.

Conclusion

The biggest change when you become a manager, is this – you need to stop thinking about code, technology and programs and instead, start thinking about your project, your team and your customers (or superiors). Less working with computers and more working with humans. That jump is what I’ve seen new managers struggle with. You need to build up your communication, persuasion and networking skills. Start by getting comfortable talking with your team, and always have your project’s roadmap in mind, and you’ll be on track to become an awesome manager.

Drawing Tablet Tips for Beginners

A few months back, I had decided to rekindle my video game making dream and have a proper crack at it. But obviously, I’m held up with two major items – one is my job which I can’t do without right now, and another one is the online master’s course on Data Science. But I haven’t put my game making journey completely on hold. I’ve been making slow (very slow) progress on non-programming areas – namely music and art.

I’ve started to learn how to draw. That’s my weakest link. I have some experience making music from learning to play my Violin. I know programming. But I am at level zero in art. I’m amazed at how much resources there are available for learning how to draw online. And of great quality. I’ve specifically started to learn using the Drawabox lessons. They appeared absolutely suitable for a know-nothing like me.

Naturally, I wanted to use my Wacom Intuos tablet to learn drawing. Boy how completely different it is from drawing on paper! I installed Krita – beautiful software by the way. Since I had already started doing some exercises on Drawabox, I tried repeating the same exercises on the drawing tablet. I just couldn’t. I was able to draw basic shapes quite well on paper, but on the tablet, I couldn’t even draw a single line without wobbling. And I’m used to rotating the paper while writing or drawing – which was not very convenient in using the tablet.

But I think I’ve got the hang of it now. No, I still can’t draw very well, let alone on a drawing tablet. But I’ve got some learning to put me on the right direction. What I’ve learned about drawing tablets so far –

Put it on the Side

We usually rotate the paper and write/draw at an angle because the arm is attached to the side, while the paper is in the centre in front of us. If the paper is also moved to the side, I realise that it’s no longer inconvenient to keep the paper fixed. Extending that, I just put the drawing tablet on the side – where I usually have the mouse. Instantly, my hand-eye co-ordination shot up and I felt so much more comfortable drawing without having to rotate the tablet. My lines were mostly aligned in the direction I want to.

Reduce the Lag

I noticed that there was an annoying lag while drawing with the tablet. Now unless I get myself a super high-end tablet, I probably can’t get rid of this problem. But I was able to reduce it a lot. I connected the tablet using USB rather than Bluetooth. It was a bit less convenient – but shouldn’t matter if you don’t have to constantly move the tablet as you’re drawing. I also quit other applications running in my computer. It’s a great improvement even if the lag reduces by a fraction.

Mind the Aspect Ratio

The drawing tablet and the monitor might have different aspect ratios. Mine did. It took me quite some time to notice this. I’m not very experience but I suppose this is a bad thing. It’s better not to get used to this kind of anomalies. To check, I put a perfectly round bottle cap on the tablet and drew a circle. It came out noticeably flat. But there was a setting in the tablet configuration (On Mac: Settings > Wacom Tablet > Mapping > Force Proportion), which made this right. After this setting, I repeated the bottle cap drawing and it came out perfectly circular.

Mind the Aspect Ratio

Practice!

Practicing a few minutes everyday improved my ease of using the tablet. While this is obvious, I just want to say that two exercises helped more than others.

  1. Superimpose lines – This was the first drawabox exercise, and it was especially useful on the tablet. Just draw a smooth line and try to draw several lines over that same line. Try to get it deviating as little as possible. This helps improve sense of direction while drawing in one place (on the tablet) and observing it elsewhere (on the monitor).
  2. Tracing – Open some line drawing as a layer in your drawing software, reduce opacity of that layer. Now with the pen, trace the drawing. This is a fun exercise too. Just be mindful of whether you’re drawing from your wrist or elbow or shoulder.

But not too Much!

Don’t ‘grind’. This is an advice I get a lot ever since I started to learn drawing, and I’ve come to completely agree with it. If you’re trying something, reach a ‘decent’ level and then move on. Don’t try to keep practicing the same thing till you get it perfectly. That’s for when you know what you want to draw. When learning, be content that you practiced. And move on. You don’t have to draw a perfect straight line – you just have to draw a ‘confident’ straight line. It improves as you keep drawing. If you repeat the same exercise to death, then it just becomes demotivating and tiresome.

Learn the Software

Remember that you just need to become confident and comfortable using the tablet. Not things like drawing a perfect straight line, being able to draw in any direction etc. Learn the standard features of the software. For example, most drawing software have a stabilisation feature that adjusts any wobbles. They make ellipses neat once you’ve drawn them. Although as a learner, it’s good to learn the basic art instead of relying on these features, it’s still good to learn the features. Because you’ll know what techniques to concentrate on in the beginning, and what techniques will be irrelevant because of software assistance.

So there it is. My (very premature) tips on learning to draw using a tablet – for beginners. If you’re a total beginner like me, first you need to learn ‘how to see’ – recognise the shapes in what you want to draw. The pen, or paper, or your graphics tablet – are just tools after that. So the most important tip – think and understand what your instructor (or ur tutorial website) says. No matter how much you stumble, you will eventually (and quite soon), become comfortable using your tools.

SOLID principles

One of the biggest advantages of object oriented programming is the amount of good practices and design patterns that have been researched and documented. Most of these exist so that introducing changes in future is easy and safe. Once a piece of software reaches critical mass, it inevitably ‘hardens’ – making changes to it is risky, it becomes extremely tough to even read and understand. Someone who attempts to fix a bug or extend a functionality, feels threatened that they might break something by making their change – and rightly so. If code is not well written, something will almost always break when a change is made.

Being able to write code which is easy to understand, maintain and extend is what separates the great coders from the thousands of people who simply write code that barely works. The SOLID principles is one set of simple guidelines that are extremely effective in elevating the quality of your code. If you don’t already know, SOLID is an acronym for 5 principles, namely –

  1. Single Responsibility Principle: Each class has one and only a single responsibility.
  2. Open-Closed Principle: Classes should be open for extensions, but closed for modifications.
  3. Liskov Substitiution Principle: Subclasses should be substitutable for parent classes.
  4. Interface Segregation Principle: Interfaces should be segregated into multiple, small, specific ones.
  5. Dependency Inversion Principle: A class should not be used directly inside another class. It should be abstracted using an interface.

I’ll explain my understanding of the 5 concepts in a bit more detail here.

Single Responsibility Principle

This one is easy to get. A class you create, should have only one responsibility. For example, when you are developing a web application, you will probably be using the MVC pattern. Most web applications also involve authorizations – like whether the current user have permissions to edit this record. Where does the code for doing this authorization go? If it is in the controller class, then the single responsibility principle is broken. The controller code should have only code that does the orchestration. Another example is validation. Your application should have a class that has all your validation code. The controller should only use this validation class to perform validations.

In the following code, UserController has only one responsibility – to orchestrate all the steps. Validator class has only one responsibility – to validate requests. Authorizer class has only one responsibility – to perform authorization.

class UserController {
    Validator userValidator;
    Authorizer userAuthorizer;

    public UserController(Validator userValidator, Authorizer userAuthorizer) {
        this.userValidator = userValidator;
        this.userAuthorizaer = userAuthorizer;
    }

    public Response createUser(Request request) {
        if(!userValidator.isValidRequest(request)) {
            return ErrorResponse("400: Bad Request");
        }
        if(!userAuthorizer.isAuthorized(request)) {
            return ErrorResponse("403: Forbidden");
        }
        // .. code to create user .. //
    }
}

Open Closed Principle

Classes should be open to extension but closed for modification. Let me put this principle in two parts –

  • It should be possible to extend a class when requirements of the application change. If you are building a bookstore application, you might have an Order object inside a OrderProcessor class. Your application should allow for future extension like ‘urgent’ orders.
class BookStore {
    OrderProcessor op;
    op.process()
}
class OrderProcessor {
    Order o;
    public void process() {
        // order processing logic
    }
}
  • It should not be possible to modify a class. This means, if you introduce a new class like ‘UrgentOrder’, you should not modify code inside the OrderProcessor class. Like ‘if (order instanceof UrgentOrder) … ‘ etc.
/* This is not allowed ! Closed for modification => must not change the OrderProcessor class. */
class BookStore {
    OrderProcessor op;
    op.process()
}
class OrderProcessor {
    Order o;
    public void process() {
        if (o.type = normal) {
            // order processing logic
        } else if (o.type == urgent) {
           // urgent order processing logic
        }
    }
}

The way we achieve this principle is by ensuring our classes will never be changed. We will only write new code to support new functionality. So this example, if written following the Open/Closed principle will be –

class BookStore {
    OrderProcessor op;
    public void execute() {
        op.process()
    }
    /* .. */
}
interface OrderProcessor {
    public void process();
}
class NormalOrder {
    Order o;
    public void process() {
        // order processing logic
    }
}
/* When a new type of order - 'urgent' order is introduced, we don't have to change the above code. Just write a new class implementing the OrderProcessor interface. */
class UrgentOrder {
    Order o;
    public void process() {
        // urgent order processing logic
    }
}

Liskov Substitution Principle

When you inherit a class, the new inherited class should be substitutable for the original parent class. That is, if your code has a ‘DatabaseConnection’ class, and you are extending this and creating a ‘CachedDatabaseConnection’, then this new type of object should be usable wherever the DatabaseConnection object was used.

If you are using a strongly typed language (like Java), you probably don’t even have to worry about this principle. It is automatically ensured that the extending class will be usable wherever the extended (parent) class was used. But if you are not using a strongly typed language, it is your responsibility to ensure this principle is not broken. An example scenario (in JavaScript) that breaks this principle –

class Item {
    stockQuantity() {
        return 5;
    }
}

class SpecialItem extends Item {
    stockQuantity() {
        return {"warehouse1":3, "warehouse2":2}
    }
}

The above example breaks Liskov Substitution principle because other code expects Item.stockQuantity to return a simple integer. If the new SpecialItem is substituted there, Item.stockQuantity will return a compound object and the application might break!

Interface Segregation Principle

I like to think of interface segregation principle as same as the single-responsibility principle, but for interfaces. It simply means that your interfaces should have enough segregation between them so that no class will have to implement methods not applicable for them.

interface Animal {
    public void swim();
    public void fly();
}

class Shark implements Animal {
    public void swim() {
        // I'm swimming
    }
    public void fly() {
        // Error: I'm a shark! I can't fly!
    }
}

class Crow implements Animal {
    public void swim() {
        // Error! I'm a crow, I can't swim!
    }
    public void fly() {
        // I'm flying
    }
}

The above example breaks interface segregation principle, because the Shark class has to unnecessarily implement the fly method, only to throw an error. Similarly the Crow class implements the swim method. To make this code compliant with interface segregation, the Animal interface should be segregated into two interfaces.

interface Fish {
    public void swim();
}

interface Bird {
    public void fly();
}

class Shark implements Fish { ... }
class Crow implements Bird { ... }
class FlyingFish implements Fish, Bird { ... }

Now that the interfaces are segregated, we can implement sharks, crows without having to write unnecessary code. And when a new class needs both functionality, we just implement both interfaces.

Dependency Inversion Principle

Using a class inside another class couples them tightly. Dependency inversion avoids this by introducing a layer of abstraction.

For example, a repository class will have a database connection object as a member. Now the repository class depends on the database connection object. If the database connection object needs to be changed (for example, you decide to use MySQL database instead of Oracle), even though the functionality doesn’t change, the repository class needs to be rewritten to use the new Oracle database connection object.

In the above example, if dependency inversion is deployed, the repository will no longer be dependent on the MySQL connection object. It will be dependent on an ‘interface’ like DBConnection. Now both MySQL and Oracle connection objects should ‘implement’ this DBConnection interface. In other words, the repository object, the MySQL connection, and the Oracle connection have all been made to depend on the DBConnection interface. The dependency has been ‘inverted’. As long as the MySQL and Oracle connection classes implement the DBConnection interface, they can be switched seamlessly.

Conclusion

So there, I’ve tried to explain the SOLID principles in the shortest possible way that I could think of. SOLID principles are like the foundations of object oriented programming – and this article doesn’t do justice to their importance at all. Watch this video – https://www.youtube.com/watch?v=zHiWqnTWsn4 to get a deeper understanding of these principles from Mr. Robert Martin. Disclaimer! The name of that YouTube channel might be offensive to some – I’m not related to that channel in anyway, I don’t condone bad language, I do not have any informed opinions about subjects like communism.

New Year Resolutions

Photo by Chandan Chaurasia on Unsplash

I know most of us hardly stick to new year resolutions. But I still like making them. It makes me size up my life and think of what I have and what I miss. For this year, I want to –

1. Get Off the Computer

If you’re the typical developer, you probably have all the other parts of your life on the computer too. Your friends are all online. You hobby is probably playing video games. Reading books, watching videos, doing their budget, writing down to-do lists. Almost everything you can think of, you’re probably doing on the computer. When you think of a side project – it’s probably something to do on a computer – writing a blog 🙄 , freelancing as a coder and so on. If you study you’re probably going to take one of the online courses and study on the computer.

Well this year, I want to get off the computer. Of course I’ve already started an online course and I’m writing a blog. But I don’t think those are taking up much of my computer time. Apart from my work, and a couple hours for those things, I think I don’t have to sit at my computer at all. A major chunk of computer time goes for gaming, Facebook, YouTube and Netflix. I can altogether drop those. I resolve to have my entertainment and social life, away from the computer. This means I’ll have to let go of some of the new and the cool. Even for studying and blogging, I’m thinking to partially move them away from the computer. Maybe I can write drafts on pen and paper before I sit to publish it on the computer. I can also study the online course using a tablet, take notes with a pen and paper.

Less computer. More real world. More pen-and-paper.

2. Learn Continuously

This is partially already done because of the nature of development jobs. You just can’t avoid learning. New frameworks and tools pop up every day. Parts of the job are getting obsolete and new parts are getting created. Lines between business and IT are getting blurred. If you’re a developer, the only way you can be successful, or even just survive for long, is if you keep learning new things. This much goes without saying.

But what about the other things? Do you know anything at all besides coding? Have you learnt music or an art? To play a sport? Do you know about economics? Do you know to cook? Pick one or two skills outside of coding, and work on it regularly. Maybe cook food on weekends. Learn a new language (a spoken language – not another programming language). Join a workshop on reparing cars. Practice it by yourself or join a class. Do something that expands your mind. Do something that makes you interesting.

Develop a new skill. Keep improving.

3. Take Health Seriously

Whenever I get pain in my shoulders, neck or lower back, I go through a ‘fitness phase’. I get the pain treated and follow a workout routine for a few days after that. But as the pain is relieved, so is my motivation. Not only fitness, but even looks can become invisible when most of your life is online through a computer. I mean who cares if you’re fat if no one ever sees you right? After two years of living alone as a developer, I have literally become that fat guy who’s only contact with outside world is with the food delivery guy. Literally!

I resolve to take health seriously. Prevention is better than cure. I’m targetting a healthy fitness level, eating good food, moderate regular exercise and frequent breaks for ergonomics. My chiropractor said the best posture is no posture at all. I like the way he put it. You need to move frequently so that you’re not really getting ‘fixed into a posture’ in the first place. That’s the only way to avoid posture related problems.

Do about half an hour of exercise, almost everyday. Include some fruits and vegetables in diet. Do not keep sitting for more than half an hour at a time. Go to bed early – without your smartphone.

4. Give to Relationships

This one is particularly hard for me because I’m a complete introvert. I am truly fine just being single rather than have to put up with a family. I simply hate even just being around people. But I’m resolving to this anyway. Because I’m old enough to know that this is important. Being around people, having face-to-face interactions, depending on and being depended upon, are immensely more satisfying than a lonely-yet-comfortable life. I, like many other developers, have always avoided social interactions with people. I don’t do small talk, I don’t attend ceremonies, I don’t even go to casual meetings at work.

I try to avoid my family as much as possible. Even though I like to spend time with my little nephews, I’d rather not because it would mean I have to be around the grown ups too. I need to stop being such a loner. Wisdom tells me that friends are important, family is important.

Make more friends and invest some time and effort into the ones that exist. Be in touch with family.

5. Travel

There are so many YouTube channels that make you yearn to just drop your ‘normal’ life and become a nomad with a back pack. But that’s simply impractical and unnecessary. Not everyone can (or should) become a full time traveller. But I believe vacations are necessary. They create a disconnect that simply can’t be achieved otherwise. I’m at the end of a two week holiday but doesn’t even seem like I left work. Because I just spent it all at home. Still at my computer. Still thinking about work.

Traveling – without your laptop – actually traveling, acts like a reset for the mind. You don’t have to travel to fancy places or spend a lot of money. Just to a simple place a few hundred kilometers away. Maybe for beautiful views of nature, maybe for spirituality of an ancient temple. Maybe solo, maybe with friends or family. But make it a point to do it.

Travel to a far away place. Atleast 3 days together. Atleast once in 3 months. Create memories.

How to Not Panic in a Job Interview

One of the nice things about sticking for long periods in the same job, is that you build trust and get picked for interviewing potential new employees. I’ve so far conducted more interviews to pick junior programmers than I care to count. I will never say no to conducting interviews because hiring an employee is synonymous to expanding the company. I believe it’s invaluable contribution to help with screening and selecting the right candidate for your company. That candidate is not only going to contribute a lot of value, but they might also be a superstar factor who propels your company to better heights – and their journey in your company would have started with your interview.

The biggest reason I’ve had to reject candidates, is obviously incompetency – but quite a lot of times, I’ve felt maybe this person is competent, but they’re stressed and aren’t performing at their best. At these times, it’s quite easy for me to direct the conversation and put them at ease, and thus having a positive interview experience. But there are times, when the interviewee just panics. Their mind just shuts down, words just come out without much thought or imagination, and I sense they just want the interview to end. They don’t even care about getting the job anymore.

Photo by Maxime on Unsplash

Before the Interview

Preparing for the interview is such a no-brainer and yet, it’s shocking how many candidates turn up without preparation. They think interview is just a conversation and they can simply answer questions from their memory. Walking in without preparation is the number one reason interviews end in failure. The interviewer has probably sat down and prepared to interview you. It’s not only in your interest, but also a courtesy to them that you spend some time properly preparing before your interview.

1. Revise what you know about your skill

If you are about to interview for a programmer job, it’s very important that you study up on your technologies. Do not skip this part. Even if it’s a technology that you’re currently working on, do a revision and checkout common interview questions on that topic. When I interviewed for my last job, I actually asked them that I need a couple weeks to study up on Java programming. If you have studied well, you will be able to give crisp and confident answers. But if you haven’t, you will be dragging your answers around, trying to shoot all over the place hoping something will match with the interviewers expectation. That never happens though. If you have put something on your resume, make sure you’ve read up on it enough to answer questions about it.

2. Know Thyself

I know questions like ‘tell me about yourself’, ‘where do you see yourself in 5 years’ and so on, seem clichéd. But frankly, what else is an interviewer supposed to ask you? Interview is a situation where you need to be analyzed in a rather short time – often barely enough to know a person. There are tons of lists on the internet about ‘frequently asked interview questions’. Select about ten good questions and prepare answers for them. And surely prepare a good answer for ‘tell me about yourself’ – I have a 2 minute answer and a 10 minute answer. Prepare answers for any areas of concerns you might have – for example a break in your career, or why you got fired that one time, or why you have a low CGPA. If you prepare answers like that, you’ll be able to control the interview – distract them from negativities and guide them towards your strength.

3. Know about the Job and the Company

Another easy – yet often ignored – part of your preparation is to know about the job and company you’re interviewing for. Have you even read the job description? There is vital information in the description – it’s not some rough note put up. The HR and the job’s department works together to properly describe the job and what the interviewers will expect. This job description is a vital tool to help you prepare for the interview. And about the company, you need to know it’s core purpose and mission. The answer to ‘do you know about our company?’ should be ‘I know it does __ and __, but I’d like to know more’.

During the Interview

1. Remember the Interviewer’s Goal

The interviewer’s goal is to hire you. Often we have to interview way more candidates than we’d like. When I start an interview, I hope sincerely that the candidate gets selected and I can move on to other work. But candidates almost never have this realization. They always appear anxious as if I was there to push them out of their limits and reject them. That is far from the truth. I’m sitting there hoping to discover what your strengths are. My managers are probably urging me to hire someone soon. There is a project that’s struggling for the lack of a developer and it will be really great if you get hired. If you kept these facts in your mind, you’d be way more confident in your interview.

2. Keep Moving Forward

You might not have answered the question as well as you liked, but are you going to let that affect your next question? That’s what a lot of people do. They start focusing on a mistake they made and lose focus on what’s happening at present. Even a little stutter or slip of the tongue, derails people. And it’s worsened because it gets accumulated with each question. Doing something wrong in one question makes you lose focus and you make another mistake soon and so on, till the point where you are in full panic, accepted failure and just want the interview to end. Avoid this. Forget that you made a mistake. You don’t have to go back and fix it, or convince the interviewer to forget it. Consciously move on and start your next answer with a fresh and positive mindset.

3. Collect Your Thoughts Before Answering

The pressure to impress the interviewer reflects in the candidate’s behavior. I have no idea why, but people always assume they have to answer fast and quick. It’s not like the interview is a rapid-fire round on a game show. My expectation is almost always the opposite. When I finish stating the question, I always expect the person is going to pause a few seconds to compose their answer before responding. Even if the question is straightforward and you don’t need to recollect anything, it’s still useful to pause and take a breath before you start answering. If you answer in a relaxed pace, you appear confident, and you can keep up your energy for longer.

Still Unsure?

If you’ve taken the points I’ve mentioned and still lack the confidence about attending interviews, then the only thing left is to practice.

  1. You can do mock interviews with other people (friends or paid services). But I find them impractical and a bit dramatic. What I would advice is, to do mock interviews in your head. Just play out your interviews in your mind and observe you from a third-person point of view. Granted, you cannot predict how the interview is actually going to be, or what the interviewer is going to ask you. But picturing your behavior makes you less concious and removes one main source of anxiety during interviews.
  2. Consider each interview as practice. Keep attending interviews of similar jobs or similar companies. For the first few, don’t keep expectations of getting hired and keep in mind you are doing it only for practice. You’ll improve with each one. You will automatically get better anyways, but also retrospect and find out how you can improve yourself for your next interview performance. Sometimes the only way you can learn is by jumping right in.