My Adventures in the Interviews Jungle

 

As you know I recently switched jobs and while finding a new one I’ve done quite a lot of interviews in different companies.

I really enjoyed the process! Some days I had 3 interviews in a row! My friends called me insane but hey, I can easily talk about software all day long!

While looking for my next job I took the way a company’s interview process as a major factor for my final decision.

In my opinion the interview process should reflect the values, the culture and the professional level of the company. A company that values my time, tries to make me feel like home and asks question that actually reflect my knowledge is most likely a better company than a one that does the opposite.

In this post I want to share some of the questions and tasks that I had in my interviews. Some of them were great. They actually allowed me to show what I know and the overall process made me feel wanted and special. On the other hand there were some that were a complete waste of time.

Let’s start.

Ridiculous, exhausting and a waste of time

Bizarre questions

“How many hair cut places are there in Tel Aviv? How many golf balls can fit into a bus?” These questions were famous due to Google’s interview process where candidates had to answer super hard and bizarre questions.

Few years ago even Google stopped asking these questions!

“They are a complete waste of time” - Laszlo Bock, Google's senior vice president of people operations. 2014.

I couldn’t agree more – these questions don’t test anything and furthermore don’t have anything to do with the candidate’s future work.

When my interviewer asked me these questions I asked if their company found it useful. He replied ‘yes, Google does it and so do we’.

That was a red sign for me – if you copy from someone at least stop when they do.

 

Endless trivia questions

By “trivia” I mean questions that don’t make the candidate think. Usually they start with what and not with why. Those questions check whether the candidate knows the answer or not. “What is HTTP? What is a transaction?” They don’t focus on the candidate understanding of why something is used or how is it used. Only if he knows the definition.

Honestly - when was the last time that you used a Mutex? Or had trouble with the GC? Either way it’s googlable. So it’s ok not to know all the answers.

I think that some trivia questions can be useful for three reasons:

1. To check if the candidate is serious about the job and that he took his time to prepare for the interview. Serious candidates usually prepare themselves and come ready for interviews.

2. To check that the candidate is not a complete noob/code monkey. It’s a bad sign if he cannot answer any question.

3. To check if the candidate knows how to say that he doesn’t know something. If he tries to lie and make up an answer in the interview then he will probably do it again in a real situation.

In one interview I had an hour and a half of trivia questions! Needless to say that it was one of the most exhausting interviews I’ve ever done.

In the end I asked the interviewer if they actually need all this knowledge to their day to day work. He told me no. They don’t even use multi threading but he questioned me for 40 minutes about mutexes, threadpool and thread synchronization.

 

Writing code for hours

In one company I had a coding test as the second interview phase. I think that it’s essential to check the way the candidate writes code but and this is a big but it shouldn’t take 6 hours@#$!

A small coding task should check if the candidate writes tests (perhaps TDD), uses SOLID principles and that his code is clear and well written. A simple calculator task can check all these. Writing a 6 hours long project is a waste of both the candidate’s time and the interviewer’s.

The worst part is that it’s in the company office (and not a home task) so the candidate will be stuck for 6 hours in a row writing code for some test in some company. Writing some code in the company office is good but only if it doesn’t takes the whole day.

 

Text exams

As I mentioned before, there shouldn’t be more than a few trivia questions in an interview. The only thing that is worse the asking 30+ trivia questions is having them in a written exam while the interviewer is not even present.

Those tests give the candidate the feeling that his time is not valuable enough for an interviewer to be present while he answers.

As a candidate I want to have the feeling that I’m wanted and that my time is valued. Leaving a candidate in a room alone with a text exam does exactly the opposite.

It can be even worse if the text exam is Scott Hanselman’s 25 things that every .NET developer ought to know and the interviewer tells that it is his private collection of questions.

 

The Good Parts

Now let’s go through the interviews that I really enjoyed, the technics and questions which allowed me to truly show my skills and made me feel wanted.

Home project, code review and pair programming

In one company I also got a coding project however it was a home project meaning that I could go home, work on it whenever I wanted and send them back the solution when I’m done.

This is so much better than working on it at the company during the interview. It allows me to put in as much effort as I want while doing it in a familiar and comfortable environment.

After I sent them the code I was invited to a code review. I think that this is the best possible interview since it checks everything! Both my coding skills, my ability to explain my choices and to see how I accept critics.

After the code review I was asked to change something in the code – it took just 10 minutes but the interviewer sat with me the whole time and was part of my design choices. It was more like a pair programming than a test. It allowed me to show how I think before I code, my TDD skills and it also allowed me to see how it feels to actually work with someone from that company. This was the best interview process!

 

Team Leader/Group leader who is in charge of the interviews process

As a candidate you usually talk to the HR in order to schedule your interviews, to get more info about the company and simply talk between the interviews. The HR are usually really nice girls (never met a HR guy) but it’s way more welcoming and respectful when your point of contact is a team or a group leader of that company.

It makes you feel important and that you are taken seriously since a manager is investing time from his busy schedule to walk you through the interview process in his company. A company that shows this kind of respect to a candidate must show even bigger respect to it’s employees and that is a company that I want to be part of.

 

CEO that talks to the candidates

I really valued the companies that their CEO invested ~30 minutes to get to know me and tried to make me feel like home even before I decided to sign with his or her company. When the CEOs shared their visions for their companies and told me their missions and values I felt an immediate connection. These talks were the last step of the interview process and companies who’s CEO actually called me or invited me to come and talk to him made me appreciate that company more than others and that is a major decision factor.

One CEO even called me from San Francisco just “to get to know me”. He is the CEO of ~100 people. If he could find the time then most of the high level managers in not huge corporate can.

 

Architectural and design questions

I was surprised to see that most of the companies didn’t ask me architectural questions. Only 2 companies wanted to know if I understood the architecture of the projects that I’ve worked on.

“Why do you have a load balancer? Why don’t you use micro services? Did you have a DRP? How does it work? What is the most fragile place of your architecture? What should you change? How? Why?”

If the trivia questions have usually the “What” prefix then the deep design questions will have the “Why” and “How” prefixes. This way the candidate must understand the pros and the cons of the architecture and more importantly to understand why the architecture is the way it is.

I think that these sort of questions show whether the candidate was just a code monkey or if he truly cared and understood his project.

 

White board role playing

Almost every company asks the candidates to approach the white board to solve a problem or design an algorithm. Remember that the solutions doesn’t matter! It’s how you thinks what’s important. This is why it’s important to think loudly and share your thoughts with the interviewers.

This is a great test however I think that it can be even better.

In one company after I solved the problem at the white board the interviewer stood up and told “now it’s my turn”. He asked another question (something about modeling and design) and then approached to the white board and started to sketch a solution.

Then he asked me if that works and if his solution was good. It wasn’t and I had to spot the problem and then explain him why his solution wasn’t good enough. It was great!

We switched roles and I felt like the interviewer. It was a simulation of a technical argument and he wanted to see if I can spot the design problem and most important part to see if I can hold on to my position and be able to convince him that he was wrong in a good and calm way. This is also one of the best interviews I had.

 

“How do you keep learning?”

There are plenty of developers out there. Only a small part of them are truly great developers. Many things distinguish them from the mediocre ones. One of them is what I call “Continuous Learning”.

The truly great developers always keep learning. They code, they read they write about it, they go to meetups and they are always up to date. Every company want these developers since they will always bring you progress.

If someone asks you to share this then they probably also care about learning and that place will probably have great developers who work there.

 

“Tell me about something that you are proud of?”

Enthusiasm and ownership are extremely important qualities. Every company wants their developers to be enthusiastic about their work, to have ownership for their features and to feel accountable for the application that they are building.

In order to be proud of something you must be involved in all aspects of the product development. You must feel that you own that something to the bones. If someone is truly proud of a feature or a product then he will talk enthusiastically while describing it.

I really liked when in one interview I was asked to tell about a feature that I was proud of. I could explain why did I think that this feature is important, it’s complexities and how did I actually developed it. It allowed me to show my understanding of that feature and my enthusiasm of software development. This is impossible to reproduce with only trivia questions.

 

That’s it.

This was a summary of most of my interviews. It was really interesting to see other companies and developers and to be tested for my skills. My personal advice is that when you go to an interview don’t be in the state of mind of a candidate that needs “to pass” the company’s tests. Go there and be the interviewer. Sure answer their questions, but don’t forget to ask yours. Remember that you are special and not every company deserves you. So be smart when choosing one. I think that the interview process can really help in deciding whether the company is worth going to. I hope that this post helped you know what to look for.

Good luck and feel free to share your experience!

 

* I want to thank Netanel Lev for review this post.

Increasing Conversion Rate in Web Forms with these 3 HTML5 features

 

Users hate typing. Most of them will abandon your app when they’ll see a long and frustrating form causing you to miss a potential new user or something important like a purchase.

Users have almost Zero patience. They want to complete what they have started as fast as possible or else they’ll ditch it. This is why you must strive to make the forms as short as possible and allow them to fill them as fast as possible.

 

Autofocus

The current page has a form that the user should fill. Remember that the user patience is short and that’s why you want immediately to focus him on the form.

If you’ll add the “autofocus” attribute to the first element of your form then the element will get focus after the page is ready. In mobile it will immediately show the keyboard.

<input type="text" autofocus>

It is so simple and it puts the user right where you want him.

 

Autocomplete

Users hate to repeat themselves. How many times did you type your full name/address/age/telephone in the last week or month? It’s frustrating! The user has to refill these details over and over again!

There must be a better way.

You’ve definitely seen this before – this is the Chrome’s AutoComplete feature which allows to automatically fill inputs that were filled in the past.

I love it!

You must ask yourself how come that not all the forms allow you to autocomplete this data, after all they all probably use

<input type="email" />and perhaps even give it a useful name attribute <input type="text" name="firstName/">

They just need to add a tiny HTML5 attribute that goes by the name “autocomplete”. The autocomplete attribute can be set with one of these values:

· country

· fname

· lname

· email

Click here for the complete list.

Each element with an autocomplete attribute tells the browser that this element can be autocompleted with a value previously used for this kind of element.

So all you need to do to enable this option and make your users happy is to add autocomplete=”on” and set the right values in the autocomplete attributes. Like so:

<form autocomplete="on"> <label for="firstName"> First Name <input id="firstName" type="text" name="fname" /> </label> <br /> <label for="lastName"> Last Name <input id="lastName" type="text" name="lname" /> </label> <br /> <label for="email"> Email <input id="email" type="text" name="email" /> </label> <br /> <label for="country"> Country <input id="country" type="text" name="country" /> </label> </form>

Wait a second, the label field surrounds the whole input element! Why?

It’s a nice trick that allows your users to click the textbox or the label to get focus to the textbox. Less clicks for the user means better chances that he completes the whole form

 

Geolocation

The last HTML5 feature that can really help your user is geolocation. It allows you (if the user enables it) to get the user’s current location. This means that if your form has some location inputs like shipping address or Zip code then you could autofill them using the user’s location.

Think about all the times you had to look for your Zip code…

Now you can ask the user:

And if he allows it then all this data will be auto filled! The users will love it!

 

With these 3 simple feature you will increase your conversion rate!

 

Feel free to comment if you have another tips.

My 2016 Goals and 2015 Reading List

2015 was a great year! I’ve worked on some of the coolest projects that I know. I’ve learned the internals on Angular 1.X and typescript. I’ve also started a new job (which is awesome) and made a pivot towards mobile development.

I’m certain that 2016 will be even greater!

Now when 2015 is over I’d like to start a personal tradition for myself in the blog. In the end of every year I’ll set personal goals for the year to come. The goals will cover the blog topics and the desired reading list for the next year. In the end of the next year I’ll go over the goals and verify that I’ve accomplished all of them. I will also list all the books I’ve read in that year so that maybe you will find something that suits you.
 
Let’s Start

This year I wrote 20 posts in my blog which are almost 3 times more than last year!

2016 Goal: Write at least 20 post.

I want to focus on mobile, agile and management topics. I will write on any other topic that I think is worth writing about but these topics will be the core.

Here are some ideas about the upcoming posts:

Mobile oriented posts:
1. TDD in IOS
2. IOS and Android best practices

Agile:
1. The psychology of Scrum
2. Retro done right
3. Agile estimations
 

2015 Reading List

Call me old fashioned but I love reading hardcopy books. My dream is to have a huge library filled will all the best books in the world. I always try to diversify and read different types of books.

I think that I did really well this year and picked awesome books. By the way - this is a great website where you can buy books with free shipping worldwide.

2016 Goal: Read books about management, leadership, innovation and at least one tech book. At least 10 books in total.
 

Here are the books I’ve read in 2015.

1. Steve Jobs – on the greatest minds that ever lived. He had an amazing and not ordinary life (the movies don’t get even close to the real deal). You must read this book if you consider yourself a manager or an entrepreneur.


2. The Last Lecture – an amazing book written by a man that was going to die. This is not one of those books about dying. It is about living. Living the life that you will not regret. The book is about the author’s last lecture which you can also watch here.


3. The Lean Startup
This is a must book for every manager and entrepreneur. It is well written, pragmatic and has lots of great real life examples.


4. 4 Hours Work Week
Life hacker Tim Ferriss in a great book about efficiency and building the life you dream about. It shows that your dreams can be accomplished. Just start and stay focused.


5. How Google Works
The managers of Google share the experience that they gained while working in Google.


6. The Leader Who Had No Title
Robin Sharma is one of the best leadership and life improving authors that I’ve encountered. I enjoyed reading all of his books. In my opinion this one is not as good as the “leadership wisdom” but it has lots of great topics in it (just read both).


7. Start-Up Nation
Great book that tries to determine how a tiny country like Israel has the largest amount of successful startups in the world.


8. The Passionate Programmer
Actually that is not a good book. The title doesn’t fit the content. It’s mostly about how not to lose your job. Don’t read it.


9. מחשבות לעט לילה
Haim Shapira writes about three philosophers: Nitsche, Schopenhauer and Kierkegaard. How did they live, what did they believe in and why? Very interesting.


10. High Output Management
Andy Grove’s book that is considered to be the Holy Grail of management books. It was written in 1983 and it is still accurate for this day. He covers all the aspects of being a manager. Great book, it’s a must read.

 

Allow me to repeat the 2016 goals:
1. Write at least 20 blog posts.
2. Read at least 10 books.
 



I like these goals :)

Now it’s time to start working on them.
Have a great year!

Everybody has a plan until they get punched in the face

“A failure” can be a result of a software or hardware problem. A fault tolerance design intends to enable the system to continue operating properly in the event of failure. In this post, I’ll talk about a way to treat a special cause of failure – a timeout using a really cool open source framework named Polly.
We prepare for failures, we put “try catch” blocks and check “if(something == null)” every now and then. We think we’ve got it covered and that we are fully protected.
As Mike Tyson said – that’s our plan. However, we all know that something “unpredictable” will always go wrong, and then we’ll be punched in the face.

Let’s say that you have a DB and you query it to get some data – user’s navigation history for example.

One of your users clicked to get his navigation history and waited for almost a minute (yes – that’s a long time) to get an error that crashes the application!

(BTW This not a great error page – read here about the importance of error pages that make your user smile.)
You guessed right – that was a timeout to the DB. Why did it happen? Who cares? It made your user wait and eventually it crashed the application. This is unacceptable!

How can we handle it?

There are two problems in this scenario: the first is that the application crashed and the second is that the user waited a minute for a response.
Let’s start from the crash. The navigation history is a cool and useful feature but it’s not the core of your system. The core feature is the navigation itself. You have to identify the core features of your application and make them work, even if some other features fail.
In this example, the application should have displayed an error message saying something like “History is currently unavailable – try to remember where you went” and allow the user to use its core features any way.
Now let’s deal with the fact that the user had to wait for a whole minute before he saw the error. That’s a horrible user experience. A timeout might happen due to many reasons in any sort of client server communication (no more available connections, waiting for a really long operation to finish or simply a stuck component).
The bottom line is that someday it will definitely happen to you! Furthermore it will cause all your users to wait until they receive the error. A timeout may accrue just once due to a race condition that only a single user will get. However, sometimes the timeout will remain until you manually fix the problem - which can take a while.
You can lower the timeout limit to a second or even 100ms - and indeed no user will wait longer than 100ms - but all the users will wait for 100ms and eventually fail, while choking your servers.
Your goal is to prevent users from waiting at all when you know they will definitely receive a timeout. In other words, if a system component has a timeout,  you don’t want the application to try to communicate with it. You want it to fail fast.

Fail Fast

Fail fast is a concept in fault tolerance systems that is designed to stop flows and normal operations when a possible failure might accrue. Such design will add check points before operations execution, which will check if the operation is “healthy”. Using “health indicators”, the system will know if a certain operation will most likely fail. If an operation isn’t healthy, then there’s no need to execute it and we’d rather call a fallback behavior.

This way, we may give the users a better experience then waiting for an error.
Let’s examine our case: the application shouldn’t try to execute the query unless the connection to the DB is “healthy”. So the system will check the “health indicator” before the execution, and if it returns false then it should immediately turn to the fallback and display the error page without even trying to connect to the DB.
You can take it even further – if such health indicators exist, then why can’t we check them on the application startup? If there’s a problem with the feature, then let’s disable it and even not show it to the user. Perhaps it’s better to make the feature “disappear” then exposing the user to a poor experience. That of course is a pure business decision (it might be a really poor experience if the messages tab in Facebook suddenly “disappears”).
Allowing your system automatically to disable features must be done extremely carefully. You don’t want to disable a feature for all of your users if for some reason a timeout has accrued just once. If it happened 10 times in a row, then most likely there is a real problem and only then should the feature be disabled.
 

Polly

Polly is a really cool and useful open source that helps you create a fault tolerant system using policies for handling exceptions and creating fallback solutions. Let’s see how we can use Polly to handle our timeout scenario and allow your application to fail fast.

NavigationHistoryController has a dependency to the database where the navigation history is stored.
It has a single public method, which provides the history by calling the INavigationHistoryProvider.
We have a try-catch surrounding the provider call. As we know this catch will eventually handle the timeout exception, but it won’t fail fast.

We have created a circuit breaker policy on the timeout exception (error code -2) setting the count to 10 and the policy duration for 10 minutes. In other words, our policy will be triggered if a SqlException will accrue 10 times and in the next 10 minutes every call to the provider will not be executed. BrokenCircuitException will be triggered instead, allowing us to quickly fallback and return an error without waiting for the timeout.

 

Let’s test it

We’ll mock the NavigationHistoryProvider and raise an exception for every single call to it “Get” method.
We’ll call it 10 times and then another time to check if the policy was activated.

Works like a charm. The code is available on GitHub.
 

Conclusion

The applications that we build will have failures. We must recognize that things won’t always fail nicely. We must be prepared for all the possible scenarios and edge cases. The sooner we start thinking about them in our development process – the better.
I encourage you to think about it from the beginning. Start using FDD – Fail-Driven Development.

Best of luck.

Applying TDD in Your Company is More Important than Ever!

I won’t cover the basics of TDD. I do want to talk about the advantages of writing automated tests (unit tests and integration tests) in general, and why applying TDD ,with a little twist, should be a standard in your company.

First, why should you write automated tests?

“In order to test and verify my code?” Daaahh! This is so obvious that it’s not worth mentioning! I think that unit tests and all kind of automated tests have many more benefits than just testing your code.

Better code design – If you have ever written unit tests, you’ll know there is no (pretty) way of testing or mocking static objects and tightly coupled classes which violate the SOLID principles. A testable class is a well-designed class that is loosely coupled from its dependencies, uses dependency injection and rarely has calls to static methods. A testable class is a SOLID class which will improve maintainability, readability and extensibility.

True documentation of the code – You’ve probably written a design paper at least once for a feature or any sort of documentation describing the code. Be honest – is this documentation still relevant? Does it really describe the code that is now in production? Probably not. The automated tests, on the other hand are the true documentation - since if the code breaks the tests, the code will be repaired or the tests will be modified to support the new behavior that has been added. Either way, the tests tell the real story of the class, allowing any other programmer other then you to quickly understand what the class does and how it behaves in different situations.

Killing the fear of change – One of the programmer’s greatest fears is the fear of changing code. You never know which class depends on this specific implementation in a specific scenario. Usually, QA will let you know about it. But not your company QA – your customers (the real QA), who will get hurt and be angry due to your changes. However, if the code is fully covered with automated tests then there’s no fear! You can add, modify and even, so help me god, delete code - and in a matter of a few minutes you’ll know exactly what logic you broke, and why (the tests assertion should be really clear).

A standard for your company

Your company is a business. It has competitors who are breathing down your neck, trying to get hold of your customers. Time and quality are crucial! You must deliver new features fast and with the highest quality so that your customers will be satisfied.

The only way to succeed is by writing automated tests that cover your entire code base and all the user flows. By doing this, you allow every single developer in your company (seniors and juniors) to quickly understand how the code works by reading the related tests, easily changing the code - since it has a great SOLID design – and having immediate feedback if any modification has ruined the existing logic, providing the exact places where it happened. This saves time and money, and should be the standard for every new feature in your product. It should be a fundamental principle for writing code in your company.

Why TDD? Just write the tests afterwards

Why should you use TDD if you can first write all the necessary code, implement the feature and only then write the tests?

Writing tests after implementation is way better than not writing tests at all. However, it might not get you the same effect as I’ve described above. When you are finally done with the implementation, the thing you want the most is to declare the feature as “done” and ship it to production. You probably won’t invest enough time in fully covering the feature with good, meaningful tests. If you encounter something that is fundamental in your implementation that is not testable, you will probably just leave it like that and not change it - leaving it untested.

The last thing is that you are biased toward your implementation: in your opinion, the way you’ve implemented the feature is the right way. Thus you will write tests that support your implementation and not necessarily cover all the edge cases and business goals that the feature was supposed to do.

TDD – the cherry on top

In order to truly enjoy the benefits described above you have to apply TDD -with a little twist:

First, start with an integration test for your feature – a test that will fully test the behavior of your feature. Some might call it “Behavior test” as in BDD. I think that is just semantics.

If you are fixing a bug, your tests should create the environment where this bug is recreated and test that the bug is prevented before you’ve actually fixed it! You want to be sure that you are able to reproduce your bug. Only then can you start actually fixing it by writing the tests first. Same goes with a new feature - first an integration test that checks the behavior of your feature, and only then begin to implement.

This way, you begin with the business goals and stay focused on them while you implement the whole feature.

Another great benefit in starting with the integration test is that you will have to create the setup for the feature. Doing so will make you truly understand how the feature works and on what it depends on. This is crucial before you start to implement, so you won’t make unnecessary mistakes.

It’s not easy: it requires strong testing infrastructure and patience – it’s hard to hold back the lines of code you are just dying to type. But it is so worth it.

If you want to easily write code at your company and not be woken up in the middle of the night to solve a bug in production, just write the tests. Better yet – start with them.

Local Images in React-Native IOS

Looks familiar?

There are several ways to use local images in a react-native app:

1. Using xcassets folder - source={require('image!bg')}. The images must be in the xcassets folder and according to the docs you should have the image in all the 3 sizes.
2. Relative path - source={require('./bg.png')}. Note that you have to add the file sufix.
3. The way it actually works - source={{ uri: "google", isStatic: true }} instead of require('image!google'). This way you can use both images that are in your xcassets folder and those that are not without killing yourself while trying to find the right relative path.

If you got here then you've probably started to use React-Native - don't give up yet- it's awesome!

Great Use of Space - Not!

Great use of space...
#WhatIsUX