Top 10 Mistakes on Interview

Practicing on a Computer 

If you were training for an ocean swim race, would you practice only by swimming in a pool? Probably not. You'd want to get a feel for the waves and other "terrain" differences. I bet you'd want to practice in the ocean, too.
Using a compiler to practice interview questions is like doing all your training in the pool. Put away the compiler and get out the old pen and paper. Use a compiler only to verify your solution after you've written and hand-tested your code.

Not Rehearsing Behavioral Questions

Many candidates spend all their time prepping for technical questions and overlook the behavioral questions. Guess what? Your interviewer is judging those too!
And, not only that- your performance on behavioral questions might bias your interview's perception of your technical performance. Behavioral prep is relatively easy and well-worth your time. Look over your projects and positions and rehearse your key stories.

Not Doing a Mock Interview

Imagine you're preparing for a big speech. Your whole school, company, or whatever will be there. Your future depends on this. You'd be crazy to only practice the speech silently in your head.
Not doing a mock interview to prepare for your real one is just like this. If you're an engineer, you must know other engineers. Grab a buddy and ask him/her to do a mock interview with you. You can even return the favor!

Try to Memorize Solutions

Memorizing the solution to a specific problem will help you solve that one if it comes up in an interview, but it won't help you to solve new problems. It's very unlikely that all, or even most, of your interview questions will come from this book.
It's much more effective to try to struggle through the problem in this book yourself, without flipping to the solutions. This will help you develop strategies to approach new problems. Even if you review fewer problems in the end, this kind of preparation will go much further. Quality beats quantity.

Not Solving Problems Out Loud

Psst- Let me tell you a secret: I don't know what's going on in your head. So if you aren't talking, I don't know what you're thinking. If you don't talk for a long time, I'll assume that you aren't making any progress. Speak up ofter, and try to talk your way through a solution, This shows your interviewer that you're tackling the problem and aren't stuck.
And it lets them guide when you get off-track, helping you get to the answer faster. Best of all, it demonstrates your awesome communication skills. What's not to love?

Rushing

Coding is not a race, and neither is interviewing. Take your time when working on a coding problem. Rushing leads to mistakes and suggests that you are careless. Go slowly and methodically, testing often and thinking through the problem throughly. In the end, you'll finish the problem in less time and with fewer mistakes.

Sloppy Coding

Did you now that you can write bug-free code but still perform horribly on a coding question? It's true! Duplicated code, messy data structures (i.e., lack of object-oriented design), and so on. Bad, bad, bad! When you write code, imagine you're writing for real-world maintainability. Break code into sub-routines, and design data structures to link appropriate data.

Not Testing

You probably wouldn't write code in the real world without testing it, so why do that in an interview? When you finish writing code in an interview, "run" (or walk through) the code to test it. Or, on more complicated problems, test the code while writing it.

Fixing Mistakes Carelessly

Bugs will happen; they're just a matter of life, or of coding. If you're testing your code carefully, then you will probably discover bugs. That's okay.
The important thing is that when you find a bug, you think through why it occurred before fixing it. Some candidates, when they find that their function return false for particular parameters, will just flip the return value and check if that fixes the issue. Of course, it rarely does; in fact, it tends to create even more bugs and demonstrates that you're careless.
Bugs are acceptable, but changing your code randomly to fix the bugs is not.

Giving Up

I know interview questions can be overwhelming, but that's part of what the interviewer is testing. Do you rise to a challenge, or do you shrink back in fear? It's important that you step up and eagerly meet a tricky problem head-on. After all, remember that interviews are supposed to be hard. It shouldn't be a surprise when you get a really tough problem.

Read More

The Interview Process for Software Engineers

Acing an interview starts well before the interview itself- years before, in fact. You need to get the right technical experience, apply to companies, and begin preparing to actually solve questions. The following timeline outlines what you should be thinking about when.

If you're starting late into this process, don't worry. Do as much "catching up" as you can, and then focus on preparation. Good luck!

Pict 1

Pict 2

Four Aspect if you're evaluated candidates :

• Prior Experience
• Culture Fit (or your personality, particularly with relation to the company) tend to matter more at smaller companies than at big companies. One way it might come up is if the company's culture is to let employees make decisions independently, and you need direction.
• Coding Skills
• Analytical Ability

Candidate will get rejected if :

• People often perceive you as argumentative, or with any other nasty adjectives, keep an eye on this behavior in an interview. Even an otherwise superstar candidate may get rejected if people don't want to work with them
• Spend some time preparing for questions about your resume. It's not the most important factor, but it matters. Even a little bit of time here can help you improve in major ways. It's a great "bang for you buck."
• Focus mainly on coding and algorithm questions

Incorrect Answers

First, responses to interview questions shouldn't be thought of as "correct" or "incorrect." When I evaluate how someone performed in an interview, I never ask myself, how many questions did they get right? Rather, It's about how optimal your final solution was, how long it took you to get there, and how clean your code was. It's not a binary right vs wrong; there are a range of factors.

Second, your performance is evaluated in comparison to other candidates. For example, if you solve a question optimally in 15 minutes, and someone else solves an easier question in five minutes, did that person do better than you? Maybe, but maybe not. If you are asked really easy questions, then you might be expected to get optimal solutions really quickly. But if the questions are hard, then a number of mistakes are expected.

Dress Code

Read More

Bagaimana berbicara agar didengar oleh orang lain

Ini merupakan kebiasaan yang harus ditinggalkan karena dapat menjebak diri kita sendiri.

1. Gossip : Menjelek-jelekan orang dibelakang merupakan kebiasaan yang baik. Seperti yang kita tahu, jika kita bergosip, akan banyak orang yang bergosip tentang kita juga.
2. Menghakimi (Judging) : Ada tipe orang ini dalam setiap obrolan dan sulit untuk mendengarkan orang lain.
3. Negatif (Negativity) : Kebiasaan yang mungkin dapat menjebak diri anda sendiri. Sulit untuk mendengar seseorang yang begitu negatif.
4. Mengeluh (Complaining) : Selalu mengeluhkan tentang cuaca, olahraga, dll.
5. Alasan (Excuses) : Orang tersebut suka melemparkan kesalahannya kepada siapa saja dan tidak dapat bertanggung jawab atas tindakan mereka.
6. Melebih-lebihkan atau Menambah-nambahkan (Lying) : Seseorang yang suka melebih-lebihkan dapat menjadi kebohongan, dan kita tidak suka mendengarkan orang seperti ini.
7. Dogmatism : Mencampurkan fakta dengan pendapat.

4 Landasan penting dimana kita harus berpegang teguh pada perkataan kita terdapat dalam kata HAIL (To greet or acclaim enthusiastically) :

1. Honesty (Kejujuran) : Jujur dengan apa yang anda katakan, sekaligus lugas dan jelas.
2. Authenticity (Ketulusan) : Menjadi diri sendiri atau berpegang pada kebenaran yang anda percaya.
3. Integrity : Melakukan sesuai dengan apa yang anda katakan, dan menjadi seseorang yang bisa dipercaya.
4. Love (Cinta) : Berdoa untuk kebaikan orang, dengan dua alasan.

Cara berbicara agar didengarkan orang lain :

1. Register : ketahui dimana letak suara anda jika berbicara. Misalnya anda ingin berbicara dengan nada berat, anda harus turun menuju arah dada.
2. Timbre (Warna suara) : Anda dapat melatih warna suara anda dengan nafas, postur, dan latihan.
3. Prosody (Ritme bersajak) : Hal penting untuk mengartikan pembicaraan karena orang yang berbicara dengan nada yang sama akan sangat sulit untuk didengarkan karena akan menimbulkan kebosanan atau monoton.
4. Pace (Kecepatan) : Apakah anda harus berbicara cepat atau bisa diperlambat dan memberi tekanan.
5. Pitch (nada) : Terkadang jika kita berbicara dengan berbeda nada akan menimbulkan arti yang berbeda kepada orang lain.
6. Volume : Dapat menggunakan volume tinggi untuk memberi semangat, atau suara yang pelan untuk menarik perhatian anda.

Cr : Julian Treasure

Read More