Hi.<p>I am full time software developer and my day to day activities involve bug fixes and sometimes working on a prototype or POCs. I recently got an chance to interview and after a little research I found that, they are more focused on Data Structures and Algorithms coding questions. The problem here is, that I know what a complexity of a quick sort or how I do use HashMaps, but I don't work on these data structures or algos everyday, or even write a tree traversal routines. I remembered all these when I was a fresh graduate. How do you deal with this? Should I ask more time before I go for an interview?? What should be a better approach.<p>Sorry for my bad English.
Thanks in advance.
Personally, I have come to realize that you cannot truly prepare for a technical interview no matter what you do. You can study for months in a futile attempt to commit to memory everything that might be relevant (data structures, algorithms, maths, statistics, API reference etc.) but they will always find something to ask you that you missed during your studies.<p>These days I simply reply that I do not do technical interviews any more as I do not believe these can efficiently probe one's professional abilities and I cannot justify expending time in memorizing bulkloads of trivial information for the sake of going through some rite of passage, which some interviews often turn into.<p>Agreeing to a technical interview also puts you at a disadvantage. They will probe your weak spots and then use this knowledge to publicly disgrace you, declare you less competent than what you'd like them to believe and then to low-ball you with an offer below what you might otherwise get. Many developers fall for that trick, the best you can do is to make sure you don't join their group.<p>Just say to them you will not do a technical interview (or a test project on your own unpaid time) but that you are prepared to meet and have a constructive discussion around their needs and your willingness to possibly help them out with whatever they have in mind. If they don't like it, skip them for the next company in your list.
I like the advice given here:
<a href="https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2" rel="nofollow">https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051...</a><p>I'm thinking about making a move and am slowly prepping algorithms and data structures again myself. Going to focus on studying nuances of the language I'm working with - JavaScript (+HTML, CSS) and the frameworks I'm currently using - Angular & Node.<p>But having seen the other side now, I recognize that you will most likely run into peoples' pet questions that you can't always prepare for. One coworker gets upset when people can't answer his Angular question, another gets upset if the Java isn't idiomatic enough. If they like you enough they'll overlook it.<p>So study what you can, be confident but not arrogant, and recognize luck will play a factor. I'd rather be writing code to build things than for practice, but it is part of the game. And in reality the quizzes should really be a screen and the decision should be based upon the things you've built. So hopefully you have things to show, can talk about what you've done, and the team your looking to join recognizes actual accomplishments are more important than solving puzzles on the spot.
I read Programming Interviews Exposed (<a href="http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Landing-ebook/dp/B008SGNJOW/ref=tmm_kin_title_0?_encoding=UTF8&sr=8-1&qid=1430703825" rel="nofollow">http://www.amazon.com/Programming-Interviews-Exposed-Secrets...</a>) - which covers lot of topics that come up during interview.
I've found that technical interviews are their own best prep. I'm sure you get contacted by recruiters/startups pretty regularly (and that you usually pass on these opportunities). I try to say "yes" to one or two per week, and go through their technical interview process, just to stay on my toes.<p>It takes the pressure off and keeps you on top of your game.
Three main ways to prepare for a technical interview are:<p><pre><code> 1. Books
2. Websites
3. Classroom courses
</code></pre>
=====<p>Books<p>=====<p><pre><code> There are a dozen or so books in the market.
The two most popular books (and well written also) are:
1. Cracking the Code Interview
2. Elements of Programming Interviews
</code></pre>
========<p>Websites<p>========<p>Websites are roughly divided into two groups:<p>a. Where you can write code and compare yours with others' solutions<p>Popular ones, in no particular order, are:<p><a href="http://leetcode.com" rel="nofollow">http://leetcode.com</a><p><a href="http://HackerRank.com" rel="nofollow">http://HackerRank.com</a><p><a href="http://uva.onlinejudge.org/(UVA" rel="nofollow">http://uva.onlinejudge.org/(UVA</a> Online Judge)<p><a href="http://SPOJ.pl" rel="nofollow">http://SPOJ.pl</a><p><a href="https://projecteuler.net/" rel="nofollow">https://projecteuler.net/</a> (Project Euler)<p>Note that not all of them have questions that are interview oriented. But it's great practice regardless.<p>b. Ones that give you a problem and then a solution, with no or little competitiveness<p>Popular ones, are:<p><a href="http://InterviewCake.com" rel="nofollow">http://InterviewCake.com</a><p><a href="http://GeeksForGeeks.org" rel="nofollow">http://GeeksForGeeks.org</a><p><a href="http://Glassdoor.com" rel="nofollow">http://Glassdoor.com</a><p><a href="http://Careercup.com" rel="nofollow">http://Careercup.com</a><p>=============================<p>Classroom courses / Bootcamps<p>=============================<p><a href="http://InterviewKickstart.com" rel="nofollow">http://InterviewKickstart.com</a> (I run this one)<p>Having said that, realize that you are not alone. Most programmers these days don't use fancy data-structures and algorithms at work.<p>But unfortunately, interviews still ask for it. That is a whole debate on its own.
I used to prepare for them using CareerCup and doing problems on either HackerRank or Google Code Jam's practice problems.<p>Now though I usually don't even bother and just go to them; I think that after you studied for them the first time you kind of already know what to expect, and the interviews themselves kind of prepare you, so usually I try to schedule interviews I don't care about as much before the ones I really want to do well on. The scheduling also helps because for the first one I might be nervous but if you keep doing it I think your body just gets used to it and I honestly kind of stop caring whether I'll get in or not. it might sound counterintuitive but I actually find that the less I care the more likely I am to do well.
I prefer the book "Algorithms" 2nd Edition by Sedgewick. It is long out of print but can be had used for a song.<p>Implement each algorithm in the book in your preferred language. The algorithms themselves are presented in Pascal, which IMHO makes them easier to understand.<p>Now implement them all in some other language - not your preferred one.