Comment by hoboon | Hacker News Reader

Comment by hoboon | Hacker News Reader

Parent Full thread

> Your #2 problem is that you think writing code is the most important skill of a programmer. It's not. Learning is. Are you a fast learner? If so, there are hundreds of companies that need you.

I'm told in my interviews that I don't program well enough for them.

I'm not so stupid that I don't know what you're talking about. I'm not the fastest learner that I know of. I do like learning new things, however.

Given your answer, I'm thinking you aren't a hiring manager or don't get involved in interviewing much. If a candidate takes too long to answer a question, even if they get it right eventually, it's as bad as getting it wrong, in the eyes of management.

> You also keep talking about "engineering". The majority of software companies aren't writing code in a way that could be called "engineering". It's sloppy, and the developers are embarrassed by it. But that's what you do when your time/budget are very limited.

It's industry parlance for the area of the company that writes novel code, as you put it.

I'm not a hiring manager, unless "hiring manager" = "someone who hires". I've interviewed more than 100 devs and hired a few dozen. I've done it internally (leading a dev team) and externally (as a consultant). Assuming I don't know what I'm talking about, just because your experience differs from mine, is presumptuous. You're the one who came to HN and asked for advice, after all.

My response didn't imply that you're stupid. Everything I know about you is from your short post. Maybe you already know everything I said. If so, there's no harm done if I re-state it. If not, then I've helped you. I always err on the side of "too much information" instead of "too little" when helping someone.

I was wrong, then. I apologize.

But I felt like you were talking down to me -- like you don't trust me.

Yes, I understand solving problems is part of the job. Every software engineer has had that told to them forever, it seems. It's common advice.

The feedback I've gotten in interviews is that I can solve problems but I don't translate them into code quickly enough. Again, spending too much time on an answer I would eventually get right.

This is why I think the advice about solving problems not code is not really true. Look at the various tomes about ace-ing job interviews: it's all code problems. And you have to do it quickly. Solving the problem is not enough for most interviewers; they want code in a few minutes, too. Perhaps you are the exception.

Thanks anyways.

No hard feelings. Text is a poor medium to convey tone, and misunderstandings happen. It seems as though you're unnecessarily hard on yourself, and I hope that improves as time goes on.

What you're describing in interviews (penalizing slower coders, even though they'll eventually get the right answer) has been discussed a lot on HN recently.

The consensus seems to be this: a lot of companies do code tests, and they do care about speed, but those companies are wrong. It's not a good way of testing someone's usefulness as an employee.

That said, there definitely are companies who do not hire this way.

As you spend more time coding on your own, rather than fixing bugs, you'll get faster, and these tests will no longer be an obstacle. Eventually, your resume will be good enough that the tests won't be necessary.

If you think you're at a dead end, or you've made mistakes you can't fix, I know how you feel. I've been there several times. And things ended up working out so well that I looked back and wondered how I could have felt so little hope.

The same will happen for you, but it does require work. That might include coding in your spare time, going to networking events, asking your friends for tips on job openings, applying to more than 100 companies, or even a drastic career change. But all those activities I mentioned do pay off.

Best of luck. It sounds like you're smart and have a lot going for you.

Reply on news.ycombinator.com