Ask HN: How do you convince someone that you are the creator of an app?

https://news.ycombinator.com/item?id=882758

by boggles • 17 years ago

5 8 17 years ago

news.ycombinator.com

I have an interview where I need to talk about an app I created. The app is closed source and doesn't identify me anywhere on screen. How do you persuade someone that you're the creator in that case?

nostrademons• 17 years ago

If they're skeptical (and you haven't given them reason to be skeptical), you probably don't want to work for them anyway. There needs to be an atmosphere of trust-by-default; if you don't have that at the interview stage, what's the job going to be like?

scorpioxy• 17 years ago

I agree. I would hesitate to work with such a company.

On the other hand, usually it's enough when you talk about design decisions or details that only the author would know.

If the person doing the interview is a technical person, then he should already know how to distinguish real from BS. Otherwise, run...

DanielStraight• 17 years ago

Right. Why are you assuming they won't believe you?

cd342• 17 years ago

There is no trust by default. You've handed me a piece of paper (your resume), that you've authored, that puts you in the best possible light, with facts that I cannot verify independently without your permission. Where have you earned trust?

99% of the people I interview have lied on their resume. When I accept an interview, it is because your resume has stood out. That doesn't mean I have put my guard down and instantly trust you. Everything you do at the point where the interview is accepted is looked at. Appearance, handshake, attitude, demeanor, etc.

We advertised a position in May and received 41 resumes. Of those, four were reasonable candidates. I personally called all 41. The 37 were told that their resume didn't meet our requirements, thank you for applying. Resumes are rarely kept on file for later hiring. When you hear that, it is a friendly way of getting you off the phone. Employers lie too.

Of the four, only one seemed like a reasonable match. During the interview, despite his claims of his coding experience, he wasn't a problem solver. Could he have really worked 4 years for a competitor without being able to solve a problem I had posed? As it turns out, he had just received a promotion but was using that title to represent himself.

A true illustration of the Peter Principle.

Was I wrong to be skeptical? He didn't get the job.

My competitor knew he was laying off people. He gave them promotions to make them more marketable when they applied for other jobs. He didn't do them a favor.

An interview is a date. I have to decide in that two hour period whether you're the right candidate. A decision costs me roughly 90 days of your salary plus a reduction in someone's efficiency while you are brought up to speed. This carries a cost as well.

You earn trust. You do this by answering honestly during the interview without giving me those canned answers that are the double edged sword. You don't embellish things on the resume by extending dates a little bit to cover up for a period of unemployment. The ONLY piece of data I can get from a previous employer are your dates of employment. I can't get salary history or even whether the company would rehire you. Anything else that company gives me is illegal. Unless you've given me permission, I cannot talk to your coworkers or previous managers. Handing me your Aunt's name as a reference is worthless unless she writes code or has seen you in a work environment.

So, as an employer, what have you set forth other than handed me a piece of paper and a cover letter expressing interest in a position that should make me trust you?

If I pursued you, that's a different matter, but then the original author wouldn't have posed his question.

melvinram• 17 years ago

During the interview, simply talk about the real challenges you had with making it, the decisions you made as you went along and why you built it in the first place. These could probably be faked but I'm sure most people would be able to pick out a fake and they'll probably be able to tell that you're credible.

raquo• 17 years ago

Tell them the app's most obscure bugs

fookyong• 17 years ago

is this something you own or something you built for a client?

I'm just wondering why you can't upload a secret "bio" page on the app somewhere that only you know the url to...

cd342• 17 years ago

Years ago I interviewed an employee that wrote "Expert MySQL and PHP Coder" on his resume. He submitted code that was very well written, commented, no unit tests, but, the code was relatively clean. He showed me his web site where it was running and had substantial evidence in his favor that he was the author.

During his first programming assignment, his code quality was horrendous -- certainly not anything like the code submitted. He had passed two Brainbench tests that we had asked for and had other Brainbench test results that suggested his coding issues may have been a result of being immersed into a large codebase. Perhaps he wasn't used to our environment, coding style or method of doing things. Programming was a small portion of his job and he made it through his 90 day probation.

After the second project, his code quality hadn't improved. I approached him and was told: "I didn't write that code, I maintain that code." His rational for expert: "Compared to my friends, I am an expert."

He beat me. He had a friend help him on the Brainbench tests, he presented code that wasn't his and he lied on his resume.

If you claim you wrote code and there is no way to independently verify it, I'm going to err on the side of caution. Other programmers that we've interviewed now take a pseudocode test. I don't care if you don't know Python because language is just syntax. If you know programming logic, you can become proficient in a different language relatively quickly. This is much easier in a pairs environment.

You will have a hard time convincing someone you wrote any code where your name isn't present on it. If they are hiring you because you wrote the app, then they have some idea. If they are hiring you and you are presenting that application as a code sample, you need to bring a piece of the code that solves some problem in a unique way and be prepared to discuss why that code segment is coded in that manner. Were there other ways you could have solved that problem? Why did you choose that method? If the code belongs to your previous/current employer, don't even think about bringing it.

Stand out against the crowd by being prepared. Bring a few copies of that code snippet printed on clean, bright white paper - in black and white. Don't bring me a sample using your editors language color scheme. Have a copy of some function or class that calls that piece of code handy as well. Bonus credit for bringing a copy of the unit tests for that function/class. Keep it light. I'm going to look at no more than two or three pages and one of the other programmers will probably glance over it as well. There is no time to study code during an interview, so, it needs to be a small sample.

As an employer, especially right now, I can pick and choose. Why are you the best person for the job? Why is your code superior to someone else's? How well can you debug code and solve problems?

That is what we look for. I don't care if you don't know a particular language -- I want to make sure you have the ability to solve problems without needing someone coaching you.

As a sidenote: When asked when you are willing to start, if you are currently employed, your answer is two weeks. If you tell me you can start work Monday, I'm going to believe that you have no respect for your job and aren't willing to give that company the respect they deserve by closing out your existing position. If you don't respect them, why would you respect me? If the company offers to throw a bonus to get you to start in a week, your answer is: It wouldn't be fair to my current employer as I need to close out tasks, finish some documentation/train the new person, etc.

Everything you say and do during an interview is going to be analyzed. During the last two interviews, I've taken both to a pizza place during lunch to 'take them out of the stressful office.' This is still a test. Everything, and I mean everything you do during that interview is going to be analyzed. Don't lie. When the question is asked about your flaws, don't give that same old answer that you're a perfectionist and sometimes you spend too much time working on a piece of code. We've heard that too many times. When asked why you are leaving your current position, be honest, but, don't disrespect your current position. I might know someone there.

All I want to know is, can you do the job well? Are you a better candidate than the others? Are you going to fit in with the existing team? Can you work unsupervised? Are you a leader or follower? Are you going to make my job easier? Are you going to be honest? When something breaks, are you going to try to lie about the problem or own up to it? I've written code for 25 years, I know there are bugs and they can crop up. If you made a mistake, am I going to get an honest answer when you're under intense pressure to get a solution or are you going to shift the blame? Extra credit here if you can solve the problem. Don't ever break something and fix it and not tell me.

I am willing to overlook some things. Lie to me, disrespect your current position, complain that your existing boss wouldn't give you a raise because of this or that and your resume hits the shredder the instant my office door closes.

Ask HN: How do you convince someone that you are the creator of an app?

Related Stories