Karim Aya

Karim Aya


Mistakes you’ve probably made in your coding task for a job interview

**Originally published by Michael Lazarski ***at *medium.freecodecamp.org

You got this task from that company you want to work for! You are hyped and you immediately start to work on it. After a long night of coding, you are done and you think you implemented the best thing ever!

So you send the task back to the company. After some time you get an email from that company. You are confident that you aced it and they are sending you a draft of the contract!

Then you read the E-Mail and you can’t believe what you are seeing. It’s just a thank you E-Mail and that they decided to go with someone else.

What went wrong and how could you improve? Let’s dig into it!

Mistake 1: you did not read the task carefully enough

Sometimes just one word can change the meaning of the task completely. Perhaps you did not catch the word responsive the first time, or you just think that you got it but you don’t get what the task is really about.

So read the task a few more times to really understand it.

Mistake 2: you started implementing the task without fully understanding the task

So you have fixed mistake 1 but you’re still having questions? Ask the person you are in contact with. It’s not bad to ask! It’s the opposite as it shows the company that you care about a good product and that you don’t want to waste their time.

If they react negatively, then I would stay far away from that company because this is the first sign of a toxic environment where nobody can ask anything.

Mistake 3: you are not using Git (or any other version control system)

Please! Please! Don’t send a 60 Mb ZIP file via E-Mail with the complete node_modules Folder. OSX does not like to unzip node_modules, so the person who will review your code will not even get a chance to look at your code.

Use Git instead. If you don’t know Git then this is the best chance to learn it because a lot of companies use Git. Sooner or later you will have to learn it.

Mistake 4: you didn’t write good commit messages

You are now using Git, good. Don’t do everything in one commit. Companies will look at your git log to read the commit messages. You have to remember you will work in a team, and in a team good commit messages matter. It’s important for the other team members, and for you in 2 weeks when you have to find a commit or understand what happened in that part of the application. So commit often and write good short messages.

Mistake 5: you forgot the .gitignore file

This comes back to mistake number 3. If you don’t have a .gitignore file everything in that directory will be added to Git. So again you will send the complete insides of your node_moudes. Nobody wants your node_modules.

Here is a good collection of gitignore files: https://github.com/github/gitignore

Mistake 5: you are sending a Zip file via E-Mail

I mean as a developer you have to know GitHub, right? So use it! Put your code on GitHub and send the GitHub link to your contact person. Your contact person will be very thankful for that.

  • No corporate spam filter will remove the zip file.
  • Yes even in 2019 E-Mail’s have a file size limit and you may be just hit that limit
  • It is easier to have a first look at the code without downloading a zip file.
  • It is easier to share with other developers in the company. Usually, more than one developer will look at your code.

Mistake 6: you don’t have a README.md file or it is not good

Github will render the README.md file and it will be shown on the main page of your repo. Write some meaningful content in it. For example, the task name or explain what this task does, maybe add the dependencies…and this brings me to my next point.

Mistake 7: you didn’t write instructions on how to start your task

Yes, I can go the package.json file and have a look at your scripts and if they are meaningful I can figure out which of them is the right one to do or maybe not. So please write down in the README.md how to set up and start your task so I can run it.

Mistake 8: you did not include a working link to your task

“But why should I do that when you just told me that I should write instructions on how to run it?” is what you are asking yourself right now. To make reviewing your task as frictionless as it can be, so the reviewer is not annoyed that they had to figure out for one hour how to see if your code is actually doing what was mentioned in the task.

Put a working version anywhere on the internet where you can give the reviewer a link. Heroku, GitHub pages, AWS or Azure are just a few which also have free services for doing that.

Mistake 9: not removing old/unneeded files from the task

Don’t be that developer that has an _old folder somewhere in the git repository. As a reviewer of your code. What should I do with this folder? Should I look into it or maybe don’t? Why is it there? I don’t even know what to say. So please remove all unneeded and old files from your code.

Mistake 10: you didn’t write a nice E-Mail with the link to your GitHub repo

Don’t just send an empty E-Mail with a link. This can be viewed as very rude. I mean on the other side is also sitting someone human. Write at least: Hello X, how are you? I hope everything is fine. Here is the link to my finished task [THE LINK]. Have a nice day. Best wishes, Michael.

Mistake 11: Don’t say something is easy

“Javascript is easy and not hard”. I don’t know why people say this but it is a common thing. You can replace Javascript with anything you want. Everything is easy and also hard at the same time. Driving a car is easy but driving a Formula 1 car is hard.

Why does this matter? It shows the interviewer that there is some kind of elitism in your mind. What do I mean by that? It’s the same thing when people who are new to programming are asking: “What is the best way to do XYZ?”. There is neither the best way or one way. There is not such a thing as the best programming language to use or to learn.

So if you learned C++ you now look down on Javascript developers, that shows that you feel like you are in some elite squad. It just means that you learned one tool from your toolbelt. You now can use the Claw Hammer but not the Sledgehammer. Yes, it will be easier to now learn the Sledgehammer but both hammers have their own pros and cons.

So please don’t say that things are easy. Most probably they seem easy because you don’t fully understand them.

Mistake 12: you don’t write tests if the job specs say you have to know how to test

It’s always a plus to show that you can write tests. They don’t have to be perfect. You don’t have to have 100% code coverage. Just write some simple tests that are testing your core functionality and you probably have a big plus point.

Mistake 13: not splitting your code into smaller files

If you send one big file with 2000 lines of code it is hard to review that.

As someone who has to check your code, it is hard to see what is happening in this file and how the code flows. Probably you also have to scroll from top to bottom. Better try to split your code into smaller files. This will also be important later for work. Nobody wants code that only you understand but none of your team members. Please split it up. It’s so much easier to review.

Mistake 14: you don’t have code comments or you just write what the next line does

This one I see people do even after some years of working as a developer. Comments like: // Loops through an array and the next line is Array.forEach(). Yeah hello, Captain Obvious. It would be better if you would describe what this loop does in a more abstract way. // preparing data for sending it via AJAX or something in this direction. So people know what the intent of the code is.

Mistake 15: your code is all over the place

const array = [ 1, 2];
array.forEach((a ) =>{
 a = a+ 1;
console.log(a) ;

This is really hard to read and also shows that you are working very carelessly. Today we have tools like eslint and prettier. Every bigger editor and IDE has this build in or you just need to install a plugin/extension. So please use it.

Mistake 16: you are not naming your variables properly

const b = true;
const a = [];

This is not easy to read and not helpful to understand what b is.

Way better naming could be:

const isReady = true;
const listOfPersons = [];

Again these are just examples and every team will have its own way of naming things. Of course, you can not guess that style, but just do what you feel is a meaningful name and stick to one style.

Mistake 17: you are just commenting out old code

I have seen this often and I still don’t understand why people are doing this. You have a file with 100 lines of code and 70 lines are just old code which is commented out and 30 lines of an actual implementation.

Should I read the old code? Should this show me that you did it the first time wrong and then reimplemented it? Nobody is perfect and writes the first time the perfect code. So please delete this code. If I want to see if you refactored the code I should see it in the git commits with git commit messages where I can understand what you did.

Mistake 18: you did not check if your code is still running

This happens all the time. You get one E-Mail from an interviewee on Sunday evening. You go to work on Monday and start to check the code and suddenly you get a second E-Mail with some updates in the code. You also get a promise that this time it really works.

So please, before you send your code. Stop the program, clean the cache, install the dependencies and start it again. If it then still works then you can say that you’re ready.

Mistake 19: you changed something and did not check if it is still running

For our full-stack developers, we have a task where they need to save variables in a database. They can choose the database, the schema and how to save the variables. We just say this has to be saved. This is where people change the code and don’t check if after the changes it still really saves to the database. For example, they change the schema or they just try it with a small file, etc.

Again before you send your task back, check if all functions are still working as they should and try to break stuff. Nobody is saying that you need to catch every edge case but at least the most common things a user can do.

Mistake 20: you did not prepare for the coding interview

Some time has passed between sending the task and the actual interview, maybe a week or more. Do you really still remember what you have done in that task? Like why did you solve this task in that way and what was your thinking when you implemented your task?

One of the goals of this entire process is not to see how good you are as a programmer but whether you fit the team and if you a team player. It’s more about your soft skills than your coding skills. Please read your own code before you go to the interview part.

These are just a few examples I have seen. Do you have more? Comment down below!

Maybe you want me to review your code? Or give you some tips on how to help you? Just contact me on any of my social media accounts and I can try to help you. Of course, I can not do the task for you but I can help with everything else!


What is GEEK

Buddha Community

Mistakes you’ve probably made in your coding task for a job interview
Wiley  Mayer

Wiley Mayer


How to Prepare for a Coding Interview in 8 Weeks

As of this writing, the market is tough. We’ve been hit hard with a deadly

pandemic that left thousands of people unemployed. It’s layoffs everywhere and the companies are being conservative when it comes to


Companies are not willing to hire people with no experience or people who they’ve to train.

Your first job in tech is the toughest, you’re competing

with virtually every new college grad and anyone who completed a boot

camp. I know it can be hard to even land an interview, for someone to

give you a chance to talk and demonstrate you could be valuable


Now, the chance of you getting an interview totally depends on how your resume compares to the job description. The more relevant it is to the

skills required, the better your chances of getting an interview.

To build your resume, I’d recommend https://thetechresume.com. It’s a nice read to follow the principles when it comes to building a tech resume.

Over the past few months, I’ve been collecting resources like videos,

websites, and taking notes to prepare for coding interviews.

In that process, I made an 8 weeks study guide curated of important data

structure resources to prepare for tech interviews and honestly this

study guide was helpful to me to know what to study every day and in

following a routine for my job search.

Why 8 weeks?

If you’re serious about preparing for a tech interview then 8 weeks is the

minimum to be given to prepare thoroughly for a tech interview. I know

there are few who would cram up pools of content in a week or two. But, I

believe that is not a realistic or sensible approach.

Tech interviews can be intense and most companies expect you to solve problems or go through a data structure topic in detail.

Now, My study guide with resources will eat up the entire blog space. So,

Instead of straight-up dumping down the content all together, I racked

my brains on how to deliver the content in the most effective way

possible to ensure the habit of consistency and dedication stays intact

during the interview preparation process.

In this blog post, I would give you what to cover each week. If you’re

interested to know what resources to refer to when covering each topic then I’d recommend subscribing to the newsletter https://thedailycoding.com in which you’ll receive one email daily about the concept and the resources to practice.

If you believe you can find resources to relevant topics on your own then

here’s how you should plan to cover each topic every week.

#coding-interviews #software-development #job-interview #job-search #coding #latest-tech-stories #coding-interview-tips #coding-job-interview-advice

Justyn  Ortiz

Justyn Ortiz


For Developers: How To Prepare for a Job Interview

Last week a friend asked me about interviews, it’s a good question because in our career we passed for a lot of interviews, sometimes to get a good job, change companies or probably you will be the interviewer, today I will try to cover both points of views to manage an Interview.


I remembered my first interview was when I finished my thesis, it was for an internship at a financial company in Madrid, I was very nervous, I did not know how the interview process would be and I was not updated on trends in software development, it was after Easter week, I was only 21 years old, you know me I was ready to spend a relaxed time on the beach with some friends, but the interview changed everything for me, I decided to study and review some topics instead of drinks, celebrations, and fun with friends.

When you have an interview all of them has a process, the first step is talk to you and verify your information, like name, address, current job, and so on, the majority of time is with someone from human resources after that you will have a personal interview, it could be face to face or for video call, in both cases, the interview is very important to verify your experience, your knowledge, and your skills for the position you’re applying, then probably you will have a code living where you will show your skills to resolve problems or algorithms finally, you will have an exercise to resolved an interview case, sometimes you will have an extra interview with the Project manager or CEO that depends on the job position.

Some process takes a lot of time, like google or amazon, and it’s a long road to follow this process, so my first advice is “Be patient and keep calm”, you should gain time in each step to prepare for the next, especially in dev interviews so I will give some advice and recommendations for it.

Please review the job position to verify this position is for you.

Sometimes when we are searching for jobs we just join to participate in interviews but we don’t review all the information about the position, for example, what are the responsibilities for the job? How long will be my job from home? Please try to review if the company and position fit with your requirements

Try to stay updated with trends in your career.

A big mistake is not follow trends and new technologies in your job.

Probably you are a developer, scrum master, or project manager with routines in your current job and same technology for all your projects, but please try to spend a small time every day to read and discover the technology world, in our career is very important because you should try to keep updated with new frameworks, new methodologies and more. It will make a big difference in your interview.

In face-to-face interview, or video call: Try to look good, and relax.

Appearance is very important: much like in a web application, you can have a perfect backend but if your application doesn’t look good, probably you can not sell your product.

It’s the same with your personal look and feel: you should wear formal or semi-formal for your interview because you will show a good personal appearance and security for the position.

I know some people think.

#web-development #frontend #coding #coding-interviews #careers #how-to-prep-for-an-interview #interview-tips-for-devs #dev-interview-questions

Brain  Crist

Brain Crist


BEING HONEST an essential UX interview tip

In this article, I share what I think is one of the best tips when it comes to design interviews.

As a junior UX designer, I’ve been asked a few times by my peers: what is the most essential UX interview tip I have?

Well, to this question I have a very simple answer,** just be honest**… well, this might sound like a no brainer, but it seems to me that not many junior designers know about it or want to apply it.

I had the chance to speak with a few designers and I discovered that some tend towards being a little bit insincere when going through interviews for design positions. It’s normal to be intimidated when going through an interview process and you might want to act as if you have more experience than you have to secure the job.

Well, I’m here to suggest that that’s not the right approach. I fact, recruiters know in advance that as a junior designer you won’t have many years worth of experience so instead of being insincere it’s better to show up with an open mindset and being honest.

A mindset of learning and improving is always welcomed and valued in today’s world. Simple answers like “I might not know X because I’ve haven’t had the chance to get at it but I can learn it as I’m an avid Lerner” go a long way with recruiters.

Put yourself on your recruiter’s shoes, would you rather employ someone “that answers to 90% of the requirements’’ but doesn’t show a growth mindset, or would you employ someone “that answers to 70% of the requirements’’ but shows it’s the thirst for learning and improving?

That’s not to say that you’ll show up with no qualifications at all. You still have to have a certain level of expertise. “Don’t be the guy with 30hrs of experience using Sketch and 1hr of prototyping experience calling himself a UX designer”.

Some skills can be rapidly learned with just a little bit of discipline and will so don’t be afraid to answer with a no if you haven’t had experience with certain techniques due to lack of opportunity of doing so, for example. It’s always easier to learn something new than being perceived as untrustworthy because you said you were qualified to do something but you finally weren’t.

keep in mind that being sincere is always the way… not just during job interviews but in life. Anytime you’re being insincere to achieve something, most probably, the lie will end catching you back and having the opposite effect you wanted it to have.

Anyway, I’ll stop with my “life lessons” and I’ll wish you a very successful interview.

Hopefully, this little advice does help you.

#design-interview #job-interview #system-design-interview #job-interview-tips #ux-interview

Alayna  Rippin

Alayna Rippin


5 Simple Job Interview Tips

Disclaimer: this reflects my personal opinions, not those of my employer.

Over the last few years, I have interviewed hundreds of candidates for positions in Software Engineering, Software Engineering Management, Product and Product Marketing Management, Technology Evangelism, and others. It has always bothered me how many people accidentally sabotage themselves, making entirely avoidable mistakes in the early stages of interviews and phone screens, preventing interviewers from getting to know those candidates better, forcing the premature end of the process for them.

I call these mistakes avoidable because not making them is entirely under the interviewee’s control, having nothing to do with aptitude, competence, interviewer having a bad day, or not being fit for a certain position. If you can avoid them (and you can!), then you are already standing out from the crowd, for being able to make your “elevator pitch” in a way that assures interviewers that you’ll be able to handle yourself in a loop with their peers and managers.

Without further ado, this is how you can do better in your job interview:

A short introduction is a short introduction!

Not an invitation for you to read through your resume. So when asked by the interviewer to give “a quick introduction so we can get started”, do just that. Time it to 90 seconds or less. This is about who you are, not (yet) about what you have done. Let’s mock it:

Interviewer: “My name is X, I have been at this company for 5 years, doing X, Y, Z, and prior to this I spent most of my career doing mobile development, now I’m managing this team and am the hiring manager for this position.”

You: “My name is Y, I started in 19xx, when I was born, then went to school, where I learned how to read (…) then I had the opportunity to learn Docker, which I think is the future with Kubernetes, AI, and the Blockchain.”

WRONG. This is what you have done, not who you are.

You: “My name is Y, I’m an Engineer/Marketer/Product person, I’ve graduated from X, been in this market for 5 years, most recently at company Y, and I love being at the intersection of product and engineering, and that’s why I applied for the position”.

Speaking of time

Don’t talk too much, or for too long. If you have been talking for 5-6 minutes without pause, your interviewer is probably already distracted and unable to piece your story together to a coherent whole. Keep answers short and to the point, make pauses, ask if the interviewer has questions, continuously check back to see if the person is still with you. If not, it’s probably time to stop talking.

A couple of extra tips here: if the company interviewing you requires that people take notes about your answers, you can pay attention to when the interviewer has stopped typing. It probably means you are adding nothing to your answer, so change gears. A second cue is that, for video interviews (or live, like in the good ole days), if the person you’re talking to has gone static, not reacting to anything you said, that’s a good sign that you should stop talking.

What’s your motivation?

“Why did you apply for this position?” is considered by many the easiest question in an interview. Well, I have news for you: it isn’t.

There are many ways to answer this question in a way that will immediately raise suspicion in a good interviewer that you don’t know what position you’re applying for, which may be a terminal mistake in a selection process.

Here are some bad answers:

  • “Because company X is a great company!” - Yes, it is, but it also might have thousands of job openings, so you’re essentially saying you’d happy to have any of those jobs.
  • “Technology is a great sector to be in right now” - A variation on the previous point, it tells nothing about your interest in this position.
  • “Because it’s not very hands-on, from the job description” - Even if the position is not hands-on (and those are becoming rare in all sectors), describing your motivation on a negative/lacking/glad-I-don’t-have-to-do-that way sends a bad sign that you are not interested in how things are built, only in the results.

Some good ones:

  • “Because the job description says that I would be doing high-impact work with healthcare partners, including leading ones, and that’s something I’m passionate about”
  • “I am very passionate about mobile development in Swift and also UX, and looking at your company’s products, I see that you have great care for your user experience, and I’ve been looking for a position where I can excel in both”

#interview #interview-tips #interviewing #job-search #tech-jobs #communication #recruiting #hr

Tyrique  Littel

Tyrique Littel


Static Code Analysis: What It Is? How to Use It?

Static code analysis refers to the technique of approximating the runtime behavior of a program. In other words, it is the process of predicting the output of a program without actually executing it.

Lately, however, the term “Static Code Analysis” is more commonly used to refer to one of the applications of this technique rather than the technique itself — program comprehension — understanding the program and detecting issues in it (anything from syntax errors to type mismatches, performance hogs likely bugs, security loopholes, etc.). This is the usage we’d be referring to throughout this post.

“The refinement of techniques for the prompt discovery of error serves as well as any other as a hallmark of what we mean by science.”

  • J. Robert Oppenheimer


We cover a lot of ground in this post. The aim is to build an understanding of static code analysis and to equip you with the basic theory, and the right tools so that you can write analyzers on your own.

We start our journey with laying down the essential parts of the pipeline which a compiler follows to understand what a piece of code does. We learn where to tap points in this pipeline to plug in our analyzers and extract meaningful information. In the latter half, we get our feet wet, and write four such static analyzers, completely from scratch, in Python.

Note that although the ideas here are discussed in light of Python, static code analyzers across all programming languages are carved out along similar lines. We chose Python because of the availability of an easy to use ast module, and wide adoption of the language itself.

How does it all work?

Before a computer can finally “understand” and execute a piece of code, it goes through a series of complicated transformations:

static analysis workflow

As you can see in the diagram (go ahead, zoom it!), the static analyzers feed on the output of these stages. To be able to better understand the static analysis techniques, let’s look at each of these steps in some more detail:


The first thing that a compiler does when trying to understand a piece of code is to break it down into smaller chunks, also known as tokens. Tokens are akin to what words are in a language.

A token might consist of either a single character, like (, or literals (like integers, strings, e.g., 7Bob, etc.), or reserved keywords of that language (e.g, def in Python). Characters which do not contribute towards the semantics of a program, like trailing whitespace, comments, etc. are often discarded by the scanner.

Python provides the tokenize module in its standard library to let you play around with tokens:



import io


import tokenize



code = b"color = input('Enter your favourite color: ')"



for token in tokenize.tokenize(io.BytesIO(code).readline):





TokenInfo(type=62 (ENCODING),  string='utf-8')


TokenInfo(type=1  (NAME),      string='color')


TokenInfo(type=54 (OP),        string='=')


TokenInfo(type=1  (NAME),      string='input')


TokenInfo(type=54 (OP),        string='(')


TokenInfo(type=3  (STRING),    string="'Enter your favourite color: '")


TokenInfo(type=54 (OP),        string=')')


TokenInfo(type=4  (NEWLINE),   string='')


TokenInfo(type=0  (ENDMARKER), string='')

(Note that for the sake of readability, I’ve omitted a few columns from the result above — metadata like starting index, ending index, a copy of the line on which a token occurs, etc.)

#code quality #code review #static analysis #static code analysis #code analysis #static analysis tools #code review tips #static code analyzer #static code analysis tool #static analyzer