

Ask HN: Tips on (mind) hacking programming interviews? - far0utb0y

Hi HN,<p>I've worked for several years as a developer at a company that most would consider to be a top-tier tech company. I also got a degree from a top-notch CS program and did well in school. I've done well at work and have hacked on various projects on the side. However, none of this really matters when it comes to applying for jobs, since the most it gets me is a quick response from recruiters and my resume at the top of the pile. Like all other mortal developers, I still have to go through the interview process.<p>This is where I'm having problems.<p>Lately, I've been interviewing with various startups and tech companies with high hiring bars. For some reason, I just don't seem to be doing very well in the initial phone interviews. The questions are not hard, but the combination of having to think, write, and talk at the same time is causing me problems. I can usually only proficiently do one or two of those things at a time. Some of the companies use web-based collaboration tools for the phone interviews where the interviewer can see responses in real-time. This seems to only make things more difficult. I find it hard to strike a fine balance between talking out loud to verbalize my thought process, taking time to think solutions through, and getting code out so the interviewer sees that I'm doing something.<p>It also doesn't help not knowing what the interview wants to see. Should I draw everything out on paper then type out the code? Should I just blast out code then fix it as I go? Should I talk while I'm thinking or brainstorming or coding? It's all very distracting.<p>At times, I find myself not actually thinking about the problem at hand, but thinking about how the interviewer thinks I'm doing. The less feedback or response I get from the interviewer, the worst off I think I'm doing, and I lose focus on solving the problem. It also doesn't help that I've been on the other end of the phone as the interviewer, dozens of times; it's even more distracting when I realize that I'm making some of the mistakes that so many candidates I've interviewed have made. For me, it's not really a lack of knowledge or preparation. I need to figure out how to balance thinking/writing/talking in a manner such that the interviewer can see that I'm not a complete n00b.<p>So, I'm reaching out to the HN community for ways to hack the interview. Especially any "mind" hacks.<p>* How do you approach interviews mentally - especially phone screens?<p>* Do you draw things on paper before implementing a solution? How do you progress from conceptualizing a solution to implementing it?<p>* How do you verbalize your thoughts or let the interviewer know that there's progress being made and you're not just bewildered and completely lost?<p>* What are some psychological ways to hack the interview? How do you stay focused on solving the problem and not get distracted by having to express your thought process and worrying about the interviewer's perception?
======
PilotPirx
1) Do they want to hire me? Yes, hiring me is the best thing that ever could
happen to them. So in the worst case it's they who fail in this interview,
never me.

2) I draw only if I need to explain something to the interviewer. But I have a
visually oriented way of thinking, so I don't need this for myself in most
cases. Then tell them how to implement this or that, when I know how it would
work. (We will need a vector to store this data, run a search on this, have
those tables in the database, linked this way, to be queried with this SQL
expression). Would depend of course, if they actually expect you to show some
code or just to outline the core points of the possible solution.

3) Normally I talk a lot and let them know intermediate steps (Watch their
faces, you can see if you're on the right track). There is no problem in
saying something that's wrong. If the interviewer knows a bit about the job,
he won't expect you to be perfect on the spot. (If they send you somebody to
interview you who doesn't know that: wrong company, good bye) If I get stuck,
I tell them that that's a complex problem and I need to think some time about
it. Shouldn't be a problem. Maybe I give them some of the points that make me
worry and line out the possible problems and solutions. (If I do it that way
it will use more memory, but the other way will give me better performance,
cleaner code...)

4) I just tell them what I'm thinking. I don't think what they may want to
hear. They get what I have and that's it. If they don't like it, that's bad
luck (For them of course, not for me)

------
davidj
schedule a interview with a company you don't really want a job ahead of the
interview with the company you do want a job from as a practice interview.

