Episode 39: Tech Tests:

I’ve completed 9 out of 12 weeks, and whilst I’m heading into the 10th, it’s pretty daunting for two reasons. The first is that I am considered a senior(i.e a person who looks like they know their stuff).

Having my mentee (shoutout to Benjamin Pourian, sweet guy) popping by “Hellos” down the stairwells trains me to act better at the role. The second is that this week is tech test week & interviews.

One could say that this week should be a fun one as it’s the first week out of all the nine weeks so far that we get to code alone. One could also say its daunting because it challenges your tech skills and chance for interviews.

What are Tech Tests:

Tech tests are where you as the words say “get a technical tests” of creating a program based on what the client wants. They will give you a certain amount of requirements to cover (i.e what the program needs to do, what the program should do and what the program should give the user). It would generally be a small project as they don’t want you to spent months on it.

And then you guessed it, you go and do it.

My first thought of tech tests were like any interview where you sit down with the interviewee whilst he/she watchers you code. However, my prediction was mostly proven wrong.

Although the worst scenario stated above could happen, it was a blessing to find out that 80% of tech tests allow you to code at home! (Note: Quoted this from a lecture but its a high chance) If you are more blessed, you can suggest or be given fair deadline to complete the project.

Now, that does not sound bad at all.

My theory of getting good at them from doing tech-tests week is practice and exposure. Whether it is exposing yourself to horribly written code or doing different tech-tests in your chosen specific language, either way will make you better at them.

Otherwise, it’s an important thing to know if you want to pass the last-half challenge of getting a job, which I’m sure is a goal everyone at a coding Bootcamp or you, who is reading this, has.

Questions I learnt the answers to during tech test week:

~“Dania, do you have to score a 100% in a tech test?”

I think this is a goal anyone would have when writing a tech-test. Since we all were kids, we were all told that the A* in school was the target to shoot for anyway. For asians, it was drained into our heads that it was a must-mission. However, firstly, it depends on what you mean by a 100% and what I mean by 100%.

Finishing a tech tests 100% could be to finish what was required from you by the client’s project. This is recommended as a wrong 100% perspective because it’s not about just hacking code, where you simply try finish everything.

It’s careful craftsmanship of how you lay out your code, think of your approach, write functional, simple, “stupid” code and craft it based on how it make sense to you. As I’ve learnt from Makers, your approach is just as important as what you produce.

In conclusion, it’s more important for your approach to score a 100% where you explain how you’ve thought out the problem, how you broke down the problem and how the design of code make sense to you than finishing what the client gave you.

~“Dania, is it all right to ask questions if I don’t know what they mean by their requirements”

Yes, absolutely.

I learnt this lesson very well where I thought of an approach for one of the tech test. It came immediately to mind but I changed my approach when I was unsure of it. Then came the Surgery(where we ask questions or reflect on the code), and I realised my lost approach was right.

Asking questions not only gives you clarity on how to solve a problem but also shows clients that you are considering the possibilities of the problem. It shows them, without showing your tech-test that you are already specifying your approach and that you are forming the problem.

Now, obviously don’t ask them a question if Google can help you solve it.

~“Dania, is it all right to extend from what the client wants?”

This is probably a contextual debate but I won’t go there. It’s just quite a common behaviour many people have, including myself and thus many people are challenged with when completing a Tech Test. Why? Well, because we always think we can do more or in other words, we know what could be the best for the client’s project.

However, the rule is simple. The objective of the tech test is to deliver what the client asks for. I’ll say it again.

The objective of the tech test is to deliver what the client asks for.

I probably think this applies to any job, where you deliver what the client asks for but in the tech world, this is the “uno” goal.

This is because tech tests are meant to discipline you, to achieve the goals of what the client has required of you for the project. Now, that doesn’t mean we have to keep our cravings of wanting to expand on the code inside, we still can do it. We should just deliver what the client wants first, and then expand on it with a good explanation of why we did later. So, in conclusion,

The objective of the tech test is to deliver what the client asks for, first. Sounds simple, but believe me, it’s hard to forget when you are trying to impress a client.

The tech tests checklist:

As I am doing several tech tests to get practice, a great tool or activity provide is self-reflection by prompting you with a checklist. This checklist poses you thoughts that you probably haven’t considered till you read it, which is a good thing because better now than when your in the deep end.

I believe having a checklist (whether it’s your own or a checklist written by some wiser developers) is a huge benefit because you can tick the boxes before you send it of to the client. After all, a tech test can be done in your given timeline (depending on the demand of the job) and that you can be sure that the code you are sending out is the best you’ve got.

Although Makers has given a very detailed checklist of what one should consider for the tech test, I’ll do my best to summarise the core things I would have on my checklist once I’ve written my code.

Note: These things I’m about to say are just learning how to do tech tests in two days. There could be more to learn or more to discover what I’m wrong about. Please do comemnt your opinion if I am mistaken or you have more to add.

Testing

Yes, it’s one of those things we can depise doing but making sure that you have tests, segregate the tests (feature test where it’s testing a feature and unit test of testing a piece of code) and writing clearly what your tests do.

Having tests is better than no tests when you send your code off to a client. Tests shows that you’ve proven that the design of your chosen code works effecetively.

Hence, it’s the no.1 important thing to have in your tech test before you send it off. Even if you aren’t sure of what tests you are writing or what you should test, it is considered a coding sin not to have any.

A handful of Diagrams or Notes:

ReadMe

This is a probably big on to cover as there would be a multiple of things I would considered in my Readme before sending it.

Could be eyecatching or exciting.

Think of your Readme like a birthday card on top of a nicely wrapped present. Like a card, we underestimate what people mean or the contents of the card. However, the Readme is as powerful as a nicely written birthday card that gives us that warm fuzzy feeling of appreciation and love when we read a birthday card and know it’s from someone special or we care about.

Although a birthday card isn’t as contextual as a ReadMe, the ReadMe is (I’m guessing) the first thing people will likely read given it states the instructions of how to use the program, explains how you approached it, how you reflected on it and how you broke the problem down.

Earlier, I said that approach is just as important as the outcome. This is where we write that approach to formulate our perspective on the design of the code. Plus, and again like I said ealier, coding is a craftmanship.

What to include in a README:

Summarising the objective:

Writing a few lines on what you thought the goal was does no harm to let the user or client understand what you thought the problem was.

How to Use

Big, big, big, huge, giant segment to never forget in a Readme. This shows that you are considering anyone who is reading your Readme to instruct them what to do to make your program work.

Plus, it tells the client that “yes I understood the problem, understand my program and can tell you how it works.”

Approach

How did you tackle the problem? Did you break down the requirements into User Stories? Did you diagram how the classes would connect to each other? Did you write down what methods were going into what class? Did you spend time on making sure that there were no holes in the problem? What made you choose this design you decided on compared to another?

All of these questions would be considered in the approach, and it will let the client know the way you think. Think of it as the client getting a taster of how you work in you practice.

User Stories, Notes & Diagrams

Example of my notes on how the code works for one of the tech tests.

It’s good to break down the problem into user stories if you can as it’s a practice developers and the government.uk apparently use. This allows you to list what is required of the program and how you prioritised what was the MVC over the stuff you could add that would be “nice”

Diagrams are really useful alongside with images. Whether it is of your project or whether it is of your approach, the more tasters you can list on the tasting menu you are serving up to the client, the better.

Code Reflection

I always like doing this part because it lets myself know what I could have done better. At Makers, you learn that there will be times, or many times where you will never finish all you can code. And that’s okay. It’s not always so important to finish! However, it’s good to do the best you can and explain to clients on what you could do better in the timeframe you are given.

What could you have done better in the timeframe? What other perspectives for the design could you consider, and why you did not choose them? How did you decide to segregate your code with what names, and why.

It shows clients that you are wiling to grow, and want to constantly improve yourself as a developer.

File Organisation & Naming with your code:

Making sure that your classes & methods are named clearly is quite vital. Imagine you have a library full of shelves with books. Your code is a library, your folders are your shelves, your books the the files of code, your classes are the sections of a book, your methods are chapters of the book and then you have your code which is the text, of the chapter, of the section of the book.

That sounds like a mouthful but this is if we’re getting into the nitty gritty of what we are looking for when we are in the library.

Now, imagine if that library was in chaos. The shelves were not ordered, the books were not in alphabetical or numerically ordered, the classes were not written right, the chapters make no sense of correlation to the book and the text you are looking for to quote on is impossible to find.

Luckily enough, if we take that analogy into coding, our text editor allows us to see everything and edit everything with ease. As we appreciate this ease in comparison to clearing up a library, we should consider the following.

• There should be somewhat of an order in your code and test
• There should be clear names of classes and methods
• There should be test files and files that match each other
• If you can, know what files go where, put them there.

This obviously can go in more depth with research and knowing what goes where, but that’s overall a concept I tend to follow.

Obviously, the last one is the following:

Have you written the best code that you can for what the client wants in the time that was given?

My conclusion:

Although we struggle under the pressures of wanting a company to like us and hire us, tech tests are challenging quite fun. They act like any other project that will test our knowledge, make us curious to design it and determine us to finish as much as we can of the challenge.

Now, if you had to sit with a client breathing down your neck. It may be an uncomfortable situation to be in but like any project, it’s a project that will help you grow as a developer.

We’re never going to get the first tech test, or the first few tech tests the way we would like to have achieve them. However, at the end of the day, it’s all about gaining experience of our passions as developers. In fact, if tech tests are like projects, that train our ways of thinking and coding to our best of ability, then we’ve been doing them along.

Fun Fact Of The Day:

For those who are at Makers, whether it be with your peers or the “Surgeries” (where you sit in a circle and discuss all questions needing answers to) that a coach will offer, go to them when you are doing tech tests week! It’s so helpful to have your questions answered about your strategy and approach to the craftsmanship of the code. In addition, you get to hear perspectives of other ways your code could be designed in. Double bonus.

Shoutout to the coach Kay, who’s brilliant at hosting them. You are a gem for enabling us to think about what we are asking and deliver the answers we are looking for at the same time x.