Hacker News new | past | comments | ask | show | jobs | submit login

When I hire, I'm not looking for a person or a resource. I'm looking for a solution to my problem. Sometimes that problem is big, sometimes it's urgent. But there's always a problem needing to be solved. The more a candidate looks like a solution to my problem, the closer to the front of the pile he/she gets.

AFAIC, the most important thing for any candidate to do is to identify my problem(s) and present themselves as the solution. The problem could be:

- We just got a bunch of new business and need someone to do <xyz> immediately to satisfy those customers.

- We just acquired another business and need to convert/integrate from technology <abc> to technology <xyz> and need someone who knows both technologies (or either one) and has done that before.

- We have a new business problem and one possible solution is to build/enhance/maintain an app. Can you do that? Have you done that?

- We plan to grow x% over the next 24 months and we need people to do more of what we already do which is <abc>. Can you do that? Have you done that?

- We have a problem and frankly, we're not sure what to do. What would you suggest? Can you do that? Have you done that before?

You kinda get the picture. The tricky part for any candidate is the research. How do you find out what my problems are? Ask! Ask me. Ask someone else in the company. Ask anyone. The simple act of research shows that you're a serious candidate. The follow up with a solution to my problem puts you at the top of my list.

If you're right out of school or don't have a lot of experience, you should still do this. You may not have as long a resume as others, but you have every bit as much to offer to solve my problems. Maybe a smart person who works hard and knows how to deliver is just what I need. You must find that out and present yourself as such. Remember, it's about my problem, not yours.

This was I great question to ask here at hn. I've never seen it before. The fact that you thought enough to ask is a huge first step. It shows that you're thinking about me, not just yourself. Keep thinking like that and there's no telling how far you'll get. Thank you and good luck.




Good advice.

You can also play the old mentalist trick.

The mentalist knows nothing of his audience, yet it appears he has amazing powers of telepathy.

How does he do it?

He throws out a lot of information, then closely watches for a response, keying off of positive responses from the subject. As he gets more and more subvocal, body-language, and affirmations from his subject, he closes in on information that only the subject knows.

You can do the same thing in an interview. When asked a question, tell a story about how you solved a problem (which is why you're there) While telling it, listen closely for clues that you have touched on something of value. If you hear them, next time you tell a story keep close to that sore spot. Usually over a period of six or seven questions you can hone in on what the problem is while reassuring the interviewer with stories that you know how to help them.


The key is to get them talking instead of you. That does help find what their pain points are, so you can address them as the mentalist above noted, but you also find out what they are really looking for so see if you're still interested.

Here's an example of what I mean. Suppose you're a Java/Struts developer historically, but have some serious Ruby on Rails experience recently. You come across a job listing for a RoR developer, with all the right RoR talk in the description with "experience with Java/Struts a plus" at the bottom.

You go into the interview and just nail all the RoR questions. They are happy, you're happy, and they ask you if you have any questions, so you ask them to describe their project. As you play mentalist you discover that they really are using Java 1.4 and Struts 1.38 and want someone to come on and maintain that old code while hoping that some day management will let them rewrite the whole app in RoR. They want you there in case management agrees and to "train" the others in RoR just in case it happens.

They extend you a job offer. You decline and go after a real RoR opportunity with a hot startup. Life is good.


This also highlights the point that it is important as an employer to write good job descriptions as well. I find this point often neglected.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: