Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to keep yourself prepared for potential interviews?
82 points by hidro on April 26, 2015 | hide | past | favorite | 60 comments
I'm a software engineer with more than 5 years experience. There have been more than 1 time I am contacted by big companies for interview opportunities. And every time I find myself in a position where I'm totally unprepared for it.

I know the drill, and I know my skills. I'm not terrific with algorithm problems. I need preparation and frequent practice to stay sharp. In the past, I have tried spending 1-2 hours each day to practice. But as I gain more experience, I find myself spending more and more time working on side projects, exploring things that interest me, solving problems at a different scale. I can't really keep myself motivated to practice random algorithm problems anymore.

I do want to be prepared when the chance comes, but I can't balance my time. What would you do if you were me?




To be frank, I have never gotten a job I've really enjoyed which required me to know my algorithms in an interview. Such questions are a negative indicator which indicate to me that the interviewer is more interested in showing off than getting things done.

The only practice I keep up with is talking to people. Being able to maintain a conversation with a non-technical person for more than a minute will has furthered my career more than any amount of algorithmic knowledge.


This is great advice.

One good way to start is to take a project that you've been heavily involved with and create a small presentation out of it. Draw up the architecture in Google Docs, keep any confidential stuff out of it, add some screen captures. Print it out and keep it in a small binder.

Practice explaining the project in under 5 minutes. Try it out on some friends that might not understand the tech completely. Rehearse questions and answers that people might ask.

Being comfortable speaking like this with management and future coworkers has worked well for me, more so than FizzBuzz on a whiteboard.


This is excellent advice specifically because it's not about "prepping for interviews"; honing these skills simply makes you more valuable to any company, and it's an aspect of your capabilities that you can show off in a decent interview process... so take advantage of that.


Just to add to my comment above, I recently did a round of hiring for a new embedded engineer. I had a handful make it to the in-person interviews.

When asked about previous projects, almost every single one waved their hands and tried to explain how they glued widget A to framework B and <magic> got product C.

Exactly one candidate brought materials to show things he had worked on and how the skills he used in those projects applied to the work we were doing. You could see eyes light up when he was asked "so, tell us about <project z>" and he smoothly pulled out some pages to show.

He blew everyone else away and got the offer.


Did you ask him to bring stuff in advance?


Nope. And I always carry materials on my interviews even if I'm not asked to. It's not much more work to carry a small 3-ring binder along with the notepad and resume folder I typically carry to an interview.

(Protip: always carry extra copies of your resume to interviews. There's always someone that is missing theirs and it's nice when you hand them an extra copy)


This is a good advice, but how about company secrets and things like that? Of course it varies by country, but is it legal in the US for example to create this kind of presentation about a adnetwork with user tailored ads you created for example?


Like I said above, showing confidential material is bad form. But in my experience you can show a lot without exposing secret algorithms or formulas.


I've flunked almost every interview where I've been asked to solve a fiddly math problem with an algorithm. I've always sucked at these types of questions. I ended up buying Gayle McDowell's book 'Cracking the Coding Interview' to get me through my next career move, but since then, I've taken a job that didn't involve getting through a coding exam.

It's these types of questions that would stop me even applying for a job at Amazon or Google. I know they'd come up and I know I'd flunk them, so I don't bother.

Funny thing is, nobody has regretted hiring me.


Yeah, the worst part is companies like Amazon will expect you to eat multiple days of PTO to go through their screening process. Hell, I feel this way even tho they have recruiters trying to fill quotas that contact me about jobs at Amazon :|

Why would I bother?

It is like they only want to hire unemployed programmers with plenty of time on their hands to prep.


Amazon and Google's hiring processes appear designed to bring in large numbers of very clever undergraduates finishing their bachelor's degree and looking for a first job -- and little else.

(For the record, I've gotten an offer from Amazon before, but never from Google, and Google seems to make their interview process noticeably harder in terms of how much of your undergrad algorithms and data-structures curricula you have to remember to do the interview. Strangely, my lack of obsession with these subjects hasn't ever stopped me getting anything done in real life.)

Alternative hypothesis: these companies believe that the ability to answer undergrad exam questions about general algoriths-and-data-structures can act as a kind of intelligence quotient for programmers, giving a strong measure of general intelligence with low false-signal rates, and they are hiring for (what they believe to be) raw cleverness because they simply don't believe domain expertise or specialization to be real, exploitable phenomena. This alternative has the advantage of neatly explaining their allocation processes, too.

But on the other hand, believing these to be disjoint hypotheses requires me to assume that undergraduates have never actually specialized by the end of their degree.


> Amazon and Google's hiring processes appear designed to bring in large numbers of very clever undergraduates finishing their bachelor's degree and looking for a first job -- and little else.

Yeah, that makes sense and its a perfectly valid explanation.

I don't get why they'd have recruiters who contact people that don't fit their mold on a regular basis if that was the case. It seems like a complete waste of resources.

That is why I think they have some other objective.

> these companies believe that the ability to answer undergrad exam questions about general algoriths-and-data-structures can act as a kind of intelligence quotient for programmers,

I'm pretty sure that is what they think they are doing. I just don't see it as successful because while its easy to remember the names/purposes of algorithms it is difficult to remember all of them at an implementation level because I implement them once and rarely every again. So I'd need to go look something up that I last implemented 5 years ago or Google it.

However, I'm not going to waste my time to "prep" to waste my PTO for maybe getting a job. Its a completely unproductive activity when 90% of other interviews don't involve me expending more than a day of PTO.


I've noticed a trend over the decades (yep, decades) where people and corporations are moving away from subjective evaluations to safe, who-could-argue-with-that objective evaluations.

If someone doesn't know how to evaluate a candidate, or doesn't feel safe or comfortable, well ... nobody gets fired for asking about algorithms.


> It's these types of questions that would stop me even applying for a job at Amazon or Google. I know they'd come up and I know I'd flunk them, so I don't bother.

I've known some decent programmers to come out of Amazon, but I've also seen some atrocious programmers that had previously worked at Amazon. I can't say it breeds confidence that their interview techniques work well.


Don't Amazon hire a lot of contractors though? Maybe they circumvent the tedious recruitment process?


Making connections and building a hiring network is awesome advice, that many many developers miss. Thank you.

I run a company (http://interviewkickstart.com) in Sillycon Valley, that helps developers brush-up their data structures, algorithms and system-design skills for interviews. Previous to that, I worked at a very fast growing startup in the valley, where I had joined early and had the privilege to contribute to multiple iterations of their technical interviewing processes.

Here is the thing: not a single employer is happy with their interviewing processes. They do it not because it's the best process ever, but it's the least evil for demands on the business, for their size, stage and culture. Every single process has its flaws.

The core reason most companies ask data-structures/algorithms and such, is because that's the lowest common denominator of knowledge between the interviewer and the interviewee.

How is that?

That's because the field of programming is so vast, that candidates apply to ANY available job, whether that fits their experience or not. e.g. If you worked on Payment systems and you apply to a Deployment systems role, what am I, as an interviewer, going to ask you about? I can't ask you about Payment systems and JUDGE you on your knowledge of 5 years in 45 minutes especially when I have not worked in it myself. And I can't ask you about Deployment systems because you haven't worked with them enough in the past. I hence fall back to the lowest common denominator of knowledge between us, which is, most likely, something in the CS programs we attended.

Then why ask algorithms, of all the CS that we may know in common? Because that needs the least amount of specific knowledge, compared to things like compilers and systems. Algorithms is a proxy to your problem-solving skills. An unfortunate proxy, but the best available among the things we know in common.

If you however end up applying to the exact SAME thing you have been doing, they should not ask you all the algo shit. They should ask you exactly what you've done and how you've done it and judge your experience off of that. After all, interviewing, by definition, is a verification of your experience.

But reality is, that you probably don't want to continue working in what you have been working in. Because you want a change and because frankly, CS is just so vast and cool opportunities exist anywhere. Data Structures and Algorithms hence, become the best equalizer/normalizer among anyone who wants to do programming.

Also, business pressures are such, that as a company, I just cannot spend more than a day or two evaluating someone's fit. Otherwise I'll take my team's attention off of more important things e.g. the holiday e-commerce season, or I'll be second to the market with a feature or I'll miss that big conference where I wanted to launch that product. I'll much rather hire an okay developer with a short interview process and hit that deadline that's going to keep my business afloat, than wait for a unicorn by a thorough evaluation. And when I can only give a short amount of attention to you, I will fall back to the easiest and most prevalent method of interviewing, which is what you see today.

In conclusion, I don't think it helps agonizing over interviewing processes of companies. It's best to remain prepared. Keep solving problems, keep interviewing. And when you need a booster, just come to us ;-) http://InterviewKickstart.com.


Always be interviewing.

This has a few advantages:

* You get practice and insight into interview questions

* you always have an idea of your worth

* interviewing stops being something you only do when you NEED a new job. Now it's just a day to day thing and it's less nerve wracking. You don't really want a new job so the pressure is off.

* you may find a much better job and decide to take it.

I'm sure there's more positives as well. The downside is it takes time away from other things including work. As you do it regularly though you'll find it takes less and les time since your resume is always up to date and you get better at weeding out companies you wouldn't want to work for.


I can see how this would be useful. On the other hand, from the perspective of a company who you might theoretically interview with... remember that running the hiring process isn't free for us.

It's a much bigger deal with small companies (I'm not sure a large one would care much), but if I pick up that you actually have no interest in what we're working on, no intention of leaving your current position, and just applied to brush up your interview skills "for free", I'm going to be seriously annoyed.

Maybe it doesn't matter -- if you've no intention of joining us anyway -- but it doesn't make sense to burn bridges this way.

If you're genuinely interested in us, and in making the connection, though (e.g., "I'm happy where I am now, but you look like you'll be really hitting your pace just as my current company is past the exciting phase", or "I like my job, but commuting across the city is awful... how do you actually work?"), that's reasonable.


As someone who does a lot of hiring, I wish more engineers would do what he suggested.

When interviewing candidates, it can be too easy to adjust your expectations downward after interviewing many unqualified candidates. My hunch is that so many candidates are unqualified because the ones that are actively looking for a job are predominantly the ones that aren't in demand an interview everywhere. If I can mix in qualified candidates that aren't really looking, I can better calibrate my assessment of the market for talent. Plus, with hiring being as difficult as it is, I'll spend the time interviewing to get an opportunity to sell my position and my company to a candidate, whether interested or not. It only takes changing the mind of one excellent developer to make it worthwhile for me.

Additionally, networking is everything. Leaving candidates with a positive impression of my company, my team and myself is worth something, even if they don't join. Whenever I extend an offer, I also offer to connect on LinkedIn with the basic message, "I'd like to work together now, but I understand that's not always possible. Even if you take another position or stay at your current job, please feel free to check back in the future or refer any friends who are looking." Most don't accept, but some do. Even if it doesn't help me hire for my open position, there's value in having a network of people who all think they've got it better than I could offer. Whenever I'm searching for a job, my first stop is looking at the current employers of the developers I respect most from my network. Those employers are likely to be doing something exciting and I've got an in to pass my résumé along if I want to apply, even if my relationship with that "in" was only a single interview process.


> from the perspective of a company who you might theoretically interview with... remember that running the hiring process isn't free for us.

Neither is interviewing free for the interviewer. S/he has to take PTO to do the interview.


The interviewer makes that calculation -- is it worth taking the time, in exchange for more practice interviewing? And it may actually not be PTO; I've done plenty of remote interviews at odd hours to accommodate candidates.

The company would be paying for a shot at a good new hire. Here's where my point applies -- in this case, if there's actually no chance you'd work for them, that's a trick they're not going to be happy about.


I wonder how you would feel if the reciprocal attitude was adopted by your employer - i.e. if they continually interviewed potential replacements for your position, to:

* get practice at interviewing people for your role

* have an idea of what your market worth is, so they can use this in salary negotiations

* stop interviews being a difficult process they only do when you leave

* keep the option of finding a better candidate and replacing you on such occasions.

I'm going to take a wild guess and assume you would not tolerate that from your employer. It would show a lack of respect, trust, engagement, etc, basically it would convey to you that your employer doesn't even care about maintaining an appearance of giving a damn about you as a person. You've only just started there last week, and they're already thinking about firing you and replacing you with someone better.

Personally, whilst I think the attitude of getting upset because someone leaves the company is immature, I also think your attitude is disrespectful and shows such a contempt for the place where you're working, such an extreme lack of even the remotest sense of loyalty, that I wouldn't want to employ someone with your attitude ever.

This is without even delving into the fact that you're imposing a tax on the system, taking time away from your current employer (presumably with this attitude you're quite happy to pull sickies to cover your frequent job interviews), as well as other potential employers (interviewing people costs time and money; interviewing people who have no interest in changing jobs is a total waste of money for the company). If everyone suddenly behaved like you, regularly applying to even just a dozen jobs a year even though they have no intention of changing jobs, the recruitment process would incur such gargantuan costs that the economy would suffer, if not crash. Basically, your suggestion above seems to convey that you only really care about yourself. At least that's what it makes me feel from the really self-centred way you've described it.

I'm sorry that this reads like a personal accusation, but you made statements about your personal system of behaviour and I find that system deeply objectionable.

If I got the wrong end of the stick (perfectly possible), please do correct me...


I have rarely worked at a place that hasn't kept an ad on their site for an engineer even when not hiring. At one, the hr vp quite honestly admitted they interview continuously at a reduced level in case someone leaves.

And really the idea of loyalty to a place that has you sign an at will employment agreement and a non-compete clause doesn't make the much sense. And that so many companies seem more than willing to move overseas or outsource work solely (and inevitably foolishly) to reduce wage costs surely shows no loyalty to their employees.

And surely the endlessly quoted "market forces" requires all rational actors to pursue the avenue with the greatest fiscal returns doesn't it?

It would be nice if it were otherwise. And the first mandatory step to bring that about would be eliminating the at will employment agreement.

Now if your company does none of these things and retains employees through their whole careers then I applaud you enormously.

For the rest, it is deeply foolish to remain loyal to an organization that is so demonstrably unloyal that, for example, it has never kept a single employee up to anything remotely like retirement age.


I'm also a guy that's always interviewing. It keeps me fresh, which seems to be an inoculation to what I see as the number one career killer: stagnation.

I would have no problem if my employer constantly interviewed for my replacement. This would be an excellent thing to do because they would have a better understanding of where others want to take their careers and general trends in software development. Cheaper than bringing in business consultants.

Work for yourself, never settle. Loyalty just means you might be the last person laid off in a slump. Only exception to this rule might be ownership benefits or a pension.


My company is interviewing potential replacements for my position all the time. The things it shows: how hard it's to find such a replacement (so there is no desire to play "it's a world-wide financial crisis, dude, no raise for you this year, ok?"), the company is not managed by idiots, who expect all their employees are immortal, immutable beings who are going to be there forever and ever (and go into a crisis mode whenever such an employee suddenly proves she or he is a human) and, finally, the company is growing.


> you're imposing a tax on the system, taking time away from your current employer

An interview shouldn't feel like such a transactional process. An interview should be a great way to share between two workers at different companies different team and technical challenges. A good interview is one that I'm learning from, no matter which side I'm on.

Unfortunately, this concept is mostly limited to small innovative and agile companies asking their employees to wear many hats.


> Unfortunately, this concept is mostly limited to small innovative and agile companies asking their employees to wear many hats.

How does "asking their employees to wear many hats" affect the interviewee?


When wearing many hats, your knowledge is more likely to collide / integrate with other people who are wearing many hats.

If the interviewers are silo'ed and aren't familiar with such a variety of things devops, team management, feature releasing, then there is less of an opportunity to learn about a wide variety of things.


> I also think your attitude is disrespectful and shows such a contempt for the place where you're working, such an extreme lack of even the remotest sense of loyalty, that I wouldn't want to employ someone with your attitude ever.

There is no reciprocal loyalty from a corporation anywhere, ever. Corporations are amoral. You will be jettisoned without remorse at the first hint of necessity, and not even necessarily at all connected with your performance or loyalty.

No one looks out for you except you. Companies do interview without a specific position open. No reason why individuals shouldn't do the same.

Time-warp me back to some gold-lit age of caring and loyalty, and maybe I'll feel different.


I get where you're coming from, but look at it from the perspective of a smaller company. If a developer leaves, they're only going to give 2-3 weeks notice, but onboarding a developer, even if they were found day one, would take months and steal time from the rest of the team. Chances are it won't be day one, which means you then have a smaller engineering staff doing the same amount of work. I WISH some of the companies I've worked for had simply interviewed outside of times of need and brought on developers simply because they were good developers, to minimize the pain when key people leave.

Look at it like servers. You want to have some level of redundancy because machines will fail. Yeah you might not have full redundancy everywhere, and a perfect storm of failures might bring down your application, but if you have NO redundancy, your application will fall over under the same amount of load.


Companies do this all the time in various forms. Recruiting and HR are entire departments at most companies.

Don't get confused and start acting like a corporation is a person with feelings.


Ah, but some corporations are run by people with feelings. And for small corporations the situation is a bit different than for a larger one. The turning point is roughly around the time the CEO no longer knows the first name of everybody that works in the company.


> Companies do this all the time in various forms.

> ... start acting like a *corporation• ...

So, partnerships, LLCs, and sole-proprietorships apparently don't exist. Good to know.


I do think this strategy can be taken the wrong way so I understand your points. I think it's very doable in an honorable way. Let me clarify:

* I think companies are doing this but they aren't looking to replace me so much as to make sure that anyone person doesn't affect things too drastically if they leave.

* "Frequent job interviews" is over stating things. Many interviews might only progress to phone interviews or coding exercises. One or both parties can learn a lot just from that. In person interviewing is rare because I really don't want to use my pto and spend time away for work just for practice. If the opportunity excites me though, I very well might.

* Getting me excited to interview with a company takes a lot. Especially when I'm happy at work, I'm taking into account big projects I'm working on, my amazing coworkers and bosses that I'm not ready to leave, etc. It's definitely about more than money. You're right that one can't look at it as just a black & white decision. It's multivariable and will shape your life for years to come. Choose wisely.

* Applying to jobs... This is interesting because most opportunities I see come from being cold called with interesting opportunities and having a conversation. It's important to be up front and say, honestly that you're not looking but open to a great opportunity. In the first call I usually give a very high price as well that would justify leaving earlier than I would like. I think it's fair to say that many people have an amount that is walk away money. Ideally if I'm leaving earlier than I'd like I should be able to tell my current boss and they will say "Damn. This sucks but I can't blame you. That's a great opportunity."

You're taking this as a very deceptive practice, but that's not the way it has to work. This can be practiced with an enormous amount of honesty. It might surprise you to know that even after telling companies that I love where I work and don't see myself leaving for a few years, they're fine with that. We will still chat.

At the very least, I'm expanding my network and learning more about other companies. I also use this understanding of other companies when I talk to candidates for my current employer to have some context.

To wrap it all up, here are my guidelines that I follow to do this in an ethical way:

* Be up front with the hiring manager that you are happy in your current job and don't have any plans to make an immediate change but are open to discussing opportunities.

* Accomplish some big things at each company you work for before leaving. In my mind this means don't hop around every few months. Stay a few years, build something you're proud of. If I were going to be coaxed away before accomplishing something it would take A LOT. But hey. I'll let someone try and make a case for it.

* Move on when the opportunity meets your "Oh shit!" criteria and don't feel guilty. If you're good, you'll always be working on an important project and it will never be a great time for a change. I also help my team reduce my bus factor as much as possible. I think that's valuable for the company as well should they ever want to fire me or move me to a different team.

* If you aren't happy at your current place, don't lie. Tell them so they can fix it. If you are happy tell them you are. If they ask if you ever talk to other companies say of course! That you are always networking and bringing the good parts you hear back to the office and simultaneously looking out for great people to recruit.

There's no reason keeping yourself sharp and knowledgeable has to be a win-lose scenario.


Thanks for the clarifications. That does seem a lot more balanced and sensible than the reading I got from your first post!


Awesome. Glad to hear it.


This works if you live in an area conducive to it. If you don't, like me, and almost always have to travel out of town for interviews it becomes much more difficult.


Just added an update but there's nothing that says interviewing need be only in person. Even just phone calls and email screens can be immensely valuable.


I reversed my attitude for interviews. If the employer has an interview process that doesn't respect my time, my experience, and my ability, then I don't want to work there.

My attitude isn't "As a candidate, I failed that interview." My attitude is "That employer failed to have a process that enabled them to hire someone as awesome as me." I know that I'm a 10x-100x programmer at the places I've been, and if your interview process can't identify that, then that's your problem and not my problem.


My takeaway from being both an interviewee and an interviewer is that the most correct attitude after a failed job interview is "We don't match each other".

The interviewer is testing their own ability to properly conduct a job interview as much as they're testing the candidate. I realized it when I was interviewing candidates myself.

Also, people and companies are drastically, surprisingly and ridiculously different. You may fail badly at one interview, and it means nothing, you can just move on to the next company and prosper.


Yes, everyone should keep in mind that you are interviewing the company as much as they are interviewing you.

Everything is a signal.


Liked that attitude.


I have reached a point where I am comfortable enough with implementing things that I do not need to practice as long as I understand how it works. So I get to spend all my free time on side projects just like you.

I have a set of downloaded algorithm lectures by Robert Sedgwick from Coursera (text version: http://algs4.cs.princeton.edu/home/) that I watch before every interview. I make it a point to do this even if I think I remember it well. In fact, I now know parts of the course so well, that I can watch it as 2x speed in VLC, and that refreshes everything in my mind.

To be fair, I'm still in college, and all my interviews were for internship positions and algorithms focussed, so it might definitely differ from your situation. However, what I learnt from this set of videos has never failed me with any of the big companies.

PS: I use scripts like these (https://github.com/coursera-dl/coursera) to download useful courses from Coursera that I can then watch before interviews.


How many hours does it take to watch the full set of algorithm lectures that you downloaded, even at 2x speed? That sounds like a significant amount of time.


Takes me a day


Stop drilling pointless "interview questions" and instead prefer employers that value your ability to do the actual work.

If you can build and ship side-projects your preferred employer will hire because of that, not some tricky interview question. You can safely reject employers that want to, if you get the analogy, hire scrabble players instead of writers


also, what a sad indictment of the tech sector when someone thinks they need to spend time practising interview questions instead of actually, ya know, programming. Crazy stuff


I'm currently making the round of interviews and I'm spending hours every day practicing and reading up on technical terms for interviews. Even this weekend has been completely dedicated to this. It's not fun but I don't have a choice because every job wants me to solve an arbitrary code test and drill me on technical definitions even though I have a github account filled with code I've written and a nicely made portfolio with live examples.


When camels are on sale in the markets, buyers look at the animal's teeth to find out if its a good healthy camel. They don't like to go and do scientific health checkups. Same with tech candidates. Its better to brush up on algos :)


Phone interviews, take home projects, all day grillings, we can't decide, come back for more grillings, is not 'looking at the teeth'. Looking at my resume and asking me to explain something on it is inspecting my teeh.


Do something like TopCoder SRMs or CodeForces rounds. They are not only fun but they take up only about 2-4 hours of effort per week. You can judge yourself how well you are doing compared to college kids and competitive programmers. After the contest, read the editorial about the problems that you could not solve during the contest.

After about 3-6 months of this, I can confidently say, I can pass the pure algo/data-structure rounds of any company..


> What would you do if you were me?

Ignore recruiters unless I was actively looking and start practising whatever the relevant set of questions; silly flash card memory tricks, etc; were if that became true.


I just do interviews constantly. Not frequently but I keep my resume updated and keep alert for relevant positions and some position that aren't an exact fit as well. I will respond to recruiters and do interviews until I am pretty sure that its not a good match. If I happen to find an awesome company to work for in this way then that's just an added bonus. Basically I'm always on the lookout for my next job.


It seems like you've already identified that the problem is you needing to know 'algorithm problems', so I would work on that. You shouldn't need to memorize hundreds of random problems. I think a few simple (not requiring much time to learn or to maintain) things would go a long way if you really are willing to make yourself put in some effort. Learn how to do basic big oh analysis. Learn how to apply recursion to simple enough problems, like the boggle question. Learn how merge sort and quick sort work and be able to implement them (they're not even that many lines of code). If you're already working on side projects and solving problems at different scale, that should help you naturally stay up on these things. Being able to talk about different libraries you learn and how you worked at different scales should also be valuable during an interview.


Found myself in similar situations in the past. My tentative solution was to maintain a corpus of resources for practice (beyond the usual suspects of implementing the standard data structures etc.), and hope that when the chance comes, 1-2 hours each day for a week before an interview would suffice. And when I do practice, I don't use a code editor, either paper or plain editor with no way to execute the code, simulating the (horrible) conditions of interviews as best as I can.

Obviously, this doesn't get you the benefit of being constantly drilled, but should provide some advantage. If you do care enough to get yourself a bigger advantage, maybe try to clear a few weeks before a round of job searching (if that's how you operate), then use those weeks for a few hours of practice each day.


I do the same as you. For me it's far more important to maintain energy level and motivation in self improvement projects than to do some specific trick question kata for a hypothetical interview. Some people like those, I can't stand them.

I get a huge kick from algorithms when they solve a specific problem at my current problem elegantly. I suppose for me my algorithm learning plan is to constantly ask myself "what is the simplest form of data that I need and which algorithms then process it most elegantly for my current problem".

The only thing I know for sure is a) people learn differently b) each must find a learning strategy that fits his or her strengths the best.


The real question is not how you as a well educated computer science professional stay ready for interviews. The question is whether or not the US economy is going to be able to handle integrating and making use of modern technology in an efficient way, or if the US software industry will be collapsed by incompetence in the same way the US auto industry was.


Always be looking for a job. Always be interviewing. Because recruiters are whores your boss will find out. Just tell them that you are looking for a part time job. Schedule all your interviews during lunch or after work.


Interview cake newsletter is a nice weekly refresher to keep you sharp


Interview Cake is great: https://www.interviewcake.com/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: