Hacker News Reader

Comment by metral | Hacker News Reader

I consider myself to be a generalist and pretty personable, the latter of which I don't think many folks remember to demonstrate during interviews, so I wholeheartedly agree with the points about chitchatting & showcasing your collaboration abilities. However, on the topic of working through a coding problem, I find myself struggling not so much with the asks per se, but rather, I focus too much on the fact that I'm thrown out of my usual dev/coding environments and working through a problem in a Word doc or some other non-text editor platform and it becomes a bit of a mental block. Compound that with the fact that my style of coding includes referring to existing code of my own or looking things up in mediums such as Google and StackOverflow to jump start me, and it becomes more of a crutch that does not aid me in these sorts of situations.

View on HN

I can't agree with you enough, thanks for verifying that other people like me exist!

Give a person a specific task in a specific environment, and stand over them, and generally all you see is that they can bumble through something pretty unfamiliar under a high degree of stress and social pressure. This is a useful skill approximately 0% of the time in a real job. Or if it is a useful skill in the job, your team has more fundamental problems than hiring to worry about!

Give them a problem to solve. Full stop. Let them take their time, do it at home before the interview perhaps, or in a quiet room on their own with their own laptop, or whatever tools they want, internet access etc, with no real time limit. If they 'cheat', you'll know because when you discuss their solution in depth later it'll be clear as day. This will test what you're really after, their ability to solve problems - allowing tools, the web, whatever else to work for them and not be arbitrary hurdles to jump over under pressure.

You are not alone. I'm also the same type of person, who become nervous when interacting with the interviewer. I am fine talking to coworkers one-on-one or contributing ideas in the group meetings. But when it comes with the pressure of securing a job (not to mention that I, as a candidate, has to go through several rounds of interviews within a day), it becomes a bit too much.

You're exactly right. If you get some dork that wants you to code during an interview then walk out immediately.

That's not how the real world works.

That said, as a senior software engineer, you should be able to get on a whiteboard and brainstorm and defend some architectural designs.

Even then, it's so much more important that you're all on the "same page" and can collaborate on problem solving, rather than they hoping your freaking Richard Feynman and will solve cold fusion for them

Amen, I swear there where a 100 times I should have walked out of interviews. Most of the time, I would have been more than happy to burn the bridge.

Why, coding an utterly simple problem during an interview is fine. The purpose of doing this is to show the process of thinking and the ability to produce, explain, and modify simple code. BTW ability to identify the missing pieces and google for them can also be checked, for it's valuable.

Any thing that's longer than 10-15 lines should be a quiet-room task or a do-it-at-home task.

I disagree completely. Every once in a while someone will slip through phone screens, etc. who does not have the foundational knowledge I want in someone who works for me. Asking them to write code to traverse a tree or implement strcpy in the language of their choice shows me if they lack the basic skills to continue taking up my time. Then we can work our way up the stack to debugging, design, architecture, and domain-specific knowledge.

Uh, we have candidates code. We also let them use their laptop and consult any resources they want. What's wrong with that?

Reply on news.ycombinator.com