#testing ability read based on nonsense words is incomplete

[storieswritteninthesand]

My dash is blindly hailing phonics and I am not okay.

[nullset2]

Five Points To Know About The Tech Interview Process

Going through the interview process for a tech company is interesting because you get to do a lot of intellectual calisthenics that you would never do otherwise in the job day to day. It's quite a complex process.

So, some times I get asked, what do you have to do to pass a tech interview? Is there an specific technology or programming language that you should take up? Does having such and such on your CV help?

And I say, nay, none of that matters. Forget your mobile apps and your infra as code and your blockchains and your rails ~and your bullshit~, and come hither, and see the Truth:

As a professional in tech, you MUST be able to problem-solve well. This is paramount.

You WILL be constantly judged based on your COGNITION.

You MUST be great at continously leveraging your sources and what others in your team know to expand your COGNITIVE abilities.

You MUST be able to be a good communicator and a team player, to KNOW how to operate with others even with obscure or incomplete information, and to KNOW how to conduct yourself decently with them and to reach a viable solution timely.

You have to demonstrate that you're able to take charge and agency to develop the product that the team that's currently interviewing you is building. You are supposed to lead.

In tech interviews this implies that you have to be GREAT with communication skills, algorithms and data structures, but we'll dive into that in a second.

In tech interviews you will speak normally with four or five people and be presented with an intentionally vague description of a programming problem, expecting you to produce code to solve it. That's why you have to be good with your CS fundamentals here, some problems solve better in one way or another, and knowing how to trade-off between memory and cpu time, which is a pretty common point of discussion with data structures and algorithms, to reach agreement with your peer, is a good way to show that you're good at this, that you're what they're looking for, and that you're serious about this. You show that you talk the talk and walk the walk.

Some people argue that this process is useless, and that knowing that much in-depth about computer science primitives, such as data structures and algorithms, is nonsense in this age of frameworks, and readily available, cheap and easy to use managed services and cloud computing, but I absolutely disagree.

I think it is very much valuable to know how to operate well at that level because those "boring" CS fundamentals are very much indeed what makes those comfy layers of abstraction possible. They will come into play once you take up those jobs. You must be literate about them.

So: problem solving in tech is what they're looking for. For that, they will subject you to programming problems. So to solve them you need to have your Computer Science fundamentals in check. Being able to confidently solve a vague data structures problem is a pretty good, if not perfect, indicator of proficiency for the job, but it's the best we've got. That's why the tech interviewing process is the way it is.

So I can sum it up with the following phrase: be aware, take charge, know your stuff and be professional. This is the main tenet of tech interviewing. Being able to clarify enough and juggle data around until you and a peer satisfyingly solve a textbook problem is the best indicator we can have to assess how effective you'll be at the job, if only because of the cultural baggage that having that kind of knowledge is sure to bring into the fray. You love programming, right? If you love programming at least enough to get into that theoretical level, you probably are pretty decent at doing what you do.

This is not to say that the tech interview process is not burdensome. It's quite terrible sometimes. It can feel overwhelming and boring, and it prone to place you in a lot of very awkward situations. I've been in tons of horror stories in tech hiring, as an interviewer and an interviewee. Not to mention, if you're an interviewee and you have a bad experience during an interview, does that entice you to actually want to work at that place? Obviously not. A disgruntled interviewee or employee will walk away and tell their friends, and their friends of friends will also tell, and so on.

To reduce the noise around the process and increase signal as much as we can, we have to be good at this, even if it's painful to get there. But hey! Everything worthwhile in life has a cost to it, right? If it doesn't hurt, how is it supposed to lead to good things? :)

So, here's five little tidbits that I wish that I would had known before jumping in on the recruiting process. To clear the fog out, you know? To make things easier for the company and for myself, too. You're getting distilled, raw goodness here. All meat, no fat!

1) Feel good being expressive and vocal and discuss!

When you go inside that whiteboard room, you're expected to be clear about your intentions and your skills, and to show in great detail why are you fantastic for this job. This means that you have to be expressive.

You will talk and work with a lot of different people in this job, and everybody thinks in a different way. Some times it's pretty hard to convey your ideas efficiently, but I've found that if you learn to use the right words at the right time, which comes with practice, of course, you can develop sort of like a baseline level of skill that you can use to achieve this. So, please be aware that you need good communication skills and work on them (but you're great, which is why you're reading this, so it's a bit besides the point for me to mention this, right?)

As you introduce yourself, speak! Again, talk the talk, walk the walk. Show what you've done and show it with enthusiasm! While you solve a problem, talk! Talk before getting started, while you're trying to find a solution, and think out loud a lot! Think out loud! The interviewer wants to know whether you're a reliable, thinking individual. If you just clamp down and start coding after getting a problem described to you, you will not pass that interview; not to mention, you will probably not even solve the right kind of problem because you haven't even clarified the problem to begin with. Interview problems are supposed to be vague on purpose to assess your ability to dive deeper and actually comprehend what your goal is supposed to be on the job. So, again, and as an absolute number one, talk. This is imperative, which leads me to number two...

2) Ask clarifying questions.

Ask a LOT of questions. Even if you think that you've been presented with all the information there is to know about a problem, believe me, you haven't. You and your interviewer have to connect and be on the same page. Before you start coding, ask clarifying questions.

Consider the following cases:

Let's say that on an interview you're asked to devise a function to calculate the product of two vectors. You already assume these are vectors, as in the linear algebra sense. What do you mean by product, cartesian or scalar? What are the constraints? What's the maximum component that a vector can have? Is it okay to represent the scalar with a simple double or should you use a BigDecimal? These are pretty great things to ask that will give your answer a lot of substance while you develop your program. If you omit them, you will end up doing a lot of mistakes and the interviewer will walk out of that room disappointed with your performance.

But, but, B-U-T, here's the kicker: you assumed. You assumed that they wanted you to solve a linear algebra problem.

Never assume, because it makes an ass of u and me.

What you should had done is that you should had asked: How do you define a vector? What if this is not even a Vector in the LA sense, but rather, in the sense that it's a list of pieces of data? Why if they wanted to get something like a set of tuples formed by pairing every element of the first with all of the elements of the second? Well, if it was so, yet you assumed that it was Linear Algebra, then you just failed the interview horrendously.

Congratulations, you just played yourself.

Another example: What if you're asked to develop a function that calculates a resulting linked list formed with the sum of two numbers, where each number is represented by a linked list? What kind of sum? Is this decimal arithmetic or another base? What happens if you overflow the base? How are the numbers represented? You should already have asked all of this before jumping into something. The more you show that you care about the details the better, because what we do is to specify details in code to enable business.

Details are the very lifeblood of what the software engineer does. If you don't abide by that and do things bluntly in your interview, you will not, and I assure you completely, you will not pass the interview process. You need to be absolutely clear that you're doing what you really should be doing.

3) Be GREAT at testing

When you have already come up with a solution to your program, all nice and dandy, you should be already well on your way to test what you wrote. Test, test, and test again and again! Lots of problems have edge cases. For example, it's simple to think of an algorithm to calculate the product of two integers, but it's not quite simple to make it work for all numbers (harkening back to the previous point, you should had already asked all the clarifying questions you need at this point). What if your program works for all integers, but it goes horrendously wrong for 9999999999999999999999999999 or 0.0000000000001? What would you do to avoid falling into those traps? The interviewer wants to know whether you already thought of that.

Again, you're expected to run over your examples with the interviewer, loudly (be expressive!). Let the interviewer know of your thought process and that you're aware of shortcomings or things that you know are problems. If possible, fix within the alloted interview time! This will get you major points in your favor.

4) Know thy Data Structures! Know thy Complexities! Know thy Algorithms!

I recommend browsing http://bigocheatsheet.com/ to keep complexity information fresh in your head. Your interviewer expects you to bring up asymptotic complexity on your own. If you don't mention what's the complexity of your algoritms you will be assumed to just not be good enough to do work at the level of scale that the big tech companies operate. Devising an O(n^2) algorithm can mean absolute chaos in some cases where you have to operate on tens of millions of operations instead of just hundreds of thousands or so. Always code an efficient algorithm, if possible. Mention the tradeoffs if you're deciding that you should go with a given solution instead of another one. Protip: divide-and-conquer algorithms and hashmaps are your friends here. Always implement something on a divide-and-conquer way if possible so you can get that sweet O(ln(n)) complexity.

What I want you to understand is that what matters is that you develop an algorithm that scales well as the size of the input grows. This is literally what big-o complexity measures, so please take time to be good at big-o complexity and how to define it. It should be big-omega complexity, as a matter of fact, because in algorithm study there's big-theta, which measures the lower boundary of complexity in a best-case scenario basis, big-omega, which measures the highest boundary of complexity in a worst-case scenario basis, and big-o, which is sort of an average case. What we consider to be big-O in interviews is not big-O for real, but by convention, it means worst case scenario to us.

5) Be a Professional! Be Nice!

Lots of companies survey for soft-skills in interviews because they want to know that you're a culture fit and that you won't disrupt internal culture too badly, but again, if you're already reading this, you're probably already a great culture fit :). However I feel that this point still needs explanation because a lot of people fail this.

Don't grovel about previous jobs. Don't brag. Don't belittle others. Don't be racist. Don't be sexist. Don't be edgy and politically incorrect. Don't lie, you WILL be called out on your bullshit. Don't think badly of your interviewer or see them as antagonistic. All of these can and believe me, they will come up as red flags on your interview feedback, and once a red flag is there, you're done.

At the same time, when you talk about what you did in your previous jobs or in school, really say what you mean. Talk about what you did, not about what the proverbial we did. This is a pretty complex point because we're normally expected to keep things humble so we don't put ego in front of ourselves when we talk about previous projects or examples, but if you use a lot of proverbial we statements instead of I statements, you will come accross as somebody who doesn't really do anything in the projects you're involved with, which is a big red flag for interviewers.

Finally, when you talk about your experiences at work: for example, if you get a question about what did you do when you ran into a personal problem with a work mate and you had to solve it, or what did you do to handle it, you have to stick to the STAR pattern. STAR means the following:

Situation

Task

Action

Response

So instead of just mentioning your anecdotes in blunt terms, you should use the STAR pattern to frame them down. This means that you should explain them in terms of:

1) What was the situation? What was the conflict? Why did it happen? 2) What concrete goal were you trying to achieve when the conflict or situation happened? 3) What specific action(s) did you take to alleviate it? How did you jump into the fray? 4) What was the reaction from the company or from others after that? Did it improve the situation? How did you make a difference?

Final Words

Your interviewer is there to assess your fitness as a potential work buddy that they will see for eight hours every day for the forseeable future, and hopefully, come to know as a valuable friend and as a great, fantastic person.

Be that person. It's simple!

Make them walk out of that room glad to have met you and being glad to know someone who's as knowledgeable as you are. If you're blunt, if you don't pull off things, and if you're rude or boastful for the wrong reasons, it WILL trigger a red flag.

Show your best self. Show your projects and show everything that makes you worthwhile. Try to make things easy for them to show them you got their back with the interview problems and in more things in general. And more over, just be chill with yourself, man! You don't have to be "on edge". This is just like, a simple interview, man! :)

Finally, I think that interviewing is definitely a skill of its own because it's a sophisticated area of professionalism. Nobody is born already knowing how to be a great information professional. Nobody is born with communication skills completely developed, and to be frank information people are usually somewhat awkward and don't have a very easy time communicating. But you can get better at this with practice! Practice, practice, practice, and never stop interviewing no matter what. You have to keep this skill fresh in your mind.