Let the Docs Do the Talking

Years Ago when I was a student, I really hated anything related to the Documentation process, at that time I have a bad idea about it. In the collage days most time teams who working on the same project be like 4 people, and they are friends who having meeting and talks all the time, the projects itself was not very complex compared to real-world projects. So, documentation at that time was just paper that nobody will read. Even if someone want to know something, they will just ask the friend in front of them instead of open a poor written document and search for an answer. Maybe we were too lazy at that time to write well written document, most of the documents the students ware delivering were something like template document who you need to just fill it after coding.

Anyway, While I should admit there are things needs to be improved in the collage documentation process, but what I really dislike is the people take that attitude into the professional work.

There are many things I consider as documentation like Design document, meeting Agenda and Action items, COE, Deployment Notes, … etc. Actually, anything needed to be well-written for historical or communication purpose can be considered as document. That means even emails can be considered as document.

Why Documentation is way more important in the real-world problems?

Time Efficient

Talking about communication, it's way easier to use technical document instead of book meeting with everyone and talk to them, maybe you can do it when you have a team with ~5 members. But when the size of the team increase it will consume a lot of time, some will be on vacation, some don't really have clear context and some be busy at that time with other stuffs. So instead of forcing people to communicate with everyone you can easily send a well written document to them, it will include all context they may need. People with context will skip it when reading, while others can take their time to understand the context.

Compared to the normal chat, Document in most cases are more organized and has clearer language, also Document will avoid having many calls/pings related to any issue.

Feedback handling and Timeline Visibility  

One that I like the most is it's so easy to give feedback on a single point, highlight it for discussion, then publish the action item regarding this point, that done very smoothly during document rather than having calls. When someone added comments, you can easily see if it's fixed or not on the next version of the document.

Reference applicable

Anyone can reference to it or search it in the future, this help a lot in the timeline estimation, Requirement clarification and tracking, onboard new people, …etc.

I don't remember how many times I need to check a document to remember what exactly was the requirements. But believe me you will need it a lot when you handle many threads at the same time or even when you will check a new task.

When I should write a document?

Document is something people will need in future -even for archive purpose-, I haven't any case when people shouldn't write document, the correct question for me is: how long time people should spend writing document ?

There is one rule I follow, and I believe it's making much sense, the more important a document is the more time you should spend on it. For example, an architecture/business document that will affect many people for months or even years can take days or even weeks. An investigation document for minor incident with no really lost should take few hours, a recap for a call with external party should take few minutes and so on.

What should a good document looks like?

Here is my thought about a good document, Some apply on all document and another apply only on long document:

• A good Title isn't enough: it's nice to have a good descriptive title, but no matter how the title is good, it Must have an introduction section defining what is the purpose of this document. One of the most annoying things for any reader is going through all the document to discover what is the goal of this document.
• Assume People with no context: Never assume readers will have any unmentioned context, something like the current case and the motivation for this document isn't something readers will know. Remember people with context can skip this section, but people with no context can't imagine it, for example a writer can mention a number assuming the reader will have context about if this number is good or bad.
  
• Define Who will read this document: defining who is the audience for this document is very important, different rules will need different way of abstraction.
• Separate between What is critical, and what is less significant: normally any document has core critical sections and another that less essential or optional, can the reader easily catch the critical sections? Separation can be done using text formatting, orders and even separate the extra content in separate files.
  
• Support the Claims/POV with facts: remember this is a technical document, something like saying X is better than Y requires an approval or justification, the document should include facts or state facts supporting the writer's POV, anything else should be avoided.
• No-meeting mindset: one of the most common root cause for bad document is the writer always rely on the discussion meeting or someone will contact him/her if he/she does not get it. There are things not mentioned in the document but regularly have been discussed in the meeting, for me if not mentioned in the document then it should not bring to the table in the meeting. When you write a document, you should have a mindset that no one should contact you regarding this document, else your document is missing important info that should be included.
• A Second eye is always better: there are difference between the document that is reviewed by someone and the document that does not. If the document is long enough, it's a good idea to ask someone else to review it for you before publishing it to the team/company.
  
• Use domain/business standards: it's always better to use wide-usage knowledge that anyone in the field or business know instead of re-create the cycle again, something like Vocabulary, template, charts, …etc.
  
• Learn from people mistakes: when you have a document that everyone mentioned it's a great document, it's highly recommended following the document style. On the other hand, when people mentioned some documents is bad, hard to understand, or misleading try to understand why people think that about it and try to avoid these mistakes.
  
   

Fresh Interviews

Lately, I had the chance to shadow and have interviews with fresh graduates, which was a great experience for me, I notice common mistakes that the interviewers keep telling the interviewee about it, and here I am trying to give the fresh graduates some generic common advice, most of them are basics, but people keep failing in them.

Why interview?

The interview isn't a simple process as there is a question, if you answer it correctly "You pass" or else "You failed", while part of that is true, but it's not as simple as that, good interviews have many things that affect the total outcome. If the company just wants to solve that problem it can just be sent, with no need for all this extra cost, so having interviews means that the company doesn't really focus on the solution, which means that you can solve the problem and got rejected or struggle with it and got hired.

A proper Interview process is hard to accomplish, having long and different interviews is tricky but when doing them right it will be guaranteed that the remaining candidate will have higher quality. The interviews cut from the employee's working hours to prepare, perform, and examine it, this process by its nature cost the company money and time to find someone that may join.

Comparing the Candidates is a tricky process as the company may have candidates with technical levels so close to each other and only one free position. What should they do in this situation? Working with a binary system (hire/no hire) means the company will pick FIFO, also that system will make it hard to have more than one interview, and when it comes to that company should handle some cases, like someone caught cheating in an interview or done very bad behavior with an interviewer, cases need to be handled smoothly in the hiring system, hire/no hire means many things.

Some Companies follow the level or the area system, in the level system each interviewee writes his outcome as (Strongly no hire, no hire, weak hire, hire, strongly hire), and each of these words is related to the hiring policy, similar to that some companies can divide the feedback into some areas (green(+1), yellow(-1), and red(-100)), and only candidate with a score greater than x will be considered.

Candidate earns and loses points without noticing, he/she thinks something is no big deal like ignoring instructions while it costs many points even if he/she manages to solve the problem, things like answering clearly about why we can't solve the problem using x give points.

Common Mistakes in Interviews

Most of these mistakes are easy to avoid after some interviews, I encourage you to get as many interviews as possible and never be down when you fail in an interview.

1. Silent solver: you need to talk about what you think, the possible solutions, and the complexity of each of them, thinking in silence will make the interviewer give you wrong hints, and he will assume you can't solve the problem using x algorithm because you didn't mention it, and possibly you saw the problem before and want to fake thinking.
2. Only optimal solution: giving a problem, the interviewer expects you to mention the brute force or some bad solutions first then try to improve them, not saying these solutions may mean you can't even solve this problem with a bad solution. 
3. Ignore hints: when an interviewer gives you a hint it is for helping you, following hints should end you with a solution or give you some point, but ignoring them is a very bad indicator.
4. Fitting solution: many fresh interviewees focus on getting an "accepted answer" based on codeforces.com or another website so they will ask something like what is the value of n, when the interviewer says "find the optimal solution" means that the best big o, if you give him an o(n*n) solution it can be a bad solution because optimal solution runs in o(log(n)).
5. Assume things and never ask about them: some interviewers will not say everything, to see if you can find out the optimal solution for some cases or handle the corner case, for example, someone will say "number" but didn't tell you it's integer or not, some may not mention the data value range is not large (only values from 1 to 100) asking about these things give you points and may end you with a good solution.
6. Asking the wrong questions: what is the time complexity of the optimal solution? What is the interview outcome? Where are the places you get the question from? ...etc. when interviewer ask you about your question he/she expect you to ask about the company, or the working environment.
7. Not listening to the interviewer: things the interviewer states very clearly like "Let's move from this point" or "That is enough here" are things related to the interview process, so ignoring them and deciding to keep going is an indicator that you don't listen to the other.
8. Zero info about the company: people can have little info about the company in the primary scanning but reaching an advanced stage without knowing the basics about the company indicates that they don't care whether it's a good or bad company, has a strong technical team or not ...etc., people who join a company with zero info about it more likely to leave it asap.
9. Questioning the interview process: normally the interview process isn't perfect, but it's something other people put many efforts into it, so asking questions like : why did you ask me this question? Does it really matter? ...etc. is an awful thing to do.
10. No interview preparation: always try to be in your top form before the interview, you need to read about related topics before the actual interview, relax, and push tasks after the interview.
11. Weak CV: having a CV without your projects, GIT account, LinkedIn account ...etc. make it hard for people to know more about you from your CV and consume some time at the interview to ask about unmentioned info, check careercup.com/resume for more info.

The summary

At the end of the day the interview is just meeting with someone older than you, just be a polite person and try to show your good side, 99% of the time the interviewer will not try to make you fail or give you wrong hints, some may try to trick you to test the technical fundamentals, but the majority will keep it straight forward and try to help you.

Being rejected in an interview isn't necessarily a bad thing, ask for feedback to improve yourself and focus on the next interview, there are many reasons why you don't pass the interview so don't assume things that are out of your control.

Also, never assume that if you are good you should pass all interviews, maybe the position needs different scope or the interview process at that company isn't good enough.

Books like "Cracking the Coding Interview" really helped me do better in the interviews, also here are videos (in Arabic) that may help you (some may be Generic for all levels not only fresh) : 

• How to join Fangs.
• What to do in an interview. 
• Fang's interview tips.
• Cracking algorithmic interviews.

Finally, good luck with your next interview.

The Success Secret

 

This small article is about a hot topic that has many discussions in the social media "The way to success".

For the last few months, I skip several books that talk about different topics (most of them have many recommendations and are labeled as "best-selling in XXXX"), there are multi reasons that make me decide to skip them like poor writing skills, filling the book with random things not related to the book topic ... etc., one of them is the authors used annoying patterns for me, he just throws some talk to you like it's known facts, these facts aren't based on experiment or proven knowledge, only based on the author's POV and many of times this POV is based on things like "Survivorship bias (or survivor bias)" and "The holy success"

Survivorship bias

This term means looking only at the survivors instead of looking at the whole group, this bias is one of the most famous reasons that result in false results on the surveys, and beliefs and result in wrong decisions in the future.

Many speakers marketing their self by the mention "X attended my courses" or "There are Y people who attended then became successful persons", They never mention the thousands who attends then had trouble failing.

I remember a few years ago one of the lecturers (I love to hear) said that if you pick a random group (with the same ideology and business) most of the time it will have about the same distribution of success and failure as a group attends to the "success course".

That doesn't mean success is totally just a random thing or that self-improvement is a myth, what I want to say is doing x to improve y is a relationship that needs a lot of experiments and surveys to prove it, not a random guy told you it is proven to be true because he believes that or he tried it.

It worked for me

Sometimes experiments to measure the relation between two variables consume millions of dollars and much time, the most critical thing in most of these experiments is not the measurement process, it's how to find out all other variables that could affect this relationship and make sure they will not change during the experiment, even after doing this step they need to repeat the experiment multi-time to make sure the result will be the same.

It's a foolish idea that a single experiment is enough after said the new facts the author will face many cases that said this isn't true fact, and the answer is known to the author "That's because they didn't do it in the right way" that "right way" will be nothing like clear steps or set of rules it will be just bunch of words in the author's mind and probably each time asked about it will say the cloudy answer that no one will understand the exact meaning with the sentence "if you understand what I said you will succeed".

This point isn't against sharing the self-improvement experiment but tying the action with results is something that isn't reliable, imagine someone trained for 4 years and before the Olympiad, he had an accident and result he couldn't contest does that mean all that he did was wrong? imagine a person who did nothing in his entire life except sleep, eat, and play however he managed to gain millions from his rich father, does that mean doing the same will make you gain millions?

The survey approval

While there are many times you hear someone talk about a survey that no matter how much you search you will never find, there are other types of a survey when the details of that survey (like the selected groups, units, other variables ...etc.) you can't find, it's an easy thing to go to a school for rich families and go out with a survey that said the average pocket money for school student is 100$ per day, or go to a village where most women don't work and said that men have 30K$ more salary than women.

The one who does the survey is human which means he/she can be biased, lair, or stupid, normally that applies also to organizations, even when someone wants to get the truth, some things could affect the result without noticing, and the same people can answer the same questions different answer based on the order of questions, writing format, environment, time ... etc.

The holy success packages

When talking about success many people have a really strong bias toward the survivors, which results in many cases following each step of them without thinking about if it's logical or not, if someone does x,y,z and became the most successful person in the people's POV, most of them will just think let's do x,y,z regards if x,y,z is good or bad.

For them, it's an illegal thing to think x was a minor factor of success while y does not, and z was the most critical factor in the process.

I am not saying that I know the success way All I want to say is if success was an easy thing that anyone can achieve through reading a book that has a bad writing style then it will be different than success in my mind.

the image reference : [https://kenzie.snhu.edu/blog/what-is-success/]