protips

Logo

This site lists the protips that we shared with students during our courses

View the Project on GitHub appliedtechnology/protips

Approaching a test assignment

Part of life here at Salt is to do tests. It’s a way for you and us to know how much of the things we have learned, from the fast paced weeks.

It is also part of life as a developer, since taking code tests are (sadly) part of many interview processes. (Personally I think taking a code test is an idiotic way of gauging the qualities of a developer, but that is besides the point, since I don’t get to decide :)).

So, how do we approach taking a test? What is a good way to handle nerves? How can I improve my chances of acing a test?

If I knew the answer to all of that I would not do this but rather be an instru … ctor… wait a minute. I do know that!

Let me share some tips and experiences - of varying degrees of concreteness.

Tip 1-10

  1. Take a test
  2. Take a test
  3. Take a test
  4. Take as many tests you can get you hands on
  5. Do a coding test together in a group
  6. Ask people for help and see how they would have approached it
  7. Share with others your struggles and nervosity
  8. Redo a test you have already taken
  9. Write a test for a friend, and try to beat each other
  10. Take a test

If I were in the PGP (time after the bootcamp) this would be the only thing I would do.

Why, you ask? Because it takes the edge of the situation. Sure I learn a lot too, but I do get more comfortable with the being judge like that.

Many coding tests, especially that uses tools like TestDome or CoderByte has a certain flair that makes it easier to follow and understand if you have read many tests before.

You know how you get a high IQ-test score? Take many IQ-test… andlearnfromyourfailurestobecomesmarter

Approaching testing

Let’s talk philosophical matters for a bit; how do you approach code tests?

They came to you

Remember that you are in this interview process because the company needs your help. They didn’t open the window and called out for the first person closest by - they want you.

I guarantee you that the thing that would make them happiest is if you succeed.

They. Want. You. To. Succeed.

It’s not you against the company. It’s them hoping that you will succeed, because they need you. NOW!

Did you feel that? Your shoulders dropping? Good.

Now you can try to make this as good as you can… because both you and the company you are interviewing for want you to succeed. You’re on the same side!

So what does that mean? It means that you can now sit back and show them your best, easiest to understand, well-working work. So that they easier can see what you know.

What are they looking for?

The reason companies are using code tests is that it is a ~awesome~ ~great~ ~good~ way to get you to write some code that they can gauge your skills from.

I have a son that is 14 and he has been struggling with math in school. I realized that when he saw a task like:

4x+16=48

He thought that he would be great if he squinted his eyes for a while, thought hard and then said 8!. Becuase he thought his teacher was looking for the answer.

Newsflash - the teacher is not. In fact, I’m gonna vaguer that the teach could even accept the wrong result, if the the problem solving is correct.

If Albert went Well, first I subtract 16 from 48 and get 36 and then divide it by 4 on each side to get x=9, the teacher would probably be ok with that. Or ok-ish. orsheisstupidandshouldnotbeateacherinthefirstplace

It’s the same for weekend tests and coding interview tests. The thing that they ask you to build (a calculator, a Todo-list, a stock ticker) is not that interesting for them. They have already plenty of those. They want to see your code, your reasoning and your problem solving skills.

So what does that mean?

If you get stuck in understanding the task, make an assumption, write down what you thought the task was, and solve that to the best of your ability Most likely, that code you write, even if it solves the wrong problem, will be quite enough to understand what you know and can.

If you get stuck on a technical issue that slows you down (like a linter for TypeScript being in your way, for the JavaScript code they asked you to write… or something) - then take that linting out. Most likely the task was not to setup the environment but to write some code. You can write that code without the linter, to the best of your ability. AND you showed that you could find a way to get unstuck and continue with (what you thought was) the task at hand.

Remember what you have done

You all amaze me. You dug deep and found the will power to turn your careers from one thing into another.

You have gone through the worlds toughest bootcamp.

You can do this too. Because you want to. Let’s do it!

Summary

Practice tests - it’s the best way to get good at the testing situation.

Remember that they came to you. They want you to succeed.

Make assumptions if you get stuck. They are not interested in the app, they want to see what you can.

Caveats

It’s always dangerous to give advice like this, because they can be misinterpreted.

For example;