Principles of Chaos Management 2/2

Part 2 - The Technical Lead As Interviewer Bible (Fun part: Sadly, this article is full of true stories)

1) A TL (Technical Lead) should never read candidate's CV. A TL can get retinal damage if he attempts reading such documents, not to mention brain damage while memorizing them.

2) A TL should always let Sales department to make all the decisions regarding the design of the application. The main page of the application should be as crowded as possible, with at least 20 pages of scroll. The main menu should always be on the bottom of the page, and the Contact information should only be found after navigating through at least 2 screens from the main page.

3) When 2 or more TL(s) talks to the candidate, the first TL should ask the candidate about his task X1 which he implemented, and while the candidate answers, the second TL should wake from his sleep and ask the candidate why is he providing details regarding the task X1 when his colleague actually asked about task X2? Using recursion (for all the remaining N-2 TL(s)) can further ask candidate questions after the 2nd TL.

4) A TL should never check the learning capacity of the candidate, he should only ask theoretical questions which aren't of any use in day to day job, and for which the answer can be found easily on the internet in just a few seconds. The candidate should always memorize all the theory that TL considers relevant. As different knowledge is not welcomed, all employees should limit their knowledge to the TL's knowledge. Any plus value/knowledge to the company is not relevant or welcomed and will be strictly and harshly rejected and punished.

5) A TL should always be ignorant to the correct answers for the interview questions which he asks, the TL's sole mission is to notify the candidate when the (right) response provided by the candidate is perceived by TL's head as being wrong.

6) A TL should always organize the project in such manner that all the members in the team spends at least 50% of working hours on bug fixing. He can achieve this with 2 simple steps: See 8) and 15)

7) A TL should always interrupt and not allow the candidate to put any questions, the interview is not a dialogue, the candidate actually stands trial, and the candidate should be wise enough to know not to ask any questions. If the candidate has the audacity?to ask "Is it OK if I ask something", it is mandatory for the TL to yell shortly "NO!!!" and then to proceed further with his interrogatory.

8) A TL should make sure that in the Project, the programmers never implements Unit Tests. If somehow there is a Manager that demands the UT(s), then those UT(s) should be written in such a manner that any change done to the source code will not result in a UT failure. If somehow an UT fails because the TL changed the source code, then the failing line should be erased or whole UT erased by the UT creator (which isn't TL) as it is not relevant anymore even though the class and the method is still present in the source code.

9) A Java TL should always ask about Dependency Injection at an interview but never use DI in the project source code. He should always create new entities in the Service public methods (which used by events or controllers) so that the code is neat and tightly coupled. All service methods are really scared of the Doctor and they really don't like Injections or parameters.

10) A TL should always be happy and never contradicted even when he is wrong. A TL is never wrong, Chuck Norris may be wrong, but a TL is always better than Chuck Norris no matter of the attribute (physical, mental or spiritual). A TL can actually defeat Chuck Norris even when the TL is "divide"-ed and "impera"-ed. If you still consider that your TL is wrong and you value your position / rank / etc, you should start removing some of the unnecessary extra brain that overflows in a disturbing way. Nobody likes a smart person.

11) A TL should always formulate an ambiguous technical problem without the full hypothesis. The candidate should already knew what is in the TL head as he should learn from the Mother Caterpillar how to be a mentalist and how read minds. This is actually reality, because programmer doesn't have access to the source code / production logs or anything, and the whole programming job is not an exact and logical science, it is a guessing science.

12) After the candidate passes all the technical interviews, the TL should check his CV for relevant information and if he considers (by watching the position of the stars during the bright daylight) that he doesn't have any, he should fail him as he is not right for the job.

13) A TL should always ask the same question multiple times. Having a piece of paper with the questions written and check boxes may prove in some situations to be even harder than finding a solution for the time travel problem.

14) A TL which is working on a start-up should always avoid all possible clients that he deems unworthy small / medium companies (via some random irrelevant motive). A small start-up company should only focus on the big fishes, because the big fishes for sure will not require any previous client list that the start-up company had or have as a client. The reasoning behind the avoidance is that the small customers asks for too many questions, and provides too much feedback, and it is impossible to provide a proper user guide / help system to the application, or to care about their constructive feedback.

15) A TL should always make sure that errors in the project are handled in a superficial way. The job of the Support/Business Analyst should be easy not complicated they should all just become "Pleasecheckers" and just forward all errors to the developer with the title "Please check this error". All errors including the ones related to misuse / lack of configuration of the application should always be detected only through the debugging processes. No LOGS policy should be enforced in production.

16) The TL should always check if the candidate knows all the methods for all the java Classes used in a Spring / Hibernate / Spring Boot application. As company, some can only afford license for windows notepad software to be used as java IDE, so it is only logical to check the candidates in such a manner (as autocomplete feature is not available, nor any features which are provided by default from a professional IDE.)

17) The TL should always check if the candidate knows how some common functionalities are implemented and should ask candidate to provide the actual code. Even though that code is never modified or overrided and it is only used.

18) When a candidate mentions that he didn't have experience in a particular topic, just keep asking different questions on the same topic and pretend that you didn't heard what the candidate said. But for the future you, the TL, should not be submitted to such efforts and you should learn how to ignore everything the candidate says.

19) An TL should make sure that inconsistency is consistent within the project. If someone defines beans in the project using annotations then it's fair to have someone else free to define some other beans in the spring XML files. If Hibernate entities are defined using HBM files, the we should make sure should make sure to define a couple of entities using annotations as well. Balance must be maintained.

20) A TL should never use Kafka which is unit tested and integrated in Spring. He should always add a new random version of Kafka dependency in the project configuration file and attempt to do this integration with spring project by himself.

21) It is the responsibility of the TL to make sure that any practical interview is not going to happen. We live in the age of pen and paper, that's how the interviews should be held just by pen and paper, not every company can afford an extra computer or an internet connection.

22) A TL should always put the candidate on hold or be late at the interview, and only after the candidate as waited for at least 30 minutes, to notify the candidate that the position for which the candidate have applied is already taken, and that they only called the candidate for the fun it.

23) A smart TL should always assign research tasks to the candidates without their knowledge, and use their knowledge for free. In this manner lots of money could saved for the company.

24) A TL should never provide the result of the interview to the candidate directly or indirectly, however it is mandatory that he gives a promise to the candidate that the candidate will receive one soon.

25) A TL should always ask inappropriate questions that are in direct violation with the candidate's signed confidentiality policy. If the candidate avoids to answer, then he should be failed at once.

26) A TL should always let his most junior member of his team conduct the interviews just for fun to see how it goes.